After spending a while mulling around with embedded Linux and Qt and qemu and thinking about OpenGL ES and how I'd build a handheld console or set top box that had a 3D graphical environment using something like Clutter, I'm now trying to figure out what kind of tools you'd need for such a world where 3D graphics was common place.
That led me back to something I tried a couple of years ago, trying to get OpenGL rendering in Eclipse. The idea was to provide a complete tool suite for building 3D games in Eclipse. We have C/C++ covered with the CDT. You might also want some 3D modeling tools for building characters and scenes. Why couldn't that be in the Eclipse environment as well. Yes, these are usually done by different people, but I'm thinking of the small, independent developer shops where that may not be true.
The OpenGL canvas widget in SWT makes this pretty easy. I installed the LWJGL library that allows you to make OpenGL calls in Java and I got the Snippet that draws a torus spinning around in an SWT window running. Very cool.
But as I often mentioned here, I "hate" Java (well, it's pretty much a love/hate relationship since I still pick it for my day job on Eclipse technologies). I want to have the option of using native CPU capabilities like SIMD instructions you get with the SSE family instructions. So I'd prefer to do as much as possible in C++.
So I did that. I got rid of the LWJGL code and replaced it with my own native library that implemented an init, resize, and draw routine. Essentially this is all the code needed to render into the canvas and you can do the rest with a few Java calls to set the current context and to swap the buffers. Very very cool. Now to get this running in an Eclipse editor and we're off to the races.
Here's a snapshot of what I have so far. And yeah, it looks like the LWJGL version, but, trust me, all the OpenGL code is in C++ behind the three native methods:
What's about O3D, Googles new 3D-plugin for browsers? That's a 500 KB native SceneGraph-API usable with C++, Javascript (so GWT too), Java (soon). And off course Android! (how to beat the iPhone?)
ReplyDeleteO3D is BSD-superfree, proposed as web-standard... and it works! Both in browsers and (why not?) could be the perfect Java 3D-API (using SWT-bindings)
Doug, this is very interesting to me. I've been toying with exactly this same concept for rendering physical aspects of a microprocessor. How far do you intend to take this idea?
ReplyDelete@Ulrich: Thanks! I'll definitely take a look.
ReplyDelete@Bryan: I'll take it as long as my free time allows, which probably won't be too far. But I'm curious to see how far I can get.
Doug, you might consider leaving in LWJGL and using it as a controller. That's what I did for my experiments, and it allows others to render in 3D with Java.
ReplyDeleteNot sure what I would need LWJGL for. The SWT OpenGL class seems to give me enough. I need to subclass it to add the init, resize, and draw methods that are called at the right time and maybe others. But I'd like to keep all of the actual rendering in native, and maybe even move a bunch of it to shaders.
ReplyDeleteI totally agree that all of the rendering should be done natively. I think the only thing that LWJGL is really needed for is to set the context from Java. Sure you can create your own JNI to do that ... my point is that by using LWJGL, it's then available for java 3D rendering as well. Then there's a single way to set the context, and maybe some other misc controls.
ReplyDeleteI'm not sure what the LWJGL set context is doing. I removed it and was fine. The OpenGL.setContext() method already seems to do the WGL/GLX set context. Am I missing something?
ReplyDeleteI'm doing something similar with JOGL. If your using the SWT GLCanvas then there is no need to use LWJGL's or JOGL's setContext or makeCurrent calls, thats only useful in swing.
ReplyDeleteAh, learned something new ... thanks :) BTW, are you going to make your code open source, or just the ideas?
ReplyDelete