> Martin, > > Using depthorder is creative. I'd like to point out that depthorder is > only an approximation to what should be "hidden surfaces". I worked on > many aspects of gnuplot. Although gnuplot does have a hidden line > algorithm (i.e., it can break a mesh into line segments--based on > intersections of lines--and discard those segments which are hidden by a > surface), it doesn't have an algorithm that breaks surfaces into > triangles--based on intersections of surfaces--and discard hidden surfaces. > So depthorder is an approximation that quite often has patch that seems > out of place, sticking through a surface it shouldn't, etc. >
Hi Daniel, I am absolutely aware of that, this is also true with all opengl implementations when it comes to transparent surfaces if triangles or quadrilaterals intersect each other. The trivial feature I have shown just works of course with the triangle meshes created by isosurface (their topology is by design of the algorithm created in a way that different triangles cannot intersect (except the common edges), this is a consequence from the mathematical property of a n-1 dimensional manifold defined by F(x) = const, where x in R^n and F(x) in R and F regular enough and the fact that the voxels in the cube are assumed to be mutually disjoint except the common faces). > I've always felt motivated to write a hidden surface algorithm but hadn't > found the time given how much work that would require. Even the syntax > "depthorder" would be nice to deprecate, and instead simply refer to it as > "hidden". > The problem with a general hidden surface algoritm will be (just an assumption) the runtime complexity, it may be takes not into account such special properties like the one mentioned above, that a triangle mesh is by design not selfintersecting and then a general algorithm leads to an exhaustive consumption of memory and cpu power in cases where it is not neccessary. Comparable to the situation if you use delaunay triangulation to triangulate a large rectangular grid compared to the solution where you simply define two triangles per cell. May be I am wrong and there are high performant general algorithms available now. I wrote what was my experience more than ten years ago when I worked with things like that (especially with opengl and transparency and ray casting through domains bounded by not convex and possibly selfintersecting triangle meshes), so I am surely not an expert. And please don't understand me wrong a general hidden line and hidden surface algorithm would be a really wonderfull thing, but also specialized solutions which take care of specialized input where a high performant solution is appropriate. > It sounds like David Bateman has a lot of knowledge about 3D visualization. > Perhaps a long term project could be started for gnuplot, but it would be > a while before I could work on such a project. > > Dan > David, is there place you can point me to see what you tried exactly for general not triangular patches maybe it can help me to get a new idea (or to give up)? Then in addition a question to everyone: Isn't it better to find a solution for gnuplot which works with triangles (and may be quadrilaterals) for the moment as intermediate step instead of a simple error message telling us that nothing is possible? At least it would enable us to implement things like "trisurf" and "patch" for triangle meshes (allways with the knowledge in mind that selfintersections may lead to disturbing visual effects if the triangles are not very small). - mh ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
