William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/1/20 6:33 PM, Bald Eagle wrote:
> > "Mr" <nomail@nomail> wrote:
> >> Sorry for what may sound like a very basic question : Apart from their names I'm
> >> not sure to fully grasp the distinction between an isosurface and a
> >> parametric... Could you clarify the difference? the paradigms for when to best
> >> use one over the other? is it that one is a surface and the other a volume?
> >
> > I would say that primarily, from an implementation perspective, the difference
> > is that an isosurface evaluates an implicit function - an ordinary function with
> > terms in x, y, and z - and it's a surface where that equation equals the
> > threshold value.
> >
> > A parametric evaluates the x, y, and z coordinates as functions of the
> > parameters u and v, and is a surface as well.
> >
> > They are both slow, or can be, depending on the settings, and the complexity of
> > the equations.
> >
> > So generally, it's a matter of how you conceive of the math(s) involved, and/or
> > whether or not it's even possible to (efficiently) express the desired shape in
> > either implicit or parametric form.
> >
> > A good exercise would be to make a sphere object, using small sphere{}
> > primitives to "plot" the points on its surface.
> > Do it "the isosurface way" using r=sqrt(pow(x,2)+pow(y,2)+pow(z,2)),
> >
> > and "the parametric way" using
> > x = cos (u) * sin (v)
> > y = sin (u) * sin (v)
> > z = cos (v)
> >
> > Where u goes from 0 to tau, and v goes from 0 to pi
> >
>
> I'll add:
>
> @Mr, you are correct that parametrics don't support an inside, a volume,
> while isosurfaces do.
>
> To get acceptable performance with parametrics, you almost always need
> to use the precompute option and this takes quite a bit of storage; On
> the order of a fine mesh for the same surface(1) where the surfaces are
> relatively simple. With the isosurface, both the SDL and internal
> representations are compact.
>
> The parametric as implemented today returns only one surface
> intersection per ray (probably to keep performance reasonable). This is
> sometimes an issue for shadows, csg and ???. IIRC Jerome has a github
> issue or two open on this.
>
> (1) Jerome - not too long ago - added to hgpovray38 an ability to create
> meshes on the fly from parametrics. This is what most other tooling does
> with parametric implementations and the feature should make the renders
> quite fast. However, there will be parametrics where a mesh would be
> prohibitive due size. For example, if using a pattern for very detailed
> surface displacement via the parametric functions, the mesh would need
> to be large to get the representation close to the actual surface. It's
> on my list to play with this new hgpovray38 option, but it has yet to
> bubble to the top.
>
> Bill P.

Interesting... Does that mean than any shape rendered as a parametric could find
an equivalent isosurface? ...But not the other way around...?

Post a reply to this message