"ingo" <nomail@nomail> wrote:

> Would it detect the hole of the doughnut?

"No," because we're only detecting surfaces, but
Yes, because we're doing winding numbers, so you'd be going from the the odd
number of crossings to an even number when you hit the hole.

Picture spearing the doughnut with a bamboo skewer, all the way through.

> Marching cubes should find all cavities in an object.
>
> That brings me to another line of thought. A mesh engine. With the nearly same
> SDL generate mesh' of al POV-Ray objects. Difference would be an added meshify
> keyword with an int for the base resolution of the mesh. A mesh resolution
> multiplier could be set in global_settings so you can make the mesh resolution
> fitting the image resolution.


> Get min-, max_extent of object.
> 1. trace() a corner, lets assume it's a hit.
> 2. At the hit point create a virtual box with the point as center.

Of what size?

> 3. Use the inside() function to test the four corners of the box.

A box has 8 corners.  You now have _7_ left.

> [*]
> Assume one point is inside the object
> 4. Trace from the other corners to the one inside the object to find points on
> thesurface.

You're not going to find (all the) holes with that method. Trace suffers from an
object's (potential) self-occlusion.

> 5.Move the box and repeat. Scan the whole bounding box using cubes.

Marching cubes has a lot to offer, and is definitely something that should be
implemented in parallel to the sort of pseudo-ray-marching method that I
suggested.

Using our primitives vs SDF's necessitates different methods, or at least a
conversion.  I've even looked into generating an SDF from an arbitrary mesh, and
apparently that too is possible with certain software.

Post a reply to this message