[Radiance-general] RE: Solar penetration
Charles Ehrlich
[email protected]
Sat, 24 Aug 2002 22:55:36 -0700 (PDT)
--0-2038736357-1030254936=:17025
Content-Type: text/plain; charset=us-ascii
I'd like to expand upon what Greg said about using oconv, but you might also take a browse through the old Radiance archives as the issue has been discussed in depth.
To quickly highlight some of the advanced uses of oconv, instances and octrees...
The first scene.rad file to be oconv'd must use the -b option to define a large enough boundary to encompass all future scene additions, as Greg mentioned. You can get the boundary size for your scene by doing "getbbox all_scene.rad" or a "getinfo -d all_scene.oct". The latter presumes that you have successfully completed an octree generation. Of course, for either approach you could pick a subset of your scene geometry which you know contain the greatest x, y, and z-dimensions. Note that the output of these two methods is different and the version that matches the input needed by oconv is the "getinfo -d" version. Then, each scene .rad file you add into the original octree is specified, one at a time, using "oconv -i scene.oct newscene.rad".
The instance primitive is more general, flexible, and much easier to decypher later on when you want to recreate what you've done.
Other tips:
Oconv works much better when the scene geometry is world-axis-aligned. Rotate the scene sub-components after oconv-ing them using the instance primitive type. For example:
void instance building1
7 building1.oct -rz 25.2 -t 1.0 2.0 3.0
0
0
And of course, do not rotate the scene to align it with the Y-axis pointing north, but rather, rotate the sky (gensky | xform -rz ) the opposite direction! These two tricks will solve most problems with oconv.
When the going really gets tough, i.e., there is just too much scene complexity, then you may need to use lots of instances. At some point, say 6 instances (one more than the default value of -n), you will notice that oconv will take a lot longer to finish and you will get tired of waiting for all of your instances to be merged into the master octree. It is reasonable to increase the "-n" parameter of oconv when doing the final oconv. You can set -n equal to the number of instances. This will prevent oconv from trying to sub-divide the instances so that no single voxel has more than n number of entities.
Greg at one time claimed that using instances and sub-instances, it would be possible to model the entire earth down to a resolution of 1 inch!!!
Another famous Greg Ward quote, "Everything you need to know about Radiance is documented somewhere, once. Your challenge is to find that one place."
What I have found to be incredibly valuable in finding that one documented location is the online Microsoft-format "help" document that we created for Desktop Radiance. The installation program for Desktop Radiance should, if my memory serves me, be able to install just the help docs if you regrettably don't care about the rest of this fine program. :-) The help docs include all of the manual pages, the reference manual to radiance (with primitive descriptions), user manual, tips and techniques (with the "notes", and quite a bit of other stuff) and . Give it a try!
-Chas
=======
> A little while ago I wrote about using the i option to combine smaller
> octrees into a larger one. This is described in chapter 8 of the
> Radiance
> text, section 8.5 on large data sets. Page 467 give the following
> example:
>
> oconv -f fl.lgt st.lgt cl.lgt -i e_twr.oct -i w_shr.oct ... >
> bridge.oct
>
Omigosh. I don't know how this one slipped by the editor -- no one
ever pointed it out to me before, but it must have been pretty late at
night when Rob typed it in... Quoting the oconv man page:
> SYNOPSIS
> oconv [ -i octree | -b xmin ymin zmin size ][ -n objlim ][
> -r maxres ][ -f ][ -w ][ - ] [ input .. ]
>
This is meant to indicate that the options must preceed the scene input
files. The man page doesn't explicitly state that only one octree may
be added to, but it should. The reason for this is because the starting
(-i) octree defines the boundaries of the scene, which may not be
changed when adding new objects. If you were to attempt to combine two
octrees, their different boundaries would make them impossible to
reconcile -- you might as well start fresh from the objects,
themselves. The only reason for building octrees incrementally is if
oconv runs out of space building the whole octree at once, or you are
trying to save time in an animation where only a few objects are
changing in an otherwise static environment.
--__--__--
--0-2038736357-1030254936=:17025
Content-Type: text/html; charset=us-ascii
<P>I'd like to expand upon what Greg said about using oconv, but you might also take a browse through the old Radiance archives as the issue has been discussed in depth.</P>
<P>To quickly highlight some of the advanced uses of oconv, instances and octrees...</P>
<P>The first scene.rad file to be oconv'd must use the -b option to define a large enough boundary to encompass all future scene additions, as Greg mentioned. You can get the boundary size for your scene by doing "getbbox all_scene.rad" or a "getinfo -d all_scene.oct". The latter presumes that you have successfully completed an octree generation. Of course, for either approach you could pick a subset of your scene geometry which you know contain the greatest x, y, and z-dimensions. Note that the output of these two methods is different and the version that matches the input needed by oconv is the "getinfo -d" version. Then, each scene .rad file you add into the original octree is specified, one at a time, using "oconv -i scene.oct newscene.rad". </P>
<P>The instance primitive is more general, flexible, and much easier to decypher later on when you want to recreate what you've done.</P>
<P>Other tips:</P>
<P>Oconv works much better when the scene geometry is world-axis-aligned. Rotate the scene sub-components after oconv-ing them using the instance primitive type. For example:</P>
<P>void instance building1<BR>7 building1.oct -rz 25.2 -t 1.0 2.0 3.0<BR>0<BR>0 </P>
<P>And of course, do not rotate the scene to align it with the Y-axis pointing north, but rather, rotate the sky (gensky | xform -rz ) the opposite direction! These two tricks will solve most problems with oconv.</P>
<P>When the going really gets tough, i.e., there is just too much scene complexity, then you may need to use lots of instances. At some point, say 6 instances (one more than the default value of -n), you will notice that oconv will take a lot longer to finish and you will get tired of waiting for all of your instances to be merged into the master octree. It is reasonable to increase the "-n" parameter of oconv when doing the final oconv. You can set -n equal to the number of instances. This will prevent oconv from trying to sub-divide the instances so that no single voxel has more than n number of entities.</P>
<P>Greg at one time claimed that using instances and sub-instances, it would be possible to model the entire earth down to a resolution of 1 inch!!!</P>
<P>Another famous Greg Ward quote, "Everything you need to know about Radiance is documented somewhere, once. Your challenge is to find that one place."</P>
<P>What I have found to be incredibly valuable in finding that one documented location is the online Microsoft-format "help" document that we created for Desktop Radiance. The installation program for Desktop Radiance should, if my memory serves me, be able to install just the help docs if you regrettably don't care about the rest of this fine program. :-) The help docs include all of the manual pages, the reference manual to radiance (with primitive descriptions), user manual, tips and techniques (with the "notes", and quite a bit of other stuff) and . Give it a try!</P>
<P>-Chas</P>
<P>=======</P>
<P><BR>> A little while ago I wrote about using the i option to combine smaller<BR>> octrees into a larger one. This is described in chapter 8 of the <BR>> Radiance<BR>> text, section 8.5 on large data sets. Page 467 give the following <BR>> example:<BR>><BR>> oconv -f fl.lgt st.lgt cl.lgt -i e_twr.oct -i w_shr.oct ... > <BR>> bridge.oct<BR>><BR><BR>Omigosh. I don't know how this one slipped by the editor -- no one <BR>ever pointed it out to me before, but it must have been pretty late at <BR>night when Rob typed it in... Quoting the oconv man page:<BR><BR>> SYNOPSIS<BR>> oconv [ -i octree | -b xmin ymin zmin size ][ -n objlim ][<BR>> -r maxres ][ -f ][ -w ][ - ] [ input .. ]<BR>><BR><BR>This is meant to indicate that the options must preceed the scene input <BR>files. The man page doesn't explicitly state that only one octree may <BR>be added to, but it should. The reason for this is because the starting <BR>(-i) octree defines the boundaries of the scene, which may not be <BR>changed when adding new objects. If you were to attempt to combine two <BR>octrees, their different boundaries would make them impossible to <BR>reconcile -- you might as well start fresh from the objects, <BR>themselves. The only reason for building octrees incrementally is if <BR>oconv runs out of space building the whole octree at once, or you are <BR>trying to save time in an animation where only a few objects are <BR>changing in an otherwise static environment.<BR><BR><BR><BR>--__--__--<BR><BR></P>
--0-2038736357-1030254936=:17025--