🔒 Locked
Triangle subdivision
Advertisement
Original Post
Hi,
I need an algorithm to subdivide a triangle into smaller ones that does not introduce T-vertices into a triangle mesh. Another property I would like to have the algorithm is that the subdivision triangles do not differ too much in shape/area. Thus, any algorithm that creates extra vertices along the triangle''s edges is not suitable.
I have been thinking about creating a vertex at the triangle''s center of mass (calculated by doing v1.Coord+v2.Coord+v3.Coord/3) and splitting the triangle into three pieces (draw a tri on paper, put a dot in the middle, and draw lines from the corners to this dot, now you know what I mean).
This would not generate T-vertices, but it can deliver very odd-shaped triangles which can differ in area considerable, which makes the split less efficient (more splits are needed to come to a certain triangle area).
Is there a better suited algorithm for this, or is there a way to calculate the extra vertex in the triangle in such a way that all three resulting parts have approximately the same area?
Thanks in advance,
DaBit.
I think there''s a pretty strong argument (though not a proof,
obviously) that you just can''t get everything you want. Any
subdivision scheme that doesn''t break up edges is going to introduce at least one point into the interior of the triangle, and the angles of the 3 triangles around that point have to add to 360 degrees, so at least two of them have to be obtuse triangles, generally considered a ''funny'' shape. From another perspective: Since you can''t create vertices on the triangle''s edges, at least three of the created triangles will have one edge as long as the triangle''s original three edges, and their other two edges have to be shorter than the original triangle''s other two, so the ''best to worst'' ratio of edge lengths goes up every time you subdivide (by a factor of about sqrt(3) at best, I think).
I can understand not introducing T-vertices to the mesh, but in general the best subdivision algorithms are likely to take a more global approach to the issue; do you have connectivity information for your mesh? I.e., do you know a triangle''s neighbors? If you do then you can simply subdivide a triangle''s neighbors (often in fan fashion) whenever you subdivide it, and there are a number of references on this -- the ''restricted subdivision'' of spline surfaces, where no two neighbors differ by more than one subdivision level, is one of the best to study.
If you _don''t_ have connectivity information on the mesh, then it may be in your best interests to get it anyway, depending on what you''re subdividing for. Can you give us more details on your problem?
obviously) that you just can''t get everything you want. Any
subdivision scheme that doesn''t break up edges is going to introduce at least one point into the interior of the triangle, and the angles of the 3 triangles around that point have to add to 360 degrees, so at least two of them have to be obtuse triangles, generally considered a ''funny'' shape. From another perspective: Since you can''t create vertices on the triangle''s edges, at least three of the created triangles will have one edge as long as the triangle''s original three edges, and their other two edges have to be shorter than the original triangle''s other two, so the ''best to worst'' ratio of edge lengths goes up every time you subdivide (by a factor of about sqrt(3) at best, I think).
I can understand not introducing T-vertices to the mesh, but in general the best subdivision algorithms are likely to take a more global approach to the issue; do you have connectivity information for your mesh? I.e., do you know a triangle''s neighbors? If you do then you can simply subdivide a triangle''s neighbors (often in fan fashion) whenever you subdivide it, and there are a number of references on this -- the ''restricted subdivision'' of spline surfaces, where no two neighbors differ by more than one subdivision level, is one of the best to study.
If you _don''t_ have connectivity information on the mesh, then it may be in your best interests to get it anyway, depending on what you''re subdividing for. Can you give us more details on your problem?
if you want the same area in each triangle you can just divide it from one point to the midpoint of the opposite segment.
JoeMont001@aol.com
www.polarisoft.n3.net
JoeMont001@aol.com
www.polarisoft.n3.net
Julio: By doing that I create a T-vertex. Do it on paper, and you''ll see what I mean.
Shaterri: You are absolutely right about the triangles getting worser every time. I just wondered if there was another method to get what I want. But now I am thinking of that, you are right that there is not a simple solution for it.
I run into this subdivision problem in a radiosity processor that uses triangular patches. At a certain moment I discover that the patch density is too coarse, and I have to subdivide. The current implemented method is splitting a triangle into 4 equal formed parts with a quarter of the area of the original ones. This method generates T-vertices. And the T-vertices hurt both patch->vertex color mapping and the final rendering stage (cracks). Unfortunately subdivision triangles are kept as children from the original patch to be able to easily distinguish between patches and elements. This ''triangle quadtree'' under each large ''master triangle'' allows me to perform a very quick form factor recalculation when required, and it boosts the radiosity calculation speed.
I was also thinking about extracting triangle connectivity information and using that. (I currently do not extract connectivity info)
It would be the best solution to this problem, but that requires radical changes to my data structures. Not something I really like.
Any ideas left?
DaBit.
Shaterri: You are absolutely right about the triangles getting worser every time. I just wondered if there was another method to get what I want. But now I am thinking of that, you are right that there is not a simple solution for it.
I run into this subdivision problem in a radiosity processor that uses triangular patches. At a certain moment I discover that the patch density is too coarse, and I have to subdivide. The current implemented method is splitting a triangle into 4 equal formed parts with a quarter of the area of the original ones. This method generates T-vertices. And the T-vertices hurt both patch->vertex color mapping and the final rendering stage (cracks). Unfortunately subdivision triangles are kept as children from the original patch to be able to easily distinguish between patches and elements. This ''triangle quadtree'' under each large ''master triangle'' allows me to perform a very quick form factor recalculation when required, and it boosts the radiosity calculation speed.
I was also thinking about extracting triangle connectivity information and using that. (I currently do not extract connectivity info)
It would be the best solution to this problem, but that requires radical changes to my data structures. Not something I really like.
Any ideas left?
DaBit.
It sounds like what you're doing bears a strong resemblance to
hierarchical radiosity, though I suppose it would depend on the
details. If you haven't already, it's worth checking
the radiosity literature for more information there.
On the subject of subdivision etc. -- yes, I'm afraid you're
really going to have to extract connectivity information; if your
data structures don't support it they'll almost certainly have to
be tweaked so they do. It's really very valuable data,
especially when you're continuing to subdivide your mesh (one
thing worth noting -- if possible, you should try and construct
it so that the representation of connectivity from element to
element bears a close resemblance to connectivity within
subpatches of a given element.
Essentially, I think the algorithm you're going to want to use should look something like this (in pseudocode-y Clike form):
RGB values at the * vertex can simply be a linear average of the
four vertices it interpolates between. Alternately, if your HW
is willing you can simply draw that trapezoid as a quadrilateral
and trust the natural interpolation.
Unfortunately, there aren't a lot of great references (so far as
I know) for meshing for radiosity. Both the Cohen/Wallace and
Silion/Puech books only devote a couple of pages to the subject,
and I don't have Ian Ashdown's book to check unfortunately.
Words of warning, though, from Silion and Puech:
"Do not underestimate the cost of designing and implementing a
high-quality meshing module; it can easily account for the
majority of the entire development effort."
Good luck!
(edited many times trying to get tags right)
Edited by - Shaterri on August 24, 2000 10:38:01 PM
hierarchical radiosity, though I suppose it would depend on the
details. If you haven't already, it's worth checking
the radiosity literature for more information there.
On the subject of subdivision etc. -- yes, I'm afraid you're
really going to have to extract connectivity information; if your
data structures don't support it they'll almost certainly have to
be tweaked so they do. It's really very valuable data,
especially when you're continuing to subdivide your mesh (one
thing worth noting -- if possible, you should try and construct
it so that the representation of connectivity from element to
element bears a close resemblance to connectivity within
subpatches of a given element.
Essentially, I think the algorithm you're going to want to use should look something like this (in pseudocode-y Clike form):
|
RGB values at the * vertex can simply be a linear average of the
four vertices it interpolates between. Alternately, if your HW
is willing you can simply draw that trapezoid as a quadrilateral
and trust the natural interpolation.
Unfortunately, there aren't a lot of great references (so far as
I know) for meshing for radiosity. Both the Cohen/Wallace and
Silion/Puech books only devote a couple of pages to the subject,
and I don't have Ian Ashdown's book to check unfortunately.
Words of warning, though, from Silion and Puech:
"Do not underestimate the cost of designing and implementing a
high-quality meshing module; it can easily account for the
majority of the entire development effort."
Good luck!
(edited many times trying to get tags right)
Edited by - Shaterri on August 24, 2000 10:38:01 PM
Some tutorials on cfxweb: (bet there's at least one interresting thing
)
Trimming for Subdivision Surfaces
A Unified Framework for Primal/Dual Quadrilateral Subdivision Schemes
Semi-Regular Mesh Extraction from Volumes
Integrated Modeling, Finite-Element Analysis, and Design for Thin-Shell Structures using Subdivision
Normal Mesh Compression
Subdivision for Modeling and Animation
Anisotropic Feature-Preserving Denoising of Height Fields and Bivariate Data
Curvature
Smoothness of Subdivision Surfaces
Progressive Geometry Compression
Normal Meshes
Subdivision Surfaces: A New Paradigm for Thin-Shell Finite-Element Analysis
Implicit Fairing of Irregular Meshes using Diffusion and Curvature Flow
Multiresolution Mesh Morphing
Subdivision for Modeling and Animation
Wavelets on Irregular Point Sets
Interactive Multiresolution Animation of Deformable Models
Interactive Animation of Structured Deformable Objects
Surface
Drawing
Fine Level Feature Editing for Subdivision Surfaces
Multiresolution Signal Processing for Meshes
MAPS: Multiresolution Adaptive Parameterization of Surfaces
Active Implicit Surface for Animation
A Multiresolution Framework for Vatiational Subdivision
InteractiveMultiresolution Mesh Editing
Wavelets in Computer Graphics (siggraph version)
Interpolating Subdivision for Meshes with Arbitrary Topology
Wavelets in Computer Graphics
Spherical Wavelets: Efficiently Representing Functions on the Sphere
Spherical Wavelets: Texture Processing
Textures & Radiosity: Controlling Emission and Reflection with Texture Maps
On the Formfactor between Two Polygons.

