[Bf-committers] Report of HE Mesh

Jean-Luc Peuriere jlp at nerim.net
Mon Mar 7 00:14:28 CET 2005

Le 6 mars 05, à 23:13, joeedh a écrit :

> joeedh wrote:
>> Hi.  Here is the current feature (and bug) list of HE Mesh.

That's good news. But the first thing is still to define exactly what 
you want to support, there is many variations on the half-edge :

- Closed mesh only or open ?
- if open, allowing inner boundaries ?
- genus order supported ?
- holes in faces ?
- face in face ?
- genus handles starting from a face in face
- multiples shells, multiples components (mandatory, but handling 
depend if we support holes in faces) ?
- exceptional vertexs ? (eg  2 pyramids joined by the point, handling 
change if hole in faces or not)
**- supporting reflexive half edges ( edge with same face on each side, 
ie tube with one seam) ?
**- supporting tube with no seam ? ( from a topological point of view, 
if open at each end, it is the same as a face with hole, but change the 
requirements on structs if not)
- degenerates cases (eg edge with no face, isolated vertices)
And i forgot certainly more. For making things even more complex all 
those features are not independant

(the 2 marked ** would cause problems to other parts of blender i think)

Considering how half-edge work, it is very important to define that 
from the start.
Both the structs to use and the tools to manipulate them will change 
according to those choices with rapidly increasing complexities. Once 
one level of support is defined, it will be hard to change to more 
complex types.

The difficult point in half-edge is to validate the datas, it is 
important to use only low level Euler operators which insure a valid 
mesh is still valid after using them. Those operators and the 
validation formula changes with the kind of half-edge mesh. Any 
operation can be expressed as a combination of those operators

Also, do you want to make room for further expansion, like 
multi-resolution meshes ?
> BTW, do you think I really have to have the renderconverter code 
> working before posting testing builds for the users?  That's really 
> and truly the only major hurdle right now: You cannot render what you 
> make.

testing build forum is for finished or at least mostly completed work 
imho. and render code is the most important

As i said before, i will help you on that project. i will prepare a doc 
(this week i think) listing the options that i think possible.

Then you will have to provide an up to date patch file, i can (with 
others) analyze and give you feedback of. but without first defining 
completely the goal, i cannot do anything.


More information about the Bf-committers mailing list