OK so as everyone already knows java3d is not that popular anymore. Something quite strange because this is a very solid and stable 3d api. So it cannot play the last 3d tricks like jogl or another binding api but it provides a scenegraph and a good model for building 3d games in java. There are, however some areas of java3d that were almost abandoned to the users to solve those problems themselfs. If you see the credits in many games you will notice that devs often pay a small team to build custom apps for them, like game editors that allow the artist to create a limited scene graph for their game engine and save it to a custom format. And i believe this was the one failure of vision of java3d devs. Content exporters are very limited. There are a few exceptions like x3d but those are often poorly documented and we dont have a good idea that any developer requires about the way they are translated to java3d. I think what a java3d user needs is an encoding like x3d that has a one-to-one relation to between xml nodes and java3d nodes and one that can be extended easly. Another problem is the lack of game editors and content creaters that could export to a pure java3d xml format. How many of you have spent any time creating your own game editors ? However today this is crucial and the java3d is criticaly lacking a generic game editor. Just some ideas to consider.
Actually, of primary importantce, it’s critically lacking is an active development team 
A generic game editor is quite hard to do, bc. it needs to be able to define the game specific things like behaviors, triggers, health points, relations and so on and so on.
But the basis to create such a thing is given due to the fact that Java3D is quite generic and well-behaved and some loaders for popular 3D formats are available.
XML might be a good format, but also might be not.
I feel other things are missing more and need to be attacked first:
[]simplify internals making it possible to make a Java3D app smooth, make frametimes more predictable and coherent
[]cleanup long-time issues like the whole sound thing that never worked reliably
[]open towards latest 3D technologies
[]tools: overlays, collision detection
[]OOTB set of loaders for common file formats OR a converter for a proprietary high-performance format
[]analysis tools: visualize axes, bounds, deliver performance numbers, culling info, statistics…
The first point may lead to a loss of scalability (towards MP machines, caves, … ) but maybe thats the price to make Java3D more suitable for gaming.
Im thinking that if a java3d game engine can work at about 60%-70% the speed of a C++ game engine and sacrifice some fireworks stuff like advanced opengl features then the performance problem is not a problem anymore and java3d is quite adequate for the job. Of course that this depends on how a game designer thinks that advanced opengl effects and engine speed are crucal for a good game. I could think of quite a few games that sold very well last year that could be done easly using java3d technology, but none of them were FPS.
"A generic game editor is quite hard to do, bc. it needs to be able to define the game specific things like behaviors, triggers, health points, relations and so on and so on. "
xj3d and x3d in general offer a good model for a game, based on the old vrml format. The way vrml works with events is quite good, i think. Many 3d apps can export to vrml (but not x3d). Java can be used to extended nodes as a scripting language.
Then what exactly a generic game editor would have to do ? Place 3d objects in the world, place special nodes in the world like triggers, characters, edit and attach scripts to nodes, edit internal databases, visualize and test the world. Finnaly i think that a generic game editor would have to be configurable and allow the user to hook code in it for certain game phases. Thats something that i was looking for in xj3d because i would like to hook some code after the x3d/vrml parsing to analize and transform the resulting java3d scenegraph. Stuff like plugable game engine code is essential when creating a game.
I’m pretty sure a Java scenegraph engine (lets call it Java3D 2.0 ) can do 100% (or even better) compared to a generic C++ scenegraph engine. This is due to the fact that a scenegraph in action is a highly dynamic data structure, where Java’s efficient memory management may pay out compared to a hand-made C++ allocation scheme.
The problem with a generic game editor might be that it can handle only the easy things in a generic way. Placing objects in a 3D world (isn’t FlyThru able to do that already? Or the NetBeans plugin? I think so). Then it has to offer a framework to do the difficult things.
The critical point is to design a framework that does not make the difficult things even more difficult! If it takes some days to teach it how to handle the sophisticated terrain engine, or the embed the editor for custom models of motion, or to access custim databases… it won’t help very much.
Writing a simple editor that creates the custom 3D environment and allows to place the (custom) 3D objects in there might be easier and leading to a more appropriate and specific game editor in the end. Some tools code I mentioned should be present in Java3D for that.
VRML completely sucks for games development. I cannot remember of even 1 game that used it! Its bloated and hard to parse. It’s very likely that the data needed to drive the game does not fit the hierachical structure of the 3D scene. So other databases are needed anyway.
I agree that a generic, pluggable 3D SCENE editor would be nice to make things fly at the beginning. But a scene editor is still quite far away from a game editor.
There have been attempts to create generic game editors in the industry. The successful ones like UnrealEd are (a) huge, expensive beast and (b) in no way generic.
[quote]I’m pretty sure a Java scenegraph engine (lets call it Java3D 2.0 ) can do
[/quote]
What an interesting name you did choose… Pure fiction?
Positive thinking
Always try to stay in the Sun ;D …
I’ve been involved in VRML from the very beginning and I can’t emphasis how true that statement is. I would never use VRML for games. For visualisation and other needs that don’t need hair-trigger response times, it’s good, or as a basic geometry interchange, it works, but nothing more than that.
Im working on a new format that is very easy to parse and translates directly (node to node) into a java3d scenegraph. Its similar to lisp. It would be something like this. The : identifies properties so “:pname value” would be translated into “instance.setPname(value)” after a node where the pname is located becomes instanciated.
( SimpleUniverse
:canvas3D ( REF myCanvas3D )
( Locale
( BranchGroup :name xg
( … ) )
( BranchGroup :name yg
( … ) ) ) )
The first name would identify the type of file, so a file could be just some 3d data for a primitive:
( Primitive … )
Of course that this would be useless without some simple applications to edit a scene using this format or to create geometry with it. But i believe that a couple of small java applications could do this.
About vrml, the event system seams to be very sofisticated and the way you can create dependencies between nodes using ROUTES is very cool. Java3D way to handle events use posts its not quite the same thing but its close. Its hard to imagine that you would need to expand a game with some feature that the Java3d post mechanism or vrml ROUTES could not provide.
Besides its a very elegant way to do things, the H-anim format was build on top of it. Most games dont go even close in providing an event mechanism as good as java3d or vrml so that may help in making them better by sacrificing funcionality.
[quote]I’m pretty sure a Java scenegraph engine (lets call it Java3D 2.0 ) can do 100% (or even better) compared to a generic C++ scenegraph engine.
[/quote]
I hope you are right. But let us try in 2 years time to compare Java3D/Xith3D to OpenSG/OSG. My bet is on the C++ based ones. Mainly because they are much bigger project that attract many more/better developers.
[quote]I’ve been involved in VRML from the very beginning and I can’t emphasis how true that statement is. I would never use VRML for games.
[/quote]
I use VRML for games. And I can only give you right, the great features of VRML cannot not be utilised in a networked game anyhow, the interactive functionality in VRML are going to have to be made in a game engine, unless X3D is going to support networked interactivity.
Sadly I did not have this great advice when I 2.5 years ago convinced my company to base their game on VRML.
[quote]About vrml, the event system seams to be very sofisticated and the way you can create dependencies between nodes using ROUTES is very cool. Java3D way to handle events use posts its not quite the same thing but its close. Its hard to imagine that you would need to expand a game with some feature that the Java3d post mechanism or vrml ROUTES could not provide.
[/quote]
Try making a networked game then, then it will be easy to imagine.
What is exactly the problem ? Maybe its the vrml players who are not optimized. Vrml is a model, it doesnt says anything about implementation.
VRML/X3D says a lot about the implementation such as minimum time interval (one second), how the content is to be loaded and the fact that a good portion of the runtime model can simply be ignored. Games require high resolution and high accuracy in order to control deterministically when things will happen. VRML/X3D do not guarantee that and actually go out of their way to enforce it. It’s a really bad choice for making games. For making models that are used in games, it is fine, but not for complete games.