Pause while moving camera

V-Ray V-Ray for Rhino Requests
1

Here is something that I find super annoying when working with the Interactive Renderer in Vray for Rhino. If you have a scene that is a bit heavier, the viewport becomes basically unmoveable, because the Rhino Viewport always seems to wait for the Vray Viewport to catch up first. That means the update speed of both the Rhino Viewport and the Vray Viewport becomes however long it takes to start rendering the scene again.
So if I have a scene that takes a long time like in this file I am just working on it means both viewports are at like 1fps.

Every time I want to move the camera I have to stop the Interactive Renderer, move the camera and then start again.

Somehow there needs to be a way to decouple this process. Like leave the Rhino Viewport as normal and only update the interactive renderer once I have stopped moving. Usually you would have a timeout function where it waits for say 100ms before actually changing something and the function gets reset every time you move the camera.

Alternatively we could have a button to pause the linking of the viewport and render camera until I press unpause, but not stop, because resuming it then starts loading everything again. Even better of course would be if it could auto-pause as soon as I move the camera. Of course this should be an option, as it would really help with heavy scenes, but is not needed for very light scenes.

Hope that makes sense.

2

I wish it was that simple…
As far as remember, there were several attempts to fix the issue and they were all fruitless.
In short - yes, there is a delay and it is not caused by Rhino awaiting V-Ray to restart. The raytracer works on a completely different thread.

Last time I measured the timing, the total delay was between 30 and 100 ms. This is the time we keep the main thread busy, and hence Rhino is blocked.
I was not able to achieve 1 fps by a any long shot. Apparently there is something else in the picture.

There are ~15-20ms delay we cannot erase by any means. That is because of the event watcher infrastructure and the virtual call Rhino makes to notify us. It always happens on the main thread.
the rest of the timing was no more than 50-60 ms with sporadic spikes, most of them out of our control (Rhino API calls or Platform SDK calls)

After all we determined that it is not worthy enough to pursuit further optimizations.

the 100ms throttling you propose won’t work, because the timer callback will hit on the main thread of Rhino. it will basically delay the things further, because the system will be busy calling the timer callback, and Rhino will wait for that call to complete.
I’ll rather choose frames skipping approach, since that is what we’re gonna use for the Grasshopper animation preview.
I’m not sure whether that will work at all either.

Meanwhile you can:
- change the interactivity level
- use vrayVPRSettings command to reduce the screen resolution and run V-Ray interactive display mode

I’ll be happy to take a look at that 1fps scene then will be happy to revisit the issue

3

Very interesting. Thank you!

I recorded a video showing the performance. I will send the video as well as the file I am working on using the uploader. The recording is at 30fps and you can see the rhino viewport move extremely slowly at probably just under 1fps. The interactive renderer updates even slower.

Maybe we can find out what is going on. There are a lot of instances of .vrmeshes in Blocks (around 60.000 of them) to form a pattern. But the Vray Proxy meshes are super simple. Using scattering with something like plants would be easily as many instances, but with much more detailed Proxy Meshes.

In the 2nd video I recorded where I use a pattern inside a .vrscene with display set to bounding box, so the Rhino Viewport performance is good, I also open the Performance for the GPU in the Task Manager. Maybe it helps. It gets close to filling all GPU memory, but not critical yet.

The PC I am using is really fast otherwise: i9-11900K, 32GB Ram, Nvidia RTX3070

4

I uploaded the files using the uploader and the same ticket I had with Natalia. Submission ID# NB5S-D7J1​

When you open the scene you will also see everything around this bug, as its the same file: https://forums.chaos.com/forum/v-ray…-on-every-open

You probably have to re-link the Rhino Blocks and the V-Ray Proxy Meshes.

5

