I would not like to have those node kit in the core of osg, because the
functionnality they provide is not the core of osg, they are adaptators
for others libs, and for me it should be a nodekit in a third party.
Instead i think an osgPython or osgOQ are a place in the core, because
it's realated directly with openGL and the scripting (osgPython) is a
wrapper to osg. But it seems i am the only one to have this opinion so
it means it will be integrated in the core ;) For the scripting language
i would prefer osgPython because python is a language Object and lua not
(maybe now it is ?).
Cedric
Jan Ciger wrote:
> -----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
>
--
+33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED]
http://www.plopbyte.net
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
