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.




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;
}





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.



 
 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