Performance and Design

Engines, Libraries and Tools Java 3D
#1

I have a need for speed - both in terms of rendering and software development. For me that means a high-level API (like Java3D) with the speed of LWJGL.

I really like the Java 3D API, but two things worry me.

First, Java 3D performs really poorly - and I still haven’t seen a demo to convince me otherwise. I have tried the RoboForge game, which is written in Java using Java 3D and - while its an original game - the graphics performance is certainly not good (compared to e.g. Quake). Can anyone point me towards a Java 3D demo that rocks? I really don’t believe that anyone will use Java 3D for games development until such a demo is made. Why hasn’t Sun created such a demo? What is it that makes Java 3D so slow? A bad design? A poor implementation? Something else?

Second, is a scene-graph-based API (like Java 3D) a poor choice in games development? If so, what is the alternative? (I am a newbie so please bear with me.) What kind of design does state-of-the-art 3D engines use (e.g. Quake) that make them so mind-blowingly fast?

Thanks.

#2

Hi,
you say j3d apis are really slow and you have not seen anything to convince you otherwise … then how come you know it is slow in the first place? ::slight_smile: … just kidding :wink:
go and check http://www.cosm-game.com/ that is quite impressive stuff in my humble opinion…
As for my own exp I’ve been working on terrain app some time and have no problems with performance - checking all the time with friend of mine who works on practically same app and is c++ guy and wouldnt touch Java and difference in FPS is couple of frames (both java and c++ version runs over 100FPS - that is on NVidia Ti4200). I guess you hit a nail saying it might be due to pure design - but desing of the actaull app and not API. Folk is running into problems due to pure documentation and to find best way to implement certain features one has to experiment a lot and watching java3d mailing thread helps a great deal as well…
just my 2 cents
Later

#3

On the Scenegraph thing, NetImmerse (Morrowind, Dark Age of Camelot, many others) is scenegraph based.

#4

It may help for you to just jump in and prototype a few things that you are trying to accomplish. There are people out there who are doing amazing things with Java3D - I have to agree that Magicosm is the best of the best. Check out the screenshots at the site - remarkable stuff.

My opinion on scenegraphs: A scene-graph API cannot intrinsically in itself be a poor choice for games development. The NetImmerse API is designed specifically for games development. Java3D is not specifically designed with games in mind, but if you’re careful it’s still a good fit.

#5

A scenegraph doesn’t really hinder performance of an application in any way - unless you make a really poor scene graph… but the same is easily said about non-scene graph techniques. I don’t believe that Java3D is necessarily a bad design of a scene graph, I believe that a lot of people are trying to fit a square peg into a round hole in their application of what Java3D’s scenegraph is good at.

As with all things, performance is really about having a tight render loop, not allocating lots of memory during runtime, and understanding what’s fast and/or slow about the hardware and the API you’re using. Same is true with other scenegraph APIs like NetImmerse. There are things that are snail slow if you do it one way in NI, and blazingly fast if done another way.

Don’t look just to the API to be the gauge of performance. The API should just allow you to do what you want with the least amount of overhead. In 99.9% of all slow applications I’ve seen (including regular Java applications), the API isn’t slow - the way its used it just bad.

#6

Yes, Magicosm looks cool. Unfortunately, there isn’t a demo to download so its hard to say how it performs.

Of course an inefficient app performs poorly. My worry was that a (seemingly) slow 3D engine (Java3D) is a showstopper for any application, regardless of its efficiency. Who wants to base their application on a slow framework?

However, it seems that people here agree that Java3D is fast enough for games purposes provided you use it efficiently. (Hopefully, using Java3D efficiently won’t make your code too hard to write and maintain, thereby forcing you to sacrifice the reason that made you start using it in the first place.)

Thanx for your input. I guess I’ll give Java3D a try and see for myself how it performs.

#7

