irradiance and antimatter

Hi folks,

rpict -i calculates irradiance on antimatter surfaces, which are otherwise (no -i) not visible.
Any comments to my thinking it should continue tracing to the first non-antimattered surface and do the irradiance there ?

That'll be in version 2.42 of rt/raytrace.c in line 177:
changing
                if (do_irrad && !(r->crtype & ~(PRIMARY|TRANS)) &&
                                (ofun[m->otype].flags & (T_M|T_X)) ) {
to
                if (do_irrad && !(r->crtype & ~(PRIMARY|TRANS)) &&
                                (ofun[m->otype].flags & (T_M|T_X)) && (m->otype!=MAT_CLIP) ) {

-Peter

···

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

Hi Peter,

This is indeed a bug, but your fix won�t work because
some antimatter surfaces should in fact be visible.
I�ll look at this and see if I can come up with a more
robust fix.

I may not get to it until next week, because I�m at
Eurographics this week.

-Greg

Quoting Peter Apian-Bennewitz <[email protected]>:

···

Hi folks,

rpict -i calculates irradiance on antimatter surfaces, which are
otherwise (no -i) not visible.
Any comments to my thinking it should continue tracing to the first
non-antimattered surface and do the irradiance there ?

That'll be in version 2.42 of rt/raytrace.c in line 177:
changing
                if (do_irrad && !(r->crtype & ~(PRIMARY|TRANS)) &&
                                (ofun[m->otype].flags & (T_M|T_X)) ) {
to
                if (do_irrad && !(r->crtype & ~(PRIMARY|TRANS)) &&
                                (ofun[m->otype].flags & (T_M|T_X)) &&
(m->otype!=MAT_CLIP) ) {

-Peter

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

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

OK now, lets try again (I was one of those whose emails got kicked out, whatever
happened at osirusoft.com, ?? if I get it right it rejected one of the t-online mail servers,
amongst others, probably...)

And now the real message:

Hi Peter,

I remember this funny thing, I " fixed " it long ago in one of my private source
hackings ...

I chose to interfere some lines further down in the same block, changing

                          if (!islight(m->otype))

                                  m = &Lamb;

into
   if (!islight(m->otype) && (m->otype!=MAT_CLIP) )

                                  m = &Lamb;

Don't know if its the correct way, either, (that's why the 'fixed' is in
parantheses ) but it suited my personal demands in simply preventing
antimatter ojects suddenly popping up out of nowhere in -i runs

-Carsten

Carsten Bauer wrote:

OK now, lets try again (I was one of those whose emails got kicked out, whatever
happened at osirusoft.com, ?? if I get it right it rejected one of the t-online mail servers,
amongst others, probably...)

yeap. osirusoft.com run one blackhole list of spam distributing sites, but suffers a denial-of-service attack since 27.8.03 (apparently the evil side fights back...) . So I changed the blackhole lists .
Sorry for that, but these lists are quite effective otherwise.

And now the real message:

Hi Peter,

I remember this funny thing, I " fixed " it long ago in one of my private source
hackings ...

I chose to interfere some lines further down in the same block, changing

                         if (!islight(m->otype))

                                 m = &Lamb;

into
  if (!islight(m->otype) && (m->otype!=MAT_CLIP) )

                                 m = &Lamb;

Don't know if its the correct way, either, (that's why the 'fixed' is in
parantheses ) but it suited my personal demands in simply preventing
antimatter ojects suddenly popping up out of nowhere in -i runs

exactly. Fruthermore, I don't feel like glass (dielectric, etc) surfaces should be ignored during irradiance calcs (T_IRR_IGN flag). Maybe time for another cmdline. Any comments, anyone ?

-Peter

···

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

Peter Apian-Bennewitz wrote:

exactly. Fruthermore, I don't feel like glass (dielectric, etc) surfaces should be ignored during irradiance calcs (T_IRR_IGN flag). Maybe time for another cmdline. Any comments, anyone ?

I agree (well, it should be optional). I asked Greg about this a little while ago, and he gave me the following hack to obtain irradiance on glass surfaces:

vwrays -x XRES -y YRES -vf viewfile -fd | rtrace -h -fd -opn octree \

rtrace -fdc -I render_options -x XRES -y YRES octree > illum_picture.pic

The first rtrace computes the intersection point (which is fast) and the second rtrace does the illuminance calculation. Cool, yes? Yes.

Note that this only works with square views. rtrace throws a little fit doing the pixel aspect ratio normalization for non-square views, which can be countered by using this variation instead:

vwrays -x XRES -y YRES -vf viewfile -fd \

rtrace -h -fd -opn octree \
rtrace -fdc -I render_options `vwrays -d -x XRES -y YRES -vf viewfile` \

octree > illum_picture.pic

To quote Greg:

"This guarantees that the resolution used by vwrays is the same as that given to the final rtrace command. this wouldn't be necessary, except that rtrace needs the -x and -y options to create a standard radiance picture on its output (along with a -f?c option)."

... but the addition of another switch to rtrace that facilitates this would be nice too.

···

----

      Rob Guglielmetti

e. [email protected]
w. www.rumblestrip.org

Hi Peter,

now the time has come for me to ask one of those (probably stuuupid) questions
which are hovering around in my mind for a loooong time:

In irradiance runs (rpict -i ...) all surface materials are replaced by the
mysterious "Lambertian" material with the reflectance set to PI.

This is obvious for a surface lit by a direct source (in Radiance terms), setting
refl=PI makes the caculated radiance equal to the irradiance by the classical formula.
(at least for the approximation of purely lambertian surfaces)
But as soon as ambient light is considered, i.e. the light reflected (diffusely) via
several bounces in the scene, isn't there an error introduced by setting ALL materials'
reflectivity equal to PI regardless of their real properties?

Furthermore, specular reflections aren't considered at all with this treatment.

So, from this point of view, -i in its current form has some considerable limitations
additionally to your mentionings...
Hmmm ??!!

  -Carsten

Carsten Bauer wrote:

In irradiance runs (rpict -i ...) all surface materials are replaced by the
mysterious "Lambertian" material with the reflectance set to PI.

This is obvious for a surface lit by a direct source (in Radiance terms),
setting refl=PI makes the caculated radiance equal to the irradiance by the
classical formula. (at least for the approximation of purely lambertian
surfaces) But as soon as ambient light is considered, i.e. the light
reflected (diffusely) via several bounces in the scene, isn't there an error
introduced by setting ALL materials' reflectivity equal to PI regardless of
their real properties?

This method doesn't introduce any errors than wouldn't also be
present in any "normal" simulation. The purpose of the ambient and
direct calculations is ultimately the same, to determine how much
light arrives at a given point from a set of given directions.
The fact that direct sources are treated seperately is mostly a
consequence of practical considerations, because the ambient
calculation is not good at finding small sources.

From a photometric/radiometric point of view, those two methods
of calculation are equivalent, which means they can be treated
the same way in this context as well.

Furthermore, specular reflections aren't considered at all with this
treatment.

On the final bounce (resp. the first when counting from the eye),
the goal is to eliminate the effects of reflection completely.
We're only interested in the incoming light (= irradiance) here.
Setting the lambertian reflectivity to Pi is a technical trick to
reach this goal, in order to avoid a more complicated special
case treatment in the code.

On all further bounces, both diffuse and specular reflections are
handled normally.

So, from this point of view, -i in its current form has some considerable
limitations additionally to your mentionings...

The -i parameter does exactly what it promises to do (besides the
antimatter bug, which should probably be fixed).

The question about transparent materials on the first bounce is
more difficult, I don't have a final opinion on that one yet.
Maybe another parameter to select the desired behaviour would be
most appropriate.

-schorsch

···

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

Carsten Bauer wrote:

Hi Peter,

now the time has come for me to ask one of those (probably stuuupid) questions
which are hovering around in my mind for a loooong time:

In irradiance runs (rpict -i ...) all surface materials are replaced by the
mysterious "Lambertian" material with the reflectance set to PI.
This is obvious for a surface lit by a direct source (in Radiance terms), setting
refl=PI makes the caculated radiance equal to the irradiance by the classical formula.
(at least for the approximation of purely lambertian surfaces)
But as soon as ambient light is considered, i.e. the light reflected (diffusely) via
several bounces in the scene, isn't there an error introduced by setting ALL materials'
reflectivity equal to PI regardless of their real properties?
Furthermore, specular reflections aren't considered at all with this treatment.

So, from this point of view, -i in its current form has some considerable limitations
additionally to your mentionings...

Hmmm ??!!
-Carsten

Hi Carsten,
the irrad code is somehow an interesting piece of C code (the MAT_CLIP hack is not part of current standard distribution)

                if (do_irrad && !(r->crtype & ~(PRIMARY|TRANS)) &&
                                (ofun[m->otype].flags & (T_M|T_X)) && (m->otype!=MAT_CLIP) ) {
                        if (irr_ignore(m->otype)) {
#if MAXLOOP
                                depth--;
#endif
                                raytrans(r);
                                return(1);
                        }
                        if (!islight(m->otype))
                                m = &Lamb;
                }

If I decode the !(r->crtype & ~(PRIMARY|TRANS)) correctly, it triggers if crtype has no flags set, but PRIMARY or TRANS. So any reflected or ambient ray will see the original materials. Light sources will not be "lamberted" too. The core idea is "lambert" a surface only for the first ray coming from the eye (PRIMARY), while all other calcs go on as usual.
However, algorithms for the surface in question will be influenced by the substitution (e.g. no ambient calcs for glass, no speculars for lambertian).

I trust Greg has further insights and/or corrections.
-Peter

···

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

Hi Peter & Schorsch,

ok, I should have looked at the code more thoroughly ... :slight_smile:

but that ! ( ... & ~( ...) ) is really tricky ...

thanx

-Carsten

I believe I've fixed this, now. The trick was to allow the antimatter type to take care of itself, as it will call rayshade() to do the right thing based on whether or not it decides that it hit a surface material. I haven't tested it at this point, but I assume Peter will do it.

-Greg

···

From: Peter Apian-Bennewitz <[email protected]>
Date: Sun Aug 31, 2003 8:51:44 AM US/Pacific

rpict -i calculates irradiance on antimatter surfaces, which are otherwise (no -i) not visible.
Any comments to my thinking it should continue tracing to the first non-antimattered surface and do the irradiance there ?