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:

https://github.com/POV-Ray/povray/issues/228

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