Isosurfaces are slow to render sometimes.

What would be good is if there was an option to render them as a mesh with a 
set detail level.

Something like

isosurface
{
  blah
  blah
  blah
  render_mesh 20,10,20
}

Internally the parser would define a 20x10x20 array of points within the 
bounding box of the isosurface, and calculate the isosurface value at each 
point.  Then an algorithm like marching cubes would be used to generate a 
mesh2 object to be rendered instead of the actual isosurface object.

This could be used for fast previews or even final renders if the speed was 
good with large array sizes.

Comments?

Post a reply to this message

> Isosurfaces are slow to render sometimes.
> 
> What would be good is if there was an option to render them as a mesh 
> with a set detail level.
> 
> Something like
> 
> isosurface
> {
>  blah
>  blah
>  blah
>  render_mesh 20,10,20
> }
> 
> Internally the parser would define a 20x10x20 array of points within the 
> bounding box of the isosurface, and calculate the isosurface value at 
> each point.  Then an algorithm like marching cubes would be used to 
> generate a mesh2 object to be rendered instead of the actual isosurface 
> object.
> 
> This could be used for fast previews or even final renders if the speed 
> was good with large array sizes.
> 
> Comments?
> 

That's only useful if you can save the mesh and use it for other 
renders. Some people have shown that generating such a mesh can take as 
long as rendering the isosurface directly. However once you have the 
mesh, you can re-render it a lot faster.

Post a reply to this message

>> Internally the parser would define a 20x10x20 array of points within the 
>> bounding box of the isosurface, and calculate the isosurface value at 
>> each point.  Then an algorithm like marching cubes would be used to 
>> generate a mesh2 object to be rendered instead of the actual isosurface 
>> object.
>>
>> This could be used for fast previews or even final renders if the speed 
>> was good with large array sizes.
>>
>> Comments?
>>
>
> That's only useful if you can save the mesh and use it for other renders.

Yes, that could be a useful feature, allowing the mesh2 to be saved as a 
specified .inc file for inclusion in later renders or an animation.

> Some people have shown that generating such a mesh can take as long as 
> rendering the isosurface directly.

AIUI that's with the mesh generated in SDL.  If the mesh generation 
algorithm were coded directly into the binary then it should run much 
faster.

There are other algorithms that could be used too, like marching triangles 
which are seemingly more efficient than marching cubes.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> That's only useful if you can save the mesh and use it for other
> renders.

#if (generate_mesh = 0)
 #include "my_mesh.inc"
#else
 mesh_generation_macro()
#end

(This is quite similar to the way Radiosity pregeneration works, you'll notice).

Post a reply to this message

> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> That's only useful if you can save the mesh and use it for other
>> renders.
> 
> #if (generate_mesh = 0)
>  #include "my_mesh.inc"
> #else
>  mesh_generation_macro()
> #end
> 
> (This is quite similar to the way Radiosity pregeneration works, you'll notice).

I *always* use this on the global photons block:

#if(file_exists("photons.ph"))
load_file "photons.ph"
#else
save_file "photons.ph"
#end

If I need to re-make the photon map, I invert the condition just for 
that render, or delete the file.

Post a reply to this message

scott wrote:
> [...]
> 
> This could be used for fast previews or even final renders if the speed 
> was good with large array sizes.

Tesselating an isosurface - no matter what kind of algorithm you use - 
is quite slow so a preview render would be a very bad example for using 
such a technique.  The most interesting uses for this would be low 
detail isosurfaces in a slow render or an animation or the possibility 
to edit the mesh in a mesh editor afterwards.  Being able to get a fast 
preview from a detailed isosurface is actually a significant advantage 
of the direct approach.

Apart from that this is a very good example of a feature that would make 
sense to have implemented in a new, more powerful SDL.  Having such a 
technique implemented internally would add considerable bloat unrelated 
to the actual renderer to the source code without a real advantage.

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

in news:474542d3@news.povray.org scott wrote:

> Isosurfaces are slow to render sometimes.
> 
> What would be good is if there was an option to render them as a mesh
> with a set detail level.
> 

IMO adding tesselation of any object would be nice. There is a patch 
for it, but a troublesome one as I understand.

Speed isn't the main thing for me in this, altough it can be usefull 
for animations.

The interesting things with tesselation are what other things one can 
do with a mesh. Think of export to other programms. Manipulation of the 
mesh with POV-Ray, regardless of wether it is done by POV-Ray directly 
or through include files. Think of subsurface division, surface 
displacement, boning, uvmapping etc.

For these I think we'd need a bit extended mesh format, one that also 
accepts (non-flat) polygons.

More important, we'd need to get access to the arrays a mesh2 consists 
of so mesh can be manipulated through SDL.

ingo

Post a reply to this message

"scott" <sco### [at] laptopcom> wrote:
> Isosurfaces are slow to render sometimes.
>
> What would be good is if there was an option to render them as a mesh with a
> set detail level.
>
> Something like
>
> isosurface
> {
>   blah
>   blah
>   blah
>   render_mesh 20,10,20
> }
>


Granted a mesh2 version would be useful as a fast clean version. Another option
(in addition to, not in place of) would be to output to a purely binary file.

A binary file would speed up creating of the file, and reading in at render time
when adding to scenes (faster than mesh2). See chambers mesage at
(http://news.povray.org/476f17c7%241%40news.povray.org)

Maybe not specifically for isosurfaces, but all types of primitives (spheres,
boxes, meshes, etc.) and combinations there of could be created as binary
files.

Wouldn't this be equivalent to instead of "parsing" an "included" ASCII text
file, it would be including a "pre-compiled" binary file?

Comments? Possible? Not Possible?

Post a reply to this message

> Maybe not specifically for isosurfaces, but all types of primitives (spheres,
> boxes, meshes, etc.) and combinations there of could be created as binary
> files.
> 
> Wouldn't this be equivalent to instead of "parsing" an "included" ASCII text
> file, it would be including a "pre-compiled" binary file?
> 
> Comments? Possible? Not Possible?
> 

http://www.tb-software.com/download/pob_sdk.zip

Post a reply to this message

Woody wrote:
> Granted a mesh2 version would be useful as a fast clean version. Another option
> (in addition to, not in place of) would be to output to a purely binary file.
> 
> A binary file would speed up creating of the file, and reading in at render time
> when adding to scenes (faster than mesh2). See chambers mesage at
> (http://news.povray.org/476f17c7%241%40news.povray.org)

I don't think a binary file would be of any use here; as I recall, the 
main speed hit in the parser has nothing to do with parsing text vs 
binary, but rather memory allocation.

My post was about allowing POVers to use binary objects from other 
programs without running them through a converter.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message