William F Pokorny <ano### [at] anonymousorg> wrote:

> --- but
> What you should be able to do - since you can define pigments and
> normals independently ahead of inclusion in a texture for each
> shape/surface - is use different maps for the pigment and normal
> uv_mapping for 'each' low level uv map-able thingy. Pigments, normals or
> both could use maps created for the object as they need to be when
> placed in global space. No automation for this as far as I know - you'd
> have to work out how to create the thingy by thingy map(s) cut from
> global space on your own.

So, I could define a function that translated an <x, y, z> coordinate (that is
used internally to calculate a uv coordinate) to a projected <x, y, z>
coordinate that is outside the range of the 0-1 uv vectors of the local space...

<insert headache here>

Then do normal {function {f_translate (x, y, x)}, which should should remap the
local <x, y, z> mapping of the uv vectors to a projected set of uv vectors that
in turn correspond to the actual spatial positions of the bezier patch...

Egads.

I'm a _little_ surprised that no one has ever brought this up before, but then
again, I'm always going off into the weeds when doing what seem to be perfectly
ordinary things...

I'm wondering if you were to implement this in povr source, if it would be as
simple as defining a "no_uv" normal type that simply uses the native EPoint
instead of the uv_vector coordinate.

I will have think a bit more on this and see when I can puzzle out something
functional [sic].

Thanks for the analysis and ideas for a solution   :)

Post a reply to this message