Hi Bertrand, On 12/13/06, bertrand greslier <[EMAIL PROTECTED]> wrote:
Java improve and glean marker parts to the 3d market. It is true for the web solutions like jogl, wirefusion (proprietary), xith3d, jmonkeyengine, java3d. Today the opengl support for java is really better and impressive than before.
How are the high level Java toolkits fairing these days? How do they compare with the OSG for instance. Improvements to jogl is encouraging, but I presume its still based around a JNI wrapper off C OpenGL. This makes we wonder if a higher level scene graph wrapper might reduce the amount of JNI calls required and improve performance. Looking towards the future with OpenGL 3.0 and OpenGL ES 2.0 there is much smaller set of OpenGL calls available, so the amount of code requied to wrapper with JNI calls goes down, but we'd still still improvements in performance by do less calls through JNI. Keeping JNI calls lightwieght is important though, so I guess this is where much of the work on improving jogl has gone. I don't know much details about it though, I'm just speculating. If you have references on this topic I'd be interested to read it.
I haven't particular problem with OpenSceneGraph, it works fine for me, I am happy from OSG. It was just an idea to extend cooki3d to java to find new market because I have today some difficulties but it is not really the problem of OSG...I have just thow this idea to have your OSG advices on this particular technical path and now I have it. Nevertheless JavaOSG is a good compromise between C++ and java. And a basic java developer will not detect difference beetween javaOSG and a 100% java solution. The file are numerous and it is bigger in size, also the .dll or .so must be compiled for all computer targets and tested on all computers. In fact this problems are annoying for an online web cross-platform solution. However JavaOSG can be a short term solution for me to propose a cooki3d java solution for java 3d developers.
JavaOSG does the difficult task of wrapping pretty well all of the OSG, including handling of all the advanced C++ used. This really pushed JNI to the limit. I would suspect lots of calls to the scene graph would be slow, there is also the memory overhead involved in the data structures either side of the JNI, as well as the memory overhead of the extra classes. The authors of JavaOSG have also moved on to other non graphics projects so arn't actively developing it any more. Perhaps others can pick up where they left off and keep JavaOSG tracking the new OSG releases. osgIntrospection might offer an alternative, there would still be memory and calling overhead issues, but it is a formalised means of querrying and calling the scene graph, that is maintained and distributed as part of the core OSG. osgIntrospection works particularily well for dynamically typed languages like Lua and Python, languages like Java and C# will require more work though, I'd welcome effort in this direction though. Another solution is to use a combination of languages in your app - Java for app side issue, and Lua/Python to manage the scene graph side of things. On language wrappers I do wonder about the possibility of having a Java Script integration with osgIntrospection. I don't know too much about Java Script but from what I've picked up it does has some similiarities to the dynamically typed languages so there is change that a lightweight integration with osgIntrospection might be possible as per osgLua and osgPython. Then there is side of distributing the plugins that add support for the OSG into these languages and the environments that run them such as browsers. We could aim to build and distribute these widely. I'm no expert in these areas so need members of the community with expertise in this area to come forward.
An high level discussion will be to say if it is really util to make a java implementation of the api (except for me ;-)) and if yes how to do this the more efficiently. I have other ideas on this subject perhaps they are better than the first ;-).
We won't know how good they are till you describe them :-) Perhaps others will have ideas how to go about better support for Java too. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
