Is there some ready to use #macro  with will turn my object into mesh?

It would be usefull for example for complicated isosurface, to speedup
rendering at expense of memory usage (for hi-quality mesh).
Yes, I know the object will be only approximated by triangles.

Best, if such macro would have options for quality of triangulation and so
on.

-- 
Rafal Maj Raf256

Post a reply to this message

Rafal Maj Raf256 wrote:
> Is there some ready to use #macro  with will turn my object into mesh?
> 
> It would be usefull for example for complicated isosurface, to speedup
> rendering at expense of memory usage (for hi-quality mesh).
> Yes, I know the object will be only approximated by triangles.
> 
> Best, if such macro would have options for quality of triangulation and so
> on.
> 
All I know of is Ingo's includes which convert parametric equations to mesh:
http://members.home.nl/seedseven/

and the fact that the heightfield object will accept a function:
height_field {
                 function 100,100 { f_wrinkles(x,y,z) }
                 scale <1, .005, 1 >
}

Post a reply to this message

Wasn't it Rafal Maj Raf256 who wrote:
>Is there some ready to use #macro  with will turn my object into mesh?
>
>It would be usefull for example for complicated isosurface, to speedup
>rendering at expense of memory usage (for hi-quality mesh).
>Yes, I know the object will be only approximated by triangles.
>
>Best, if such macro would have options for quality of triangulation and so
>on.

It turns out that in most cases converting a non-parametric isosurface
into a mesh of reasonable quality takes much longer than rendering the
isosurface. That's because the conversion macro has to go hunting for
points on the surface at parse time in the same sort of way that the POV
renderer hunts for them at render time. The macro doesn't have to
evaluate as many points as the renderer does, but it runs in POV SDL
code which is a bit slower than C.

It may be possible to gain a speed advantage if you're using the same
isosurface in each frame of an animation, by saving the mesh to a file
rather than calculating it for each frame.

<http://www.econym.demon.co.uk/isotut/approx.htm>

See this page also for the parametric case, for which a mesh macro
generally does run much faster.

<http://www.econym.demon.co.uk/isotut/param.htm>

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

nos### [at] econymdemoncouk news:pVu### [at] econymdemoncouk

> <http://www.econym.demon.co.uk/isotut/approx.htm>
> <http://www.econym.demon.co.uk/isotut/param.htm>

Thanks, that is exacly it :)

> It turns out that in most cases converting a non-parametric isosurface
> into a mesh of reasonable quality takes much longer than rendering the
> isosurface.

Yes, but if scene uses hi-quality radiosity, area-lights, reflections, DOF, 
and so on, and calculating each pixel of image have to trace thiusands of 
points, half of them hitting isosurface? 

Also, I can once create isosurface and the re-run render playing with some 
settings like lights, other objects, camera, and so on :)

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

Mike Williams wrote:

> 
> It turns out that in most cases converting a non-parametric
> isosurface into a mesh of reasonable quality takes much longer
> than rendering the isosurface.

For a generalized algorithm capable of triangulating *anything*, this is 
true. Applying whatever human knowledge you have of the general 
topography of the isosurface could allow a more effecient searching 
algorithm, however. A simple example would be a heightfield, but this 
idea can be extended to many other topologies.

  -Shay

Post a reply to this message