Home › Forums › Programming › Java3D in Games Programming
- This topic has 21 replies, 11 voices, and was last updated 17 years, 9 months ago by Anonymous.
-
AuthorPosts
-
-
05/12/2006 at 3:33 pm #5735AnonymousInactive
I’m a final year student studying Multimedia. For my main research paper I’ve decided to explore the reasons why Java 3D is shunned when it comes to games programming. To accompany this I also have to create an application in Java 3D. I’ve decided to create an interactive crime scene.
If anybody could provide any links, books, documentation or any of there own personal advice I’d appreciate it.
-
05/12/2006 at 3:37 pm #34710AnonymousInactive
java = slow. QED.
As for links, books etc, you’d get afar better response by asking more specific questions.
Dave
-
05/12/2006 at 3:48 pm #34711AnonymousInactive
java = slow[/quote:f5dbbaceac]
This claim comes with almost no evidence. Jacob Marner did the only serious test (2002). Marner carried out comparative performance tests on OpenGL and Java 3D versions of the same 3D noninteractive space of randomly positioned, scaled and rotated boxes. He used the C++ and GL4Java bindings for OpenGL, and used Version 1.3.0 beta 1 of Java 3D. His master’s thesis, Evaluating Java for Game Development, can be obtained from http://www.rolemaker.dk/articles/evaljava/.[/quote:f5dbbaceac]
Java3D relies on Open3D or Direct X so graphic speed is virtually independent of the speed of Java.
I want any information on Java 3D and its history of game development. Any information from game developers as to why they don’t use Java 3D would be appreciated. Any necessary acknowledgments would be made. Thank you!
-
05/12/2006 at 4:42 pm #34713AnonymousInactive
Java3D relies on Open3D or Direct X so graphic speed is virtually independent of the speed of Java. [/quote:f53bef7d7c]
Writing a game is far more than simply OpenGL or DirectX, AI springs to mind immediately. The main benefit of java (interoperability) is also lost if you choose to use DirectX. Given that dX is written using lower level languages to begin with, you are likely to need to have C/assembly engine programmers anyway, it doesnt really make sense to have additional programmers in a different language on the team too without a very good reason.
I’ve also heard the argument that java *can* be as fast as C, and it is possible that this is true for certain cases, but in general if you are running a virtual machine layer it is an unwanted overhead that cutting edge games can’t really afford.
Any information from game developers as to why they don’t use Java 3D would be appreciated.[/quote:f53bef7d7c]
Some of the mobile developers might fancy a comment on this with regards to mobile games in the next few years?Dave
-
05/12/2006 at 5:02 pm #34714AnonymousInactive
java = slow[/quote:3a89f21312]
This claim comes with almost no evidence. Jacob Marner did the only serious test (2002). Marner carried out comparative performance tests on OpenGL and Java 3D versions of the same 3D noninteractive space of randomly positioned, scaled and rotated boxes. He used the C++ and GL4Java bindings for OpenGL, and used Version 1.3.0 beta 1 of Java 3D. His master’s thesis, Evaluating Java for Game Development, can be obtained from http://www.rolemaker.dk/articles/evaljava/.[/quote:3a89f21312]
Java3D relies on Open3D or Direct X so graphic speed is virtually independent of the speed of Java.
[/quote:3a89f21312]
Thats B.S. mate you better do alot more research there. You got java and its vm, then you got jni calls to get at opengl and d3d. So instead of direct calls to the libs you’ve got 2 levels of indirection. therefore its gonna be slow as fuck.Typically java isnt used because theres better libraries out their than java3d.
Also a ps3 or 360 doesnt have a virtual machine so you couldnt get the thing to run. Well actually you could prob hack a ps3, get linux onto the thing then run java 3d, but that aint exactly ideal.
-
05/12/2006 at 7:31 pm #34715AnonymousInactive
Isn’t Java used to implement the interactive menus for Bluray… I wonder if there’s a more interesting way to get java games running on the PS3 than booting into Linux…
-
07/12/2006 at 5:29 pm #34786AnonymousInactive
-
07/12/2006 at 5:30 pm #34787AnonymousInactive
-
07/12/2006 at 7:21 pm #34788AnonymousInactive
-
08/12/2006 at 12:05 pm #34791AnonymousInactive
Thanks, a lot of that was real helpful.
By professional I meant commercial. Apart from Law & Order II all the games created in Java 3D that I’ve discovered have been independent. I’ve heard of some online project called RoboForge that I haven’t gotten around to looking at. As for console support, I know that neither the PS2, XBox or GameCube support Java 3D, although I currently have no information on the next generation consoles (I imagine it’s the same story) or hand helds. I’ve been informed that because of the Wii’s virtual console feature it should have some compatibility but I’m positive this is speculation on my friends part.
This is my degree project so I have another couple of months to work on it. I’m currently looking for documentation or research papers to reference for my first draft and before I start on the actual application (which will hopefully be just after Xmas) Most papers I’ve found so far are more interested in creating a Java games engine rather than using the Java 3D implementation.
In the end I want to show that despite the fact Java 3D has been used for games successfully, it’s avoided . All the information so far has been great and I’m grateful for any other information people could provide. -
08/12/2006 at 1:07 pm #34794AnonymousInactive
As for console support, I know that neither the PS2, XBox or GameCube support Java 3D, although I currently have no information on the next generation consoles (I imagine it’s the same story) or hand helds. [/quote:20a88ce924]It is the same – one exception being if you install Linux on PS3 (see the Eurogamer article on this)
-
11/12/2006 at 11:32 am #34818AnonymousInactive
There is another efficiency problem with java3d, which you hit on in your last post. Using java3d forces you to use the java3d scenegraph implementation.
It is a general scenegraph implementation. And so, it is not a game optimised one, nevermind a game genre specific one. (if you use the given 3d engine, you might get a scenegraph with the engine, but the engine would probably be optimised for a certain genre or sub genre).
So it’s probably going to not completely fit the type of game you are coding, be too generic, and too slow. [/quote:d68ebf9958]Just found out, Java 3D gives you the option to use the scene graph but also has an immediate mode which bypasses it.
-
13/12/2006 at 2:17 pm #34439AnonymousInactive
Just found out, Java 3D gives you the option to use the scene graph but also has an immediate mode which bypasses it.[/quote:138aa2cc50]
Not sure if this is 100% true from what they say in the docs?
This scene graph can be minimal and not noticeable from an application’s perspective when using immediate-mode rendering, but it must exist. http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_3_API/j3dguide/Rendering.html#47302%5B/quote:138aa2cc50%5D
Anyway, if you decide to use immediate mode, then are you really using Java3D..?
JAVA 3D is fundamentally a scene graph-based API. Most of the constructs in the API are biased toward retained mode and compiled-retained mode rendering. http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_3_API/j3dguide/Immediatea.html#47576%5B/quote:138aa2cc50%5D
I would say that if you find yourself using the immediate mode, you have probably answered your original question:
For my main research paper I’ve decided to explore the reasons why Java 3D is shunned when it comes to games programming.[/quote:138aa2cc50]
If you are going to go down that route, of dropping most of java3ds features, why not just use OpenGL bindings for java or similar?
Eg: https://jogl.dev.java.net/
That’s probably going to be faster, less overhead… and probably be easier to port to a faster language later as well.
Again, haven’t really used java3d myself, and I’m no expert in this area, so would be curious to see what you end up doing. -
13/12/2006 at 3:44 pm #34404AnonymousInactive
I don’t know if anyone’s seen this, but there’s a games engine for Java called the Java Monkey Engine (don’t ask, I don’t know either). It’s based on another engine called LWJGL (Lightweight Java Games Library). Both have some pretty nice games, nothing ground breaking, but not bad nonetheless.
Also, if I remember correctly, there was talk of swapping the underlying engine of Java3D with JOGL when it became sophisticated enough. -
13/12/2006 at 11:54 pm #34389AnonymousInactive
The main benefit of java (interoperability) is also lost if you choose to use DirectX.[/quote:b8910367bf]
This is true on mobile etc….
[/quote:b8910367bf]JAVA “interoperability” on mobile? You’ve obviously never done much mobile development. Yes your code might work across several devices, but at what speed, memory constraints and screensize. The major device fragmentation is a serious pain, even among devices that are supposedy similar.
Anyway my 2 cents on Java3D is it is a load of rubbish. There are already plenty of libaries that are better and more mature for doing 3D in JAVA. I’ve always steered clear of Java3D after seeing how frustrated other people have got trying to use it. If I was doing a 3D game for desktop or console platforms in JAVA I’d use LWJGL.
-
14/12/2006 at 2:58 pm #34387AnonymousInactive
JAVA “interoperability” on mobile? You’ve obviously never done much mobile development. Yes your code might work across several devices, but at what speed, memory constraints and screensize. The major device fragmentation is a serious pain, even among devices that are supposedy similar. [/quote:959cd9b982]
I’m not sure your comment, that I’ve ‘never done much mobile development’ is warranted? (I actually have seen all the problems you described! :-) )
I never said Java was perfectly interoperable (I know it is not); I just said that the interoperability has been Java’s main advantage on mobile.
And this is true – the common platform and midlet portability (although not perfect) is the reason why j2me has been the success it has. Or what would you say the main benefit of Java as a mobile development platform is?
Again, I do agree that it’s far from perfect – have seen the problems you mentioned, and others (IO not working as described on certain devices etc). But it’s better than developing with vendor specific apis, and for a long time, it was more portable than brew?
Anyway my 2 cents on Java3D is it is a load of rubbish. There are already plenty of libaries that are better and more mature for doing 3D in JAVA. I’ve always steered clear of Java3D after seeing how frustrated other people have got trying to use it.[/quote:959cd9b982]
That seems to be the common opinion… -
14/12/2006 at 3:08 pm #34372AnonymousInactive
I’m not sure your comment, that I’ve ‘never done much mobile development’ is warranted? (I actually have seen all the problems you described! :-) )
[/quote:54a5c557d0]Yes, but on a forum I don’t know if your some kid ranting off about stuff he read on the net or someone who has actually done this stuff! Besides I wrote the above half asleep, so if it sounded harsh sorry!
-
15/12/2006 at 9:03 am #29245AnonymousInactive
Is there a link to the Project Proposal Document available? I think it would better inform the group as to the Software Requirements.
As Skyclad has pointed out above, Java (even Java3D) is relatively slow., strictly due to it’s Virtual Machine. This component which facilitates platform independence is also the nail in its coffin.
Note however, I use the the word “relatively slow.” If you are new to programming, and not use to direct memory access via C (or even ASM) as well as low-level API’s like Direct3D then you might not notice the cost.
There are several projects up and running like:
Which proves that 3D engines are possible with Java3D.
I would like to point out that, YES, Java3D could be used for game engine development, but everyone in industry will instinctively roll their eyes.
It reminds me of a former student, who took it upon himself to write his own string class, even after being introduced to STL. Every potential employer he showed his string class to, deemed it an exercise in futulity, (why re-invent the wheel, other than to prove you can?)
Again, if you can provide a link to the proposal document, perhaps I/we can offer better insights.
Hope this helps,
B. -
15/12/2006 at 9:11 am #29244AnonymousInactive
It reminds me of a former student, who took it upon himself to write his own string class, even after being introduced to STL.[/quote:f079c50a20]
Writing you own string class is the ultimate path to doom.
-
15/12/2006 at 2:47 pm #34857AnonymousInactive
While I can’t obviously speak for other people, I can tell you some the reasons why I found the JOGL bindings a much more appealing prospect than using Java3D:
(1) Writing programs using JOGL in Java is very similar to writing programs with the ordinary OpenGL libraries in C/C++. This is good because it means you can take any tutorials and resources written about OpenGL and easily apply it to JOGL. The only real difference between JOGL and OpenGL is the initialisation, loading of extensions and how the library functions are called- you call all OpenGL functions through a ‘GL’ object in JOGL instead of calling them directly as with regular OpenGL. JOGL is just a set of bindings really around the ‘proper’ C OpenGL libraries.
(2) JOGL is very flexible and gives a lot of control over the rendering pipeline. I’ve never used Java3D personally but I’d imagine it wouldn’t be as powerful or as flexible as using just regular OpenGL or a binding like JOGL. Does Java3D support shaders for instance ?
(3) While I haven’t done any sort of comparisons or concrete tests betweent the two libraries myself, the general consensus on the internet seems to be that J3D is much slower than using the likes of JOGL or LWGL.
Thats about it I think.. Now to go get myself a hangover cure :)
-
15/12/2006 at 3:49 pm #34859AnonymousInactive
Writing you own string class is the ultimate path to doom.[/quote:40253ab829]
Wrong…standard string classes are horribly inefficient. -
17/12/2006 at 1:28 am #34865AnonymousInactive
Writing you own string class is the ultimate path to doom.[/quote:5e23fa94c3]
Wrong…standard string classes are horribly inefficient.[/quote:5e23fa94c3]Perhaps.. But you still shouldn’t spurn the standard library classes unless your back is up against the wall performance wise and you require a more specialist / highly optimised class to fit your applications needs.
-
-
AuthorPosts
- The forum ‘Programming’ is closed to new topics and replies.