I think I understand the issue. The problem is actually in determining the
external boundary of your grid. Consider a face of a simplex that is
internal to the model - hence matched by a face of a different simplex.
The triangles in the face are geometrically coincident with the
corresponding triangles in the matching simplex face - but are not actually
shared. They refer to different vertices that happen to be geometrically
co-incident. Thus ShowBoundary doesn't recognize them as matching, and
triangles from both faces are considered to lie in the boundary. So you
aren't getting the a set of triangles that model the surface of a torus,
you are getting the set of triangles that are in all four of the faces of
each tetrahedral simplex.
Now consider the shading that would be applied to the external boundary of
a tetrahedron. It would be a very poor approximation of a sphere, since
the tet's triangular faces share the vertices, so the vertex gets a normal
that is the average of the adjacent faces. But now subdivide the faces. A
whole lot of the internal baby triangles share their vertices only with
triangles in the same face, and hence the bulk of the face is essentially
planar-shaded. Only the triangles that have vertices that lie on a face
edge get any contribution from any other face, so as you subdivide the
triangles, the curved portion moves to a narrow strip along the edge of the
tet faces. Which is what you are seeing.
If you are looking for smooth shading across the external surface of the
torus but the surface is comprised of triangles that sometimes do not share
vertices, then you have a difficult problem. If I were you I'd look at
computing my surface normals explicitly, rather than by averaging element
normals. I bet you are using a computational space that is different from
the (xyz) space you are looking at, maybe two angles and a radius, and you
apply a function to that to get the vertex location in (x,y,z) space. If
so, then there is a similar equation you can apply that maps a point in
your original two-angles-and-a-radius space to compute the normal.
Greg
Renato Gomes Damas
<[EMAIL PROTECTED]> To:
[email protected]
Sent by: cc:
[EMAIL PROTECTED] Subject: Re: [opendx-users]
Discontinuous data on tetrahedron mesh and
son.ibm.com ordering of nodes
04/04/2003 04:29 PM
Please respond to
opendx-users
Julien,
I my knowledge is not so deep about this topics, but is some thing like you
have written "I guess it is a problem with opendx treating each (red)
simplex
as if no other simplex were present when it computes the lightning".
best regards!
On Quinta 03 Abril 2003 02:05 pm, julien pommier wrote:
Well I admit my first mail was not very clear ;-) I am well aware of what
you're saying. I'm producing dx files whose data is often discontinuous.
So I don't what to enforce its continuity, hence, as you say, I am using
different set of nodes for each simplex of the mesh. But my test-case was
just to see what is displayed when the data is indeed continuous (the two
nodes which share the same location are assigned the same value), and the
result is not what I expected to see, since the displayed colors are not
continuous across elements!
It looks like a rendering bug, the variation of colors depend on the
lightning angle. It may be clearer on the following example:
http://www.gmm.insa-tlse.fr/~pommier/dx_donut.png
The data that I am trying to represent on this donut is continuous, but it
has been exported as a discontinuous one on a finite element mesh (red
edges). In order to represent high order finite elements, each simplex of
the mesh is refined (the yellow edges). Since the finite element base
functions are continuous, the refined tetrahedra share their nodes inside
each element, but the red tetrahedra do not share there nodes with others.
As you can see, the result is strange: the color are right inside each
element, but they are too dark near the red edges.
So I guess it is a problem with opendx treating each (red) simplex as if
no other simplex were present when it computes the lightning or something
like that.
--
R.G. Damas
Universidade Estadual de Campinas
Faculdade de Engenharia Civil
Laboratório de Mecânica Computacional
+55 19 37882396
