Hello

[DavidYazel]

My name is David Yazel, a developer on the Magicosm project (http://www.magicosm.net) I know some of you guys already from the Java gaming and Java3d forums.

I spent the day looking at the code from LWJGL and JOGL.    I also checked out the quake demo and read most the posts on this site and others.

I like what I am seeing in the LWJGL library and the clarity of the demo code.  I like the fact that AWT is not part of the picture because I have had a bitch with inputs in the event model of AWT, namely WToolkit.

I am going to try an exercise so I can learn how this works.  The idea is to write a simple renderer that takes a Java3D universe, walks through the nodes and renders using OpenGL bindings.  This first test should run like a dog because primarily I would not be replacing the Java3D nodes with ones which map the API directly, but would be translating them at runtime.  For example, when I go to render a Shape3D and I get the Material object, I will have to get the ambient, diffuse, etc tuples and then move them into an NIO buffer so that I can call glMaterialfv() with the color info.  Even worse is the geometry if it is not already in an NIO buffer.  I would have build a buffer and move it over.

My goal would be just to get it to run, and in the process figure out the GL code needed for rendering the node components of value to me.  

Based on what I learn in this exercise the next step would be to write new versions of the Java3d objects, but build them to encapsulate the NIO buffers needed to talk to OpenGL.  Then to write a more sophisticated renderer that handles culling, material ordering, alpha passes/sorting, caching, texture management, list management, etc.

Some questions:

- Do you think I should wait until 0.7 of the API before starting this?

- Is 0.7 going to rename to the GL standard? glBegin, glEnd, etc?

- Will the new API do away with system pointers altogether, eliminating wierd memory errors and VM crashes, or will that always be a risk?

- What is involved in the ports to other operating systems?  I noticed DLL's in the windows download, so I assume there is some C code as part of the API.  We want support for Linux, Windows and Mac, so it is a concern of ours that we will have to rely on that notive code layer.

- Regarding your recommendation that we don't multi-thread the program, I have some concerns which might not be well founded.  Right now we calculate our next frame in the only behavior we use in Java3D, which fires once a frame.  This is supposedly being done while Java3d is rendering to the card, thus they are done in parallel.  It is my assumption that this rendering is actually happening inside the j3d DLL's and so are really in another system thread, so it is real timeslicing.  If we currently calculate frames at 60 FPS and currently render frames at 60 fps will we go to 30 fps using the recommended (calc -> render) loop?

- We will not be implementing the entire Java3d API.  We won't be doing behaviors, 3d sound, picking, etc because we already do that in our own engine.  basically what we are looking to do is replace the renderer and remove the risk of Java3D and at the same time open up more control on some of the pipeline.  Do you think this is a reasonable goal?

- I have read a lot of opengl code and ported a lot to java and read the books, etc.  But I have never written opengl code before, so I will probably be asking some newbish questions over the next few weeks.  So please forgive me.

Dave Yazel

P.S. Newb question #1 when you glPushMatrix does it leave the values of the current matrix available?  Does it go to the identity?  Is the matrix stack a tranform stack so if you translate to 0,0,1 then push matrix then translate 0,0,1 it really is 0,0,2?  Do you recommend using the push and pop, or just calculating the matrices and using glLoadMatrix?

[princec]

Hi David, nice to see you in here too  

You're on the right track!

You might want to look at the SPGL code for doing triangle rendering (com.shavenpuppy.jglib.renderer). Essentially you decide on how many levels of characteristics your triangles have in the entire engine, and then every triangle you render is associated with an array of these characteristics which can be rapidly sorted and then shunted out to the graphics card. You might not want to use it verbatim but it's a nice place to progress from after you've done the basic super-slow unsorted single triangle rendering thing. Not sure how to handle alpha sorting yet.

To answer your questions:

- 0.7 will be out "real soon now" but the Mac port is still in an unknown state. Linux and Win32 get released at the same time. If you can wait a week or 2, start with 0.7. But be warned it'll look a bit ugly until static import makes it into the language; although I do believe there's an expermental javac available that has static import in it already from Sun.

- 0.7 is going to move to glXXX prefixes again in anticipation of static import.

- Yes, pointers are gone. We might put some extra error detection in the debug library build to catch a few common errors. There won't be error detection in the release build, for maximum performance. Probably. Have to ask the others to see what they think. You can still crash the JVM quite thoroughly by passing rubbish into a gl call and sometimes it's very difficult to detect if not impossible.

- We prebuild the native libs for Win32 and Linux but haven't got a Mac build yet. The JAR is completely platform independent. Don't be concerned about relying on the native code layer; it's usually pretty stable, and it's very, very small. And if you find a bug you can be sure we'll fix it fast.

- You really don't need to multithread. In your single threaded main loop, you do your logic, then render it. All your logic has to be the kind that is executed stepwise, in the manner of Bresenham's line drawing algorithm, or A* pathfinding - perfect examples of things that people often try to put into threads for no good reason! You are then able to schedule exactly how much stuff you want doing per frame. Playstation developers for example often use alternate timeslices to make sure everything fits in a frame: monster AI on evens, collision detection on odds, etc. You will easily achieve 60FPS with your scenes, even without any fancy rendering engine.

- Your goal of not emulating the whole of J3D is entirely sensible; all you need is the scene graph culling and traversal. Anything involving behaviours etc is strictly unnecessary for games programming where you generally need maximum efficiency. You may as well do the 3D sound through OpenAL - it's excellent.

- I'm by no means an expert on OpenGL and nor are many people in here! But there's often help to be found on the opengl.org forums if we don't know the answers.

And the answer to Newb Question #1: yes, it takes a copy of the current matrix. This is generally what you want as you'll apply further transforms to the current modelview rather than loading the identity and positioning something from scratch. But don't push too many; if you're going more than a few layers deep your scenegraph is probably flawed and slow. A matrix push causes the entire GL rendering pipeline to stall.


Cas

[cfmdobbie]

Well, if it isn't the Wonderful Wizard of Id!  Greetings!

The idea is to write a simple renderer that takes a Java3D universe, walks through the nodes and renders using OpenGL bindings.

Now z-particle went some way towards writing a J3D-like scenegraph to sit on top of LWJGL, but I think it's stalled due to lack of interest.  You could ask him for details - might be a start?  It's not quite what you're talking about though.

- Is 0.7 going to rename to the GL standard? glBegin, glEnd, etc?

An interesting point - the GL standard actually deals with the methods without the prefixes!  It just goes to show how popular the C bindings are that people prefer to see OpenGL calls with the prefixes than without.

I assume there is some C code as part of the API.

Yep, no other way to access the hardware.  Just as Java3D has a native side, so must JoGL and LWJGL.

[...]remove the risk of Java3D and at the same time open up more control on some of the pipeline.  Do you think this is a reasonable goal?

From what you've said, Cosm already has a nicely abstracted rendering layer?  If so, yeah, great!  Can only be a good thing for you.  You need to put up some effort up front, but it gives you yet another client that people can use if the others don't work.  Nice!

[psiegel]

David -

Welcome!  I was wondering how the MagiCosm team would react to all stuff going on with JOGL/Java3D.  I think you've made the right decision coming here.

I thought I might toss out some links to the stuff zparticle has done already with the Java3D scenegraph and LWJGL.  Here's some links he posted on the thread in JGO.  If they don't work, I have these files on my hard drive and can get them to you.

http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_api.zip - The javadocs, such as they are
http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_src.zip - The source code
http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_bin.zip - Everything you need to run the examples

Here's a link to the start of the disucssion that started it all:

http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1049466445

It looks to me like this might be prime stuff to move to a SourceForge project.  Although I'm currently swamped with reaching my own game's deadline of July 30, once I'm past that I could probably be enticed to helping out with such a thing.

Well, good luck.  I'd love to hear reports of your results.

Paul

[princec]

Hey Paul, what are you working on by the way?

<edit> And what the hell is Binkystick!? Is it like Ween? Or Instant Death?

Cas

[psiegel]

Cas -

I was wondering how long I could get away with perstering you guys with questions and bug reports without giving any clue as to what I'm doing.  

Anyway, I'll actually have to get back to you on this.  I'm not sure exactly what I'm allowed to say and what I'm not, so I think I better just check with the team before I post anything.  We should be having a full dev meeting soon, so it shouldn't be too long.    I only post now as I don't want you to think I'm ignoring you.  But I can assure you that it's a game, it's in Java using LWJGL and Jet, it'll be distributed as downloadable shareware, and it should be complete within the next two months.  And you can bet that I'll plaster this forum and JGO with announcements as soon as I can, and I'll probably be trolling for beta testers soon as well.

Well, all that horribly vaguery out of the way, I'll be happy to tell you all about Binkystick.  Ween is a good comparison, and I might include The Residents as well.  I'm not familiar with Instant Death.  When I was in high school, my best friend, his brother, and I discovered the magic of a four track recorder.  We quickly formed a band and started recording all the craziness that came into our brains.  The songs are pretty bizarre, and tend more to the humurous side.  

Anyway, we kept this up through college, releasing three albums along the way.  It was in college that computer-nerdiness took over, and I started running my own server out of my dorm room closet.  I needed to name it, so it was christened after the band, Binkystick.  Now of course that name has stuck, and I admit giving out an e-mail addresses with that in the name often causes people to raise their eyebrows.  But after all this time, I don't think I could handle a name switch.

The band hasn't gotten together in many years.  One of the members moved to Hollywood, another stayed in NY, and here I am in Boston.  Who knows what the future may hold though?  I think you can still order the albums at our website, if you're that curious.  There should be some downloadable mp3's there as well.  Here's the URL:

http://www.binkystick.com

Madness!  (Hey, that was a good band too.)  Um, yeah, time for me to stop rambling.  I'm sure you were much more interested in the first question than all this crap.  More info to come.

Paul