View Full Version : Visualization of Tetrahedron Mesh

10-11-2005, 06:50 AM
Hi guys, I have a problem with displaying my 3D model, which is made up of a large amount of connecting tetrahedrons. (~100 000). i have a complete data set of each tetrahedron and the vertices that specify each corner of the tetrahedron. Using this input, i can easily display the model.

but, the surface shown is jagged and not smooth and pleasing to the eye at all. Does anyone knows where i can get the code, or perhaps some ideas to smoothen my surface?

another thing.. i am trying to achieve good lighting effects, which firstly requires me to calculate the normals for each face, and assign this normal to each of the 3 vertices in a face. but then, this is taking up a lot of cpu time as it is only needed to calculate the normals at THOSE polgons at the surface.

so.. does anyone have any source code or algorithms that can enable one to display the surface from a solid 3d data set comprising of vertices?

I really appreciate your help~~!

10-11-2005, 07:37 AM
Why can't you calculate the normals and store them along with the data set. Use VBOs to improve performance. Also enable backface culling to further improve performance.

For smooth surface one way is to subdivide the tetrahedrons to generate a finer mesh. Are you using glShadeModel(GL_SMOOTH) ?

10-11-2005, 07:59 AM
Each vertex connects to multiple triangles in your mesh. You need to average the normals of each vertex using the ajacent triangle normals.

This is addition to the shademodel advice already given will smooth your surface.

You really should mesh those primitives for better performance too.

10-11-2005, 09:26 PM
To enable lighting effects by calculating the normals, I will need to calculate the normals of the surface polygons, and i can further optimise the lighting effects by averaging these normals. so that at any vertex, the total normals contributed by adjacent *surface polygons* are averaged, and *assigned* to that vertex.

but then, when dealin with a 3D data set, each vertex at the surface is a part of not only the surface polygons, but also forms other polygons *beneath* the surface polgons. so, averaging the normals in this case will produce an erroneous result.

therefore, the situation is to identify *which* polgons lie on the surface, save these into an array, and I can do normal averaging *correctly*. =)

As for shading, yes, i enabled backface cullin and shademodel. I think the lightin (and therefore the normals) are givin this problem.

So, back to the question, I really need some insights to identify these surface polygons, so that i can process this data for normal averaging.. Anyone with any ideas/algos?

Thanks for replying guys, I really appreciate it.

10-12-2005, 12:28 AM
I guess this depends completely on your data set. Are you looking for a smooth surface on the "outside" and a "spiky" surface on the "inside"?
Are your edges of the tetrahedrons touching or are they further appart?
You can also search the web for algos dealing with pointclouds...

10-12-2005, 04:27 AM
Hi =)
My tetrahedrons are a closely knit pack; they are all touching together, and obtained from delanur triangulation algorithm. they are not point clouds. Put more succinctly, one vertex can belong to a number of tetrahedrons.. now the thing is still how to identify the surface polygons, which in this case is triangles..

thanks for responding..any other ideas and references though?

10-12-2005, 04:41 AM
You should be able to flag boundary faces during the delauney tetrahedralization stage.

After you have the faces, you can compute vertex normals from the face normals. One simple way that works reasonably well is to add the cross products of each triangle on a vertex (making sure you use consistent winding order), and normalizing this value.


10-12-2005, 05:10 AM
Assuming your tetrahedral mesh is manifold (as delauney ought to guarantee), then boundary faces are going to be the ones that have exactly one tetrahedron on them (interior faces have two).

If you want to iterate through vertices instead, you can measure the solid angles surrounding each vertex. The vertices with total solid angles less than 4PI steradians are on the boundary. This computation requires spherical trig, which sucks harder than regular tri.