Confusing, I know
I am using 3.7.2.
I am trying something like:
cnt 2 3| rcalc -e '$1=$1;$2=$2;$3=1;$4=0;$5=0;$6=1'| rtrace -I -ab 1 -ad
64 -h -w -oov axel.oct| rcalc -e '$1=$1;$2=$2;$3=$3'
0 0 2
0 1 2
0 2 2
1 0 2
1 1 2
1 2 2
Compare this to:
cnt 2 3| rcalc -e '$1=$1;$2=$2;$3=1;$4=0;$5=1;$6=0'| rtrace -I -ab 1 -ad
64 -h -w -oov axel.oct| rcalc -e '$1=$1;$2=$2;$3=$3'
0 1 1
0 2 1
0 3 1
1 1 1
1 2 1
1 3 1
radiance 3.7.2 seems to add the direction vector to the ray's origin at
its -oo output.
Now try:
cnt 2 3| rcalc -e '$1=$1;$2=$2;$3=1;$4=0;$5=3;$6=0'| rtrace -I -ab 1 -ad
64 -h -w -oov axel.oct| rcalc -e '$1=$1;$2=$2;$3=$3'
0 1 1
0 2 1
0 3 1
1 1 1
1 2 1
1 3 1
Aha! It is in fact the _normalised_ direction vector which it adds.
I've done similar rtrace jobs lots of times before, but this behavious
seems to be newly introduced in a recent release. -oo always used to spit
out exactly the input, not (input+direction).
Please advise.
Axel
Hi Axel,
The -oo option and -od option report the origin and normalized ray direction (respectively), but only with -I-. When you set -I+, then rtrace fudges the calculation by creating a ray 1 unit above an imaginary Lambertian surface, and this is why the origin (and direction if you check) do not match your input. Instead, the intersection point (-op) and surface normal (-on or -oN) will match the origin and direction given.
This is not a new bug in 3.7, but something that's been there since I enabled reports of parameters besides ray value with -I+ in the 2.3 release. Perhaps you weren't using the -I+ setting in your previous scripts.
I think I could fix this behavior if it's really screwing you up. I agree that it's confusing to have the -oo and -od options change their apparent reporting depending on the -I setting, but they are reporting the values on the ray actually traced. You don't start out at the surface and direct the ray straight up in order to compute irradiance. That wouldn't work.
-Greg
ยทยทยท
From: "Axel Jacobs" <[email protected]>
Date: October 24, 2005 7:27:00 AM PDT
Confusing, I know
I am using 3.7.2.
I am trying something like:
cnt 2 3| rcalc -e '$1=$1;$2=$2;$3=1;$4=0;$5=0;$6=1'| rtrace -I -ab 1 -ad
64 -h -w -oov axel.oct| rcalc -e '$1=$1;$2=$2;$3=$3'
0 0 2
0 1 2
0 2 2
1 0 2
1 1 2
1 2 2
Compare this to:
cnt 2 3| rcalc -e '$1=$1;$2=$2;$3=1;$4=0;$5=1;$6=0'| rtrace -I -ab 1 -ad
64 -h -w -oov axel.oct| rcalc -e '$1=$1;$2=$2;$3=$3'
0 1 1
0 2 1
0 3 1
1 1 1
1 2 1
1 3 1
radiance 3.7.2 seems to add the direction vector to the ray's origin at
its -oo output.
Now try:
cnt 2 3| rcalc -e '$1=$1;$2=$2;$3=1;$4=0;$5=3;$6=0'| rtrace -I -ab 1 -ad
64 -h -w -oov axel.oct| rcalc -e '$1=$1;$2=$2;$3=$3'
0 1 1
0 2 1
0 3 1
1 1 1
1 2 1
1 3 1
Aha! It is in fact the _normalised_ direction vector which it adds.
I've done similar rtrace jobs lots of times before, but this behavious
seems to be newly introduced in a recent release. -oo always used to spit
out exactly the input, not (input+direction).
Please advise.
Axel
Hi Greg,
The -oo option and -od option report the origin and normalized ray
direction (respectively), but only with -I-. When you set -I+, then
rtrace fudges the calculation by creating a ray 1 unit above an
imaginary Lambertian surface, and this is why the origin (and
direction if you check) do not match your input. Instead, the
intersection point (-op) and surface normal (-on or -oN) will match
the origin and direction given.
This is baffling. I always used just plain -I, without +/-, and it worked.
I am indeed after illuminance.
Let me repeat this:
- rtrace -defaults: -i- (so illuminance is off, hence luminance)
- -i/-I is a boolean switch (or are they two independent boolean switches?)
- I have -I in my rtrace command line. This toggles the default, turning
it on.
- with i/I set to on, the origin should be set to the input, no?
This is not a new bug in 3.7, but something that's been there since I
enabled reports of parameters besides ray value with -I+ in the 2.3
release. Perhaps you weren't using the -I+ setting in your previous
scripts.
No, just -I
I think I could fix this behavior if it's really screwing you up. I
agree that it's confusing to have the -oo and -od options change
their apparent reporting depending on the -I setting, but they are
reporting the values on the ray actually traced. You don't start out
at the surface and direct the ray straight up in order to compute
irradiance. That wouldn't work.
I think I understand the subtlety of measuring luminance vs. illuminance,
so the added '1' and the inversed direction doesn't worry me. The
'toggling' is, though.
Thanks for your reply, anyhow.
Cheers
Axel
I'm still not over this.
Just tried all possible combinations of 'I':
none: fine, no added 1
-I-: fine, no added 1
-I+: fine, added one, but expectedly
-I: not fine, added one but unexpectedly (should toggle)
Can I assume that the 'i' is for 'i'lluminance, not 'i'nversed?
Also: I think the man page to rtrace used to say under -I something like
"like -i, but..."
Axel
Let me repeat this:
- rtrace -defaults: -i- (so illuminance is off, hence luminance)
Also defaults to -I-. These are separate options, and need to be considered independently, though their behavior is somewhat similar.
- -i/-I is a boolean switch (or are they two independent boolean switches?)
Independent.
- I have -I in my rtrace command line. This toggles the default, turning
it on.
That's right. Two -I options would turn it off again.
- with i/I set to on, the origin should be set to the input, no?
WIth -i the origin will match the input, as the rays are traced from there. With -I, the origin will not match the input, as I said.
I think I understand the subtlety of measuring luminance vs. illuminance,
so the added '1' and the inversed direction doesn't worry me. The
'toggling' is, though.
Again, -i and -I do not toggle each other. With -I+ set (either using -I alone or -I+), the -i setting become irrelevant. Think of -I as superseding the -i setting.
-Greg