Xith and JSR231

Engines, Libraries and Tools Xith3D Forums
#1

Hi, is anyone working on the port of the jogl renderer to the forthcoming JSR-231 ? or may be is it already done ?

Lilian

#2

I don’t know, but I would be very interested also.

#3

Can you post some more information about JSR231 please and your thoughts on the matter? Would it be hard to port?

Will.

#4

jsr231 should be nearly comptible with jogl, except for package names and a generalized use of NIO buffers.

I will do the port, and send you the full source code.

just give me a package name … com.xith3d.render.jsr231 ?

As there are two API for rendering (the old glEventListener way and a more direct one), I’ll test both.

I’m going to need some help in running the test suite, volunteers please !

Lilian

#5

I’d be pleased to test your port. Thanks for your engagement !

#6

I am happy to test your port on OS X.

The package name sounds fine.

Please submit your code for tracking via IssueZilla. Following the Xith3D coding standards would be appreciated too (essentially these are the standard Sun Java ones with 4 space indents).

Are you able to maintain this renderer going forward? Not essential but always nice :slight_smile:

Thanks!

Will.

#7

Long term commitment : I don’t know yet, it will depend on the success of the small game I’m currently working on.

I’ve opted for Xith3D to shorten the development times, and I haven’t encountered yet a blocking problem, my productivity is an order of magnitude over my previous “raw open-gl” developments… I must admit I like it !

I try to adapt the engine to my needs when something doesn’t suit me (see the “Xith contributions” topic I’ve started today) and I’m willing to share my updates whenever possible.

I should finish this game in the near future; after that I’ll decide whether continuing (and contributing more) with Xith3D (with a more ambitious project) or to opt for something else…

Lilian

#8

All good. Thanks for participating in the community. We seem to have quite a few active members currently which is really great. Good luck with your projects!

Will.

#9

Porting done…now testing !

… these new nio buffers that replace int and float arrays are tricky… I seem to have forgotten a rewind() and nothing works… back to re-reading every class I’ve updated…

I should post the sources (once the whole set of test classes and the q3d demo are working on my computer) in the issue tracker next week.

Lilian

#10

[EDITED] SOURCE CODE POSTED as Issue 103

Test is finished, everything seems to work fine here,

Some issues or things to enhance/discuss, I think it’s better to expose them here instead of the issur tracker :

  • The quake demo shows some hickups not present with the old jogl renderer, it’s not gc related, but seems to happen when new clusters are loaded. I’ll have to investigate to understand why this happens. Any help is welcome ! It might be related to texture loading (see point below) but I’m not sure of this.

  • the GeomNioIntData used to send array indexes needs to be updated, the setInts(…) method don’t rewind or position() the underlying nio buffer

  • Same for GeomNioFloatData, buffers not rewinded.

  • There are new features in jsr231, like the shared GLContext, that could be exposed in CanvasPeerImpl to allow for instance texture sharing between multiple Xith canvases. If someone is interested please start a new topic to discuss it.

  • I’ve implemented the port with the GLAutoDrawable/ GLCanvas objects (similar to the jogl version). As it works fine, I won’t develop the more direct mode (the one without listener) unless someones sees some real improvements in doing so.

  • I’ve used the ByteBuffer.wrap(byte[]) in the TextureShaderPeer to send texture data to the GL, I’m not sure it’s the best way to do it, as Ken Russel said in a jogl thread that it’s better to always use direct buffers (or is this a kind of direct buffer ?). Also, It might be better to store directly the texture data (currently a byte[ ] ) into a ByteBuffer to avoid some data transfers when loading a texture.

  • Many matrix methods use float arrays to store matrix values, I haven’t messed up with that code : I’ve added some private FloatBuffers to store these values in the appropriate Peers and use them as intermediates between matrices and the GL.

  • the Q3d demo starts with a messed initial screen (as rendering the first frame takes several seconds) exposing memory internals, whereas the jogl version starts with a white screen…

Any comments on theses points are welcome !

Lilian

#11

Hi,

Thanks for this excellent contribution. I have posted some comments in https://xith3d.dev.java.net/issues/show_bug.cgi?id=103 relating to the JSR231 and JOGL relationship (upon investigation I get the impression we should be replacing the jogl renderer with your port rather than adding a new renderer).

From what I could tell, JSR231 is what JOGL is now, and JOGL as it used to be is deprecated. Is that correct?

Incidently if anyone is looking for the JSR231 packages, they are here: https://jogl.dev.java.net/servlets/ProjectDocumentList?folderID=4650&expandFolder=4650&folderID=4649

Cheers,

Will.

#12

This is correct. JOGL has evolved to track the forthcoming Java bindings for OpenGL standard. The old JOGL APIs under the net.java.games.jogl namespace are no longer being maintained. The new implementation is more robust than the JOGL 1.1.1 release and also offers new features such as lower-level control of OpenGL drawables and contexts if it is needed. I would encourage you to replace the JOGL renderer in Xith3D rather than also attempt to maintain the original one.

#13

Thanks for the answer Ken, I think we will do exactly that.

Cheers,

Will.

#14

Hi,

So what is the status of JSR231-based renderer?

Yuri

#15

For my part, I’ve updated it locally (small patches) but I haven’t got the time right now to properly prepare and file that version. I will certainly do it at the beginning of march.

Lilian

#16

Hi again,

Would be great to have a version even unprepared, because of I am going to update my apps that use Xith3D to JSR-231.

So, if you can send me your version, I can also check it out and commit to Xith3D core CVS (I think even unprepared but most recent version would be really OK, so you can save your time also :slight_smile: )

Yuri

#17

I was sure you were going to ask that :slight_smile:

Give me a day or two to diff the files (I have to check if I haven’t added specific game code).

Lilian

#18

Great thanks,

…and… I just checked the game from JavaPause - it is amazing! Really amazing!

Yuri

#19

wait till march… you’ll see much much more … :wink:

Lilian

#20

What happened to the LWJGL renderer? Is it working? Up-to-date?

Cas :slight_smile: