Preliminary LWJGL binding

Engines, Libraries and Tools Xith3D Forums
#1

As some here may be interested in this, FYI:

https://xith3d.dev.java.net/issues/show_bug.cgi?id=73

[quote]Here’s a preliminary LWJGL binding for Xith3D:

http://www.padcroft.org/cfmdobbie/xith3d/

lwjgl-libs.zip contains the LWJGL 0.89 binaries for Win32; lwjgl-src.zip contains the rendering code. No changes outside of the com.xith3d.render.lwjgl package structure have been made. A number of tests are included in com.xith3d.render.lwjgl.test.

This code is very much a translation of the JOGL work and shares a huge amount of code with it - maintaining both rendering layers will be hard work without some refactoring of duplicated code. I think this nicely demonstrates that another abstraction layer is required - while the current interface is pretty good for JOGL vs Java2D implementations, it’s way too low-level for implementing multiple OpenGL bindings at.

Known issues:

[]There are a couple of calls that haven’t been ported (IIRC all related to generating snapshots).
[]As I’ve only tested a single codepath (only one machine available to test) there are guaranteed to be a number of hidden issues - buffers that need rewinding, typos, BufferOverrunExceptions etc.
[]Xith3D has evolved against JOGL, so works the way JOGL prefers. LWJGL has to jump through hoops to comply with some parts of the interface, making some code downright ugly.
[]The required main-loop code as it currently stands basically sucks. More intelligence needs to be moved into the LWJGL CanvasPeerImpl to make it cleaner.
[*]It is written against the unofficial LWJGL 0.89, which is to be superceded within a couple of weeks by 0.9.

With those caveats, I am happy to state that this code contains the same functionality as the JOGL layer as of 28th March, 12:45pm.

Cheers,
Charlie.
[/quote]
Some lessons learned:

[]Input is an area that could do with an abstraction layer.
[]As noted, a higher-level OpenGL-binding abstraction layer is required.
[]If someone passes you an NIO buffer and you’re passing it straight to something that cares about the buffer position, it’s sure to need rewinding. (Sod’s Law of NIO Buffers.)
[]Xith3D has a number of dependencies that stop it fully achieving its aim of implementation independence, such as assuming the presence of an AWT Window, referring to AWTEvents, inheriting classes from Component etc. This isn’t necessarily bad - it just means the goal of the project may have to be adjusted.
[*]JOGL and LWJGL have approached some problems in subtly different ways, such as quadrics support and vertex/fragment program input. Maybe not a book, but you could certainly write a good size pamphlet detailing the differences and the reasons behind them!

#2

great going! I’m testing the code out now.

I have added abstraction for some window operations (such as setTitle) but there isn’t really any input handling in the API at all. Someone on these boards was writing an abstraction layer a while back, I might ping them and see how it’s going.

Thank you for this effort, it is most appreciated.

Will.

#3

Great work Charlie,

a lot of people wanted LWJGL support in the past weeks and it’s really a great thing to have! :slight_smile:

I hope we can use your “lessons learned” to improve Xith3D. If you have time to do so, you can open most of them as bugs in the issue tracker. This would probably help to solve them.

Jens

#4

Test results for Linux (Fedora Core 1), GeForce2MX 400 (driver version 5336)

HelloXith3D - pass
Xith3DBackgroundColorTest - pass
Xith3DLineAttributesTest - pass
Xith3DMorphPyramid2CubeTest - fail
Xith3DPolygonOffsetTest - fail

The two failures report this:


java -cp libs/xith3d.jar com.xi

th3d.render.lwjgl.test.Xith3DMorphPyramid2CubeTest
Hit SPACE to toggle projection policy, or ESC to exit
 
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x8CF587
Function=XGrabKeyboard+0x17
Library=/usr/X11R6/lib/libX11.so.6
 
Current Java thread:
        at org.lwjgl.input.Keyboard.nCreate(Native Method)
        at org.lwjgl.input.Keyboard.create(Keyboard.java:293)
        at com.xith3d.render.lwjgl.test.Xith3DMorphPyramid2CubeTest.runTest(Xith3DMorphPyramid2CubeTest.java:191)
        at com.xith3d.render.lwjgl.test.Xith3DMorphPyramid2CubeTest.init(Xith3DMorphPyramid2CubeTest.java:178)
        at com.xith3d.render.lwjgl.test.Xith3DMorphPyramid2CubeTest.main(Xith3DMorphPyramid2CubeTest.java:252)
 
Dynamic libraries:
00240000-00244000 r-xp 00000000 03:02 211968     /usr/X11R6/lib/libXtst.so.6.1
0

I don’t know why it is complaing about the keyboard - the LWJGL demos work fine. Edit: And the keyboard events in the passed Xith3D/LWJGL demos works as well.

Nice work!!! I’ll get this committed asap.

Will.

#5

ok, the code’s now in CVS. I think you should apply for developer access so you can make changes directly :slight_smile:

what’s the best way to solve the LWJGL/JOGL code duplication issue? Will the OpenGL layer that Cas is talking about fix this?

Cheers,

Will.

#6

