Hi JMonkeyEngine community,
How difficult would it be to write an adapter so that we can use the JMonkeyEngine scene graph on top of a pure java software renderer such as jGL 3D Graphics Library for Java
JavaGL (aka JGL) is a pure java implementation of OpenGL API on top of Java2D.
Someone tried something similar here, but he was aiming more toward Xith:
JIGL \ Software \ Library \ CroftSoft
I'm not familiar with the rendering components for JMonkeyEngine, so I'm not sure how difficult this will be, or if similar efforts have been undertaken before.
Thanks,
Sam Reid
Hi Sam,
I am a jme newbie, anyway it seems to me mainly you should rewrite any class which name starts with LWJGL. Example:
LWJGLTextureState
LWJGLBlendState
LWJGLCamera
…
About 37 classes… those are the classes that "convert" jme data / data structures into the appropriate OpenGL calls using the lwjgl (lwjgl.org) library. You should use JavaGL instead. I think it could be a lot of work … 
What is your use case for a software renderer?
Hi!
JavaGL and JIGL are very slow especially on old machines with a small micro-processor. Is software rendering really useful whereas JMonkeyEngine 2 uses 2 bindings of OpenGL for Java? JOGL is very reliable even on quite old machines but the JOGL renderer needs much work to be as complete as its LWJGL equivalent. I really doubt of the usefulness of a software renderer.
Or one can use JOGL and the user only needs to accept the certificate from sun, and I doubt sun will install viruses 
Software rendering is useful for compatibility reasons as well. Broken opengl drivers are everywhere.
Tobias said:
Software rendering is useful for compatibility reasons as well. Broken opengl drivers are everywhere.
There are workarounds for most OpenGL bugs and you should not underestimate the reliability of OpenGL. Actually, some implementations of the GLU are more buggy than OpenGL itself and JOGL contains a pure Java implementation of GLU that allows not to meet the bugs of the native versions.
Haladria said:
Or one can use JOGL and the user only needs to accept the certificate from sun, and I doubt sun will install viruses ;)
I find this solution acceptable of course as Sun is famous. I hope Kenneth Russell has updated the certificates...
One would be wise to not underestimate the crappability of some people's drivers. A DirectX binding like LWJGL would work wonders for java games' compatibility in windows, and a software renderer would be even better in that regard (but slower of course).
I don't care if it's Sun, Dell, or Bill Gates' personal certification, there is still a prompt that comes up asking if you want to trust "This One Guy" to not do evil things to your compy. If for no other reason than to avoid the pop-up I think software rendering is a very valid option. Apart from that I'm all for another renderer and I'm pretty surprised anyone would really be opposed.
"Oh no…new optional features and functionality…no, we can't have that!" :-p
When you’re downloading a program, clicking an attachment in an email, or even clicking a link on a website, you always must trust the party involved. People have gotten so used to this sort of thing that it’s completely normal now. Besides, both LWJGL and JOGL have authorized certificates, so the dialog looks less scary. Take a look:
If you ask me, I much prefer Java’s method of simply clicking a link or going on a webpage to play a nice looking 3D game to having to having to download a dangerous exe, installing it, etc.
Software rendering is not magic, the kind of graphics it can do are very limited if performance is to be maintained.
Compare these two images and you’ll see the difference:
Software Rendering
Hardware Rendering
Momoko_Fan said:
When you're downloading a program, clicking an attachment in an email, or even clicking a link on a website, you always must trust the party involved.
It is not true anymore, read this:
http://www.javagaming.org/index.php/topic,20435.msg166308.html#msg166308
I develop apps frequently that need absolutely no security and thus do not require the user to click "trust me, okay?"
You may think it's the norm, and perhaps to Java developers it might be easy to think so, but in the real world the user has to 1.) trust you to allow it, 2.) have a solid reason to want to follow through with this step of authorization. If I go to some random site that is just trying to rotate a 3D model of a product or something I have no intention of giving them my blind trust and I think it would be ignorant to do so. However, do we really want to dismiss these developers from being able to use jME because we think that software rendering isn't pretty enough?
darkfrog said:
However, do we really want to dismiss these developers from being able to use jME because we think that software rendering isn't pretty enough?
No we're not :D
Did you look at the link I gave??
Updates to the GlueGen runtime 1.0b06, JOGL 1.1.1, JOAL 1.1.2 and Java 3D 1.5.2 have been pushed out revising the signing certificate used for these binaries. As an added, though arguably dubious, benefit, if you are running Java SE 6 Update 10 or later you will not even need to accept a security dialog.
I think software rendering could be very interesting in jME. Of course not for realTime game rendering, but some application need that, and we have many examples in the forum.
We do applications using jME (not games) and most of times clients don't have recent computers and graphic card.
Even on basic 3D rendering they have problem, so software rendering could be the solution. Sometimes they have recent processor but bad graphic card, so software rendering could work on that configurations.
Also, it can be used to do offscreen rendering, so not in real time.
It depends on what kind of application you do. If you think that jME it's only for games so we don't need that, but people have different use of jME.
pitchonel said:
most of times clients don't have recent computers and graphic card.
Even on basic 3D rendering they have problem, so software rendering could be the solution. Sometimes they have recent processor but bad graphic card, so software rendering could work on that configurations.
I admit that JMonkeyEngine 2 does not work on graphic cards that does not support at least the vertex arrays but it concerns only some extremely old hardwares, please have a look at the OpenGL documentation, GL_EXT_vertex_array appeared in 1995, it does not concern a lot of people, maybe you overestimate the number of clients that would have problems with JMonkeyEngine 2.
In my case, I use a graphics card created in 2003, it works fine but I had to fix several bugs in the JOGL renderer as some programmers had performed calls supposing that everyone owns a recent graphics card supporting shaders, etc... :-o If this kind of bugs are in the LWJGL renderer too, JME 2 won't work for some of your clients. You should rather check if driving JMonkeyEngine 2 more reliable could solve your problems without needing to implement software rendering on my view.
samreid said:
Someone tried something similar here, but he was aiming more toward Xith:
http://www.croftsoft.com/library/software/jigl/
JIGL would be easy to use as JMonkeyEngine 2 already supports JOGL but you will have to help me to fix the remaining bugs in the JOGL side ;) JIGL is very close to JOGL and there is a wrapper for it. I think it is the easiest approach to implement software rendering in JMonkeyEngine 2 even though I still doubt it is useful. Maybe you will have to modify a bit JIGL as it is a bit old, then use jigl.jar and jgl.jar.
The jGL code library has not been updated since 2003 so much of the JIGL code is for the purpose of adapting jGL to the current JOGL interface.
This is the main difficulty.