Edited by - baskuenen on August 24, 2000 9:02:55 PM
Trimming for Subdivision Surfaces
A Unified Framework for Primal/Dual Quadrilateral Subdivision Schemes
Semi-Regular Mesh Extraction from Volumes
Integrated Modeling, Finite-Element Analysis, and Design for Thin-Shell Structures using Subdivision
Normal Mesh Compression
Subdivision for Modeling and Animation
Anisotropic Feature-Preserving Denoising of Height Fields and Bivariate Data
Curvature
Smoothness of Subdivision Surfaces
Progressive Geometry Compression
Normal Meshes
Subdivision Surfaces: A New Paradigm for Thin-Shell Finite-Element Analysis
Implicit Fairing of Irregular Meshes using Diffusion and Curvature Flow
Multiresolution Mesh Morphing
Subdivision for Modeling and Animation
Wavelets on Irregular Point Sets
Interactive Multiresolution Animation of Deformable Models
Interactive Animation of Structured Deformable Objects
Surface
Drawing
Fine Level Feature Editing for Subdivision Surfaces
Multiresolution Signal Processing for Meshes
MAPS: Multiresolution Adaptive Parameterization of Surfaces
Active Implicit Surface for Animation
A Multiresolution Framework for Vatiational Subdivision
InteractiveMultiresolution Mesh Editing
Wavelets in Computer Graphics (siggraph version)
Interpolating Subdivision for Meshes with Arbitrary Topology
Wavelets in Computer Graphics
Spherical Wavelets: Efficiently Representing Functions on the Sphere
Spherical Wavelets: Texture Processing
Textures & Radiosity: Controlling Emission and Reflection with Texture Maps
On the Formfactor between Two Polygons.
Edited by - baskuenen on August 24, 2000 9:02:55 PM
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement