Hi Guys, For 2.9.x we a not far away from a feature freeze so adding lots of extra code is not appropriate.
Longer term I'd love to see us properly solve the issues of language wrappers and introspection for the OSG in a way that is easy to maintain for all involved. What form this might take I don't know. My original hope was that osgIntrospection would be the basis of solving these problems, but alas this hasn't picked up the usage out in the community. I believe it would be inappropriate to have two different schemes for wrapping though, so if we introduce a new scheme it'll need solve be fit to replace osgIntrospection's place in the core OSG, rather than just add another scheme that runs in a parallel. W.r.t MixinVector, have a look at the svn logs from include/osg/Array to see the author and details of why the changes we required. The quick answer is that in C++ you need a virtual destructor to do inheritance, but std::vector<> doesn't have one, so the results on inheriting from it are undefined and can lead to memory leaks. Robert. On Tue, Aug 4, 2009 at 3:46 PM, Gerwin de Haan<[email protected]> wrote: > Hi Luigi, Frank and others, > > FYI I am currently using osgswig with a "patched" osg 2.9.5. This patch > consists of reverting the MixinVector stuff from osg 2.6+ with the standard > std:vector alternative in osg 2.4 so osgswig can wrap the VecArrays again. I > have tried this only on linux, and I'm not sure if I break anything in osg > itself by messin' up MixinVector. > > Luigi, I am interested in your modifications, could you send them to me so I > can integrate them? > > First thing would be to make a list of things that are wrapped or are > ignored. I started working in that direction by using a wrapped version of > osgIntrospection to inspect what's available in the osg libraries and > plugins. Adding unit tests for basic instantiation would be a bonus. > > As far as automation of the process goes, I'm keen to see what the > techniques from the new wrapITK could bring us. > (http://code.google.com/p/wrapitk/) My colleagues tell me ITK is bigger a > beast than osg, an heavy on STL templates and nested classes, but that their > Python/Java wrappings are impressive. > > As far as (potential) users go, please mail me your name, > company/institution and a use case so I can update "the list" > (http://code.google.com/p/osgswig/wiki/UsingOsgswig). Hopefully we can > convince others (e.g. bosses, colleagues) that working on and working with > osgswig is useful. > > regards, > Gerwin > > > On Tue, Aug 4, 2009 at 4:15 PM, Frank Midgley <[email protected]> > wrote: >> >> On Aug 4, 2009, at 7:55 AM, Luigi Calori wrote: >> >>> I'm unwilling to update as each time I update osg... there are some >>> problems with swig wrapping. >>> One of the worst issues has been the MixinVector that has broken all >>> the vecArrays wrapping thus preventing python construction of geometry. >>> I do not know weather Robert is aware of the hassle this mod has caused >>> to osgswig users. >> >> >> I'm still running against OSG 2.6 but was finally able to construct custom >> geometry via Python with code similar to the following: >> >> def vectorArrayFromList(vectorList): >> from ctypes import * >> vectorArray = osg.Vec3Array(len(vectorList)) >> arrayPointer = >> pointer(c_float.from_address(int(vectorArray.getDataPointer()))) >> vectorSize = vectorArray.getDataSize() >> offset = 0 >> for vector in vectorList: >> for dim in range(3): >> arrayPointer[offset + dim] = vector[dim] >> offset += vectorSize >> return vectorArray >> >> The vectorList argument should be a list of tuples to stick into the >> array, e.g. [(1.0, 2.0, 3.0), (4.0, 5.0, 6.0)]. The trick is to take >> advantage of the Vec3Array constructor that takes just a length argument. >> You get a vector full of (0.0, 0.0, 0.0) values which you can then replace >> with real data via ctypes. I adapted this from Randolph Fritz's post to >> osg-users >> (<http://www.mail-archive.com/[email protected]/msg23368.html>). >> >> You can do the same thing for primitive sets: >> >> def primitiveSetFromList(primitiveType, vertexIndexList): >> from ctypes import * >> primitiveSet = osg.DrawElementsUInt(primitiveType, >> len(vertexIndexList)) >> arrayPointer = >> pointer(c_uint.from_address(int(primitiveSet.getDataPointer()))) >> offset = 0 >> for vertex in vertexIndexList: >> arrayPointer[offset] = vertex >> offset += 1 >> return primitiveSet >> >> I haven't done massive testing but it's working fine so far on both Mac OS >> X and Win XP… >> >> -Frank >> >> ------------------------------------ >> Frank Midgley >> HHMI JFRC - Scientific Computing >> [email protected] >> (571) 209-4629 >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