Looks like you’re rendering on the GPU. It might be a stupid question, but do you have a separate GPU for the display only, that does not take part in the rendering ?
Second question: are you aware your scene is far away from the origin ? This may result into raytrace errors
Third: I get 1 fps even without rendering at all. I’ll try without RDP in the next few days
Fourth: your geometry is veeery heavy. The instancing is fast, but not instant. the OpenGL driver need to process every vertex of every instance of every triangle anyway, and then run that thru the pixel shader. Some stuff is cached during the process and heavily parallelized, but it is still per-instance processing.
Have you tried V-Ray Enmesh, this mosaics look like a perfect candidate
Fifth: You can lower down the preview mode of the proxies. Currently it is proxy-preview. That is lightweight for a particular instance (no more than 10000 faces per .vrmesh file), but you have millions of them. That is a lot of triangles. I’d rather use bounding box mode.

6

Thanks for all the suggestions.

No, I have one Nvidia RTX3070 and I have 2 4K Monitors attached to it.

True. Not sure why that was, but I’ll move everything to the center.

Not for me. When V-Ray Interactive is not running I get more like 5fps. Definitely usable to navigate, whereas with Interactive Renderer running its almost impossible to move around, as you can see in the videos.

Yes, I am aware it is heavy, but the individual VRMeshes each have maybe 10 to 100 vertices. Nothing like say scattering a whole forest, where I might have 60.000 trees. Compared to that the scene is not that heavy.

We have our own software, built in vvvv, where we create the patterns and there the instances are all rendered at 60fps even while transforming them all in realtime. So it’s not like its not possible to be fast. Then we export them as instances blocks in a Rhino .3dm file.

But I am aware that Rhino is also not very good with things like that and is probably a big part in why it is so slow.

I have not tried Enmesh and will check it out. We have to control the transformation of each and every cell though and use different ones. At first sight seems to me like Enmesh is more for duplicating the same mesh and some options for arrangement. It might be interesting if we could somehow write our own Enmesh engine, where we can literally control placement of each cell in the grid and its transformation, because that is the point. But I will check it out for sure.

Funnily I could not get that to work. I set the preview mode of the V-Ray proxies in the blocks to bounding box, but in the parent file they are still shown using the default preview. I will try again.​​​

7

Just checked again, and this is definitely not working. You can see here how I cannot change the preview mode for the Proxy Meshes if they are instanced in Rhino Blocks it seems. Placeit | Create Amazing Mockups, Logos, Videos & Designs

image.png
image.png835×599 427 KB
​
You can see it here as well. The cells marked are the OH6-Pos Proxy Meshes (if I right-click and chose Select Objects in Scene, they get highlighted). If I change the Preview Type nothing at all happens and the preview is always the same. I will try and see if I can change it inside the linked block file.

8

Yeah, there is something strange going on with the V-Ray Proxies. I will post a separate Bug report.

9

Sorry, another quick question regarding Enmesh. Looks to me like Enmesh is using a different type of instancing somehow or I would say “proper” instancing, where the geometry being instanced exists only once in the memory.

Then my question would be: Why is normal instancing of .vrmeshes not using the same process internally? How is it different? Is it only not using that better process, because the better process is not compatible with GPU (yet)?

I find it funny that you call our geometry veery heavy, but when talking about Enmesh it is talked about how it is possible to render what would be billions of vertices with ease. So maybe it’s heavy for what we are doing with it, but its still super light compared to Enmesh stuff :wink:

Last question: Where can I find some info on Enmesh or Documentation? When I google search for “Vray Enmesh” all I can find is stuff from the forum and some Youtube videos. Nothing on the normal Chaos Website, or can I just not find it?

10

Hi,

You can see it here as well. The cells marked are the OH6-Pos Proxy Meshes (if I right-click and chose Select Objects in Scene, they get highlighted). If I change the Preview Type nothing at all happens…
Let me explain this. Your file is containing linked blocks. The proxy you’re editing is actually a referenced object from another file. This means it is intrinsically read-only for your master file. You shall not change referenced objects. According to Rhino rules changing a reference object will make a local copy of the object into the master file. This means that the same object will be serialized in two files - the master file and the linked file. When you open the master file again, you will get 2 objects - one dummy in the master and one real in the linked. Why dummy ? becase we cannot edit read-only geometry and assign the new tag to it. You can verity that with a Rhino material - editing a material will make a local copy, next time you load the master file, you will get the material twice - once from the external reference file, and once from the master file. When I implemented linked blocks and worksessions in V-Ray for Rhino I had to comply with that Rhino rule and expand the definition along to V-Ray objects.
This is mostly harmful for objects like fur and clipper, etc. since they are “assignables”. However proxies, decals and infinite planes are intrinsically connected to its viewport representation. For example you cannot drag&drop a proxy from AE to some geometry in Rhino. You can do that with Fur, Scatter and alike.
I guess that is the reason why you get all those dummy copies in your project. Either that, or you’re using that buggy version of Rhino, before McNeel fix the block objects deserialization.

