** Proprietary **
Group,
A couple of months ago I ran a series of simulations tracking the sun
across a space. Since then I've gone back and tried to clean up and
improve the animations (for marketing purposes) only I've run into what
seems to be either a glitch or more likely a user error. I'm using rad
and ranimate to automate the process.
My rif file looks like this...
EXPOSURE= 1
DETAIL= H
EYESEP= .225
INDIRECT= 2
materials= ./material/mat.rad
OCTREE= ./octree/lobby_a.oct
PENUMBRAS= T
PICTURE= ./images/lobby
QUALITY= H
RESOLUTION= 512
illum= ./scene/illums.rad
scene= ./scene/ground.rad ./scene/floor.rad ./scene/ceiling.rad
./scene/aluminum.rad
scene= ./scene/brick_xy.rad ./scene/brick_xz.rad ./scene/brick_yz.rad
./scene/brick_45.rad ./scene/brick_135.rad
scene= ./scene/glaz_exterior.rad ./scene/glaz_interior.rad
./scene/glass_door.rad ./scene/glaz_ripple.rad
scene= ./scene/wall.rad ./scene/rug.rad ./scene/wood.rad
./scene/wood_wall.rad
scene= ./scene/steel.rad ./scene/slats1.rad ./scene/slats2.rad
./scene/drapes.rad
UP= Z
VARIABILITY= H
view= vw1 -vf ./views/v1.vp
ZONE= I 0 17 0 19 0 9
render= -t 10
My ran file looks like this...
BASENAME= anim2/frame%03d
DIRECTORY= anim2
DISKSPACE= 500
START= 1
END= 53
host= localhost
INTERPOLATE= 0
MBLUR= 0
OVERSAMPLE= 3
RESOLUTION= 512
RSH= rsh
RTRACE= F
VIEWFILE= ./views/v1.vp
ANIMATE= genoctree_a.script
EXPOSURE= ./exposure/exp_a_interpolated_15.rad
RIF= lobby_a.rif
And my octree generator looks like this...
frame=$1
tmp=sun.rad
time=`ev "5.25+($frame/4)"`
gensky 3 21 $time +s -a 38.7 -o 90.5 -m 90 > $tmp
oconv -i ./octree/lobby_a1.oct -f $tmp sky.rad
rm $tmp
The problem is that the illum.dat files are not being updated for each
image and considering the fact that the sky is changing for each frame,
it seems to me like they should be. Perhaps ranimate was really only
meant to deal with static lighting scenes with movable objects/camera
positions?
Any comments would be appreciated.
Thanks!
Mark de la Fuente
Hi Mark,
From: "Mark de la Fuente" <[email protected]>
Date: April 18, 2004 9:50:58 AM PDT
** Proprietary **
Huh? If this information is really "proprietary," the last thing you should be doing is posting it to a public discussion list. I assume you meant another word, here.
[...]
The problem is that the illum.dat files are not being updated for each
image and considering the fact that the sky is changing for each frame,
it seems to me like they should be. Perhaps ranimate was really only
meant to deal with static lighting scenes with movable objects/camera
positions?
Indeed, ranimate's support of changing illumination and geometry is minimal. You are responsible for any frame updates yourself within your "genoctree_a.script" file. You are free to use rad to help you with this. Your script file currently changes the sky and expects ranimate to figure out what that means, but how could it? What you need to do is make the octree created by rad depend on some file that is altered in your script, like so:
frame=$1
time=`ev "5.25+($frame/4)"`
gensky 3 21 $time +s -a 38.7 -o 90.5 -m 90 > sun.rad
rad -v 0
cat ./octree/lobby_a.oct
Then, to "lobby_a.rif" you should add:
scene= sun.rad sky.rad
Your current rad input file is broken in the sense that it doesn't have the information it needs to generate correct illum's. This is where your problems began.
Hope this helps.
-Greg
** Proprietary **
Greg, sorry about the proprietary bit. My e-mail was adding this
automatically. I think I just fixed it. Please disregard if I did not.
If anything, I hope that people trying to use rad and ranimate for this
sort of thing will avoid problems thanks to this discussion. Originally
these animations were run without illum surfaces, so this never came
up.
Thanks for the help.
Mark
** Non-proprietary, but possibly hazardous **
Hi Mark,
I hope by this you mean that you were able to solve your problem. Good -- although I noticed an omission in my original response. I should have written:
frame=$1
time=`ev "5.25+($frame/4)"`
gensky 3 21 $time +s -a 38.7 -o 90.5 -m 90 > sun.rad
rad -v 0 lobby_a.rif
cat ./octree/lobby_a.oct
I missed the "lobby_a.rif" needed for the rad command.
-Greg
···
From: "Mark de la Fuente" <[email protected]>
Date: April 19, 2004 7:18:51 AM PDT
** Proprietary **
Greg, sorry about the proprietary bit. My e-mail was adding this
automatically. I think I just fixed it. Please disregard if I did not.
If anything, I hope that people trying to use rad and ranimate for this
sort of thing will avoid problems thanks to this discussion. Originally
these animations were run without illum surfaces, so this never came
up.
Thanks for the help.
Mark
Quite Hazardous! 
I did get it to work, although not quite the way you suggested. Not
sure what the problem is with Cygwin & rad, but I almost always get a
core dump when rad tries to oconv something big. Therefore I needed to
get around this problem as well as I was getting tired of manually
oconving after each core dump... (BTW, it's been great having Cygwin as
an option for running radiance on a Windows system)
The one problem I'm still having (not really a problem) is that I can't
get mkillum to generate all of its *.dat files in the illums folder.
This is making it harder to keep everything nice and clean since I end
up with 82 files for every run and there are 53 runs! Best I can do to
clean this up is to remove the old *.dat files before I begin the next
mkillum process.
Also, I can't quite settle on the best looking view.. But I don't
expect much help there!
My final octree generator looks as follows. Basically I pulled the
light sources and octree updating from rad. This eliminated both of my
problems. We'll see how long this takes with all the variables set to
high.....
frame=$1
time=`ev "5.25+($frame/4)"`
gensky 3 21 $time +s -a 38.7 -o 90.5 -m 90 > sun.rad
oconv -f -i ./octree/lobby_b.oct sun.rad sky.rad >
./octree/lobby_b0.oct
rm *.dat
mkillum @anim1/render.opt ./octree/lobby_b0.oct "<" ./scene/illums.rad
./illums/processedillums.rad
oconv -f -i ./octree/lobby_b0.oct ./illums/processedillums.rad
Greg, thanks for the hand.
Mark
Hi Mark,
I'm not quite sure what to suggest about the core dump -- I found out on another project that Cygwin isn't all that good with memory use.
As for mkillum creating extra *.dat files, you need to set the f= option as explained in the man page to avoid this behavior.
http://radsite.lbl.gov/radiance/man_html/mkillum.1.html
-Greg