With respect to the report of sombrero.pov breaking with +b2:

"LoneStar" <nomail@nomail> wrote:
> Ooooo, and +B2 breaks sombrero.pov (right half gets cut off completely!).
>

It turns out that the behaviour changes significantly with changes to the
value for NumIterations: 1-10 show only the left half; 11-13,15 render OK;
14 gives a small distortion in the top-middle; 16 gives black distortions
all along the middle vertical. At higher values you get ever changing but
similar distortions.

I've tried a couple of changes to see where the error originates;
hand-calculating Increment, not using all the translations (for instance
everyting is on y=0 instead of rippled), using different ranges for Xc and
Zc, removing the union { } block, using "sphere { 0,1 }" instead of the
BasicShape definition inside the loops, removing the object { } block. In
all these cases the distortions remain the same.

All attempts using the same changes & values for NumIterations without +b2
seem to give no problem at all.

Jeroen.

Post a reply to this message

LoneStar wrote:
> Ooooo, and +B2 breaks sombrero.pov (right half gets cut off completely!).

Fixed, thanks.

-- Chris

Post a reply to this message

LoneStar wrote:
> Something that changed between 11c and 12a (didn't get to 12 in time) broke
> balcony.pov - the glass is now full of clear liquid instead of purple...

fixed, thanks for the report.

-- Chris

Post a reply to this message

LoneStar wrote:
> Just noticed that wineglass.pov renders differently too, though the color is
> still present in the liquid.  The checkerboard pattern is reversed (white
> and black squares are switched).  Weird.

at a guess this may be related to the old half-pixel offset stuff. if you
tweak the scaling in line 225 from <30.0, 4.001, 30.0> to <30.0, 4.000, 30.0>
the issue goes away.

-- Chris

Post a reply to this message

>> Before anybody else asks... is there a good article somewhere that 
>> explains what BSP is, and why it's good?
> 
> 
> http://en.wikipedia.org/wiki/Binary_space_partition_tree

Just says that BSP involves recursively subdividing space and storing 
the chunks in a binary tree. Doesn't really explain why this would be 
useful for the purpose of raytracing.

Post a reply to this message

Invisible wrote:
>>> Before anybody else asks... is there a good article somewhere that 
>>> explains what BSP is, and why it's good?
>> 
>> 
>> http://en.wikipedia.org/wiki/Binary_space_partition_tree
> 
> Just says that BSP involves recursively subdividing space and storing 
> the chunks in a binary tree. Doesn't really explain why this would be 
> useful for the purpose of raytracing.

put simply it's a fast way of finding what objects occupy a given region of
3d space irregardless of the origin and direction of the ray being shot. each
leaf node of a tree represents a particular (possibly overlapping) volume and
contains a list of all objects that potentially occupy that volume (in terms
of their bounding boxes).

so, if we have a start and end point of a ray, and then determine which nodes
the ray crosses through, we have available a list of all objects that it can
possibly intersect. as a general rule, the fewer objects per node the better,
though there would be a point where the time taken to iterate a deep tree may
exceed the time taken to test the bounds of each of the objects in a higher-
level node with multiple objects.

in the ray-tracing community there has for some time been some argument over
the various merits of the BVH (our standard bounding method) vs BSP, with
some folks being strongly pro-BSP, and others usually in the middle (there
don't seem to be a lot of anti-BSP'ers out there:). There's little doubt that
BSP is a very useful technique, but IMO BVH (bounding volume hierarchy) isn't
as bad as some folks seem to think - POV-Ray has done quite well with it for
a long time and it's quite memory-efficient.

-- Chris

Post a reply to this message

> put simply it's a fast way of finding what objects occupy a given region of
> 3d space irregardless of the origin and direction of the ray being shot. each
> leaf node of a tree represents a particular (possibly overlapping) volume and
> contains a list of all objects that potentially occupy that volume (in terms
> of their bounding boxes).
> 
> so, if we have a start and end point of a ray, and then determine which nodes
> the ray crosses through, we have available a list of all objects that it can
> possibly intersect. as a general rule, the fewer objects per node the better,
> though there would be a point where the time taken to iterate a deep tree may
> exceed the time taken to test the bounds of each of the objects in a higher-
> level node with multiple objects.

So is traversing a BSP tree faster than testing a ray against some 
arbitrary bounding box then? Because at the moment, I'm having 
difficulty seeing how dividing space into smaller and smaller "halves" 
is drastically different from just having bounding boxes inside bounding 
boxes...

If you have some insane isosurface object, it's going to take forever to 
trace it no matter what bounding algorithm you use. As I see it, there 
are two main cases where bounding makes things faster:

* You have some object that's slow to do intersection tests on, but 
doesn't take up much of the scene (i.e., you ought to be able to skip 
the intersection test for most rays)

* You have millions of tiny objects. (Most rays will only hit a few of 
them, but testing them all would take forever. A good bounding algorithm 
would skip most of these tests.)

As I understand it, the BVH intersection algorithm goes something like this:

+ Test the ray against the top-level BBs. (Hopefully there are few of 
those.)

+ If any are intersected, test the ray against the BBs they contain. 
Recurse until actual object surfaces are tested. Keep all intersections 
found.

Presumably, the BSP algorithm would go

+ Test ray against the left and right halfs of the top-level box.

+ If either is hit, recurse into sub-boxes (as with BVH).

I'm clearly missing something, because those two don't look 
significantly different. (Obviously, the performance of each is going to 
depend on how well the algorithm that builds the bounding structure does 
its job.)

Post a reply to this message

Invisible wrote:
> 
> If you have some insane isosurface object, it's going to take forever to 
> trace it no matter what bounding algorithm you use.

Not necessarily but creating a tight fitting bounding (no matter if 
using BVH or BSP) is difficult for arbitrary isosurfaces. See:

http://www.imagico.de/fast_iso/patch.html

Concerning which method is 'better' - that quite definitely depends on 
the scene.  And note in POV-Ray the BVH method is combined with Vista 
and Light buffers which can speed up things quite a lot in some cases.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 14 Mar. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

>> If you have some insane isosurface object, it's going to take forever 
>> to trace it no matter what bounding algorithm you use.
> 
> 
> Not necessarily but creating a tight fitting bounding (no matter if 
> using BVH or BSP) is difficult for arbitrary isosurfaces.

I once wrote my own system for splitting an isosurface into a grid of 
"chunks", so POV-Ray would only sample the function near its surface. I 
had constant problems avoiding holes in the surface! :-\

> Concerning which method is 'better' - that quite definitely depends on 
> the scene.

Really? I find that supprising. (And one immediately wanders which kinds 
of scene each one is "best" at...)

> And note in POV-Ray the BVH method is combined with Vista 
> and Light buffers which can speed up things quite a lot in some cases.

Indeed - but it only accelerates camera rays and shadow rays. As soon as 
you have any reflection or refraction on your scene (or a weird camera 
for that matter) these speedups can't help you.

Post a reply to this message

> http://www.imagico.de/fast_iso/patch.html

Tangentally related to the current beta, but... I once though about the 
isosurface tracing algorithm. If I evaluate the function at a particular 
point in space and the result is a large positive value, then given that 
value and the max_gradiant, I know that there can be no surface within a 
sphere of some radius centered at that point.

If POV-Ray would cache this information, we could potentially save a 
hell of a lot of function evaluations. (For example, if the whole length 
of the ray falls within these "empty" spheres, then the ray clearly 
strikes no surface, and there's nothing to evaluate!)

OTOH, how much effort does it take to test a ray against a growing 
multitude of spheres?

Post a reply to this message