|
![](/i/fill.gif) |
In article <qqm### [at] ramsen fmi uni-konstanz de>, Thomas
Willhalm <tho### [at] willhalm de> 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] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |