www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - OpenMesh 1.9.5 ported to D

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
I ported most of the OpenMesh library from C++ to D 
(http://www.openmesh.org)

It's not available anywhere yet, but it will be eventually, under the 
LGPL licence like its papa.
I'm mentioning it here now because I've just been lazy about putting it 
up.  But if there's interest, I can work a little faster at getting a 
project up for it on dsource.

It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
entirely templates, so doing a wrapper didn't make much sense.

--bb
Sep 22 2007
next sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
Bill Baxter wrote:
 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)
 
 It's not available anywhere yet, but it will be eventually, under the 
 LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting it 
 up.  But if there's interest, I can work a little faster at getting a 
 project up for it on dsource.
 
 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.
 
 --bb

neat! did you contact the maintainers? there is at least one D project at the ACG group atm, there might be people interested in supporting the D port.
Sep 22 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:
 Bill Baxter wrote:
 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)

 It's not available anywhere yet, but it will be eventually, under the 
 LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting 
 it up.  But if there's interest, I can work a little faster at getting 
 a project up for it on dsource.

 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.

 --bb

neat! did you contact the maintainers? there is at least one D project at the ACG group atm, there might be people interested in supporting the D port.

Yes, I contacted them. Initially I was trying to submit patches and stuff against the C++ version for improvements I was making there, but there doesn't seem to be anyone with write access who's interested in maintaining it right now. They responded to my emails (eventually) but that was part of why I decided to just go ahead and port to D, the C++ version seems not to be much of a moving target now. I also asked them if they would be interested in hosting the D port alongside the C++ port, but they said no. Actually the one who responded to me only said "Good work -- never heard of this language.". So I'm just going to put it on dsource. --bb
Sep 22 2007
next sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
Bill Baxter wrote:
 Jascha Wetzel wrote:
 Bill Baxter wrote:
 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)

 It's not available anywhere yet, but it will be eventually, under the 
 LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting 
 it up.  But if there's interest, I can work a little faster at 
 getting a project up for it on dsource.

 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.

 --bb

neat! did you contact the maintainers? there is at least one D project at the ACG group atm, there might be people interested in supporting the D port.

Yes, I contacted them. Initially I was trying to submit patches and stuff against the C++ version for improvements I was making there, but there doesn't seem to be anyone with write access who's interested in maintaining it right now. They responded to my emails (eventually) but that was part of why I decided to just go ahead and port to D, the C++ version seems not to be much of a moving target now.

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.
 I also asked them if they would be interested in hosting the D port 
 alongside the C++ port, but they said no.  Actually the one who 
 responded to me only said "Good work -- never heard of this language.".
 
 So I'm just going to put it on dsource.

uh, that's kind of surprising. maybe that's because the project is officially maintained by the group, but all the initial authors aren't with the group anymore (all but the last of the listed contacts). 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.
Sep 22 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:
 Bill Baxter wrote:
 Jascha Wetzel wrote:
 Bill Baxter wrote:
 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)

 It's not available anywhere yet, but it will be eventually, under 
 the LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting 
 it up.  But if there's interest, I can work a little faster at 
 getting a project up for it on dsource.

 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.

 --bb

neat! did you contact the maintainers? there is at least one D project at the ACG group atm, there might be people interested in supporting the D port.



How do you know? Are you a member of ACG?
 Yes, I contacted them.  Initially I was trying to submit patches and 
 stuff against the C++ version for improvements I was making there, but 
 there doesn't seem to be anyone with write access who's interested in 
 maintaining it right now.  They responded to my emails (eventually) 
 but that was part of why I decided to just go ahead and port to D, the 
 C++ version seems not to be much of a moving target now.

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.
 I also asked them if they would be interested in hosting the D port 
 alongside the C++ port, but they said no.  Actually the one who 
 responded to me only said "Good work -- never heard of this language.".

 So I'm just going to put it on dsource.

uh, that's kind of surprising. maybe that's because the project is officially maintained by the group, but all the initial authors aren't with the group anymore (all but the last of the listed contacts).

They said the group uses it regularly in their projects, so it sounds like it's not 'dead', it's just at a state where they're pretty happy with how it is, and nobody has time to tinker around with it much. I suggested they set up an open repository. Nothing. So I offered to set one up for them. Nothing. Then I suggested at least setting up a mailing list for the project. Nothing. So I offered to set up the mailing list for them. Nothing. Then I submitted patches that make some improvements to the demo programs. Nothing. (By "nothing" I mean they responded to my emails, but didn't commit to doing anything or take me up on my offers.)
 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?! I'd probably still be trying to get the port working if it weren't for ddbg. :-) Just asked for the dsource account. --bb
