Alain <kua### [at] videotronca> wrote:

Thanks Alain - I'm familiar with all of the primitives and syntaxes - my
question was a deeper one, relating to the source-code/method of generating the
surface.

> > The obvious question is WHY are some of these methods fast and others slow?

I mean, why should there be *ANY* speed difference between an isosurface and a
parametric describing the same surface, and why should the polynomial equivalent
be faster than both of those?

I can only imagine that there must be some increased number of calculations
using one way compared to another, which would account for the speed difference.
 But if we only need to calculate enough points to get "good coverage" - all the
contiguous visible pixels of the surface - then why would there be so many
calculations to slow down the parsing?
And if we're talking about calculating only the pixels that a ray intersects,
then distance from the camera or scaling of the object should impact the speed
with which such a surface renders - scale {0.000001} might make the whole
parametric only cover a single pixel - so why calculate it in its entirety?


> > Another question I have is:  What method is used to determine the fineness of
> > subdivision for calculation of the surface?  Is it a bailout sort of thing, or
> > is there some link to the pixel-coverage, where nothing finer than a pixel is
> > calculated?
>
> That's the role of the «accuracy» parameter found in isosurface and
> parametric. The max_gradient parameter also play a capital role. The
> subdivision is along the tracing ray from the camera outward, possibly
> after some reflection or refraction.

I was under the impression that the primitive was constructed during parsing -
and was independent of the pixel coverage - which would only be relevant at the
time of rendering.  Which is why I'm asking.

> There is no sampling between pixels unless antialiasing kicks in.

There must be calculation "between the pixels" for these surfaces, otherwise one
would only need to provide very small numbers for accuracy, and speed would
never suffer.
I'm envisioning the surface is essentially a point cloud calculated during
parsing, and then the pixels get interpolated (if needed) during rendering.


> > Would it be possible / desirable to define an internal mesh-generation method
> > for rendering complex, time-consuming shapes?

> Converting an arbitrary shape into a mesh is absolutely not trivial.
> Especially if that shape have any overhangs or holes/bubbles in it.
> You may want to take a look at meshmaker.inc
> Note that there are no general or universal way to make that conversion.

Not for arbitrary shapes - but for mathematical ones, it seems pretty
straightforward.  If you lokk at Nylander's code, and the isosurface estimator,
and meshmaker, etc, I'm sure that's how they construct the meshes for those
alternate methods.  And it's "easy" and reliable - because the surfaces are
mathematical.   If they were arbitrary CSG shapes, it would be much more
difficult - the recent work on generating fillets for CSG objects comes to mind.
 Clipka said that if it were _already_ a mesh, it would be "trivial" (no details
provided), but going FROM the CSG of mathematical objects TO a mesh is not (as I
and others have discovered with some of our experiments).

> Many shapes demand custom, specific to them, methods, and it may not
> always be accurate.

True, but I can always project a rectangle onto the surface of a globe - no
matter the terrain, and get the 4 corners.  If the globe is a parametric object
in spherical coordinates, then the finer I subdivide it into rectangles, the
better my approximation will be.
There are no special cases - it's a general method.

Post a reply to this message