Question about transdata usage

radiance-general
1

Hello Radiance users,

I have a question about the transdata material type. It doesn't
seem like I am using it properly, the results always look like
an unmodified "trans" material, no matter what I do with the
data file.

Untimately, I would like to render a smoky cloud by using multiple
planes, each totally transparent except where the smoke exists,
where it is semi-transparent. It seems like "transdata" is the
best way. I have a 3D data field of density values, scaled either
0 to 255 or 0.0 to 1.0. I can also write individual planar data
files, if need be. The density is controlled only by position
in space, not by view vectors, angle, etc. This makes my
funcfile very simple.

Right now, my scene.rad looks like this:

void transdata layer1trans
5 noop layer1.dat translayer.cal pos_u pos_v
0
6 0.5 0.5 0.2 0.0 0.97 0.0
# r g b rspec trans tspec

layer1trans polygon layer1
0
0
12 0 0.1 1 0 0.1 1 1 0.01 0 1 0.1

[other scene stuff: ground plane, light "source"]

The simplified data file that I am using now is (layer1.dat):

2
0.0 1.0 3
0.0 1.0 3
1 0 1
0 1 0
0 0 1

And the .cal file contains:

pos_u = Px;
pos_v = Py;

What this does is create a brown-ish semi-transparent plane
with no variations across it. I can only change the trans component
of the material, and that works properly. When I make the rspec
or tspec non-zero, I get a "rview: pos_u: undefined function"
error.

So, I have a few questions:

1) do the values in the data file need to be in any particular form?
   (one of my files has integers 0 to 255, others are 0.0 to 1.0;
    I know I can scale them within the .cal file)

2) how do you control rspec, trans, and tspec from the .cal file?
   It seems like I can only return one value from there; I use
   a noop for that one.

3) shouldn't I be seeing *some* variation across the plane here?

I've been trying variations on these files for a few hours. I
don't have the Radiance book here with me to help, but I have
scoured the digests, online archives, and everything in the
distro.

Can someone please tell me what I'm doing wrong? I am very geeked
to make some high-quality renderings of my fluid dynamics research.

Mark Stock
mstock at umich dot edu

2

Oh, bother these questions that require one to think!

From: Mark Stock <[email protected]>

...

Right now, my scene.rad looks like this:

void transdata layer1trans
5 noop layer1.dat translayer.cal pos_u pos_v
0
6 0.5 0.5 0.2 0.0 0.97 0.0
# r g b rspec trans tspec

layer1trans polygon layer1
0
12 0 0.1 1 0 0.1 1 1 0.01 0 1 0.1

[other scene stuff: ground plane, light "source"]

The simplified data file that I am using now is (layer1.dat):

2
0.0 1.0 3
1 0 1
0 1 0
0 0 1

And the .cal file contains:

pos_u = Px;
pos_v = Py;

What this does is create a brown-ish semi-transparent plane
with no variations across it. I can only change the trans component
of the material, and that works properly. When I make the rspec
or tspec non-zero, I get a "rview: pos_u: undefined function"
error.

Your description is suffering from multiple problems. First off, the transdata is not the type you want to be using, as it only varies the specular lobe for highlights from sources, where what you want is probably something which varies the transmitted component. For this, you should use the basic trans type in conjunction with a brightdata modifier. The brightdata value will act as a multiplier on the specular transmission of the trans material. See the reference manual <http://radsite.lbl.gov/radiance/refer/ray.html&gt; for details. The second error, which the first makes irrelevant, is that you need to specify functions for the pos_u and pos_v parameters, even if they don't use their arguments:

pos_u(dummy) = Px;
pos_v(dummy) = Py;

Otherwise, the interpreter decides these are variables, and you get the error you got when you try to use them. You didn't see any variation because you set the rspec and tspec values to zero, turning off the whole directional diffuse calculation. Since transdata uses its function only for the directional diffuse component, there ended up being no variation in your results.

I hope this is enough to get you back on the right track.
-Greg

3

Oh, bother these questions that require one to think!

> From: Mark Stock <[email protected]>
...
> Right now, my scene.rad looks like this:
>
> void transdata layer1trans
> 5 noop layer1.dat translayer.cal pos_u pos_v
> 0
> 6 0.5 0.5 0.2 0.0 0.97 0.0
> # r g b rspec trans tspec
>
> layer1trans polygon layer1

[snip]

>
> And the .cal file contains:
>
> pos_u = Px;
> pos_v = Py;

[snip]

