I am fighting with a simple animation for VR, scene is fixed, camera is the only object moving in a straight path.
I am using the spherical camera with frames each eye of 2048x1024. Total dimension of the renderings for both eyes (TopBottom) are 2048x2048 . Gear VR has a hardware limit to 2K in vertical resolution so I cant increase resolution for better quality. Single outputs looks great, but when I stitch them together for the animations it’s all flickering.
Vray settings are set to IR (Multiframe Incremental) +LC (flythrough).
Let me know if you have any suggestion.
I read all the previous post in the forum but got more confused since some suggest to calculate LC per each frame instead of flythrough, some suggest to use Brutte Force for the primary engine and LC for the secondary.
my normal workflow in these situations (the best we can have - only cam, no object moving)…
primary: IrrMap, mode single frame!, use camera path “on”
secondoary: Brute froce with depth of 8 - rest default
…no you start render, and only one file will be saved for the IrrMap (per eye!?)
…when final render starts, stop it…
…and set Irrmap to “from file” - the only one file
Thats all!
If you wish to use Lightcache make it like Irrmap..single frame mode - use camera path - result one LC Map.
Must work perfect too.
And no worry when the camera path results looks funny, they have all informations of all the things in the scene at any time.
Hope it will help..
First of all you have to switch your IRR map to Medium - Animation preset to avoid visible splotches. and then I would really do it like the official tutorial suggests:
You can re-use both the Ligth Cache and IRR map for the second eye render as well.
to use BF as secondary was my choice from beginn.
Maybe the “one Irrmap-managing” was the first reason for me!?
To use BF as primary, makes no sense in this case - needs much more rendertime before the noise is less enough.
Did you test the Irrmap/BF way? No flickering anymore?!
btw. to use another Irrmap-preset makes no sense for me. But to use higher values could be a very good idea.
When you´ve some visible splotches, than you can increase subdivs to 100 or more, or preset to high, or both. The longer prepass time only happens once - in camera path mode - and then you can forget it…
TheLooopCGI, the official tutorial is the one I followed in since the beginning. Very bad results, I don’t know why…
Komposer, I tried using BF as a primary engine since i read that answer before in a lot of other topics, it was slower, yes. But flickering disappeared! Big improvement.
Now, I don’t have the time to test it with BF as a secondary engine due to the deadline, but will try that for sure in the future. I am not sure I quite understood if the flickering is caused by the primary or secondary engine. Which the one that has the most influence? It would be easy to choose which one should switch to BF then.
I am in the middle of rendering interior animations and BF+flythroughLC with Denoiser is way faster than Good quality precalculated IM.
and I think OP has flickering of the ceilling lighting in mind (although GI looks splothy as well).
if its lights - just clamp the color values as much as possible (sub pixel mapping and clamping to 1 if you don’t need more, or go easy on the power of this light or light material visible)
I am using an external rendering farm, and it doesn’t allow me to add render elements like the Denoiser. It am stuck whith what I have.
And I thought it could be done only for still images though…can you apply the denoiser automatically to all the frames?
Did a test, still flickering. The only way to avoid it for a complex interior scene is to calculate the GI for each of the points of the scene! Brute force unfortunately with crazy times. Cant have everything in this life i guess
