On 12/14/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
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.
xith3d <http://www.xith.org/> 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. 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.
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). 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.
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 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.
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). 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.
Yes it seem a better solution, more safe and light solution for web app. 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.
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. 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 :-) several steps : 1°) study xith3d and extract all reasons and all features why osg is better : visitors,tools, models ... 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. Perhaps others will have ideas how to go about better support for Java too. Yes please give us good idea because I haven't. Regards, -- Bertrand Greslier http://www.cooki3d.org
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
