Java 3D open sourced? is there any affect on Xith?

Engines, Libraries and Tools Xith3D Forums
#21

Yep. Put it this way: Elias has just spent the best part of a year writing the graphics engine for Tribal Trouble. I imagine he’d be pretty green if I could just plonk a few things into some scenegraph and it actually performed within a few percent of his custom engine after only 2 weeks’ work.

In fact to distil this sentiment further: right now I’m stuck doing 2D games because the sheer amount of hassle involved in doing 3D. If you can get the 3D abstraction down to the point that 2D abstraction is at you’re sorted.

Cas :slight_smile:

#22

[quote]Yep. Put it this way: Elias has just spent the best part of a year writing the graphics engine for Tribal Trouble. I imagine he’d be pretty green if I …

…right now I’m stuck doing 2D games because the sheer amount of hassle involved in doing 3D…
[/quote]
OK, granted. Now, can I ask you to point out what’s wrong with Survivor? Or Martian Madness? (Kev’s two quick-hack incomplete Xith games - assuming he won’t mind me calling them that ;)). I’m not - by any means - attempting to hold them up as shining examples (neither are complete, and survivor was hacked together from scratch in half the intended time, after the original graphics programmer disappeared). The interesting thing for me about survivor is that it had >> 50 animated MD2 models in a fast-paced game - EVEN paying the penalty of using beanshell for parts of the core game logic (which is a massive trade-off).

There were major problems (nb: could be our ignorance more than Xith, simply because we had no time to do things properly!):

  • overly large textures caused MASSIVE ballooning in JVM memory. E.g. putting 16Mb of 1024x1024 textures on the walls and floors added 70Mb+ to the amount of RAM used by the JVM.
  • sound system ahem sucked; any problems with sounds should just be ignored (super fast last-minute addition!), including performance glitches due to sounds being loaded etc
  • Xith’s 2D overlay system had a LOT of problems (which I know caused Kev some nightmares) and I’ve since identified some things that appear to be non-deterministic bugs in Xith’s clipping of 2D stuff.
  • collision detection breaks when FPS drops below about 15 - we were using a custom simplified system because of problems with Xith’s one.

Of course, in it’s present guise, Survivor looks very non-3D. But that’s a camera-angle problem :slight_smile: and was left as-is as much because we didn’t have the time for difficult stuff like tweaking cameras as for any other reason.

#23

Jme in my opinion has abstracted much of the 3d stuff to an even simpler solution to Java2D, while remaing extremely powerful.

Collision detection in jME:


CollisionResults rs = new CollisionResults();
CollisionDetection.hasCollision(spaceShipNode, WorldNode, rs);

if (rs.getNumber() > 0) {
  for (int i = 0; i < rs.getNumber(); i++) {
    System.out.println("Collision Occured between spacehip and " + rs.getNode(i).toString() );
 }
}

and thats it.

Compare that with Java2D?


