Hi Bertrand, On 12/14/06, bertrand greslier <[EMAIL PROTECTED]> wrote:
xith3d seem be as good to compare with osg. It use jogl and provide a scene graph, and several loaders. See jnlp online demos and documentation to view features.
I have just browsed through the website and read a bit of the docs, I don't see it as far good comparison, the OSG is a full blown power users scene graph, with full fsupport for multi-threading, multiple graphics context, paging, support for almost of OpenGL functionality and its a mature and heavily tested out in industry. Xith3d looks to be still early in its life cycle, and features are pretty lighweight in comparison, I can't see many serious simulators using Xith3d, perhaps a few browser based games, in this context in may outstrip the OSG in terms of convenience. What strikes me that the lack of good integration with other languages in the OSG is a source of a lot of wasted time out there with people reinventing the wheel. Its an enormous effort to write a professional grade scene graph, I know from first hand experience :)
jogl is a binding to OpenGL (https://jogl.dev.java.net) and support OpenGL 2.0 specification. I don't know detailled implementation. Also very good jnlp impressive online demos to directly test it (https://jogl-demos.dev.java.net).
I'm curious how does jogl handle extensions to OpenGL that have to be querried at runtime. per graphics context?
for me one JNI == one C function call == one opengl function in jogl, I believe a jni call is as fast as a call to a C function because it is a C function perhaps it is partialy false, I am not sure in fact. However Jogl seem has progress you can view this benchmark, now the frame rate of this game is equivalent to C frame rate ! =>http://bytonic.de/html/benchmarks.html for jake2 (a java online version of quake2).
I think one would need to do some specifics performance tests to know the types of overhead involved, if the bottlneck is fill rate for instances then overheads on the CPU will be masked, only once you start throwing tens of thousands of objects at the scene graph do you start to test the CPU side properly. Now if you are targetting modest scenes then you might not ever push the CPU so it doesn't really matter, but for power users they will always push capacity to the limit. The OSG traditionally caters for this crowd, much more than the more casual users - to the projects detriment if you are own of these casual users just wanting to get a bit of graphics up on the scene graph - the OSG power and complexity (and lack of high level docs:-) is a hindrance.
for me C# is not a good language, this is a bad copy of java with additionnal bugs and portability problems, no worthy to interess and spare time on it...(IMHO).
But still people are suckered into it.. ;-) Now Java is open source I don't see a great future for C#, especially if Java can be re-invigerated by the better availability and outside input. However, for those still wanting to use C#, the similiarities to Java do mean that the solutions suitable for Java and likely to work with C# and visa-versa.
I know than java6 now will use the Mozilla/rhino java implementation to interpret javascript. "osgJS" could be directly support in java use of OSG. I don't know the C/C++ solutions.
Forgive my ignorance, I'm not familiar with javascript, how would java script integrate with other languages like C/C++? Is it possible to integrate as per osgLua and osgPython? How would running it on a java virtual machine affect this integration?
several steps : 1°) study xith3d and extract all reasons and all features why osg is better : visitors,tools, models ...
It seems Xith3d is inspired by Java3d, while the OSG took its base inspiration from the likes of Performer, the OSG now goes far beyond Performer though, both in features and extensibility but it retains Performers affinity for vis-sim power users. Rather than wonder how OSG is better than Xith3D, I'd suggest focusing on how to make OSG better in ways that its weak right now i.e. Java integration.
2°) study all the rules, concept equivalence, and find solutions to port the C++ implementation of this features to java... 3°) find an addtionnal tool with cvs to easily manage the two project in the two languages, give a number (automaticaly) foreach chunk of code, insert new comments in the two versions, propose an automic convertion in comments in the two directions. 4°) parse only the headers like JavaOSG do and generate java classes (only methods with a proposed code in comments) 5°) implement manualy with the proposed codes. 6°) manage manualy all the modification with the new multi-cvs tools indications. In fact I have not other ideas and I am already aware that these steps are not suitable.
I can't help but feel that trying to recreate the OSG in Java will be a huge amount of work, and will loose all the benefit of the existing code base and community beyond the basic design. Even if you formalise the way of extracting the class interfaces, the implementation is still a huge amount of work, and the class interfaces themselves won't map perfectly. I have to go right now so can't expand further, but I think wrapping a common core C/C++ scene graph will be the most profitable route. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
