In article <3ee0e6b6@news.povray.org>, "Shay" <sah### [at] simcopartscom> 
wrote:

> I'm waiting patiently for the camera_view pigment and perhaps at a later
> date a scene pigment where a pigment is taken from an entirely separate
> scene.

I'm not sure how feasible that second one would be. It would require 
duplicating all the internal data structures, something that POV is not 
designed for. You would be better off just putting the camera in another 
area of the same scene.


> The point of my response however is to ask how polygon displacement can
> do anything which isosurfaces cannot do. I would like some clarification
> because now I really cannot see the point.

Some displacements and deformations just can't be done with an 
isosurface. For example, anything that causes the surface to penetrate 
itself, or a surface rippling simulation. In addition, complex 
isosurfaces can get quite slow, and there are graphical modellers for 
meshes.


> What would be interesting is a set of mesh structures which could be
> "built" when rendering and require less memory usage. For example, a
> mesh box which would only need 8 vertices stored in memory. PoV-Ray
> would know where the 12 triangles should be. This would be most useful
> for grass, tiny spaceship details, flower petals, etc.

The example you describe sounds too fine-grained. However, it might be 
useful to store triangles as quads, strips, and fans. Indexes for each 
vertex in the shape would be stored stored once for the shape, instead 
of once per triangle in the shape.

However, this would slow things down by more than just the overhead of 
supporting the new object: these shapes would be larger in size, so 
their bounds would be hit more often, and they would have linear time 
complexity (computation time would be linearly related to number of 
triangles in the shape). Quads usually aren't much bigger than either of 
the triangles they would replace, so they might not be slowed down much, 
but a long triangle strip would perform quite badly. And even if these 
composite shapes were reduced to individual triangles during parsing, 
this idea could greatly reduce parsing time and mesh file sizes.

Another idea I've been thinking of trying in my own raytracer is to 
store vertices with point, normal, UV, and texture information, 
replacing these four indices in the triangle structure with a single 
index. In some meshes, this could save a fair amount of memory. (storing 
3 longs instead of 12 in the triangles)


> Even better would
> be some way to define a set list of triangles (as vertex list
> references) for any list of the correct number of vertices. Just
> throwing this out there. I've of course got no idea how to implement it.

A generalization of the above idea? It might be useful in a few cases.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message