Sep 22 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Bill Baxter wrote:
 neat! did you contact the maintainers? there is at least one D 
 project at the ACG group atm, there might be people interested in 
 supporting the D port.



How do you know? Are you a member of ACG?

no, just a student. i'm planning on writing my diploma thesis there. if they let me do all the coding in D, that is :)
 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.
 They said the group uses it regularly in their projects, so it sounds 
 like it's not 'dead', it's just at a state where they're pretty happy 
 with how it is, and nobody has time to tinker around with it much.   I 
 suggested they set up an open repository.  Nothing.  So I offered to set 
 one up for them.  Nothing.  Then I suggested at least setting up a 
 mailing list for the project.  Nothing.  So I offered to set up the 
 mailing list for them.  Nothing.  Then I submitted patches that make 
 some improvements to the demo programs.  Nothing.    (By "nothing" I 
 mean they responded to my emails, but didn't commit to doing anything or 
 take me up on my offers.)

bummer! apparently it's not meant to be an open project, despite the name... 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. 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.
 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 ;)
 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... :)
Sep 23 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 23 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Bill Baxter wrote:
 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.

ah, right, and they need some state like the start vertex. actually, the way they look right now is pretty good. foreach ( vh; VertexVertexIterT(mesh, start_vh) ) { ... }
  Or maybe the easiest is to endow the 
 iterators and circulators with an opApply so that this works:
    foreach(vhandle; mesh.vertices_begin()) {
       ...
    }

yep, for those that don't have a state.
 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?

There wouldn't be any advantage at runtime, but FinalMeshItems and AttribKernel would pretty much collapse, simplfying the whole Traits stuff a lot. Unless i'm mistaken, the only benefit from having those two is to check for availability of standard properties at compile-time. In D we can have compile-time checks for any property. Here is a prototype: http://mainia.de/ctprops.d That way, having standard properties merely means having a convention for their names and types. We could therefore easily add a large number of standard properties without bloating the lib and loose a lot of Traits complexity at the same time - D rules :)
 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.

looks interesting. i will try that one next time i do some gpgpu stuff. last time i wrote a lot of test code to check the output - tedious...
Sep 24 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:
 Bill Baxter wrote:
 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.

ah, right, and they need some state like the start vertex. actually, the way they look right now is pretty good.

I went ahead and added those opApplys to the iterators after your suggestion.
 foreach ( vh; VertexVertexIterT(mesh, start_vh) ) { ... }

  Or maybe the easiest is to endow the iterators and circulators with 
 an opApply so that this works:
    foreach(vhandle; mesh.vertices_begin()) {
       ...
    }

yep, for those that don't have a state.

They all have a state. You mean for those that don't need a particular starting state?
 There wouldn't be any advantage at runtime, but FinalMeshItems and 
 AttribKernel would pretty much collapse, simplfying the whole Traits 
 stuff a lot. Unless i'm mistaken, the only benefit from having those two 
 is to check for availability of standard properties at compile-time.
 In D we can have compile-time checks for any property. Here is a prototype:
 http://mainia.de/ctprops.d

That is pretty slick.
 That way, having standard properties merely means having a convention 
 for their names and types. We could therefore easily add a large number 
 of standard properties without bloating the lib and loose a lot of 
 Traits complexity at the same time - D rules :)

I think would still be useful to have the most common types -- Point, Normal, etc, defined as part of the mesh type since most practical algorithms require those. I hacked up your ctprops to do something along those lines. I also think that it's good to be able to define your mesh at some point as class Mesh(traits = DEFAULT_TRAITS) so that if you just want a "standard mesh" you don't have to think too much. In other words there needs to be a way to define a set of Prop!s. So I whipped something up along those lines and put it here. http://www.dsource.org/forums/viewtopic.php?p=16708#16708 Apart from the properties I think it might be nice if you could supply a template mixin to the Mesh, and it would mix that for you. In that way you can inject whatever you want into your MyMesh type. In C++ I'd make it a base class alongside the PropertyContainer thing. But no MI in D... Maybe PropertyContainer could be a member of the mesh instead of a base. --bb
Sep 24 2007
parent reply Jascha Wetzel <firstname mainia.de> writes:
Bill Baxter wrote:
 I went ahead and added those opApplys to the iterators after your 
 suggestion.

ah, ic. i was already wondering there :)
  Or maybe the easiest is to endow the iterators and circulators with 
 an opApply so that this works:
    foreach(vhandle; mesh.vertices_begin()) {
       ...
    }

yep, for those that don't have a state.

They all have a state. You mean for those that don't need a particular starting state?

