Fly-through and DE

[rikou]

Hi,
I have to do some animation (certainly mainly fly through)and I was thinking about technical details.
I'm a newbie (I do only stills, not animation !) and I don't know if I'm right or not :
Is there advantage to pre calc' my IR every 5,10 or 20th frame without DE and then, use it when I will render ?
If not, is there anything to know about using DE during ma pre calc' ?

Thanks in advance

[Zdravko.Keremidchiev]

What do you mean by DE?
Here you can find a tutorial on how to render walk through animations with V-Ray: http://docs.chaosgroup.com/display/V...ugh+Animation#
Generally the advantage of pre-calculating the GI maps comes from the fact that you don't have to calculate the light map of every frame.

[super gnu]

DE =detail enhancement.

for me its not a very useful feature. ive tried loads of times, but i can always see the boundary between the DE and the imap. also i never get it looking very clean with a reasonable rendertime.

wrt using it for flythroughs, i wouldnt bother.

use good old imap. use oversized settings (min rate of -5 or -4, max rate of 0, or even +1 for example, very high hsphs subdivs and a lower interp.samples than default.)

this way you will get a really sharp, but massive sized, and slow to calculate imap, but fast rendering frmaes with no gi calcs to worry about.

beauty of doing "multiframe incremental" for flythroughs is that as you note, you only need to calculate every 10-25th frame for the lighting calc, plus, any areas already covered in previous frames will calculate faster than you expect.

for me, this means i can swallow rather large imap calc times, since for a 250 frame sequence, you only need 12-25 imap frames calculating. include the fact u can use DR to speed up the calc.. and i definitely prefer to use silly-detailed imaps than fanny around with DE.

its my preffered method for flythroughs, until brute force/RT becomes really stupidly fast.

[rikou]

Thanks for your advices !
Yes, in fact, I'm sure that I will use a precal' GI maps... I use Vray 2.50.01, I'll updating really soon but too late for this animation
my rendertime is too big with BF/LC .... too bad !
Anyway, my precal' will not be calculating with DE and I was thinking to use DE (yes, DE =detail enhancement) just for my final render... I was thinking that it could a good way to refine my render


But perhaps it's not useful if I try to do like super gnu... When you said "very high hsphs subd & lower inter.samples", 200/20 ? something like that or more ?? what do you think about ?

[super gnu]

well if its an exterior with lots of detail, you can keep the subdivs quite low, say 100 and drop the interp samples to 10 or so.. if you start to see blotches, increase subdivs to increase quality or increase interp to blur out noise. more interp will increase final frame rendertime, but more subdivs will only affect imap calc time.

if its an interior or something with lots of clean surfaces, your stuck with big subdiv numbers.. most extreme example i can remember was for an animation i did for the saatchi gallery. diffuse lit white walls, had to be pristine. i needed about 400 subdivs for that.. took ages to do the imap calcs. iirc i used interp samples of 10 for that too.

wrt the max rate, i never saw the point of positive numbers (i.e more than one sample per pixel) until i did a job where i used self illuminated planes for streetlights on a massive masterplan. the ones in the distance were way smaller than a pixel, and to get them reliably emitting light into the scene i needed a max rate of +1


that was a classic example of this method. imap took well over 2 hrs a frame to calculate, on multiple machines, but it was a huge night illuminated park and cityscape, with thousands of tiny lightsources, all done with selfillum geometry. in the end, no direct lighting, all stored in one multi gigabyte super sharp imap. final render frames took a couple of minutes to render.

regarding detail enhancement, IIRC, you need to calculate the imap with it enabled, as it modifies the imap calculations to leave "space" for the DE in the corners. adding it onto a normal imap will give wierd results. might wanna double check but i think that the case.

[rikou]

Thanks, I'll give a try

[Oleg_Budeanu]

I've recently done an animation where it was a lot of GI light and very small amount of drect light (thank you workflow!) , so what helped me is calculating irrmap and lightcache in use camera path mode and after that controlling just the interpolation amount. But be careful with that , if in static image 50 interpolation is fine , than using the same amount in saved "camera path" irradiance map wil lead to really high rendertime as it will interpolate several frames with this amount , multiplying it. So i used about 20 - it was perfectly fine. Also i really do not recommend calculating irrmap in that low resolution. If that will work for exteriors - you do not need GI details there as you have mainly direct lighting , in interiors situation can be really different. In my situation i needed to calculate min -2 max 1 to get rid of blotches and that kind of stuff. Anyway was faster than using BF.

[rikou]

Thanks, I will see if I have ti use camera path mode...
I have as much exterior as interior... It start outside to go inside in fact....
I have to deal with quite a lot of GI details in differents inside spaces.

[rikou]

Is there any advantage to "store direct light" in LC if I have 10/15 vraylight in a room ?
I never use it during an animation.

[vlado]

Is there any advantage to "store direct light" in LC if I have 10/15 vraylight in a room ?

This option is enabled by default in newer builds and you should keep it this way. It gives a significant speed boost to GI calculations.

Best regards,
Vlado

[rikou]

Thanks,
Will I have to boost LC subdiv in this case ?

It will be a "traditional" walk-through, nothing fancy...
Anyway, long time since I did that, when I will calculate my IR, do I have to put my LC (calculated before for the entire animation) in secondary engine ?

[super gnu]

you need the LC in the secondary slot for doing the imap calc. when rendering, you can leave it out, unless you use "lightcache for glossy rays"

having said that, may as well leave it in, cos a) it doesnt take much ram and b) "lc for glossy rays" is great.

[rikou]

Thanks !!
And yes, I always use "lc for glossy rays" !
And of course, after thinking, it was a silly question !!
I never do animation (my last was 7/8 years ago !!), so I'm a bit confused

[rikou]

another question...
eg. my cam move slowly the first 300 frames, then move quickly 150 frames and move slowly again the next 300 frames... precal' my IR every 10th frame is ok for the slowly part but I need to precal every 5th frames just for the 150 "quickly" frames...
Is there a convenient way to avoid a precal' IR every 5th for the entire animation ?

[super gnu]

well id say every 10th frame is too much for a slow move.. you can tell by looking at one frame on part that is moving more quickly, then skip forwards frame by frame until there is say a 10 - 20% overlap in the geometry visible.. thatll be your nth frame number.

as you note, faster moving bits need a closer frame spacing.

if you are rendering the imap locally (with DR if you want) you can just calculate the first bit of the sequence with 10 or whatever for the nth frame, then with the imap still in ram, set the next set of frames going with the smaller nth frame number.

you could also manually type in a frame list if you are submitting to backburner. im not sure if there is a syntax in the frames to render dialogue that lets you specify "render frames 0-200 @ every x nth frames, then render frame 200-300@ y nth frames.