Solar penetration

When I did 'Building Science' many years ago, we used "solar protractors" to
read off the suns altitude and azimuth at different times of the year. The
solar protractor was a plot of the suns path across a hemisphere for
different times of the day for a given latitude, generally printed on a A4
bit of clear plastic. This was used in assessing orientation of designs in
plan and overhangs/shading in section. Alternatively we could use it to
assess solar penetration from a point inside the building by marking out on
the protractor the area of sky visible through openings.

What I would like to do is step back a bit to the solar protractor idea. I
want to plot the sun's path across the sky from a specified view - say for
the solstices and equinox - annotate the time of day, and overlay on a
previously rendered view. I think this could be a more graphic illustration
of when and for how long the sun will penetrate into a space. It should be
quicker than several animations.

I think this could be quite easily done by rendering sequences of empty
scenes from the required viewpoint and combining them and the fully rendered
scene using pcomb. The sun positions could appear as dots. (Would the 0.5
degree angle subtended by sun be too small?). Can anyone help me with
functions I would need to feed pcomb - to convert "suns" to dots and the
skys to white graphic infomation and how do I automate the annotating? The
final compositing could be done with Photoshop. I have tried the long way
round - plotting the sun paths on cad - but this seemed unneccessarily
fiddly and potentially inaccurate.

Many thanks

Bruce Sounes

Nothing to do with Radiance, but some of your might be interested in
knowing that these are still available. It's now called the
Pilkington Sun Angle Calculator, and they can be ordered from the
Society of Building Science Educators at
<http://www.sbse.org/resources/sac/index.htm>.

Randolph

···

On Wed, Aug 21, 2002 at 12:43:41PM +0100, Bruce Sounes wrote:

When I did 'Building Science' many years ago, we used "solar protractors" to
read off the suns altitude and azimuth at different times of the year. The
solar protractor was a plot of the suns path across a hemisphere for
different times of the day for a given latitude, generally printed on a A4
bit of clear plastic. This was used in assessing orientation of designs in
plan and overhangs/shading in section. Alternatively we could use it to
assess solar penetration from a point inside the building by marking out on
the protractor the area of sky visible through openings.

For a novel approach to solar penetration using
a Radiance-based technique, see:

http://www.iesd.dmu.ac.uk/~jm/sol_pen/jmcibs.html

(HTML slide-show, 25 slides).

The space-time maps of solar irradiation generated
using this approach are far more revealing of the
performance of shading devices than traditional
methods based on shading patterns. It's a new
idea and there isn't yet an end-user version.

-John Mardaljevic

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. :slight_smile: 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.

--__--__--