Yes osgAL is tied with OpenAL++
And with Cmake it would be rather easy to make the ogg/vorbis integration a
simple choice in the Cmake gui.
/Anders
On Dec 9, 2007 1:28 PM, Robert Osfield <[EMAIL PROTECTED]> wrote:
> 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
>
--
________________________________________________________________
Anders Backman Email: [EMAIL PROTECTED]
HPC2N/VRlab Phone: +46 (0)90-786 9936
Umea university Cellular: +46 (0)70-392 64 67
S-901 87 UMEA SWEDEN Fax: +46 90-786 6126
http://www.cs.umu.se/~andersb
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
