I am not really firm in stuff regarding functions. For all
I know, eval_pigment will return you only the rgb-component,
and this wouldn't be slope-dependant. If this is correct, it would
be of no use for the thing we're trying to achieve.

Also, we couldn't do a trace against a union/merge, since we
wouldn't know, which objecs of that union/merge we are
actually hitting. We need to look at the different objects
one by one, check, which is the nearest (first) intersection,
look for the reflection-variables in already mentioned array,
and calculate the actual reflection-values from there.
It in fact we do have a slope-independant pigment, we might
use eval_pigment after all in case we want to calculate the
influence of the color on the reflected laserbeam.

All this together would be one major project, as you need a
very intuitive use of pigments/reflections/arrays for users to
quickly set everything, e.g. by calling macros at the appropriate
places.


Batronyx wrote:

> "Tim Nikias" <tim### [at] gmxde> wrote in message
> news:3CEC3A25.46062591@gmx.de...
> > I think he was referring to the amount of reflection, as
> > reflection .4 or even in version 3.5 reflection{.2,.7} would
> > be something far different from 100% mirror-like reflection...
> >
> > AFAIK it is not possible to return those, unless you use
> > trace on objects, of which you have set the reflection inside
> > an array. A macro could trace the object, check the reflection
> > in the array, and return intersection point, surface normal, and
> > reflection value.
> >
>
> Yeah, that makes more sense upon re-reading. <DOH!> Thanks for setting me
> straight.
>
> Let me see if I follow you correctly here; you might not need an array for a
> single simple object with an explicit reflection value set in the texture, but
> an array would be handy for a union/merge object and/or complex texture mapped
> objects right?  If so, how might you get the values for variable reflection,
> and/or the interpolated values within a pigment_pattern or image_pattern? The
> eval_pigment() function in functions.inc ?
>
> Batronyx ^"^

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3CEC73CF.F75C3AC5@gmx.de...

<snip>

Yeh - IMHO it would be a nightmare to implement unless it was possible to return
the reflection component, etc. of a point.

Without this, any scene where you wanted to simulate a laser bouncing around
would require a very complex setup.

Post a reply to this message

Why would a mirror have angle-dependant reflection?

Grim
Tom Melly wrote:
> "Tim Nikias" <tim### [at] gmxde> wrote in message
> news:3CEC73CF.F75C3AC5@gmx.de...
>
> <snip>
>
> Yeh - IMHO it would be a nightmare to implement unless it was
> possible to return the reflection component, etc. of a point.
>
> Without this, any scene where you wanted to simulate a laser bouncing
> around would require a very complex setup.

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3CEC73CF.F75C3AC5@gmx.de...
> I am not really firm in stuff regarding functions. For all
> I know, eval_pigment will return you only the rgb-component,
> and this wouldn't be slope-dependant. If this is correct, it would
> be of no use for the thing we're trying to achieve.

Actually, I was thinking of using the .gray value of the function as a mapping
parameter from which to approximate the interpolated values, but even this won't
work if we're talking blended/layered textures, since the color could be off and
skew the results.

>
> Also, we couldn't do a trace against a union/merge, since we
> wouldn't know, which objecs of that union/merge we are
> actually hitting. We need to look at the different objects
> one by one, check, which is the nearest (first) intersection,
> look for the reflection-variables in already mentioned array,
> and calculate the actual reflection-values from there.

I think that might depend on the object, but I have to agree it would be hard to
achieve consistency without the arrays.


> It in fact we do have a slope-independant pigment, we might
> use eval_pigment after all in case we want to calculate the
> influence of the color on the reflected laserbeam.

Can't disagree here either.

>
> All this together would be one major project, as you need a
> very intuitive use of pigments/reflections/arrays for users to
> quickly set everything, e.g. by calling macros at the appropriate
> places.
>

Yep, it could get messy.

Post a reply to this message