"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