Forcing brute force on an object... how to?

[Deflaminis]

I can't seem to find the thread now, but I remember from a while back there was a way to force brute force on an object while the rest of the scene is using say IR/LC. I want to say it was in the material settings but for the life of me I can't remember it. (For example, letting trees render with BF instead of the blotch problems that can come from millions of little leaves and IR/LC.) I am aware I could render it in passes but I do remember there was a 1 pass solution that I want to practice in case I ever need it.

Can someone please refresh my memory? No deadline or anything, just curiosity.

[zeronove]

Maybe is the use irradiance map checkbox inside the vraymtl option rollout...

[Deflaminis]

That would make a lot of sense, thank you!

Can anyone confirm?

[super gnu]

yep thats it. one of my favourite "hidden" features in vray, as you can use it for small animated elements in your scene without comping. im not sure if its useful for trees, i find that you cant see any blotchiness in the imap on a tree, as its so insanely busy with detail anyway.. in fact i usually set the object subdiv multiplier lower on my trees and plants to speed up the imap calc.

[Deflaminis]

I see. Thanks to both of your for confirmation.

I've had some issues getting say flyover animations rendering easily with hundreds of trees and leaves down there. Many times I just turn off GI and render them separately with an ambient light but I was thinking BF might do a decent job at them from a high distance. I like the idea of using the object subdiv multiplier but maybe I'm doing something else wrong because with animated trees from a distance I always seem to have to increase them to reduce the weird flicker in animations rather than decrease. I've definitely nailed it down as an IRmap problem but so far my attempts to fix it without rendering things separately over the years have been less than satisfying. Found myself a bit of downtime and figured I'd look into it.

Thanks again to you both for the help.

[super gnu]

if you are doing tlythrough animations with a precalculated imap, you shouldnt have any flicker in your gi on any objects..
ive done big flyovers of forests etc hundreds of times, and the culprit for distant trees flickering is always AA.. you need a crapload of aa (and a corresponding low noise threshold) to reduce the shimmer on distant trees, and the most important thing is to have the AA min-rate ABOVE 1. usually 2 is fine. otherwise the aa sampler seems to miss those tiny subpixel leaves entirely sometimes.

[Deflaminis]

I've been noticing the min AA rate being above 1 to really help in a lot of areas. This is some solid advice and thanks for it.

I guess I still have some problems getting my precalc IRmaps to not take so long in rendering. For most commercials or non-tree flythroughs I've gotten away with optimizing single frame and getting decent results without precalc but with Vray3 that's starting to not work out. I think that's because with 2 I was somehow using it wrong to get the right results and the particular way I was messing with it isn't the same in vray3.

Most notably back then I could get away with 6 or 7 as max subdivs for my AA sampler but now with the DOF and motion blur attached to the AA rate my old workflow doesn't work the same nor render as quickly. Despite all that I do like vray3 more, but it took me a good six months to really understand what I wasn't understanding. I've learned a lot more about sampling and process with 3 to the point where I'm quite confident, but one thing that always evades me is getting that interp value from quadrupling my render times. Maybe it's the nature of the beast plus unreasonable deadline times in the past. I guess this is why I've been looking for a way around the precalc on trees by forcing brute force.

I wonder, the default interp for the irmap is something like 5... think that's too much? I've tried lower but still get some animated splotchiness. Thanks again for all the help!

[super gnu]

ive never managed to get clean animation with perframe imaps.. always have some shimmering. im not sure how youve managed to get longer rendertimes using the precalc method.. you need lower imap settings and you only need to calculate it for every 20th frame or so... so it should always be *craploads* faster than perframe imaps...

wrt the interpolation on the imap, i rarely touch it.. but the default is actually 20 , not 5. reducing this speeds things (final rendering, not precalc) up a bit, and also gives a sharper, but more blotchy imap. you have to increase the subdivs to compensate. i usually only reduce it for stills where i can use very high subdivs and want things to look sharper, or when using imap "animation mode" which i very very rarely do, as it never really works very well, takes ages to render (reducing the interp samples is recommended here) compared to a precalced imap plus bf for moving objects, or just bf/lc, for scenes where everything is moving.

[Deflaminis]

This is interesting... I clearly *don't* fully get the irmap precalc then. When you view your GI element in the frame buffer, does it look splotchy before you precalc? (Meaning, a quick single frame render) I've typically tried to get the splotch out on single frame before I precalc, and maybe that's why mine take so much longer. I was also generating it for every frame, thinking that was typical. I guess I was way off.

