Issue Nr. 2
May. 15th 2000.
Contents:
LBNL has released the first prerelease version of Desktop
Radiance 1.0 to it's registered beta testers. Included in
this new release is a fully native port of Radiance for
Windows 9x and NT. This is a very important step towards
making Radiance available for a broader audience, and at
the same time a precondition for the efficient use of
Rayfront on NT systems.
As LBNL representatives have informed me, all modifications
to Radiance that were needed to make this possible will be
available to the general public under similar free license
terms as for the unix version. The optimal solution would
of course be to merge the changes back into the main
distribution, but I'm not sure who easily this can be done.
We'll see what the developers in Berkeley will come up with.
I have yet to fully test this new release, and will do
so with the required thoroughness, in collaboration with
my own beta testers. I will do my best to forward all
the feedback needed to the developement team, so that
the NT port Radiance can become as robust and stable as
the original version for unix systems. Integration into
Rayfront will be significantly improved and simplified
by the removal of the overhead required for the earlier
Cygwin based solution.
As a tribute to the Rayfront testing efforts at the Victoria
University in Wellington, New Zealand, I rearranged my
priorities and attacked the problem of exporting geometry
from Autocad 2000 earlier than I had planned. There were
various issues and incompatibilities to fight, but as a
result I could make a solution available much ahead of my
original schedule.
The well known Radout ARX module to export geometry data
from Autocad to Radiance is now available for Autocad 2000
and can be
downloaded for free
in a standalone version.
The final version distributed with Rayfront will offer full
suport for exporting ACIS solid models. For the moment, this
feature is disabled in the free version, but otherwise it is
identical to the real thing. If you're already working with
Radiance, and want to export your geometry from Autocad 2000,
then this is the solution for you!
The Tech-Babble section of the Rayfront-Announce Newsletter
is targeted at those readers who are interested in the down
and dirty details of working with Radiance. I'll do my best
to explain things in a way that everybody can profit, but
readers with prior Radiance experience may get more value
from the information presented herein. The topics will be
a little heavy on theory, especially for those that are not
part of the Rayfront beta testing program and can't see the
dialogs I'm talking about on their own screen. I'll try to
make my explanations as clear as possible to compensate for
this. If nothing bad happens, then all future issues of
the Rayfront-Announce newsletter will contain a Tech-Babble
section.
In this issue, I'll talk about how to use procedural
modifiers without having to create an extra function file for
them. As a background refresher: Many Radiance modifiers
(materials, patterns, textures and mixtures) allow you to specify
their effects in procedural terms. You can create an extra function
file to define those procedures, or you can use the ones
predefined by Radiance or the rayinit.cal initialization file.
With Rayfront, you'll have the choice of both methods.
If you need to define your own functions (or if the modifier
type requires them), then you can of course create a function
file and put them in there. The modifier editing dialog will
then offer all functions and variables defined in that file
for selection, provided they match the expected signature
for a specific entry. Obviously, if the modifier definition
requires a function with two arguments, then a function with
three or more arguments is not valid, and will not be shown
in the selection pop-up. On the other hand, Radiance is
flexible enought to allow functions with less arguments
or even plain variables. The values normally available for
the remaining arguments will be just "thrown away" in those
cases.
While the definition of functions is only possible within
function files, the application of plain variables is much
simpler. The entry fields for variable values in the editing
dialogs can operate in two modes. In the standard "Select"
mode (with a function file active), they work just like normal
pop-ups, presenting all variables defined in the function file
for selection. If you switch them to "Edit" mode (which is
done automatically if there is no function file), then they
will morph into text fields for entering freely formatted
expressions.
Each of those entry fields understands the expressions you
enter, and will inform you of any errors interactively. As
long as the expression is formally correct, the background
of the entry field will be the standard white. If there is
a problem, then the background becomes red, and the message
bar at the bottom of the dialog displays diagnostic
information about the nature of the problem. Note that you
can't close the dialog with the "Ok" button in this situation.
Let's look at an example: if you compare the two color plates
6 and 7 in the book "Rendering with Radiance", then you can
see the effects of a "metal2" type material on the top of
the little box in plate 6. I haven't found a detailed
description on how the actual image was made, but we still
can theoretize about the how we'd approach the problem.
The color and reflectance values are not what we care for at
the moment, they are boilerplate for a metallic surface.
We assume that the example has a larger u roughness, and a
smaller one for v. The interesting thing now is how the
vector u gets defined.
For this purpose, we'll go to the "Procedural" page of the
editing dialog. The image simulates a brushed aluminium surface.
If the brushing stroke goes straight, then the u vector is
constant for all points. This means that we can just enter
the values 1.0, 0.0 and 0.0 into the fields for the X, Y and
Z coordinates for the vector and we're done, without
specifying a function file. (We'll also need to establish
a suitable transformation for bringing the vector in
alignment with the actual box, but that's a topic for
another Tech-Babble).
Now we consider this easy solution pretty boring, don't we?
An interesting variation would be to simulate a meandering
brush stroke pattern. For this purpose, the u vector needs
to change it's direction depending on the position on one
axis. The most obvious solution is to replace the 0.0 value
for the Y coordinate with an expression. The system knows
about the sine function, so let's try this: "sin(Px)".
Px is the builtin variable for the X position of the current
point. We now have defined a waveform stroke that swings
once towards both +Y and -Y for each meter distance along X.
Our box is only a few centimeters long, so that won't give
us the desired result. We need to scale our function a
little: "sin(Px*150)" will give us 150 up and down swings
per meter, or one every 6.66 mm. If we want to vary the
intensity (amplitude) of the wave, then we just multiply
the result with a correction factor. "0.25*sin(Px*150)"
will result in a much flatter wave.
Remember that the formal correctness of this expression is
automatically checked! What happens when you make a mistake?
The expression "0.25*sin(Px*150" will paint the entry field
background in red, and the message bar will read: 'Missing
closing paren for function "sin"'. "0.25*sin(Px,150)" results
in a: 'Builtin function "sin" requires 1 arguments" (while
the grammar may be flaky, the information is precise, since
replacing the "*" by a "," results in a function call with
two arguments). Other errors will give you similarly obvious
feedback, so that you can correct the problem easily. Note
that the system has no way of garanteeing that a formally
correct expression returns the result that you actually
wanted. There's no way I can implement mind reading in
Rayfront, but you probably didn't expect that anyway.
Most of the short topics mentioned in the last issue are
still on the list, though generally with different priorities
and at different levels of completion:
Autocad integration has seen significant progress, but
still needs some refinement. The new Radout for Autocad
2000 simplifies many things, so that one of the next
Rayfront beta releases will probably be able to run
completely within Autocad.
Luminaire selection and data conversion. My idea of
offering an online luminaire data translation service
is moving up on the priority list, where it had been
replaced temporarily by the expression validation
described in the Tech-Babble section above.
The expression validation features have triggered some
redesign in the modifier editing mechanisms, which as
a consequence have been significantly improved. The
online user manual that the beta testers rely on now
also conatins detailed explanations about some of the
more common materials.
As usual, several bugs get fixed a day, and an unknown
new number is created at the same time. A big "Thank You"
in this place to all those beta testers who pointed me to
problems and supplied suggestions for improving Rayfront.
Issue 08 (2002 Sep. 9.)
Issue 07 (2002 Apr. 29.)
Issue 06 (2001 Jul. 10.)
Issue 05 (2001 Feb. 20.)
Issue 04 (2000 Dec. 5.)
Issue 03 (2000 Aug. 31.)
Issue 02 (2000 May 15.)
Issue 01 (2000 Mar. 19.)
| 