There is a problem with redefining the controls: When I try to hit one of the buttons to redefine a key or hit the ok button to finish, instead it binds the previously selected one to the left mouse button.

When you use different classes for them you have additional code to maintain...

Making a difference between points and vectors by using different classes is actually new to me. I know two solutions, both make no difference at all, both call the thing (which is essentially a 3-tuple) a vector, and none of them produces any 'dirty' code if you know what you are doing.

Solution no. 1 (which I'm using in my engine): There is very very very seldom a case where you do not know if a vector means a position or a direction. Actually I have not yet seen any such case. There are simply two transformation functions, one for points and one for methods.

Solution no. 2 (which OpenGL uses): Very nice, but requires additional CPU time. All vectors are stored as 4-tuples, where the fourth value is 1 for positions and 0 for directions. A transformation is stored as a 4x4 matrix where the rightmost column contains the translation part of the transform. Advantage: You can store the translation in the matrix as well. Also, computing the signed distance of a point to a plane means simply computing the dot product of two 4-tuples.

BTW the ugly code when transforming normals may have another reason: You cannot transform normals the same way as you transform vertices. This only works for either orthogonal or orthonormal transformations (not sure). Otherwise the normals are tilted towards the surface during transformation.

I think Cas is right that LWJGL should not be thread-safe, because I actually don't see a reason to have several threads feed OpenGL at the same time. But if you want to move other stuff like the game logic to threads, why not? Unless you are already in the optimizing stage, your main criterion should be whether your program works in a pro-thread way. That is, it has to do several unrelated jobs which need to synchronize seldom or never.

I can provide a set of math classes that I have more or less copied from Crystal Space. Euler angles and quaternions are still missing, but that should be simple. Apart from that, it got 2d and 3d vectors, matrices, planes, 3d transforms, axis-aligned boxes and an interface to parametric lines and surfaces.

The real point however is that all classes are *IMMUTABLE* like String. I know that this will hit you because it means lots of allocations all the time. On the other hand it makes coding very clean and makes optimizations possible which are not possible with mutable classes. (For example, you never need to copy a 3d vector).

My intention was to use these immutable classes until they prove to be a bottleneck, and then introduce mutable variants (like StringBuffer) for the inner calculations but still use the immutable variants where possible. Has anyone made real experience with the performance of such an approach?

Just got a mail with this link:

https://caethaver2.ath.cx/ftoma/

Looks like tons of free stuff, but I haven't look at it myself yet.

What about alpha? I had problems with the 0.5 because it couldn't get alpha for the frame buffer. In the latest CVS version this works though.

Wouldn't it be possible to run swing inside the OpenGL window? AFAIK the swing components are designed to render themselves to an awt.Graphics object, whatever that does internally. It should be possible to write such an object that actually maps everything to OpenGL. Sounds nice to me because suddenly you get everything in your GUI that swing has, including user-made extensions from the 'net.

And about structs: I'm not sure if that really speeds things up. Because, before you can access the members of a struct you have to set up the struct itself (as a window to the buffer). Either this takes more time than you gain, or you cache the struct itself and that takes a lot of memory when you do it everywhere.

You DO gain some cleaner code, but you could get that otherwise, like:



This is nearly as clean. To solve the speed problem, I think another trick than structs is needed. Speed is only a problem anyway when you want to perform some operation on all elements of a big buffer - The term "batch processing" comes to my mind again.

Just found out that LWJGL already supports what I need! In fact, your library looks very similar to what I had in mind. Looks like the right choice to me

@kevglass: I wanted to provide a higher-level API than OpenGL to the Java side, but still based on JNI. Like, transfer an array of vertex data to the native side at startup and then, at runtime, do something like "batch processing": one JNI call to a native function which sends all data to OpenGL in a tight loop. In other words, exactly what I found buffers in LWJGL to be

Actually, I wanted to write a "lowest layer" (the only part of the program that contains native code), set it on top of OpenGL and provide a _different_ interface to the Java part. However, I have noticed that I don't get around providing some functions that are actually the same as OpenGL functions. So I could as well try an OpenGL binding

One thing would be important to me though: In case I find a part of your mapping that becomes a bottleneck because it works through JNI, is it then possible to replace only that part with a self-made native library?This native library would do nothing than to run some OpenGL functions in a kind of "batch mode" to avoid JNI. I think it should work, because OpenGL is designed to work that way, but I want to be sure.

Not that I expect such problems, but I don't want to change the binding again, should they appear.

Hi you all! I'm currently unsure what to do. My goal: I want to write a 3d engine. However, I am not sure which low-level API to base it on. AFAIK I have three options:

1. Base it on Java3D. This sounded very good to me at the beginning because it is portable and the API allows a lot of optimization in the background. However, I did not read any "performance success stories" yet (only about success in development time), and the API is not exactly what I need (maybe it works with some tricks though).

2. Base it on an OpenGL-for-Java binding (LWJGL, GL4Java, etc.). This leads to problems as well: When it comes to transferring all the data of a really complex 3d object down to OpenGL, the repeated JNI calls *seem* to be a performance problem (can anyone clear this issue?) But an OpenGL binding seems to be "almost good"

3. Write an own Java/native binding which uses OpenGL at the native side but offers a higher-level interface to the Java code. This would allow to create an API which is designed specially for Java (unlike OpenGL) and also does a lot of caching on the native side.

As you probably see, I favor the third option. Note that I understand the difference in Java3D vs. OpenGL as "scene graph vs. immediate-mode access". I would write the scene graph / management part completely in Java then (the native part would work at a lower level then scene graphs).

It also seemed to me that OpenMind is similar to what I want to do, but like Java3D its API is not what I had in mind.

My question is, does this sound like a reasonable approach?

Thanks in advance.