Radiance workshop, etc.

Hi Everyone,

I just read through Rob's very well-written and flattering article on the workshop, which didn't include a single reference to baseball (must have been some oversight). I hope the other attendees enjoyed it half as much as he did -- for my part, the workshop gave me loads to think about as I go into Exponent for the last time today to clean out my desk and contemplate what I'll do next....

I'm sorry that my presentation on Radiance OpenSource raised more questions than it answered. I didn't want to conceal the fact that I have no clear notion what it means, myself. I am hoping it will be a good thing. Certainly, having LBNL continue to own and "manage" the UNIX source code is not desirable, and the fact that they're willing to let it go is something I take as a very good sign for the rest of us. Still, it is nice to have a single, authoritative version on which to base derivative works, so we may have to think up a way to do this (possibly with LBNL's cooperation).

Like I said, the workshop gave me lots to think about, and I made a list of the improvements I would like to see in the source code, ordered here from most to least compelling from my standpoint. I would welcome feedback on this list with additions or things you think ought to be made a priority. The ones with an asterisk are features that others have already done most (or all) of the work on, and the ones with double-asterisks are enhancements I really need someone else's help in doing.

Possible Radiance Enhancements

···

-----------------------------------------------
1. ANSI-fication and CVS, library conversion
2**. Integration of Windows version or addition of Windows portability and functionality
3*. Photon map
4. Direct calculation improvements
5. Cylindrical arcs
6. Rendering with light probes
7*. Complex fenestration
8**. Rendering artifact assistance pages
9**. Material library/assistance pages

I would also encourage people to try out Roland Schregle's photon map extension to Radiance 3.4. I think this could be a very good thing for Radiance, but it probably needs some critical stress-testing before being rolled into the main distribution. At least, it would if I had written it!

-Greg

Greg Ward wrote:

Hi Everyone,

I just read through Rob's very well-written and flattering article on
the workshop, which didn't include a single reference to baseball (must
have been some oversight). I hope the other attendees enjoyed it half
as much as he did -- for my part, the workshop gave me loads to think
about as I go into Exponent for the last time today to clean out my
desk and contemplate what I'll do next....

