Hi Allen, On Dec 20, 2007 4:12 PM, Danklefsen, Allen M <[EMAIL PROTECTED]> wrote: > Well not exactly what I was thinking, most of what you described as > wanting to have: physics, audio, animation; is already done heavily in > Delta3D and we would both benefit from having the same code base we > worked off of. This gives us an up to date osg, and OSG all the game > apis integrated that you want.
Ahh yes. This is very much part of the motivation of integrating more functionality, currently there are a number of disparate implementations that all have strengths and weaknesses, but lack of coordination between them does result in none being quite as capable as they could be if more shared resources was applied into them. For instance proper threading and multi-context support is often left behind in 3rd party addons, and this hobbles the OSG own capabilities to work within the capabilities of those addons, it becomes a case of lowest common denominator. Not all engineers have the know how, hardware and motivation to make hard things like threading and multi-contexts work so this is not surprising, but once you open out to the whole OSG community and you find quite a few engineers who live and breath this and can make sure that things are done in a way that fits well with the core OSG capabilities. > It seems strange to want gameplay api/sdk elements in the core of osg. > Since this is more of a rendering engine and not a game engine. The OSG is a general scene graph, general focus is one rendering support, but its also the graph that represents your scene for most applications, and as such it stores all the state, geometry and various attributes that are used for more than just rendering. Its the interoperability with these other uses that a scene graph need to be put to that stress applications developers leverage the OSG, both in application functionality and art parths - the later which sparked this discussion. Rather than have end users have to solve this interoperability with other functionality from the ground up I think it makes sense to integrate more into the core OSG in the form of a coherent set of NodekIts. This should make it quick for many users to put application together, make for more complete art-path solutions and ensure that applications can be made scalable easily. I don't see the OSG trying to become a game engine, its a scene graph and that's the way it'll always be. It might become something that makes it much easier to build good game engines from, but its not appropriate to go too far over into the application domain like a game naturally will, a scene graph is solidly in the realm of general purpose middle ware. My own perspective is that game engines tend to focus on particular styles of games, this makes them functional efficiently in this realm and be productive to write when developing games in this realm as you can make lots of assumptions. I feel having lots of different game engines satisfying different market segments is a good thing, having everyone re-invent the same wheels is - a well rounded scene graph would be the wheels in this context. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