if (spaceShip.intersects(enemy1) {
  //do something
}else if (spaceship.intersects(enemy2) {
  //do something else
}else if (spaceship.intersects(enemyBullet) {
  // do something rather odd and get out of my face
}

I do realise that the Java2D alternative is more specific than Jme, but then you can have different nodes depending on the alien. e.g. Aliens who come from the sun are rather stupid, so you put em into their own node and check collision with that. Aliens who come from earth are smarter ( :stuck_out_tongue: ), so you put em into a different node.

I know there are loads more ways of collision detection in Java2D, but none of them (that I have seen) come anywhere close to the simplicity of Jme.

DP

#24

If you want to know how good Xith3D or JMe have to be - go and download Blitz3D and write a 3D game right now. That’s how easy it is. Try it. Be in awe. Understand why and how it works.

Cas :slight_smile:

#25

I have seen Blitz3D, and to be frank, im not overly impressed. Its not extendable, its not portable, and its not Java :slight_smile:

DP

#26

You programmer types are always arguing about the minutae of grammatical correctness and OOP style instead of actually writing any games :slight_smile: Seriously, try Blitz. If there’s one thing it will do it’s let you write quality games, fast. It doesn’t need to be extensible (though, of course, it actually is…), nor does it need to be OOP (except that the new one’s out new and it’s got some OOP in it).

Think about it from the perspective of someone who wants to see results, on time and under budget.

Cas :slight_smile:

#27

But is Blitz3D a scenegraph?

#28

Yes.

Cas :slight_smile:

#29

[quote]so is NetImmerse, but NetImmerse is priced in the $125,000
[/quote]
Netimmerse/Gamebroy is much cheaper, it’s just $50,000 per platform-title (plus $25.000 per support-year if you need it).
lol
(The lol meaning the “much” and “just” words, not the engine itself, which looks impressive.)

#30

oh right, ive seen the site before, it does look impressive. jME is very similar to it :o

A bird told me that Renderware has begun to show its age as its been programmed in C. But heck, it still sells for alot of money!

#31

Would you have the kindness to release the code that you used to prove that? i’d really want to explore that problem.

#32

What sort of proof would you like? Although it’s not Xith3D, it’s a good enough indicator: Download Xj3D and run the browser in the two different renderers (commandline switch -ogl or -j3d). Load the same file in both and see how much faster the Aviatrix3D renderer is over Java3D (typically twice as fast). The internal message passing system and synchronisation effects associated with it are a major performance killer. About the only time J3D comes close to AV3D is in static geometry with no transforms because it does some optimisation we don’t (multiplies transforms through and generates interleaved arrays).

#33

I guess that to say that the scheduling mechanism is the cause of such a huge performance drop (a messaging system that takes 2 times the time to render a frame is for sure slow), he must have been into some interesting testing and benchmarking. I’d like to see them.

About your testing, how can you ensure that it is only the scheduling that makes the difference? It looks to me that there can be lots of other factors.

#34

For us, we have a very abstract architecture that separates the rendering from the runtime model. About 90% of the runtime model is independent of the renderer. Everything is then clocked based on a single “event” from the renderer (WakeupOnElapsedFrames(0) for J3D and SceneObserver.updateScene() callback for AV3D). The only place where we’ve had to break into separate code is for picking.

Most VRML/X3D content does not use the code paths where there is no picking so one of the simpler tests is just loading up worlds of various sizes and compexity and seeing what framerate happens.

The other test is a timed profile of how long it takes to execute our userland code before returning to the renderer. This allows us to judge the effects of renderer-specific interactions, particularly doing dynamic things like moving around. For any given world, the time difference between the two on a Win32 machine is not visible. (ie to 10ms accuracy) so the differences come down to the scene graph itself and how those changes get propogated through. Given the lack of accuracy of timers and the very different models that the two renderers use to update the scene graph, it’s very hard to get any accurate view on how a simple write to a node is in efficiency. But, we can have a decent approximation because the same VRML file will produce the same interactions with the scene graph regardless of renderer.

#35

:o
Do you realize that:

[quote] The internal message passing system and synchronisation effects associated with it are a major performance killer.
[/quote]
and:

[quote]Given the lack of accuracy of timers and the very different models that the two renderers use to update the scene graph, it’s very hard to get any accurate view on how a simple write to a node is in efficiency
[/quote]
simply state the opposite?
In the first, you state that messaging IS responsible for perf drop, and in the second you say that you can’t measure… That lack of timer is not a valid excuse. Accurate timers are accessible. use JDK5.0 or J3D’s timer. it’s there for that. And if the scene is not dynamic enough, why not make a completely dynamic scene?
Can you produce precise numbers and share code for that bench, so the FUD impression i have on that problem can be beaten down precisely?
Just a precision: i don’t do that to prove you are wrong, but to be certain of where the problem lies. I take that issue seriously.
Yuri, would you produce your code, also?

#36

You should take a look at the Java3D internals and the way it works. Both statements are entirely accurate and not contradictory. I’ll try a simple example to show you why.

Java3D works with a message queue internally. Say you do a setCoordinate() call. That takes your geometry and generates an object to be placed on the queue as well as making a local copy. This may require a copy and some simple checks (eg enough coords for vertex count etc). The code then exits back to runtime code. This part is relatively fast and efficient. There is some synchronisation here to make sure that two objects don’t clobber each other as they’re being placed on the queue. Nothing that a simple synchronized keyword on the add method and a synchronised block around the queue itself (in case the render thread is pulling objects off the internal queue as well).

As some point the render thread kicks in. It loops for items on the message queue and processes them one at a time until there is nothing left. There’s a lot of processing that goes on here. For example, for almost all the geometry it will pull the arrays, generate interleaved versions and a lot of other stuff behind the scenes. After all these are done, then the rest of the cull/draw render cycle takes place. However, due to the multi-threaded nature of that portion, it’s quite possible (though not definite as it depends on the number of CPUs and/or setting of some system properties) that there are more synchronised blocks to go through while it is doing culling, state/transparency sorting etc.

In addition to this very basic management, there’s another extra layer of complexity dealing with the behaviour system. At the start of the frame it has to do, potentially a lot of work to find out what behaviours are to be triggered. Potentially that means having to clear the message queue to pick up any transform updates above the behaviour locations and/or active viewplatform. I haven’t checked into the picking code yet, but I suspect it too may have to flush the message queue before each pick.

That’s why the outside code can be quite fast, yet it causes a much slower execution speed. The reason that Xith3D and AV3D are much faster than J3D is that there is no queue in the middle. Both of these scene graphs do not permit updates at any time other than at a very specific point in the app-cull-draw cycle. Java3D does not have this restriction. That means it has to be very careful about when those updates are placed on the queue and when they’re pulled of.

As for the code, simple - head to http://www.xj3d.org and download the current version of Xj3D. Install. Open any VRML or X3D file using the included Xj3DBrowser. If you are using a Win32 box, two icons are installed - on for Java3D, one for OpenGL. Take a look at the contents and you’ll see the only difference is the commandline switch. There’s a FPS counter on the lower left corner. That will give you the simplest check for the basic numbers. Go as small or as large a file as you like. We run everything from a simple rotating box (thus only transform update, no geometry), right up to full cityscapes that about 120 megs of raw geometry/animation data and over a gig of textures.

#37

Mithrandir’s explanations are 100% correct. As of benchmark, I am not really sure that it is even possible to do correct benchmarking of such a different engines like Xith3D, jME and Java3D, at least because of they have different architectures and often need different implementation approaches to get to highest possible performance, so the same functionality SHOULD be implemented differently for different engines, which leads us to the tests that I would never call benchmarks. If we agree to go this way, we very soon come to plaing OpenGL and SSE assembly coding, and even hardware implementations for the functionality of the tests.

Our internal tests show that there is a significant difference even if we add synchronization keywords to every possible scenegraph modification point.

Few months ago JavaCoolDude posted to this forum links for similar (read: the same) application coded for Xith3D and Java3D. This can be also a comparison example, in addition to Xj3D pointed by Mithrandir. And, of course, detalied studying of the codebases of these engines will explain a lot.

Yuri

#38

mhhh. did we diverge, or weren’t we talking about benchmarking event system and messaging of java3d? what had rendering to see with that?
Mithrandir’s test seems somewhat valid to me. Creating a big dynamic scene, with same hierarchy on the three engines (xith, j3d and aviatrix) and recording only time passed between renderings will benchmark how fast the messages and handling of the scenegraph is.
We are talking about three API that are all scenegraph. (and moreover are all ‘based’ on philosophy of one of them). Whatever the way to access the scenegraph, it stays valid for the whole bench. changing transforms does not means anything else than changing transforms, whatever the three of the API. (from a person using the engine point of view. internals are part of the merits and weakness of an engine and thus MUST NOT be taken in account)

#39

Yuri, that’s a rather interesting statement. Would you mind expanding on it with exactly where you put the synchronised pieces and what sort of performance penalties were seen? We haven’t done anything like that for Aviatrix3D yet, so I’m interested in hearing your experiences with it in Xith3D.