I’m running into a problem in getting my irradiance map to work for my animation. Right now I went to a simple scene with just a tea pot and a plane and a sunlight. What I did was pre calculate my Imap for every 10th from then compiled them. I went in and set my Mode to From file pointing back to my merged together Imap. So far I’m getting an error for using my Imap. It will say “error: This irrandiance map can only be used in animation mode”. Is there an animation mode button? Does it want my to set my Mode to Animation (rendering)? I’ve always used ‘from file’. But I’ve tried this on two different scenes and ran into it saying the same error. First scene was a full scene with building and trees. And the second scene is just the tea pot one. Any help is appreciated.
So the machines that work with this method of rendering Irradiance maps seem to have the setup of 3d max 2012-14.0 SP1 commercial and V-Ray Adv 2.10.01 .
Think I’ve seen this once before… when setting up the IR with Animation - Prepass, it’s only usable after that in Animation - Rendering mode. You can use multiframe incremental if you want to do other types of final rendering in the dropdown.
Deflaminis- Yeah we use the Animation (prepass) for when we send the file over the network to our render farm to get the lighting information back quicker than one machine processing it. We would process every 10 or more based on the animation. Bring back the lighting information and merge those together. But recently with the new update it doesnt seem to like this processs. I’ve made a video to show the processs used to get our animation renderings done. This same processs works with other machines here that haven’t been updated to the lastest version of Vray and using service pack 1 of max. But if anyone has a different work flow or just getting this process to work that would be great.
Please note that Animation (prepass) mode saves slightly different irradiance maps format, which can only be used with Animation (rendering) mode.
To proceed with the same workflow you will need to use Incremental add to current map or Multiframe incremental modes instead.
if what I’m reading is correct, the only way to use a 50 cpu renderfarm to calculate IR maps for a flythrough animation in teh latest version is to use a host system and use Distributed rendering?
Seems incredibly inefficient given in previous versions you could render every 10th frame saved out as file00xx.vrmap and use the Irradiance map viewer tool to combine them very quickly into a single map.
Add to current map and multiframe incremental both still have to rely on previous frame info and can’t be used when on a renderfarm, correct?
If you are just doing a flythrough multiframe incremental works just fine, and you can render just the 10th frames. Animation - Prepass is for flythroughs with moving objects from what I understand…
so multiframe incremental rendering tieing up a single system with 50 systems setup as a distributed pool is the only way to maintain the same productivity we’ve become accustomed to? seems like a few steps backwards in terms of development.
Maybe user error there… we’ve been doing it for HD 720 frames, takes 1 computer 2-6 hours to generate an IR map for a 3 minute long animation. No DR involved… rendering every 10th frame.
EDIT: Some jobs take up to 6 hours in retrospect, added a wider window.
Hmmm…how about just removing the error check function in the animation precalc mode? seems as though that would solve everything. There’s nothing wrong with assembling the IRmap like the video shows. It’s just that the latest release will not accept it as a valid precalc file.
2 hours is a long time to wait. wouldn’t you rather have 50 computers render 10 frames each at 3 mins/frame for a 5000 frame sequence and start your final render in 30 mins as opposed to waiting? I know I’d rather be home for dinner and reading my son a bedtime story than watching that blue bar all evening.
There’s gotta be a way to render every nth frame on more than one system simultaneously and still use the utility to merge the maps. Perhaps by using single frame mode and adding a post-render suffix operation to prevent overwriting the file?
Otherwise, what’s the point of still including the utility? can anyone else verify this super fast and efficient workflow is no longer an option?
Your workplace sounds stressful. Generally speaking I’ll set it up as I go home and have it when I get in. I have plenty of other things to do while I wait. I’m watching this thread though because I’ve had a terrible time with animation-prepass in terms of render times. Found it was just faster to generate IR/LC for every frame than use it…
Setting it up and going home and saying it will be ready in the morning means 49 machines were not doing anything that night, and means another night of rendering for the same project, when it could be done in 1 night. Deflaminis, how large is your render farm? I know I dont like mine not rendering, no money there when machines aren’t working.
I agree with you Gunny, and edgemaster. Sounds like it should be an easy fix for chaos.
True. Generally speaking we have all machines going all the time, it’s just that there are a lot of us here so my render isn’t necessarily the most important at any given moment. We’ve only got about 32 machines on the farm…
Still interested in the solution here. I’ve had terrible luck with animation - prepass as opposed to other methods…
there seems to be some confusion about efficient GI lighting workflows. your method of calculating multiple seperate maps and merging them is not something id really consider as its very inefficient.
im not sure why the hostility towards using distributed rendering.. why is it a step backwards? you use all the machines to calculate one map, as opposed to using all the machines to calculate multiple maps you have to merge together. doesnt sound anything like a step backwards to me.. in fact its one less step you have to do.
also, youll find (unless this has recently changed) that you will get MUCH larger imap files using the imapviewer to merge, since its a “dumb” merge, simply adding all the maps together. this means saving, loading and rendering -way- more lighting samples than are necessary. (there will be massive overlap as each machine will have no idea what the others has done, and you get many duplicate samples in the merged file.)
using DR on a multiframe imap it will
a) only calculate what is needed in the first place -MUCH faster- Using seperate independent maps means duplicated calculations, since multiple machines will calculate the lighting for areas that other machines already calculated.
b) only save what is needed- smaller files and less overhead on your network
c) only load and render what is needed -potentially speeding up renders and avoiding your merging process altogether.
d) avoid any possible rendering errors caused by different samples from different merged maps trying to light the same point with different light values.
all this talk of watching renderbars… why not just send a backburner job to one machine, with dr set up to use all the others. then set another backburner job, without dr, with a dependancy on the completion of the first job, to render the frames. that way you can have tea at home with no waiting at all involved and no machines sitting idle.
I fogot to mention that the version I was using was 2.20.02