In article <qqm### [at] ramsenfmiuni-konstanzde>, Thomas 
Willhalm <tho### [at] willhalmde> wrote:

> I agree (at least) on the second. We should also add NURBS support.
> Both would make it easier for modellers to export to POV-Ray.

At the very least, adding subdivision capabilities to the mesh object 
would be useful. You could just export the NURBS object to a medium 
resolution mesh, and use adaptive subdivision to get rid of the 
faceting. Adding NURBS support isn't a bad idea, just not as useful.


> However, I think we should try another approach in POV-Ray than 
> triangulate the objects. I really like the fact that POV-Ray has a 
> variety of objects like spheres, boxes, cylinders, planes, etc. 
> That's why I don't like the idea of converting them into triangles, 
> even if it only the case for some objects. Particularly, I don't like 
> this idea, because we have an alternative which fits better in the 
> philosophy of POV-Ray IMO: isosurfaces. For me, they are something 
> like an extension of blobs and polynomial objects.
> 
> Why should we choose to use isosurfaces when the rest of the world 
> likes triangles? First, we already have them in the megapatch and 
> will have them in POV-Ray 3.5 (as far as I know). Second, at least 
> displacement maps are possible with them. You didn't comment on my 
> picture 
> (http://www.fmi.uni-konstanz.de/~willhalm/bilder/displace.jpg), but I 
> think that it is not too far away from the image at 
> http://graphics.stanford.EDU/papers/displace/ (I even consider my 
> picture as a proof of concept.) I'm almost sure, that smooth 
> conjunctions are possible as well. The recent images in p.b.i with 
> blobs suggest this.

Isosurfaces can be slow, they are one of the objects that would benefit 
the most from tesselating. Even if the tesselated version was just used 
to bound the "conventional" version.


> So, what we need is a mechanism to automagically convert CSG objects
> to isosurfaces inside POV-Ray.

An interesting idea, but isosurfaces are already capable of CSG...and 
making sharp edges smooth would still be quite difficult. This is 
possible with isoblobs, though you still have to come up with the 
density equations, and it only does union-like things.
How would you do CSG on the isosurfaces to end up with rounded edges? 
They are basically density fields...if you defined a desity field for 
every shape, how would you manipulate them to simulate difference, 
intersection, and merge(union would be impossible this way), and still 
retain accuracy and something close to the current CSG syntax?

What I am thinking of is a separate set of commands for operating on 
meshes, and maybe including a "make_mesh()" function that takes an 
object and some parameters and returns a mesh. Things like:

// These operate differently from ordinary CSG, they only use meshes.
// Maybe they should be functions, I'm not sure...
merge_meshes {}
union_meshes {}
difference_meshes {}
intersect_meshes {}

// If used on an object which can't be reduced to a mesh, like
// an infinite plane, these either make a close approximation
// or return an empty mesh(and make a warning).
make_mesh(OBJECT, PARAMETERS)         // returns a mesh
  // make_mesh() is more consistant with the others, maybe tesselate()?
subdivide_mesh(MESH, PARAMETERS)      // returns a mesh
smooth_mesh(MESH, PARAMETERS)         // returns a mesh
displace_mesh(MESH, WARP, PARAMETERS) // returns a mesh
  // Uses a warp to displace the mesh. Displacements should also work
  // on pigments, textures, etc.
  // Maybe add a new warp type that uses 3 (x,y,z) functions.

There would also be parameters for the mesh object itself to adjust 
render-time subdivision, like bezier patches do.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message