I’m looking in a similar direction and the only real problem you will find is the almost zero support for Java3D - you will have to spend a lot of time poring over the javadocs if you’re going to make it work. If you’re looking at books, Selman is currently the best, as far as I can tell- java3d jumpstart is ok but only just tells you more than you can find online, the others have had very mixed reception. J3d.org is a good resource and it is very well worth subscribing to the Java3d-interest mailing list.

Good luck with it.

#8

Java3D … performance…

If you need the fastest spinning cube in the world, Java3D is not your friend. If you do things like this, Java3D also won’t give you maximum performance.

Java3D is highly biased due it’s goal of being scalable. The more complex it grows, the less the bias is noticable. So if you have a ‘full’ environment with terrain engine, hierarchical objects, animations, collision detection, lighting, LOD, picking, sorting, many textures, transparencies here and there … the more Java3Ds mechanisms get hold.

‘Doing it right’ in Java3D is not that difficult, bc. a scenegraph is a well understood architecture. Of course there are KO things that shouldn’t be done or things that are slow regardless how you do it.

At the end of the day, Java3D isn’t a top-performer. It’s a generic, well-behaved, multipurpose 3D engine without cutting-edge features. Stable (well…ok), reliable, scalable.

This might not sound highly attractive in the first place, bc. gamers always tend to look for the latest stuff first, but I feel that there are a lot of things that can be done before reaching Java3Ds limits.

#9

[quote]If you need the fastest spinning cube in the world, Java3D is not your friend.[
[/quote]
Indeed that was my problem when I initially tested Java3D, a spinning cube. But what disturbed me was that at 320x200/16 the cube was spinning fast (don’t remember fps), but at 1600x1200/16 it was very slow (about 5fps or so). I don’t have this problem with LWJGL (only expected frame rate reduction, but not that extreme).

So my question is: how does this happen? The difference in resolution should be only a problem if the gfx-board is too slow and then it should happen in both 3d-libs.

#10

These are the oddities. Maybe you had Java3D/D3D and LWJGL is OGL, together with some driver issues??

I just checked it out on my Athlon700/GeForce2MX and a full-featured game prototype still runs with ~20FPS in 1600x1200x32. So what you saw is not a principal problem.

#11

[quote]320x200/16 the cube was spinning fast (don’t remember fps), but at 1600x1200/16 it was very slow (about 5fps or so).
[/quote]
I’m quite sure this can’t have anything to do with java3d but it must be related to the video hw / driver.

Erik

#12

[quote]you will have to spend a lot of time poring over the javadocs if you’re going to make it work.
[/quote]
All I have to say is - what 3D API is easy? Openg GL - thats very complex. If you are looking for a dummy fied api - then you will most likey need one of those pre-build engines that you buy and just mod their engine - and even thats pretty complex…

#13

agree no 3d api are easy …you can make it “gamelike” easier but underlining principles are the same…sure more abstracted it gets faster you can get it done but we are still a bit afar from something like:

String wish_movement=“Please make this bird fly around the scene currently visible and PLEASE make it look COOL”;
gameObject.transform(wish_movement);

so no matter which api one decides to use - you have to get your hands math dirty

hm…but that is the fun isn’t it!!!

:wink:

#14

Actually the reason I use OpenGL is because it’s so utterly simple. The hard bit is not the API, it’s the knowledge of maths and techniques which take the time. The API is beautiful. Just look at Direct3D if you want to see how ugly things can be.

Learning the maths and techniques behind it all will only do you good, so do it!

Cas :slight_smile:

#15

Yes, OGL is simple. But using it is not. I used to work with D3D where e.g. setting a renderstate as well is simple. But combining 20 or so states to get a certain effect - thats where the complexity is. There also is the knowlegde of 3D techniques.

And then combining hundreds of these blocks of 20 states in a way that keeps performance high introduces the next level of complexity. There the knowlegde about the hardware comes into play.

Depending on the level you want to work, this knowledge might be valueable or useless. For my part I feel I wasted so much time playing around with renderstates (renderstates just as an example!). Today I feol more comfortable placing an object an artist made into the world an move is around :slight_smile: