I'm used to pigment pattern based on 3D data (a.k.a 3D procedural pattern).
They usually take as input a 3D vector, performs their black magic and 
returns a single float between 0 and 1, then this float is used against 
the ramp to get another float (default ramp being linear, a.k.a no 
change) and finally the float is used to compute the interpolation from 
a map. So far, so good...

Two days ago, I get an idea: what if the colour of the point was 
directly computed from the 3D vector... well in fact, what if the colour 
was just the 3D vector. It does not make too much interest with a 
position vector, but I was then thinking about either the ray direction 
or the normal (it can be made available, that's not the problem here).

Illustrating with only the normal, I was just thinking first of
   color.x = abs(normal.x)
   color.y = abs(normal.y)
   color.z = abs(normal.z)

Thus, a sphere would be colored two red,green and blue spots each at the 
pole with smooth transition to a dark grey of eight spots, while a 
rotating cube would get
homogeneous colour for each face...

Of course, that could be only the first step before a more complex 
operation based on three map (one map per component, as well as one ramp 
per component).

Kind of something like
  <3D info> --> <x,y,z> --> average(mapx(rampx(x)), mapy(rampy(y)), 
mapz(rampz))

instead of the traditional pattern
  <3D info> --> v --> map(ramp(v))

So far, It won't be a pattern as we know it (so a name might be needed, 
and any suggestion is welcome), but is there any interest for the concept ?
Or can it already be done with the actual feature and there is therefore 
no need to patch ?

Post a reply to this message

Le Forgeron wrote:
> 
> [...]
> 
> So far, It won't be a pattern as we know it (so a name might be needed,
> and any suggestion is welcome), but is there any interest for the concept ?
> Or can it already be done with the actual feature and there is therefore
> no need to patch ?

In fact that seems nothing more than the previously proposed custom vector
function and the possibility to use the intersection information (ray,
normal) in functions. The latter involves the problem that the function
will only be defined on an object surface - just like the slope pattern
which results in various problems.

Custom vector functions will probably not be that easy (at least according
to what Thorsten said, i did not look into that matter more deeply) but
surely not impossible.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3D8### [at] freefr>, Le Forgeron <jgr### [at] freefr> 
wrote:

> Two days ago, I get an idea: what if the colour of the point was 
> directly computed from the 3D vector... well in fact, what if the colour 
> was just the 3D vector. It does not make too much interest with a 
> position vector, but I was then thinking about either the ray direction 
> or the normal (it can be made available, that's not the problem here).

That is possible now. For the position, it is very easy, though it only 
works over a finite range. You don't even need functions, just use an 
average of three gradient pigments, one along each axis:

pigment {average
    pigment_map {
        [1 pigment {gradient x color_map {[0 rgb 0][1 red 3]}}]
        [1 pigment {gradient y color_map {[0 rgb 0][1 green 3]}}]
        [1 pigment {gradient z color_map {[0 rgb 0][1 blue 3]}}]
    }
}

Scale to contain the desired area and adjust the color values if you 
want them to go outside the [0, 1] range. (They go up to 3 because 
averaging will drop them to 1/3 of their original value, so use 
3*desired final value. We need an "add" or "sum" pattern. "multiply" or 
"product" would be useful too. Or just vector functions.)
Put this in a pigment function if you want a vector function, this is 
the only way I know of to work around the lack of custom vector 
functions.


> Illustrating with only the normal, I was just thinking first of
>    color.x = abs(normal.x)
>    color.y = abs(normal.y)
>    color.z = abs(normal.z)

A little different, but still possible. Use the slope pattern instead of 
gradient.

Ray direction is more of a problem...you could use the intersection 
point - camera position, but that won't work for secondary rays like 
reflections or refracted images. That is something that will need 
patching to fully support.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

See how you like this - http://www.ogre.nu/source/tufte.inc ;
I use it in the top two images in http://www.ogre.nu/doodle.html

Tufte recommends unsaturated colors; hence my name for the pigment.

The slope vectors are chosen so that luminance is roughly constant
for a given value of slope y.

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message