Tweet
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.
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.
Comment