Transparent textures (again)

radiance-general
1

Dear all,

this was discussed here
http://www.radiance-online.org/pipermail/radiance-general/2004-July/001926.html,
but if there was an answer that I understand, I missed it.

I am working on the advanced tutorial again.
Created a falsecolor picture of the working plane illuminance in a room
following John M.'s technical note number 2 here
http://www.radiance-online.org/pipermail/radiance-general/2002-September/000405.html

See the tutorial for details:
http://luminance.londonmet.ac.uk/learnix/files/phatfile/radcourse_advanced.pdf

I would like to map the falsecolor illuminance image back into the room
onto a new surface at working plane height to make the result more
understandable. For this, the background of the falsecolor contour line
image should probably be black, but this is no problem. The false colour
lines would appear to be hovering in the room. I saw something similar in
a demo of some commercial lighting software, but don't remember where.

I think my problem is the cal file (PAB named his one picture_UV.cal)
which is often referred to, but never given as an example. Since my object
is a nice'n'easy plane, would it be possible to use picture.cal that comes
with RADIANCE?

Those are PAB's words of wisdom:

--------------------- 8< - Schnipp -----------------

void plastic mp1
0
0
5 .01 0.01 0.01 0.35 0.1

void glass mp2
0
0
3 .9 .9 .9

void mixpict mp
15 mp1 mp2 digital1 sp.pic picture_UV.cal tpic_u tpic_v ...
0
0

--------------------- 8< - Schnapp -----------------

Could somebody explain the mixpict primitive a bit more?

Cheers

Axel

2

Hi Axel,

The mixpict primitive uses the indicated function of the red, green and blue channels of an image to determine how much of one material to use versus another. One of these materials may be "void", which I recommend instead of the "glass" primitive that you're using in your current example. A "void" material is the same as a perfectly transparent surface, which glass is not. I would also recommend using "glow" instead of plastic to show up your falsecolor lines as something not truly belonging to the scene.

Here is a more complete example:

void colorpict fc_val
7 red green blue sp.pic fc.cal fc_u fc_v
0

fc_val glow fc_glow
0
4 1 1 1 0

void mixpict mp
7 fc_glow void nonzero sp.pic fc.cal fc_u fc_v
0

···

--------
The file "fc.cal" looks like so:

{ Use false color contour image as selector }
nonzero(r,g,b) = if(max(r,max(g,b))-FTINY, 1, 0);
fc_u = Px;
fc_v = Py;
------
The mapping for fc_u and fc_v may need to be a little more sophisticated if your image and space don't match, or you can try transforming the colorpict and mixpict primitives to match these coordinates, similar to how it's done for picture.cal. Let me know if you need help with this part, and be specific with your questions (it helps a lot).

-Greg

From: "Axel Jacobs" <[email protected]>
Date: March 2, 2005 3:20:05 PM PST
...
I would like to map the falsecolor illuminance image back into the room
onto a new surface at working plane height to make the result more
understandable. For this, the background of the falsecolor contour line
image should probably be black, but this is no problem. The false colour
lines would appear to be hovering in the room. I saw something similar in
a demo of some commercial lighting software, but don't remember where.

I think my problem is the cal file (PAB named his one picture_UV.cal)
which is often referred to, but never given as an example. Since my object
is a nice'n'easy plane, would it be possible to use picture.cal that comes
with RADIANCE?

3

Hi Greg,

The mixpict primitive uses the indicated function of the red, green and
blue channels of an image to determine how much of one material to use
versus another. One of these materials may be "void", which I
recommend instead of the "glass" primitive that you're using in your
current example. A "void" material is the same as a perfectly
transparent surface, which glass is not. I would also recommend using
"glow" instead of plastic to show up your falsecolor lines as something
not truly belonging to the scene.

All this makes sense to me.

void colorpict fc_val
7 red green blue sp.pic fc.cal fc_u fc_v
0
0

Since the black is going to be removed anyhow, we could use the normal
picture.cal like so:

void colorpict fc_val
15 red green blue sp.pic picture.cal pic_u pic_v -s 4 -rz -90 -t .5 5.5 0
0
0

Doesn't seem to make any diff.

fc_val glow fc_glow
0
0
4 1 1 1 0

The glow intensity would have to be adjusted to 'look nice' with the
ambient light in the scene, right? It looks better in my scene with a glow
of 2 2 2 0 or 3 3 3 0.

void mixpict mp
7 fc_glow void nonzero sp.pic fc.cal fc_u fc_v
0
0
--------
The file "fc.cal" looks like so:

{ Use false color contour image as selector }
nonzero(r,g,b) = if(max(r,max(g,b))-FTINY, 1, 0);
fc_u = Px;
fc_v = Py;
------

Exactly what I was missing. The FTINY thing is in case the black isn't
really black, isn't it? Or is it for internal rounding errors etc. With my
perfectly back background (you wished you had this in a lighting lab...),
I could drop this. Well, I did remove it and it still works, anyhow.

You've been a great help

Axel

4

Hi Axel,

Beware, quick response ahead:

From: "Axel Jacobs" <[email protected]>
Date: March 3, 2005 12:05:22 PM PST

void colorpict fc_val
7 red green blue sp.pic fc.cal fc_u fc_v
0

Since the black is going to be removed anyhow, we could use the normal
picture.cal like so:

void colorpict fc_val
15 red green blue sp.pic picture.cal pic_u pic_v -s 4 -rz -90 -t .5 5.5 0
0

Doesn't seem to make any diff.

True, but they you won't be able to change the definitions of fc_u and fc_v and have the colorpict line up with the mixpict. I think it's better to use the same file for clarity.

fc_val glow fc_glow
0
4 1 1 1 0

The glow intensity would have to be adjusted to 'look nice' with the
ambient light in the scene, right? It looks better in my scene with a glow
of 2 2 2 0 or 3 3 3 0.

Yes, you are right to adjust it for your scene -- should have mentioned that.

void mixpict mp
7 fc_glow void nonzero sp.pic fc.cal fc_u fc_v
0
--------
The file "fc.cal" looks like so:

{ Use false color contour image as selector }
nonzero(r,g,b) = if(max(r,max(g,b))-FTINY, 1, 0);
fc_u = Px;
fc_v = Py;
------

Exactly what I was missing. The FTINY thing is in case the black isn't
really black, isn't it? Or is it for internal rounding errors etc. With my
perfectly back background (you wished you had this in a lighting lab...),
I could drop this. Well, I did remove it and it still works, anyhow.

The FTINY is in there as a guard against rounding errors, and I wouldn't recommend removing it. It may work on your compile on your machine, but another machine may not.

-Greg

5

Greg

···

----
Thanks for your help; it worked like a charm.

Matiu Carr
----------
If you read this, would it be o.k. to put up a PDF of your "Image Mapping"
binhexed ancient Mac Word file on the RAD site? The old one was a bit of a
challenge to decode. Excellent document!

All
---
I've written down what I've learned from this threat in the Advanced
tutorial under
http://luminance.londonmet.ac.uk/learnix/files/phatfile/radcourse_advanced.pdf

Inspired by Andrews EcoTect presentation in Fribourg, I tried to find some
ways of putting RADIANCE results back into the scene. The results take a
little bit of effort but look REALLY COOL! See sections 2.4.2 Transparent
Textures and 4.6 Vector Illuminance in the above PDF.

Also new: 2.5 Using pcomb, 3.2 Using Ground Planes, 4.1 Non-standard
views, 4.5 Illuminance on a Virtual Plane.

Please send comments if you spot any errors or would like to contribute
any personal experience/wisdom.

Cheers

Axel