no, i mistakenly assumed there might be circulators without state. then we could have had methods for the mesh class, that return delegates that can be used in foreach loops.
 Apart from the properties I think it might be nice if you could supply a 
 template mixin to the Mesh, and it would mix that for you.  In that way 
 you can inject whatever you want into your MyMesh type.  In C++ I'd make 
 it a base class alongside the PropertyContainer thing.  But no MI in 
 D...  Maybe PropertyContainer could be a member of the mesh instead of a 
 base.

actually, since the prototype does not distinguish between vertex-, halfedge- and face-properties, making the PropertyContainers members is mandatory anyway. besides that, i think the easiest way to add mixins is to have a wrapper template: class MixinMesh(alias MT, P=DEF_PROPS!(), T...) : Mesh!(P,T) { mixin MT; }
 http://www.dsource.org/forums/viewtopic.php?p=16708#16708

the rest of my answer is over there.
Sep 25 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jascha Wetzel wrote:
 Bill Baxter wrote:
 I went ahead and added those opApplys to the iterators after your 
 suggestion.

ah, ic. i was already wondering there :)
  Or maybe the easiest is to endow the iterators and circulators with 
 an opApply so that this works:
    foreach(vhandle; mesh.vertices_begin()) {
       ...
    }

yep, for those that don't have a state.

They all have a state. You mean for those that don't need a particular starting state?

no, i mistakenly assumed there might be circulators without state. then we could have had methods for the mesh class, that return delegates that can be used in foreach loops.
 Apart from the properties I think it might be nice if you could supply 
 a template mixin to the Mesh, and it would mix that for you.  In that 
 way you can inject whatever you want into your MyMesh type.  In C++ 
 I'd make it a base class alongside the PropertyContainer thing.  But 
 no MI in D...  Maybe PropertyContainer could be a member of the mesh 
 instead of a base.

actually, since the prototype does not distinguish between vertex-, halfedge- and face-properties, making the PropertyContainers members is mandatory anyway.

Good point.
 besides that, i think the easiest way to add mixins is to have a wrapper 
 template:
 
 class MixinMesh(alias MT, P=DEF_PROPS!(), T...) : Mesh!(P,T)
 {
   mixin MT;
 }

Hmm. Yeh, I guess if you're talking about letting users add extra stuff that the mesh internals don't use and aren't aware of, then there's not much reason to inject it into the low level. The above could just as well be a user derived class. No need for the mixin, and certainly no need for it to be provided by the library.
  > http://www.dsource.org/forums/viewtopic.php?p=16708#16708
 
 the rest of my answer is over there.

Unfortunately "over there" seems to be down right now, so I'll check out your reply later. Ah, the joys of forums... --bb
Sep 25 2007
parent Jascha Wetzel <firstname mainia.de> writes:
Bill Baxter wrote:
 besides that, i think the easiest way to add mixins is to have a 
 wrapper template:

 class MixinMesh(alias MT, P=DEF_PROPS!(), T...) : Mesh!(P,T)
 {
   mixin MT;
 }

Hmm. Yeh, I guess if you're talking about letting users add extra stuff that the mesh internals don't use and aren't aware of, then there's not much reason to inject it into the low level. The above could just as well be a user derived class. No need for the mixin, and certainly no need for it to be provided by the library.

oh, you're right of course. but it looks more interesting than a profane subclass ;)
Sep 26 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I also asked them if they would be interested in hosting the D port 
 alongside the C++ port, but they said no.  Actually the one who 
 responded to me only said "Good work -- never heard of this language.".

He's heard of it now!
Sep 27 2007
prev sibling next sibling parent reply Will (quartz) <william.quartz gmail.com> writes:
Bill Baxter Wrote:

 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)
 
 It's not available anywhere yet, but it will be eventually, under the 
 LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting it 
 up.  But if there's interest, I can work a little faster at getting a 
 project up for it on dsource.
 
 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.
 
 --bb

I would be interested in using it. I have a hacked together structure and have really wanted to standardize on something. Will OpenMeshD have places to "plug-in/provide" importers. I am currently importing x3d into my app that interfaces to ODE.org. -Will
Sep 23 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Will (quartz) wrote:
 Bill Baxter Wrote:
 
 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)

 It's not available anywhere yet, but it will be eventually, under the 
 LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting it 
 up.  But if there's interest, I can work a little faster at getting a 
 project up for it on dsource.

 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.

 --bb

I would be interested in using it. I have a hacked together structure and have really wanted to standardize on something. Will OpenMeshD have places to "plug-in/provide" importers. I am currently importing x3d into my app that interfaces to ODE.org.