If you want to see the difference, you must make the change in the linked .3dm, and reopen the master. No other “correct” way.

Now the real topic.
On my machine this beast runs with ~11 fps. When V-Ray Interactive is running it slows down to ~3-4 fps. That timing is after I made some changes and it added one 1fps to the framerate. Not really a game changer, but still worthy.
If you change the preview mode of the proxies in the linked files - this will significantly improve the viewport performance. I was able to reach >15 fps with pure Rhino, and ~8fps when interactive is running

Rendering performance.
This will not improve the viewport, but will improve the rendering speed.
I took the transformation matrices of all instanced linked blocks and wrote them in a file, then made a simple GH Script to read the file and produce Translation, Rotation and Scaling matrices. Plugged that into a V-Ray instancer component, and got more or less the same thing, and then all the way down to a RenderInProject component. Hiding all the source geometry in Rhino will make render the 5 instancers from GH. That is quite fast. It starts really quick and renders a bit faster. V-Ray has even faster instancers that are used in Houdini, but I didn’t try them here. They are instant

Bottomline:
there are two things to note here
1. Improve the viweport handling by 1fps
2. Improve the preview of the instancer component in GH

On the other questions:

Why is normal instancing of .vrmesh’es not using the same process internally It is in V-Ray. Every external resource - .vrmesh, texture, or whatever lives only once in the memory manager of the renderer. It is most likely the same in Rhino. The problem here is not memory, it is the GPU taking too long to draw. Probably there are some inefficiencies in the Rhino’s OpenGL pipeline

…but when talking about Enmesh it is talked about how it is possible to render what would be billions of vertices with ease… That is in V-Ray ! V-Ray is cutting a lot of corners with enmesh. It is render-time only effect. Rhino is not rendering it in anyway. We don’t show a viewport preview. It is not rendering billions of “real” vertices, because of some clever optimizations.

Last question: Where can I find some info on Enmesh or Documentation?
V-Ray for Rhino

Probably the Enmesh suggestion I gave was not a good idea. If you ask me now I’d chose GH-generated rendered geometry. I’ll make improvements to the instancer preview options, so that it is event faster

11

Thanks for taking the time to explain this! I think we will not go for linked blocks as there are too many difficulties in working with them and not many benefits in our case.

From what I remember in the McNeel forum the devs were saying that they don’t actually use instancing in the Rhino viewport. Even things like the Grid lines in the viewport are not instanced. That’s why making the grid really large with many subdivisions can really slow things down. I think the same is true for instancing geometries, where in the viewport they don’t actually do instancing, but just transform the block instance geometry.

At the speed they are going at McNeel it will take another 10 years before they tackle that.

We tried that a while ago and because it was so super slow we went the route of integrating it in vvvv in the first place, but I will try again with V-Ray components.

12

From what I remember in the McNeel forum the devs were saying that they don’t actually use instancing in the Rhino viewport.
Now I vaguely recall a talk with Pemek from Rhino Nature explaining basically the same thing. This was more or less the reason he switched to points instead of BBoxes for the instances. There is Point preview for proxies as well, but it draws 3 more lines. If that is too heavy as well, I can think of removing the lines

We tried that a while ago and because it was so super slow
yup indeed. I hit the same wall with my test, 2 posts above. Reading 56K matrices from file and converting them to transforms was terribly slow in GH, so I wrote a script in C# to do it faster. That script takes <1s for 10K matrices. I strongly suggest you do the same by identifying the slowest part first, and then tackle it