The current scene I am working has a few displaced geometries with Max subdivision set to 8.
When Geometry generation is set to pre-tessellated the tie to first pixel and stop time is:
pre-tessellated:
2m 24s time to first pixel
43s to stop
If I set one of the hero geometry’s Geometry generation to On the fly (2D displacement, 16k map), it gets worse.
2m 40s time to first pixel
47s to stop
Are there settings to speed up the time to first pixel and decrease the time Vray takes to stop (release Maya UI)?
Also, after pressing the IPR button in VFB, it took like 30 seconds to become the “pause” state. It can be confusing to let users wonder if the IPR is started. I have to check the Output window to know Vray has started compiling the scene. And before the IPR button turns to “pause” state, I can’t cancel the render by either pressing “Esc” on keyboard or pressing the “stop” button in VFB.
Using on-the-fly is expected to be slower.
Choosing between the two methods is actually choosing between speed and memory consumption. Pre-tessellated renders faster, but requires more memory, while on-the-fly does the opposite. Btw, 2d displacement does *not* tessellate the geometry - it simply takes the geometry as is and relies on its UV coordinates to displace it with the given texture. This means that it won’t matter what method you use with 2D displacement - it will have no effect. We’ll grey out those settings in the future. 2D displacement is often chosen for better detail preservation.
Depending on the scene, it can take more or less time to compile the geometry and show the first pixels, so I can’t really say if there’s a way to optimize this by simply choosing one of the two methods.
With 2D displacement, you can tweak the Texture Resolution to get faster to the first pixels. Usually, you would need a value that is equal to the displacement texture resolution. For the purpose of faster look-dev you can try lowering it slightly to the point where the overall result doesn’t change much, but you gain a bit of speed to lookdev faster. Then bring it back up for the final rendering.
@yolov I tried “on-the-fly” based on your comment in another thread here. I am focusing on speeding up the time to the first pixel, not total render time.
The scene has multiple displaced geometries. One of those is set to using 2d displacement, others are using normal displacement.
Thanks for the tip on tweaking the texture resolution for 2d displacement.
I guess the “cache geometry plugins between renders” under Render settings>Overrides>Renderings doesn’t support displaced geometries or does it? I am hoping if it does, at least after the first time, the following render will start faster.
“Cache geometry” will cache the geometry plugins (V-Ray will know in advance some info about them on the next render), but any displacement and subdivision will have to be generated again each time. For the moment there’s no way around this. This doesn’t mean that “cache geometry” won’t help in your case, it will just help very, very little.
On the other hand, if your displacement textures are large, enabling “cache bitmaps” should help you out quite substantially on each subsequent render after the first one, you could give that a try.
@yolov Yes, I also have “cache bitmaps” on almost all the time. Are both “cache geometry” and “cache bitmaps” supported by subsequential IPRs after the first IPR render in 3.60.04? In the past, I noticed speed up of time to first pixel for subsequential regular render but not IPR. Just would like to confirm. If not supported, is it considered to be added in future builds?
@jasonhuang1115 Yes, both are supported as long as you’re only doing a local IPR and it’s set to be in-process (which is the default). What I mean is that this only works when everything runs in the same process. That’s why it won’t work for DR for example and that’s why it didn’t work with older V-Ray version where the IPR was out-of-process (an additional console used to open up). All 3.6 support that, 3.60.04 included.
So if you have this enabled, well every optimization I can think of is already in place.
@yolov thanks for the confirmation. I don’t recall if I use the out-of-process IPR again after the in-process one is introduced.
I guess the most efficient way might be to take the first hit of scene translation time to get the IPR started and keep it running while editing the scene. With frequent saves and more stable IPR, I can look-dev without lots of interruptions of waiting for the scene to be translated.
@yolov oh man, you can’t do that me… I can smell something really exciting cooking. I know you probably can’t comment on the timing, but hopefully it’s not too far after the Max Next next beta…
Is the official Beta different than the nightly ones that i have been testing? Does the new IPR include faster time to first pixel? I have not measured the difference between 3.6 and 4.0 beta in terms of time to first pixel yet.
Yes, the beta and the nightlies are the same. The more time goes by, the more different they get, but for the moment they are similar.
I’ll see if I can make some measurements for the IPR.
The current scene I am working on has about 200 2k UDIM tiles in png (didn’t convert them to .tx or tiled exr). It took about 4.5 min to start IPR where I see lots of messages in Maya console about debug, mipmap texture buffer etc. With caching bitmaps turned on, following IPR would start faster, which is good. Any setting I can tune to minimize the initial 4.5 min of waiting?
We’re doing some improvements to IPR for the next major version.