[Radiance-general] Re: Radiance animation questions

[Greg Ward]

Hi Zack,

I'll just respond to a couple of things that caught my eye...

> From: Zack Rogers <zrogers@archenergy.com>
> Date: December 17, 2003 3:07:35 PM PST
>
> Greg's response
>
> The time reduction after the first frame isn't noticeable as it doesn't
> progress much from there -- each new frame adds incrementally to the
> ambient file.  You are still much better off than not using one (MUCH),
> but don't expect your rendering times to continue decreasing as the
> animation progresses.
>
> I was thinking that since each frame is so similar (6 inches - 15cm -  
> apart) that there would be alot of ambient data that could be shared  
> from one frame to the next. �Is it because the incident angle to each  
> surface changes enough that the previous ambient data cannot be used.  
> �I don't have to great of a grasp on how the ambient file works, so I  
> apologize.

The thing is, you are saving a lot of time over not having an ambient  
file and you are sharing a lot of values.  It's just that the time  
doesn't continuously decrease -- it quickly drops to a small fraction  
of what it would have been and stays there as your frames progress.   
You have to think about it I guess, but once you are sharing 95% of the  
values from the previous frame, just calculating the new ones needed  
for whatever small movement you've made, what more can you save?  You  
reach this level of sharing after one or two frames, and your rendering  
times stay constant from there on in a walkthrough.  If you make a  
"jump cut" to another position or rapidly rotate the view, you might  
see a momentary slow-down where it has to add a lot of new ambient  
values, but after that your calculation times will level off again.   
The biggest savings after ambient value sharing in a walkthrough will  
come from view interpolation using pinterp.  Even if you decide you  
can't afford to space your rpict renderings any further apart, you can  
still add inbetween frames with pinterp and improve the smoothness of  
your results at little additional cost.

> You might also increase your -ar value,
> as 45 seems very low for a model of this size, especially with all the
> exterior geometry.  I think you're losing resolution on the
> interreflection calculation as a result.  Divide the octree cube size
> (getinfo -d octree) by the length of your arm in your world
> coordinates, and that should give you a reasonable number.
> Oops, I had set my -ar value before I added in the the extensive  
> parking lot. �Getinfo -d gives me this:
>
> bc.oct: -214.5790355 -249.1505 -170.126913 352.68657
>
> My model is in meters. �I don't quite understand this. �My xmin and  
> ymin may be as stated but I know my zmin is not much more than -1  
> meter. �Am I misunderstanding this output. �And so my arm is about a  
> meter so would a good -ar setting be 352/1 = 352? �This would make my  
> calculation time much longer. �I've been setting this in Rayfront  
> where you input xsize, ysize, zsize and octree size (which is longest  
> of the 3 sizes).

Getinfo reports the minimum x, y, and z coordinates plus the size of  
the bounding cube.  An octree is always a cube, so one or two of the  
dimensions will always be smaller than the actual minimum -- oconv  
centers the cube around your geometry.

> This isn't the cause of some the splotches i am still seeing, is it?  
> �I have my -ad and -as parameters really high, but perhaps too high??  
> �Here is a panoramic animation I also created for this model that is  
> even more splotchy:
>
> http://www.archenergy.com/downloads/pub/images/Radiance/ 
> panoramic_walkthrough.exe

Can't look at an .exe file, I'm afraid.  Increasing -ar to 352 is not a  
bad idea, though you may end up seeing a few more splotches.  The  
too-low value you currently have is causing interreflected (ambient)  
values to be spread around too generously, giving an artificially  
smooth appearance to your rendered frames.

> I had these running on some XP machines (since they couldn't handle  
> ranimate) and with a separately generated ambfile. �These were the  
> settings from my .rif file
>
> QUALITY���� = medium
> DETAIL����� = high
> VARIABILITY = high
> INDIRECT��� = 1
> oconv������ = -r 4096
> render����� = -ad 4096
> render����� = -st 0.01
> render����� = -dp 512
> render����� = -av 2.5 2.5 2.5
> render����� = -as 2048
> render����� = -sj 0.1
> render����� = -dt 0.1
> render����� = -aa 0.08
> render����� = -ar 60
>
> There are some pretty significant splotches - I am not sure why these  
> are so much worse than my walkthrough - both ambfiles were about 7MB  
> by the end.

I'd only be guessing without seeing your image, but a frequent cause of  
splotches in a model such as yours is solar reflections off specular  
surfaces, such as glass.

-Greg