-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Osfield wrote:
> Hi All,
>
> After a two month break I'm now doing a purge of the submissions
> backlog. I doubt I'll get all the way through before Monday, but on
> Monday I'll tag the first dev release since 2.2 stable was made. This
> dev release will be 2.3.0 and be the first concrete step towards the
> final 2.4. This leads me on to asking the question - what features
> should we aim to integrate with 2.4?
>
> My own short list for contenders for integration are:
>
> osgOQ - Occlusion Querry support
> osgCal - Cal3D integration
> osgAL - OpenAL integration
>
> I'm not personally familiar with these libraries, but do know that
> they are known to work with the latest OSG so should be relatively
> straight forward to integrate. Thoughts for the authors, maintainers?
> What extra work would be appropriate before integration? Would you
> be happy with integration?
osgCal is pretty small and its inclusion to the core would be a good
opportunity to clean up the code. However, be careful about the two
version of this library - one is GPL and the other is LGPL licensed.
Regarding OpenAL integration - I am not sure how well is osgAL
maintained. We have integrated OpenAL with OSG on our own, because osgAL
had some additional dependencies and didn't seem to be maintained at the
time. It may have changed in the meantime, though. One way or another,
OpenAL is fairly easy to interface with OSG - it needs only the
positions of the sound sources and the listener's position, the rest is
independent from the scene graph (sound data management, triggering of
sounds, etc.)
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 :)
> 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. 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 ...
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFHWux2n11XseNj94gRAieUAJ90RrKitL+FunLHNFkIhOzWcD+2IACgnaH7
I1Jq6mvn7/nOnfPd7CZOsds=
=9xr/
-----END PGP SIGNATURE-----
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
