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