Hi Jan,

On Dec 8, 2007 7:11 PM, Jan Ciger <[EMAIL PROTECTED]> wrote:
> Another good contender for integration would be some physics engine. I
> have experience with ODE, Bullet and the Opal wrapper, all three are
> reasonably usable with OSG (I have running code for this). However,
> physics integration is a bit more involved - there needs to be support
> for loaders of physically-simulated objects because the collision
> proxies need to match the geometry being displayed and the rigid bodies
> being simulated need to be initialized as well. Collada has some support
> for this already and it would be great to have this integrated. I know
> that Bullet has a Collada loader implemented already. One really cool
> thing would be to integrate osgCal with e.g. Bullet or ODE to provide
> rag dolls - I have this on my plate for a while already, unfortunately
> the days have only 24 hours :)

I have been thinking about physics integration as well, but not
suggested it on this round as there wasn't a contender sitting of the
shelf ready to integrate.

Longer term I'd like to see physics integration, ideally in a way that
we can plug in different physics engine implementation, be them open
source or commercial.  OPAL might the a basis for such an
implementation, or perhaps just inspiration to how to tackle/how not
to tackle it ;-)

I'd suggest member of the community experienced in this area propose
what they see as a workable route forward.  Even better get some code
together for it 8-D


> > One has to ask
> > which scripting languages to go for - Lua and/or Python?  Lua would be
> > the easiest to integrate in terms of being very self contained i.e.
> > which could stick the whole of the lua interpreter into the core OSG
> > distribution and one would hardly notice as its so tiny.
>
> That does not make really sense.

And that doesn't really parse ;-)

>There are actually two very different
> ways of integrating scripting:
>
> 1) Application is written in C/C++ and calls embedded scripts. This is
> fairly typical for game development - game is written in C/C++ and e.g.
> AI is scripted using a built-in scripting engine. Here Lua is great (it
> was written for it), because it is fairly easy to maintain separation
> between different scripts (exception/error in one script does not crash
> the whole thing). Furthermore, Lua is really tiny, with negligible
> overhead. Another contender is Javascript (e.g. VRML standard uses it
> for exactly this purpose). I wouldn't target this case, because it is
> very application-specific and there is little a generic scene graph
> binding could provide to it.
>
> 2) Application is written in a high level language and calls into C/C++
> code to run the performance critical stuff. I think that this is what
> you want ("... enable us to
> develop applications purely from scripting languages, so developers in
> this realm would just need the binaries to the OSG installed, and no
> need for C++ dev environment").
>
> In this case I would go for a full featured language with a rich set of
> libraries. Python trumps Lua very easily here with its huge collection
> of libraries and tools. Lua is a very minimalistic language designed for
> embedding, not for writing whole applications in. Soya3D 3D engine is
> written in this manner - programs are written in Python, calling C/C++
> libraries that provide the functionality on top of OpenGL.
>
> Moreover, the Python bindings (osgPython?) do exist already, even though
> probably unmaintained at the moment ...

Agree with all the above, and this is what I had in mind with my own
introduction of motives.

One of the reasons to integrate osgLua and/or osgPython with the core
is facilitate all the above usage, but also help consolidate the
effort on making these libraries better supported and maintained.
There libraries will need work to get them fully functional.  This is
something I can help mentor, but being stretched for time and skills
will be unlikely to be able contribute too much to the development.

Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to