If you render every 20th frame and the interp is at say 20, does that mean it takes 400 3dsmax frames for it to be able to jive? Sorry for all the questions, I appreciate your time.

I'll try this out this weekend... thanks again for all your help.

[super gnu]

are you using flythrough mode or animation mode? you need to use flythrough mode, and yes, i always get a single frame clean first... doesnt matter if it takes a while, for a 250 frame shot youre doing a maximum of 15 odd frames of gi calc, and also, in flythrough mode, any geometry that has had its gi calculated in an earlier frame, (i.e the overlap in whats visible between the frames) goes really fast in the subsequent frame calc.. so it gets faster as it progresses usually.

the only requirement for the spacing of your gi calc frames is that there is -some- overlap in whats visible between frames, otherwise not all your geometry will be covered in gi when you render all the frames. therefore, the further/ faster the camera moves, the more frames of gi calc you need for a given length of animation. you have to use your judgement to get the least calculating without missing any slices of model.

i suggest you look at the guide on renering flythroughs in the vray help.. it explains step by step how to do it.

if you ar using animation mode, or doing a flythrough with a calc every frame, its no wonder youve got calc time issues and blotchiness.


if you want a step by step i can quickly write something up tomorrow, but this technique has been the standard for flythrough animations on vray since the year 0...

[Deflaminis]

Had to step away for a couple days.

Yup... I went back and checked some old scenes.. was using animation mode with flythrough mode and "use camera path". Went that route based on the vray tuts... for example this one: http://help.chaosgroup.com/vray/help...ials_anim2.htm I think my problem might have been using too many frames for interpolation, as you were right the default was 20. I set it to 5 and it's great. I think in the past I must have set this too high or used another setting that was just wrong. Starting fresh with reset settings and it was faster and easier than ever.

Also, unchecking "use irrandiance map" on the material does seem to force brute force, so I'm doubly grateful. I was able to check it in the irmap viewer and it was black, but it's getting gi so I guess that means it's working.

[super gnu]

hm i still think we are on a different page here. if you are doing a scene with lots of moving objects then this is the correct workflow (although bf/lc is far better and less hassle if you have the farm for it)

i was under the impression that you were doing flythrough animation, where only the camera moves (or only small elements of the scene move - this is where the "use imap" checkbox comes in handy)

if this is the case, you should not use animation mode at all.. you need to use flythrough mode for the lightcache, and "multiframe incremental" for the imap.

basically following this tut:

http://help.chaosgroup.com/vray/help...ials_imap2.htm

although i usually skip all the stuff about sample size for the lightcache, leave it at almost default.. whack up the subdivs to 2-3000 and set it on flythrough.. seems to work fine.. world space coords are not very practical if your doing a 50km long landscape.

[Deflaminis]

Edit: I went back and read my initial post, I did say flyovers but there are usually moving cars, trees blowing in the wind, some water or something. I should have mentioned it. I opened the link you have here... yes that process is a bit different because of the moving objects.

Regardless the process did work a lot better... I'm getting 1920x1080 frames of a simple character swinging a hammer with motion blur in less than 5 minutes (after precalc) with no flicker whatsoever... super happy about it. (Haven't tested trees yet.) The frame without the precalc GI takes only a tiny bit less time (about 20 seconds per frame) but has some chatter so this really only added a fraction of render time and totally worked out any blotch issues.

I've played with multiframe incremental in the past but found it faster to generate per frame gi than precalc with it. Maybe it's the same situation and I need to re-evaluate.

Thanks again, this thread was very helpful to me, appreciate it.

[Lupaz]

yep thats it. one of my favourite "hidden" features in vray, as you can use it for small animated elements in your scene without comping.

I'm curious why you say "small animated elements" and not just "animated elements".
It's just that this option is new to me and it seems to be very...powerful, no?

[super gnu]

its because the static elements (with the precomputed imap on them) will not be affected by the moving objects. this means no gi contact shadows under the animated objects (apart from at the point in the scene where they were when you calculated the imap - i usually hide those elements while doing the imap calc..), no colour bleed.. imagine using it on a door to a darkened room, animated opening, with a light behind. the door would have correct gi, but the room would have unchanging gi, either bright or dark depending on the position of the door when you calculated the imap.

same goes for a brightly coloured object moving into the sun, youd expect reflected light and colour bleed to appear on the surroundings but it wouldnt happen.

i use it generally for people, cars etc on large landscapes. works perfectly.

you can fake the gi contact shadow under the feet/car using vray dirt maps on the materials below, set to be affected only by the animated object.

still very powerful, but not a fix all..