Hi Jan, On 12/11/06, Jan Ciger <[EMAIL PROTECTED]> wrote:
Moreover, what is a point of doing this? What would you gain by a pure Java implementation over the JNI binding except of a slowdown?
I do think there is value is having a native scene graph, JNI bindings do slow things down, and add a large overhead in terms of having to wrap the C++ side, a pure java scene graph wouldn't carry this overhead and could end up being faster than a low level mix of Java and OSG C++. If your app isn't CPU limited then a Java version of the OSG could be just as fast as C++ version of the OSG. So in general principle I'm not against having Java scene graph as well as C++ scene graph. To me its the practicalities of managing things and deriving from one source base is hard, especially with the current C++ centric version of the OSG. While we have osgIntrospection which certainly makes a massive difference to the ability to interoperate with other languages, especially for the dynamic languages like Lua, Python, Ruby etc, it isn't a trivial for languages like C# and Java. The strong focus on pure C++ is what will make this difficult, the C++ language is just so a big complicated beast. Long term I'm curious about the possibilities of making it easier to have other languages integrated with or even implementing an OSG style scene graph. Long term being say 5 years time. The standards based approach would be mean a lot of work, and only really practical if you just standardised the core scene graph, do anything more and you'll never finish the task of getting the spec out let alone any implementations of it. Standards take a huge amount of resource to put together and implement. Open source to a certain extent mitigates the need for standards in context of scene graphs at least, as rather than just providing a spec we also provide the definitive implementation, there really isn't much need to go off an implement things for different hardware platforms as OpenGL does most of this tricky work for us. Where this breaks down is once you want a number of native language versions of the same scene graph, standards based approach comes back to the fore. With open source projects you have a great deal of certain types of resources and very little of other types of resources. You have lots of developer resources, albeit extremely adhoc, to take advantage of this resource you have to have a pretty efficient system for harnessing it, if you don't harness it efficiency projects stall, developers march off to more efficient projects and you stall even more... To be successfully you have to keep the engine running as smoothly as possible, and for developers to remain productive, all large scale changes to a project, or any new projects need to respect this. So while desirable to have a new OSG style Java scene graph one has to measure up the practicality of it and the amount of gain you get from it. In the case of using osgIntrospection the hit to core developers for supporting other languages is pretty small, you just develop in C++ as usual, yet the likes of Lua and Python bindings can automatically be built at runtime. So you for a small overhead you get a great boost in ability to use the OSG in other ways. Cloning the OSG java stye right now will probably falter as a project, its would be a huge undertaking, the OSG is now small project. Yes there are lots of Java developers out there, but not so many Java developers who are also experts in high performance graphics, you need both to make a great Java scene graph. The words "right now" is something I would stress. Long term I'm open to possibilities of making it easer to grow other languages implementations of the OSG style scene graphs. Its certainly not a trivial task to keep the community dynamics as well as the specs and implementations all working smoothly and productively. Reuse of as much human and code resources would be critical. I think its also worth highlight the fact fact that half the OSG code base is dedicated to loaders - much effort goes into the less glamorous code issues of scene graph development yet absolutely crucial to success. You really don't want to have to replicate this type of work over and over. This is where interoperability of data between different scene graph implementations would be critical. Perhaps one possibility is to implement a core scene graph in pure C or very basic C++ that makes it easy to create wrappers for other languages. This core scene graph would define the key data structures and operations such as basic traversal and rendering, but not high level elements like utilities, loaders, node kits, viewer etc. Such approach would provide the standardisation of the data structure but without needing formal standards body, it'll also allow one to keep all the performance critical elements like calls to OpenGL in its native C without need for JNI wrappers. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
