OpenMesh 1.9.5 ported to D

[Bill Baxter]

Jascha Wetzel wrote:
> Bill Baxter wrote:

>>> it seems that the c++ version is too complex to be commonly used. 
>>> apparently, only a small subset of the flexibility gets used. it 
>>> might not justify the complexity of the lib.
>>
>> Huh, well compared to the alternatives (LEDA, CGAL, maybe GSL) I found 
>> it to be actually pretty lean, mean and straightforward.  And the LGPL 
>> licensing sits better with me than the licenses of some of the 
>> alternatives.  If anything is holding it back I'd guess it was the 
>> _lack_ of features compared to the others.
> 
> there were some casual comments that made me infer the way OM gets used. 
> maybe i took it out of context. looking at CGAL, OM does appear pretty 
> lean, indeed.
> what i'm missing (or haven't found) in CGAL is a consistent design for 
> meshes. there is HalfedgeDS, Triangulation_*, some boost/graph usage, 
> all in a rather specialized setting.

> bummer! apparently it's not meant to be an open project, despite the 
> name...

Well, we'll put the "open" back in "OpenMesh" with OpenMeshD, by golly!
Just got the Dsource account, so I'll upload soon.

> i'm curious about where it can be taken with D. circulators should 
> simplify to delegates. maybe some of the traits business can be 
> simplified as well.

Well you can't really get rid of the circulators entirely.  Sometimes 
you want to go around the edges of a vertex more than once.  But "one 
time around" is certainly the common case.  A second set of functions 
that provide an opApply for circulators (and iterators) to handle that 
common case would be nice.  Or maybe the easiest is to endow the 
iterators and circulators with an opApply so that this works:
    foreach(vhandle; mesh.vertices_begin()) {
       ...
    }

What I have so far is pretty much a straight up port done in the most 
direct way I could think of, so not much in the way of taking advantage 
of D-specific features.

> one of the things i like about OM is the obvious, yet compact and 
> powerful design for properties. i wish all the standard properties 
> wouldn't be special cases, though. adding a normal to a vertex should 
> just be an ordinary property. algorithms that need a certain set of 
> properties should then be parameterized with property handles.

Interesting.  Yeh, that might be good.  I haven't really analyzed why 
they decided to make normals and such special cases.  Aesthetically 
maybe it's not so great, but is there any major downside?

>>> anyway, i'd use it right away and help improving it, if necessary. 
>>> i've written two specialized mesh structure-sets by now and it's time 
>>> to use a single, generic solution.
>>
>> Cool.  That was my feeling too.  So you're a compiler/debugger guru 
>> *and* a mesh wrangler?!
> 
> nah, just have been a student at the language theory group too. and 
> evidently, i do have too much time on my hands ;)

Take advantage of it while you can.  :-)

>  > I'd probably still be trying to get the port
>> working if it weren't for ddbg.  :-)  Just asked for the dsource account.
> 
> nice. one of my motivations for ddbg comes from writing CG stuff - 
> support verifying numerical algorithms that work with complex data 
> structures on large amounts of data. especially hunting down numerical 
> instabilities has been bothering me severely sometimes. the debugger 
> should be able to help to deal with problems that are difficult to 
> reproduce. ddbg is not there yet, but it'll improve. steadily... :)

Cool.  I wrote a sort of debugger while I was working on my thesis.  And 
it certainly saved my butt - http://www.billbaxter.com/projects/imdebug. 
  Debugging GPGPU algos before I had that to use was killing me.

--bb