Not really…
…what you need to do is create your own GL interface and then delegate it to either a JOGL GL instance or an adapter LWJGL instance thjat calls the static LWJGL methods. Because of the new way LWJGL handles pointers you are probably better off using the LWJGL API style and bodging it to fit JOGL rather than the other way around.

Cas :slight_smile:

#7

As Cas says, you need a proxy to delegate calls to the appropiate OpenGL binding. However, the two bindings do things in different ways, so this becomes a non-trivial task. Here are a couple of differences between the APIs:

[tr]
[td]Area[/td]
[td]LWJGL[/td]
[td]JOGL[/td]
[td]Problem[/td]
[/tr]
[tr]
[td]Quadrics[/td]
[td]Sphere, Disk etc Java objects in org.lwjgl.opengl.glu package.[/td]
[td]C-style method calls.[/td]
[td]Totally different approach[/td]
[/tr]
[tr]
[td]Shader program inputs[/td]
[td]ByteBuffer containing 8-bit ASCII.[/td]
[td]16-bit Java String.[/td]
[td]Data conversion[/td]
[/tr]
[tr]
[td]glVertexPointer[/td]
[td]GL11.glVertexPointer(count, offset, buffer);[/td]
[td]gl.glVertexPointer(count, type, offset, buffer);[/td]
[td]Different numbers of arguments[/td]
[/tr]
[tr]
[td]glLightfv[/td]
[td]GL11.glLightfv(j, GL11.GL_DIFFUSE, buffer);[/td]
[td]gl.glLightfv(j, GL.GL_DIFFUSE, array);[/td]
[td]Different type of arguments[/td]
[/tr]

Careful planning required! I’m sure it’s do-able though.

Re: those two failures - very odd! The Keyboard initialization code is frankly trivial (“Keyboard.create();”) and in any case there’s no real difference between a working and a non-working main loop. Are those two failures repeatable?

#8

First I would like to say that the effort you put into making this binding were very useful since all I had to do to make it uptodate is few changes here and there.
Having said that, you actually forgot few things when setting up Light, material and Pixel/vertex shaders peers; you need to call flip…
;D
float4.put(emmissive.x).put(emmissive.y).put(emmissive.z).put(1.0f).flip();

#9

Man you sure have forgotten a lot of flips here and there ;D
Fixed IndexedTriangle geometry display;
Vertex/Fragment Shaders
Material
Light
…
currently investigation for more bugs, but man you’ve done one hell of a job :stuck_out_tongue:

#10

More grooviness:

In the new org.lwjgl.util package (see CVS) I’ve now got 3 super-extra-brilliant classes:

GL - is a static class with all of OpenGL1.1 through 1.5, plus all the ARB and EXT extensions that LWJGL supports too

IGL - this is the big one! This is an interface implementing all of the GL1.1 -> 1.5 methods and all of the ARB and EXT methods that LWJGL supports.

GLImpl - is an implementation of IGL which delegates all its instance calls simply to the aforementioned GL class.

What is the significance of all this you ask?

Well…

If Xith3D were to be, ahem, refactored to use the IGL interface everywhere instead of any hardcoded references to JOGL, then the Xith team could simply provide an adapter implementing IGL that delegated to a JOGL GL instance. You’d have to be clever with the buffers of course because of the coolbeans way that LWJGL uses buffers, but that’s what your adapter class is for, eh?

What do y’all think?

Cas :slight_smile:

#11

Source
Jar

A quick little tutorial on how to set up a basic window;


  CubeMapReflection(){
    int parameters[]    =        new int[7];
        //screenWidth   =     parameters[0];
        //screenHeight  =     parameters[1];
        //canvasWidth   =     parameters[2];
        //canvasHeight  =     parameters[3];
        //refreshRate   =     parameters[4];
        //bitDepth      =     parameters[5];
        //fullScreen    = parameters[6]== 1;

    DisplayOptions.showSettingsSelector("Select Screen Mode",
                                        DisplayOptions.USE_XITH3D_ENGINE,
                                        parameters);
    parentFrame.setSize(320, 240);
    parentFrame.setLocation((parameters[0] - 320)/2,
                            (parameters[1] - 240)/2);

    parentFrame.getContentPane().add(DemoStatus.getStatusPanel());
    parentFrame.setVisible(true);

    VirtualUniverse virtualUniverse   = new VirtualUniverse();
    RenderPeer      renderPeer        = new RenderPeerImpl();
    CanvasPeer      canvasPeer        = null;
    Locale          locale            = new Locale();

    view.setBackClipDistance(1000);
    view.getTransform().setTranslation(new Vector3f(0,0, 7));

    virtualUniverse.addLocale(locale);
    locale.addBranchGraph(scene());
    virtualUniverse.addView(view);

    canvasPeer   = renderPeer.makeCanvas(null,
                                         parameters[2],parameters[3],
                                         parameters[5],parameters[6]==1);

    canvas.set3DPeer(canvasPeer);
    view.addCanvas3D(canvas);
    run();
  }

PS: Don’t forget this line
import com.xith3d.render.lwjgl.*;

#12

bump

Anybody? GLI interface? Hm?

Cas :slight_smile:

#13

Cas,

Unfortunately I just had no time to take a look at the interface.

What I am thinking about is a minimalistic GL interface that exposes only functions Xith3D uses, but let me check in more details.

Yuri