Your description is suffering from multiple problems. First off, the
transdata is not the type you want to be using, as it only varies the
specular lobe for highlights from sources, where what you want is
probably something which varies the transmitted component. For this,
you should use the basic trans type in conjunction with a brightdata
modifier.

Yes, trans and brightdata appear to work much better than transdata.

The brightdata value will act as a multiplier on the
specular transmission of the trans material. See the reference manual
<http://radsite.lbl.gov/radiance/refer/ray.html&gt; for details.

I assume you meant the opposite, that the data modifies the
transmissivity, not the transmitted specular fraction.

The problem now is that I only get good renderings if the
tspec is 1.0, which creates very dark cloud volumes. I am
looking for more of a high-albedo look. When I reduce the tspec
to anything below 1.0, the entire volume thickens.

I am going to try to use mixdata to mix between a purely
transparent and a semi-transparent and diffusely scattering
material. I think that'll fix the problem.
[time warp]
Okay, I tried that, and it seems to render about 100 times slower,
maybe 1000 times slower. Hmmm.

The
second error, which the first makes irrelevant, is that you need to
specify functions for the pos_u and pos_v parameters, even if they
don't use their arguments:

pos_u(dummy) = Px;
pos_v(dummy) = Py;

Otherwise, the interpreter decides these are variables, and you get the
error you got when you try to use them.

I am using 3.4.1, and if I add the "(dummy)" arguments to "pos_u"
and the others (in a new 3D-capable file), it doesn't even render.
rview does the "1 sampling" then exits with:

rview: pos_w`translayer: undefined variable

Keeping them off allows it to work well, though.

Hmmm, I *did* use a good number of performance-related optimizations
when building the binaries...

You didn't see any variation
because you set the rspec and tspec values to zero, turning off the
whole directional diffuse calculation. Since transdata uses its
function only for the directional diffuse component, there ended up
being no variation in your results.

Thanks for the help, Greg! It's good to see that you're still
very involved in Radiance. BTW: another Radiance-rendered image
of mine will be in the SIGGRAPH Art Gallery this year. I hope
you enjoy it.

Mark

···

On Wed, 2 Apr 2003, Greg Ward wrote:

4

Okay, I think I've figured it out. The ridiculously high
rendering times are from the trans-trans-mixdata simulation
with a tspec of 0.5 on the "issmoke" material. I have the tspec
at 0.1 now, and it seems to render in a much more reasonable
time, *and* the cloud volume self-shadows beautifully.

I'll put some images up as soon as I can the network here
set up a little better (e-mail from Win, real work on Linux).

Thanks for all of your help.

Mark

···

On Thu, 3 Apr 2003, Mark Stock wrote:

The problem now is that I only get good renderings if the
tspec is 1.0, which creates very dark cloud volumes. I am
looking for more of a high-albedo look. When I reduce the tspec
to anything below 1.0, the entire volume thickens.

I am going to try to use mixdata to mix between a purely
transparent and a semi-transparent and diffusely scattering
material. I think that'll fix the problem.
[time warp]
Okay, I tried that, and it seems to render about 100 times slower,
maybe 1000 times slower. Hmmm.

5

Mark Stock wrote:

Okay, I think I've figured it out. The ridiculously high
rendering times are from the trans-trans-mixdata simulation
with a tspec of 0.5 on the "issmoke" material. I have the tspec
at 0.1 now, and it seems to render in a much more reasonable
time, *and* the cloud volume self-shadows beautifully.

Since you apparently are trying to model clouds (resp. smoke)
here, have you looked at the "mist" material? I'm not sure
about the performance implications, but the visual result
would certainly get a lot closer to what you're after.

-schorsch

···

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

6

Georg Mischler wrote:

Mark Stock wrote:

Okay, I think I've figured it out. The ridiculously high
rendering times are from the trans-trans-mixdata simulation
with a tspec of 0.5 on the "issmoke" material. I have the tspec
at 0.1 now, and it seems to render in a much more reasonable
time, *and* the cloud volume self-shadows beautifully.
   
Since you apparently are trying to model clouds (resp. smoke)
here, have you looked at the "mist" material? I'm not sure
about the performance implications, but the visual result
would certainly get a lot closer to what you're after.

-schorsch

as far as I recall looking at this some months ago, mist does show light cones (by volume scattering), but one convex hull of material 'mist' for one cloud doesn't represent the different paths through the cloud when viewed from different eye positions. The function file would have to depend on position on the hull and view direction at that position. That's somewhere in the manual too. - Probably not too difficult to get the line integrals right for some "mildly behaved" density distribution inside the cloud. Any nice examples much appreciated.
-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de