Thorsten Froehlich <tho### [at] trfde> wrote:
> On 21.06.10 14:30, Warp wrote:
> > Thorsten Froehlich<tho### [at] trfde>  wrote:
> >>> Native support for mesh-based surface approximations
> >
> >> You can already do this with a macro. Native support would have no benefit -
> >> the probable assumption that a high quality mesh would be faster to generate
> >> and then render compared to a native object (i.e. an isosurface) is incorrect.
> >
> >    Given that meshes which approximate the same shape as a complex CSG
> > composed of other primitves sometimes renders faster than that CSG object,
> > I don't see how an isosurface would be even faster than that. On the
> > contrary, an isosurface with the same shape as the complex CSG most probably
> > would render at least an order of magnitude slower than the original CSG
> > object.

> Not sure where you read isosurfaces are faster than CSG. Oh well :-(

  "the probable assumption that a high quality mesh would be faster to
generate and then render compared to a native object (i.e. an isosurface)
is incorrect."

  If you claim that rendering an isosurface is faster than generating a
mesh from it and then rendering it, you are also implying that rendering
an isosurface is faster than rendering a (complex) CSG because there are
cases where meshes are faster to render than CSG. If meshes are faster than
CSG and isosurfaces are faster than meshes, it logically follows that
isosurfaces are faster than CSG.

  I don't really understand what you base your original claim that
isosurfaces are faster to render than generating a mesh and then rendering
the mesh on.

  There may be extreme cases where a really fast isosurface (one which is
extremely simple, ie. has a very low gradient, such as a sphere) is faster
to render than generating a mesh from it and then rendering the mesh because
of the overhead of the tesselation process (after all, the tesselation
algorithm requires some processing itself). However, that probably only
happens in extremely simple cases.

  In more complex cases tesselating the isosurface is more or less akin
to rendering it at low resolution (because usually it's enough to generate
a mesh which has triangles larger than pixels when projected onto the final
image). Also, when tesselating the isosurface probably needs to be solved
once per mesh vertex, while rendering it might be involve solving it several
times per pixel (eg. in self-reflection, refraction and shadowing situations).
If ray-mesh intersections are faster to compute than ray-isosurface
intersections, then in these cases tesselation + mesh rendering ought to
be faster than direct isosurface rendering.

  Even *if* for some reason tesselating the isosurface would be significantly
slower than rendering it, there may still be advantages of doing that because
the resulting mesh can be stored in a file and then read from there in
subsequent renders. Hence even in that case tesselation would be useful.

-- 
                                                          - Warp

Post a reply to this message