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 02:27:42 GMT
  Re: Non - rgbf 1 pigment only applied to surface.  
From: William F Pokorny
Date: 8 May 2020 12:24:16
On 5/8/20 7:09 AM, Bald Eagle wrote:
> 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.

Ignore it for where I 'think' I now understand you're headed. :-)

> 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.

Starting to follow and I've had thoughts along similar lines. Random-ish 
stuff from my head:

1) Today with isosurfaces we have the contained_by shape. I had the 
thought long ago it would be really helpful to be able to specify any 
standard shape as that container. See github issue:


2) Christoph introduced the potential pattern which has the potential to 
be applied to more the blobs and isosurfaces(where not that useful). We 
have some issues with normals and warps... A wild thought I've been 
carrying around is to implement always an implicit form of the shape in 
a way where we'd get today's fast ray - surface intersection with then 
underneath a standard way to both deform shapes, get normals deformed or 
not and provide a potential pattern(a). I think of this as my always has 
isosurface shapes inside the ray-surface shape. CSG would perhaps always 
be some isosurface where the ray-surface intersections are only giving 
us the collection of shape-functions on which to work. But, yeah the 
implementation here not easy...

(a) - The traditional normal and normal perturbation code 'could' go 
away in total for any 'got ISOs-inside' shapes. Maybe performance wise 
still useful to fake normals too.

3) With some of my new functions coupled with the f_dual() idea I am 
aiming to nest complex shapes/patterns within simpler ones. Until I can 
work out a mechanism to delay function evaluation this likely to help 
only with better gradients. Think f_dual(), as I can implement it 
quickly, likely to buy a lot only when we are forming multiple shapes 
within one isosurface.

Your idea and/or a mix of those above there is a key component for 
usefulness - some way to fade the isosurface function(s) at the hard 
surface boundaries. Otherwise, we have gradient issues there - unless OK 
with the container shape cutting or clipping the resultant shape.

Aside: An aim of the, new to povr, f_mult1to8pairs() and f_eblob 
functions was to help with this shape/shape, shape/pattern blending. 
Though the gradients are still sometimes high depending on how the 
component functions come together - especially with the former and 
negative*negative multiplication. If you are intersecting half way 
through a shape with the multiplication method the gradient is high at 
the resultant 'surface' despite achieving some fade.

Bill P.

> ---------------------------------------------------------------------
> And this is just the un-thought-through circus in my brain, before coffee....
> 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.

Interesting idea... I'll let it bang around in my head.

> 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.