[java] Current state of 3D in Java?

Started by
12 comments, last by elFarto 16 years, 4 months ago
Quote:Original post by hplus0603
jMonkeyEngine seems to be closest to what I'm looking for. Hey, it even supports COLLADA!

I'm trying to find out how big the required install is. Also, I wonder if it can be totally installed from a browser object tag, or whether an actual executable/msi has to be installed and run.

Last time I checked it's distributed as a normal library (ie. a bunch of jars) so you don't need any kind of installer. Of course since it uses LWJGL you'll need permissions to load a native library, which means if you want to launch it from a browser you can use either webstart or an applet, but you'll have to sign it.
Advertisement
Yes, I figured as much. I'll have to live with that. Thanks!
enum Bool { True, False, FileNotFound };
Quote:Original post by hplus0603
Quote:Last time I looked at java they had given up on J3d


Well, that seems to depend on who you're asking. Java3D seems to still be developed; it's now a part of the Java community site, but it's not default part of the J2SE install (and neither is JOGL AFAICT).

The problem is, if I go with JOGL, I'll need to write model loaders and texture loaders and shader handling all by myself -- and I'll have the same OGL compatibility problems that a C++ OGL program would have, especially on Vista. Isn't there something better?

(And please don't say Multiverse :-)


I don't think that JOGL or Java3D be a part of J2SE in the near future, since they aren't as widely needed for everyday applications. I think that Sun is happy with it being a seperate download.

You are correct about Java3D, it is still being developed and is very slowly being fixed. Future iterations of Java3D are supposed to allow low level access to JOGL, as well as a couple other things, which will help somewhat, but I think that it will be several years down the road (if at all) before Java3D will be very good.

Greggles
I've been using JOGL and it's been quite good. I've only come acrossed one real problem with it, and that's their insistence on putting checks for direct byte buffers and correct state inside say, the glDrawElements call. I found this to end up taking ~20% of the frame time (even with an extremely simple scene) until I ripped it out.

Unfortunately, I'm still left with a Java method calling a native method as it's very difficult to remove it. E.g:

public void glDrawElements(int mode, int count, int type, long indices_buffer_offset){   glDrawElements0(mode, count, type, indices_buffer_offset);}private native void glDrawElements0(int mode, int count, int type, long indices_buffer_offset);


There's another glDrawElements that takes a Buffer object instead of the long.

Regards
elFarto

This topic is closed to new replies.

Advertisement