It's not set up to have dynamic plugins (as in loaded from a dll), but it isn't hard to compile in new importers/exporters. But OpenMesh is an implementation of a half-edge mesh data structure which is really more useful for implementing mesh manipulation algorithms (mesh smoothing, LOD algos). If all you want to do is render or deform, then all the connectivity info in a half-edge data structure is wasteful. Also the current code doesn't handle texture maps very well. At least the current loaders just ignore textures. That's one thing I'd like to fix, because I need textures. I think the loaders could be improved to store the texture info in mesh-level properties, but the main issue I think is what representation to use for textures. Anyway, there's a forum now, thanks to Brad, so maybe OpenMesh/D specific chat should be moved over there: http://www.dsource.org/forums/viewforum.php?f=159 --bb
Sep 23 2007
prev sibling parent reply Ansible <notmyemailaddress nospam.com> writes:
Bill Baxter wrote:
 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)
 
 It's not available anywhere yet, but it will be eventually, under the 
 LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting it 
 up.  But if there's interest, I can work a little faster at getting a 
 project up for it on dsource.
 
 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.
 
 --bb

Very cool! I'm interested in doing some 3d mesh manipulation myself, and exploring D at the same time. Here's a bit of an OT question for you: I have a 2d laser triangulation scanner sitting in my office, which I use for work. You can push an object through the scanner and create a point cloud that more-or-less approximates the object. I've gotten interested in writing something to turn this point cloud into a 3d model. I've done it in C++, but its not quite where I want it to be - it doesn't handle objects like rabbit ears or coffee cups - but as long as you want to scan cigars, you're fine. Can you recommend a lib or algorithm out there for doing this kind of work? From a brief overview of the openmesh website it looks like this isn't the kind of thing openmesh does, its more the kind of thing that openmesh is used to make. Ben
Sep 25 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Ansible wrote:
 Bill Baxter wrote:
 I ported most of the OpenMesh library from C++ to D 
 (http://www.openmesh.org)

 It's not available anywhere yet, but it will be eventually, under the 
 LGPL licence like its papa.
 I'm mentioning it here now because I've just been lazy about putting 
 it up.  But if there's interest, I can work a little faster at getting 
 a project up for it on dsource.

 It's a 100% native D port rather than a wrapper.  OpenMesh is almost 
 entirely templates, so doing a wrapper didn't make much sense.

 --bb

Very cool! I'm interested in doing some 3d mesh manipulation myself, and exploring D at the same time. Here's a bit of an OT question for you: I have a 2d laser triangulation scanner sitting in my office, which I use for work. You can push an object through the scanner and create a point cloud that more-or-less approximates the object. I've gotten interested in writing something to turn this point cloud into a 3d model. I've done it in C++, but its not quite where I want it to be - it doesn't handle objects like rabbit ears or coffee cups - but as long as you want to scan cigars, you're fine. Can you recommend a lib or algorithm out there for doing this kind of work? From a brief overview of the openmesh website it looks like this isn't the kind of thing openmesh does, its more the kind of thing that openmesh is used to make.

Google for phrases like "surface reconstruction from point cloud data" or "from scattered data". I don't know of any particular algorithms off the top of my head, but I know moving least squares (MLS) and radial basis functions (RBFs) are both frequently used components of algorithms. One thing you might like to do with the mesh one you've extracted it from the scanner data is to apply some smoothing algorithms to reduce scanner noise. And for that OpenMesh should be appropriate. There are some smoothing algorithms already implemented in there. (Caveat: I haven't verified the functionality of the smoothers, but the code compiles, and given that it's a pretty mechanical translation of the C++, if the C++ worked chances are good this does too. If not it should only take a minor tweak or two.) --bb
Sep 25 2007
prev sibling parent Jascha Wetzel <firstname mainia.de> writes:
Ansible wrote:
 I have a 2d laser triangulation scanner sitting in my office, which I 
 use for work.  You can push an object through the scanner and create a 
 point cloud that more-or-less approximates the object.
 
 I've gotten interested in writing something to turn this point cloud 
 into a 3d model.  I've done it in C++, but its not quite where I want it 
 to be - it doesn't handle objects like rabbit ears or coffee cups - but 
 as long as you want to scan cigars, you're fine.
 
 Can you recommend a lib or algorithm out there for doing this kind of 
 work?  From a brief overview of the openmesh website it looks like this 
 isn't the kind of thing openmesh does, its more the kind of thing that 
 openmesh is used to make.

i happen to know this one: http://research.microsoft.com/users/hhoppe/recon.pdf it's for 3d point clouds. it uses k-nearest neighbors of a point to approximate a best fitting plane using least squares, like Bill mentioned. using these planes, a (volumetric) signed distance function can be approximated. then you can use the marching cubes algorithm to triangulate the surface. if your scanner can provide a set of 2d range images instead of a 3d point cloud, you can use a trivial triangulation of the regular grid. then the tricky part is to join the images into a 3d model. you'll find algorithms for that searching for "registration integration laser range image".
Sep 26 2007