Maybe I’m doing something wrong with new settings, but I’ve been noticing that frames which render using pre-calculated GI are actually taking longer than when calculated per-frame. I’m certain that in the past, and intuitively, pre-calc GI frames were quite a bit faster. Has anyone else noticed this?
Now I’m reading that I shouldn’t be using this antiquated method, and should switch to BF/LC…
Yes, BF+LC is the preferable GI setup with the latest version of V-Ray. It’s the easier to set up and with the latest optimizations it is quite fast as well.
Thanks you. Either way, I’m still curious why the frames would take longer when they load an imap rather than creating their own. Any ideas?
Any help would be appreciated…
I get that BF+LC is the simpler, preferred method, but pre-calc is still a viable option, especially when time is an issue.
I agree. It would be great to still have a quick and dirty option. BF+LC for animation is really only valid when using render farms. I did this (https://www.youtube.com/watch?v=pm0HjzPdj8E) using IM+LC, rendering one HD frame in between 2 and 5 mins on a single workstation, and it wouldn’t be doable with BF+LC.
Don’t you think its strange that frames loading IMaps take as long or longer than calculating themselves? This is definitely a change from previous versions. Any idea why?
yeah ive also noticed that imap seems to be generally slower in all respects recently.. not done any actual scientific tests tho..
@BBB3 , by the way, really cool video
Nice video Bertrand. Really cool stuff going on in there.
I don’t think this is a new issue with the IR maps taking longer, I saw this with Vray 2.2 a while back.
Quite the contrary, you’d just trade splotches and lack of detail for noise.
I meant that the frames which load the IR map take longer than if they generated their own. Maybe I wasn’t explaining very well.
But I’m not sure it would be more pleasant…
Debatable.
I personally find the lack of per-pixel detail (and consequent lack of GI shadows) utterly disturbing, and 1990s looking to boot.
Yet, it doesn’t need to float my boat: personal taste be personal, first and foremost.
@vlado , Could you chime in on this?
Its really odd to me that the exact same frame, with the same settings (excluding GI) take the following times:
Frame calculating LC+IR each frame. 0:27:41
Frame only rendering, loading pre-calc’d GI. 0:56:08
These are on the same machine in our farm. Its part of an interior animation. When I started this post last month I was working on a similar project and had the same results. Its bizarre that a render needing only half the steps would take so much longer than one doing all the pre-calc. What changed? Any we we can have an option to switch back to the old way?
Caleb
Vlado, I hate to be a pest, but when a computational problem seems illogical, there has to be a good explanation. Could you shed some light on this?
i`ve had a similar thing when using gi calculated from a different vray version. recalculating the prepass seemed to work better ? although i`m still using 3.4 so..
ping!
[sorry. this is ten characters]
Same issue here, I’m finding I can render a single frame including the GI in about 25 mins but it’s taking 55 mins with precalc’d GI. I have been testing over the last few days with the new recommended preferred method mentioned here:
Message - Chaos Forums. but find render times spiralling out of control and too much flickering aa in the small details.
I can’t find a report about that into our system so if anyone has the opportunity to send us a production scene (not a test one) that replicates the issue it would be great.
I know that the following is already mentioned but I would like to inform you that the preferable GI approach in the latest version of V-Ray is Brutte Force + Ling Cache, except more accurate and reliable in many cases it could be also faster than Irradiance Map + Light Cache.