I'm sorry that my presentation on Radiance OpenSource raised more
questions than it answered. I didn't want to conceal the fact that I
have no clear notion what it means, myself. I am hoping it will be a
good thing. Certainly, having LBNL continue to own and "manage" the
UNIX source code is not desirable, and the fact that they're willing to
let it go is something I take as a very good sign for the rest of us.
Still, it is nice to have a single, authoritative version on which to
base derivative works, so we may have to think up a way to do this
(possibly with LBNL's cooperation).

Like I said, the workshop gave me lots to think about, and I made a
list of the improvements I would like to see in the source code,
ordered here from most to least compelling from my standpoint. I would
welcome feedback on this list with additions or things you think ought
to be made a priority. The ones with an asterisk are features that
others have already done most (or all) of the work on, and the ones
with double-asterisks are enhancements I really need someone else's
help in doing.

Possible Radiance Enhancements
-----------------------------------------------
1. ANSI-fication and CVS, library conversion
2**. Integration of Windows version or addition of Windows portability
and functionality
3*. Photon map
4. Direct calculation improvements
5. Cylindrical arcs
6. Rendering with light probes
7*. Complex fenestration
8**. Rendering artifact assistance pages
9**. Material library/assistance pages

I would also encourage people to try out Roland Schregle's photon map
extension to Radiance 3.4. I think this could be a very good thing for
Radiance, but it probably needs some critical stress-testing before
being rolled into the main distribution. At least, it would if I had
written it!

Actually, the validation we're doing can, in all fairness, only be
considered an exemplary case study (albeit a pretty exacting one). What
this basically means is that we test the *fundamental* correctness of
the method. The caveat is that a poor choice of parameters can still
throw you off by several percent, at least locally in some regions of
the rendering. All the more reason for people try the thing out with
scenes of their own. Stress-testing basically relies on the feedback I
get from the RADIANCE community and entails applying the addon to a
broader spectrum of scenes.

See ya!

--Roland

···

--
"Life is too short for core dumps"

Hi all,

a first feedback from my point of view...

Having one central code base is certainly something desireable, although
it may take more effort than thought at the first glance, including some
of the 'good old' hierachy and scheduling. People taking over
responsibilities for certain parts and deliver results more or less
within some schedule, test persons willing to bother about sending back
detailed feedback and so on ...

Personally, I would like to have some more time for checking out the new
stuff, thinking about further ideas of modifications and ways how to
combine everything. But, in order to keep things and persons from
drifting apart some sort of deadline might be helpful, by which those
who are interested to continue further development deliver short lists
or possible short reports of interesting topics similar to Gregs
'wishlist', plus additional information about the amount of work they
are able to spend on it. People form the user's end of the line should
be integrated in the same manner right at the beginning, too, giving
info about what improvement is needed in the everyday applications.
A very vague assumption of mine is, that when the process finally
starts, it will not just end in pouring all add-ons into one bigger
bucket (stirr well !), but that a rather comprehensive renewal will take
place in the end.

(OK, this sounds very much of a typical politians speech, talking big
about organizing without actually doing something. For a personal
excuse, there have been elections in Germany recently, so still everyone
here is in some way infiltrated by that spirit ...)

so long

- Carsten

Hi Greg,

my suggested improvement to Radiance:

rview version of rpiece
active brdfs: mkillum brdfs
easier application of picture maps to surfaces - write a routine that maps pictures/textures onto surfaces of any orientation
reliable smoothing functions to model automobiles etc.
the ambient calculation is really only visually pleasing at ad >= 2048 and as >=1024 or so. Find a better interpolation algorithm for low values of ad and as to get rid of the nasty indirect blobs that look like spray paint spots (sorry, I don't mean to be harsh, but I would different interpolation approaches for the indirect component)

Martin

Hi Martin,

some short comments to your suggestions:

rview version of rpiece

would be a nice thing to have. Indeed, I already wrote something like
this (although not based on rpiece, but generally on a separate parallel
processing library (PVM)). The problem is, however, that the succesive
refining scheme of rview needs a lot of data shuffling when sending the
output of different processes to the display, so the parallel rview came
out really slooooooow, which is why I abandoned it and do parallel
processing only in rpict mode.

easier application of picture mapping

try to include the picture/texture mapping and the object on which it is
mapped in one file. When placing this file with xform to an arbitrary
position and orientation, the mapping function gets transformed
automatically as well

reliable smoothing functions

the smoothing option in e.g. gensurf (-s) works very well. I don't have
any experience in cases when polygon meshes are imported from CAD
programs, although I already thought about an independent smoothing
process which could be let loose on any given polygon set.
Question: does the smoothing generally get lost when importing stuff
from, say, Autocad ?

the ambient calculation..

well, there's no easy way to accomplish difficult tasks. Intricate
geometry demands a high sampling density, interpolation always is some
sort of 'secondary' measure which - no matter how sophisticated it is
performed - often reaches its limits rather soon . Nevertheless, I judge
your given settings to be very high. I had much succes in achieving
visually appealing images (judged not only by myself.. :slight_smile: with far
lesser parameter settings.

-Carsten

> easier application of picture mapping
try to include the picture/texture mapping and the object on which it is
mapped in one file. When placing this file with xform to an arbitrary
position and orientation, the mapping function gets transformed
automatically as well

Martin, have you checked out the "arbmap.cal" file included
with Rayfront? That normalizes the *orientation* of image
maps in space, so that they are always mapped flat onto the
respective surface. Of course you still need to make sure
that they appear at the right location in space (unless it's
a global mapping).

In general, the best approach for location specific mappings
(pictures hanging at the wall) is to create a seperate file
with the picture sufrace, and possibly the frame etc. Peters
genpic program does a nice job there for most situations.
Then transform that file to the right location, geometry,
mapping, and all.

Rayfront includes genpic binaries, and the "parts" mechanism
provides an easy way to place external objects in the scene.
And no, this is not all cheap advertizing, Martin maintains an
educational Rayfront license at PSU (whether he actually
uses it is another question, of course... :wink:

> reliable smoothing functions
the smoothing option in e.g. gensurf (-s) works very well. I don't have
any experience in cases when polygon meshes are imported from CAD
programs, although I already thought about an independent smoothing
process which could be let loose on any given polygon set.
Question: does the smoothing generally get lost when importing stuff
from, say, Autocad ?

Yes. That may eventually change once I have understood how
gensurfs smoothing actually works (doesn't seem to bee too
complicated, just that I didn't have the nerve to dig into
the topic yet).

It seems that Ole Lemmings ConRAD preserves smooting when
converting from 3D-Max files.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Hi!

try to include the picture/texture mapping and the object on which it is
mapped in one file. When placing this file with xform to an arbitrary
position and orientation, the mapping function gets transformed
automatically as well

Does this work with frozen octrees as instances, too? I don't get these
images visible...

CU, Lars.

Unfortunately, I couldn't read Martin's posting, as it came out as an encoded sequence that my mailer couldn't decypher. Folks, if you're sending text, see if you can use ASCII. It's a good standard, and it's been around for some time. My mailer figures out most things, but it's not 100% reliable.

I'm gathering my notion of what was said by Carsten and Schorsch's responses...

rview version of rpiece

would be a nice thing to have. Indeed, I already wrote something like
this (although not based on rpiece, but generally on a separate parallel
processing library (PVM)). The problem is, however, that the succesive
refining scheme of rview needs a lot of data shuffling when sending the
output of different processes to the display, so the parallel rview came
out really slooooooow, which is why I abandoned it and do parallel
processing only in rpict mode.

The new rholo program is runs like rview in parallel, as you can start as many processes as you have processors. I never got around to making it work over a network, and I have doubts it would really pay off due to the latencies involved. Carsten's statement would seem to confirm this.

reliable smoothing functions

the smoothing option in e.g. gensurf (-s) works very well. I don't have
any experience in cases when polygon meshes are imported from CAD
programs, although I already thought about an independent smoothing
process which could be let loose on any given polygon set.
Question: does the smoothing generally get lost when importing stuff
from, say, Autocad ?

Yes. That may eventually change once I have understood how
gensurfs smoothing actually works (doesn't seem to bee too
complicated, just that I didn't have the nerve to dig into
the topic yet).

Gensurf will also take vertices from its standard input or a file and generate smoothed polygons, but the vertices have to be laid out on a grid. (I added for the next release a feature to enable you to cut rough holes into gensurf meshes.) If you have a triangle mesh and you know the vertex normals, you can use the tmesh2rad or mgf2rad converters to get these into smoothed triangles in Radiance. The mgf2rad program will also smooth quadrilaterals, but it does so by breaking them into triangles. The obj2rad program can also take smoothed surfaces in Alias/Wavefront format, so there really are many options for getting smoothed surfaces into Radiance.

-Greg

You can use the mgf-format to store the geometry meshes with the vertex
normals. These files are much smaller than "pure" radiance primitives.
To include the mgf files use "!mgf2rad car.mgf | xform ... " in your *.rad
files.

To create the mgf file use "3ds2mgf" or write your own exporter. I did
one for Blender a year ago. It's simple if you can access the vertex
normals.

Thomas

···

On Mon, Oct 07, 2002 at 01:22:12PM -0400, Martin Moeck wrote:

Hi Greg,

my suggested improvement to Radiance:

reliable smoothing functions to model automobiles etc.

--
Thomas Bleicher
[email protected]
...................................................................
There is no room for smalltalk in a big universe.
        -- Terry Pratchett, Thief of Time