On 04/22/2016 08:02 PM, clipka wrote:
> Folks, I need your help.
>
> I'm planning on a feature, but can't think of a good syntax to go with
> it. Here's the deal:
>
> Some of you may be aware that isosurfaces can be used as a replacement
> for blobs, to get some added flexibility, such as adding toroids or
> boxes to the set of elements, or tweaking the way the elements fuse with
> each other. Unfortunately this comes at a huge performance penalty.
>
> Part of this difference in performance is because POV-Ray's blob
> implementation makes use of the fact that the individual components have
> a limited range of influence, employing a bounding hierarchy to bypass
> computation of components that are too far away to make any difference.
> Isosurfaces do not provide such a mechanism.
>
> I want to change this.
...
>

I'm still finishing a move to a new city and apartment as I try my hand 
at retirement, but as I play quite a bit with isosurfaces, saw your 
post, and have some initial thoughts more on the internals than syntax I 
guess.

- I have often enough wished for a more flexible contained_by mechanism 
for isosurfaces than the sphere / box container shapes we have today so 
I welcome any effort to improve it.

- We can today use shape functions as in "(F_Stem(x,y,z)>=0)" or 
functions testing whether inside or outside and object with select() 
limit the evaluation of other functions. I sometimes use left side 
multiplication too because it is quicker to code though not sure if the 
VM really bails early. I've played with isosurfaces defined by inside 
tests on objects in the past too.

The point is the performance limiter on implementing container/range 
methods for isosurfaces very quickly becomes the fact there is no 
internal optimization on the evaluation of the container objects. Any 
scheme to enable many bounded_by objects in functions, I believe should 
look to make rapid inside evaluations of all those container shapes. It 
was not clear to me from your proposal if this would be the case? I 
believe all the containers would have to be evaluated for each 
evaluation step the isosurface code takes.

- Suppose obvious, but containers internal to the isosurface can 
themselves introduce discontinuities / gradient issues in the overall 
function. Inside a single isosurface they'd need to be used with care.

Bill P.

Post a reply to this message