POV-Ray : Newsgroups : povray.general : Non - rgbf 1 pigment only applied to surface. : Re: Non - rgbf 1 pigment only applied to surface. Server Time: 14 Jul 2020 03:57:01 GMT
  Re: Non - rgbf 1 pigment only applied to surface.  
From: Bald Eagle
Date: 8 May 2020 11:10:01
William F Pokorny <ano### [at] anonymousorg> wrote:

> Not sure I'm following.

And here I thought you would have seen exactly where I was going with this.

> Are you looking for ray tracing efficiency?

.... in a way...

> Underneath today everything is textured - carries that overhead - no
> matter.

My brain couldn't parse that.

Imagine you have the checkered pattern. One color is blue, the other clear.
Apply that to a plane.  You can see through the clear parts - but not the blue
Put an object of some sort under/behind the plane.   You can see IT through the
clear parts of the checkered pattern.
So far so good.

Now make a box{} with the same pattern, and have the edge you're looking at
transect a row of squares.  What do you see?  Alternating clear and blue, sure
..... but you don't see the blue of the second row (if your box is deep enough) -
what you see is the very farthest edge of the last row.  You don't even see the
orthogonal edges of the first row, except on the top and bottom surfaces of the

And here's where I was going with this.
If you COULD have the raytracer evaluate the interior of the pattern (sans
media), then you would essentially have ---- _an isosurface.  But given how
patterns and isosurfaces are evaluated under the hood, I'm betting it would be
rendered a LOT faster.

And this is just the un-thought-through circus in my brain, before coffee....

I haven't even begun to think through the implications of having
#declare Pattern = pattern {function{myFunction}}
#declare F= function {Pattern}

#declare PartialVectorFunction = function {something * F(x,y,z).x +sumthin_else
* F(x,y,z).y + another_sumthin * F(x,y,z).z}

Shortening the variable names and implementing a default (x,y,z) argument if
unspecified, you'd get a nice tight expression like

#declare PVF = function {s * F.x + se * F.y + as * F.z}

I'll also have to think about encoding a vector into a function so that the
pattern {function{}} thing evaluates to the same VECTOR result everywhere - thus
you could define a function intead of a vector and then use the dot notation in
a function, whereas you currently can't use Vector.x in a function expression.
One needs to resort to the clunky
#declare VX = Vector.x and THEN use VX in the function.....

Post a reply to this message

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.