Le 24/04/2016 17:19, William F Pokorny a écrit :

> I don't believe the function bounding being suggested is going to help with such
isosurfaces. It is at least not apparent to me how I could employ it. Perhaps I could
though if this new method could associate many containers - as in say a spline of
spheres/ranges - with
> one function?

Now thinking about it: what is the gain of one function being the sum of bounded boxed
functions,
compared to a multitude of distinct functions which are bounded by their own box ?

Wouldn't it duplicate the union{} for isosurfaces ?

Post a reply to this message

On 04/24/2016 11:36 AM, Le_Forgeron wrote:
> Le 24/04/2016 17:19, William F Pokorny a écrit :
>
>> I don't believe the function bounding being suggested is going to help with such
isosurfaces. It is at least not apparent to me how I could employ it. Perhaps I could
though if this new method could associate many containers - as in say a spline of
spheres/ranges - with
>> one function?
>
> Now thinking about it: what is the gain of one function being the sum of bounded
boxed functions,
> compared to a multitude of distinct functions which are bounded by their own box ?
>
> Wouldn't it duplicate the union{} for isosurfaces ?
>

I think I did a poor job of describing what I was thinking while 
thinking aloud...

With the sphere sweep iso, the one function is based upon a spline 
function along which an f_sphere is swept(1).

What I'd like - or think I'd like - in cases like this is a way to 
better bound this one function. To that end I was thinking about being 
able to specify set of spheres/ranges to bound the function roughly 
following the same spline, but larger as a collection of bounding 
regions which I presumed would fit nicely in any new search scheme.

If the point in space being tested is inside - any - of the spheres in 
this collection of bounding spheres the one function would be evaluated. 
It does need a many bounding shapes to on function mechanism for this. 
The gain or aim would be evaluating the one function a good deal less 
than happens today - or would happen if I had access to only one 
container shape for the function.

I think what you are suggesting is a set up multiple f_sphere/blobbing 
functions already placed following the spline each with there own 
bounding shape? This would probably work too I guess with some work on 
how to distribute the sphere/blobs ahead of time along the spline so as 
to look right. This approach would have the significant advantage the 
iso sphere sweep could fold every which way with no issues. Maybe this 
is the better way to go given internal bounding...

Aside: Some more thinking aloud. Not seen it stated out right in this 
thread, but to be most general we too would like to be able to distort - 
with passed coordinates - both the functions and containers/ranges 
together. Or, is the thinking we'd set the sub function containers up to 
handle any distortion as is the case with the outer contained_by shape 
today ?

Bill P.

(1)- Lying a bit as there were derivative adjustments too, to keep the 
sphere rounder as it was swept.

Post a reply to this message

Am 24.04.2016 um 17:19 schrieb William F Pokorny:

> I've played with isosurface sphere_sweep equivalents(1) and they work -
> slowly. The gradients are somewhat steep - which is very often tolerable
> if the container is tight to the shape so to speak - but today the
> container for such things often ends up by volume very much larger due
> having only spheres and boxes.
> 
> I don't believe the function bounding being suggested is going to help
> with such isosurfaces. It is at least not apparent to me how I could
> employ it. Perhaps I could though if this new method could associate
> many containers - as in say a spline of spheres/ranges - with one function?

No, I don't expect much of a speedup for sphere_sweep equivalents
either, unless they have a lot of segments.

This thing I'm planning on is specifically intended for blob-like
isosurfaces.

> Aside: Hmm. Wondering... Did we ever wrap up that sphere_sweep bounding
> bug someone found as a git bug or otherwise fix it? This one:
> 
>
http://news.povray.org/povray.bugreports/thread/%3Cweb.5692847b8bcbbc2219f71b680%40news.povray.org%3E/

Not that I remember.


> Expect you are already aware of it, but to be certain, Christoph Horman
> did quite a bit of isosurface optimization work/study some years back.
> See the isosurface speed up items on the page at :
> http://www.imagico.de/pov/tools_en.php

No, I wasn't aware of that. This looks like an interesting approach as
well. Entirely orthogonal to my idea though.


> I did wake up this morning wondering more about the interaction internal
> function bounding with the isosurface mechanism itself.
> 
> I don't see any issue for bounded sub-functions used in patterns. There
> the function will be passed a point in space and return a value.
> 
> In isosurfaces though there is that search inside the outer container
> along the ray for threshold value(s) defining shape surface(s). My
> thinking is still cloudy, but wondering if this could lead to additional
> iso-search work due the internal container boundaries interacting at
> distance from any intended shape(s)?

Provided the bounding information isn't a lie (i.e. provided each
bounding shape includes the entire volume for which the corresponding
component function is non-zero), this will have no impact on the
Isosurface algorithm whatsoever (aside from speeding it up, obviously)
-- the algorithm doesn't do anything magic with the function, it just
evaluates it plenty of times with different parameter values. So
whatever speeds up the function evaluation without giving different
results is fair game, and unless the bounding information is a lie
that's exactly what the mechanism will do.


> Guess thinking some rays might travel through multiple adjacent search
> ranges causing differing sets of functions to be evaluated along the ray
> in a way that is noisier. Ah, maybe though this is just the same
> gradient concern but away from the shape surfaces. For large numbers of
> functions have to think we'd still come out ahead.

The algorithm will just replace additions of zero with no additions at
all, while retaining all other addends.

There is a theoretical possibility that careless implementation of the
mechanism could lead to the addends being summed up in a different order
at different points in space, which indeed would have some potential for
wrecking continuity if a particularly large number of non-zero addends
were involved, but I consider that a purely academic issue; in such a
borderline pathological case, the isosurface would probably be suffering
from precision limit noise anyway even with stable addend ordering.
Besides, I expect stable ordering of addends to be virtually inevitable
except maybe for a pathologically over-optimized implementation.

Post a reply to this message

Am 24.04.2016 um 17:36 schrieb Le_Forgeron:

> Now thinking about it: what is the gain of one function being the sum of bounded
boxed functions,
> compared to a multitude of distinct functions which are bounded by their own box ?
> 
> Wouldn't it duplicate the union{} for isosurfaces ?

Not at all.

Just think of blobs: As far as the underlying maths goes, a blob is just
a special kind of isosurface, and its underlying function is indeed the
sum of multiple component functions, each of which have a limited volume
of influence, and the algorithm makes use of bounding; so in a blob you
have exactly the situation in question.

Now note that a blob comprised of a single element (and thus a single
component function) is spherical in shape. If you'd union{} multiple
such single-element blobs together, you'd get a boring set of (possibly
overlapping) spheres -- an entirely different shape than if you add the
components up together in a single blob.

The difference is that if you use a union, you're combining the results
of a threshold operation applied to individual elements, whereas in a
blob (and also in a isosurface based on a sum of functions) you're
applying a threshold operation to a combination of those elements.

Post a reply to this message

On 04/24/2016 01:23 PM, clipka wrote:
> Am 24.04.2016 um 17:19 schrieb William F Pokorny:
>
>> Aside: Hmm. Wondering... Did we ever wrap up that sphere_sweep bounding
>> bug someone found as a git bug or otherwise fix it? This one:
>>
>>
http://news.povray.org/povray.bugreports/thread/%3Cweb.5692847b8bcbbc2219f71b680%40news.povray.org%3E/
>
> Not that I remember.
>
>

Thanks.

Still getting settled post move, but I'll go back and take a look today. 
I had the idea then an explicit bounded_by might help as a work around, 
but I didn't try it. I'll look at the source code too, but as you know, 
I'm a hack coder...

In any case, I'll open a bug on github for it.

Bill P.

Post a reply to this message