Hi David,
On Tue, 2011-01-11 at 07:25 -0600, David Kabala wrote:
> Hi Gerrit,
>
> I don't have any experience making python bindings, but I do with
> creating Lua bindings for OpenSG. In the search for good libraries to
> automate the creation of the bindings I found SWIG to be the most
> useful for my purposes. This allowed most of the bindings to be
> automated. However, I did find it useful to code a few by hand.
>
> Given that Lua, and Python, are dynamically typed, it was possible to
> simplify the binding interface considerably. For all FieldContainers a
> single method can be used for getting a field value and setting a
> field value. As an example (In LUA):
>
> local NewMaterial = OSG.createFieldContainer("SimpleMaterial")
>
> NewMaterial:setFieldValue("ambient", OSG.Color3f(1.0,0.0,0.0))
> NewMaterial:setFieldValue("diffuse", OSG.Color3f(0.0,1.0,0.0))
>
> local NewGeometry = OSG.createFieldContainer("Geometry")
> NewGeometry:setFieldValue("material", NewMaterial)
>
> The setFieldValue method is generic and can be used to change the
> value of any field of any FieldContainer. I don't know if this is any
> help for you, but I wanted to mention it. The Lua support libraries
> can be found on my github for of OpenSG here.
I'm aware of them ;) and coincidently I restarted to look at the toolbox
repositories, in particular the DevMaster branch to merge some changes
back into the main line.
I'm also going to start to think about how we can get the whole of the
DevMaster_Toolbox tree back into the mainline. Currently there are
two elements that I'm not sure about how best to handle, the relatively
big window classes and the event structure. Both are things we have
been avoided to include directly into the core. Similar/limited window
functionality is inside the complex scene manager part, so that part
might be easy to factor out from both variants into a common contrib
lib.
The event structure seems more tricky. Currently the only data flow
model OpenSG is less intrusive working of the changed callbacks as
a model of 'routes' to move data between fields. The event structure
is different in that it is more invasive instantaneous and does not rely
on underlying storage to be changed. What I really would like to avoid
is to have a split so that parts support either one or the other.
But I haven't look at it in to much detail yet, so if anybody has
a good idea how to move forward and get the route/event models into
one model I'm happy to listen ;)
kind regards
gerrit
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
