Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Java 3D open sourced? is there any affect on Xith?  (Read 4323 times)
0 Members and 1 Guest are viewing this topic.
Offline pepe

Junior Duke




Nothing unreal exists


« Reply #30 - Posted 2004-07-02 03:10:33 »

Quote

Java3D implements thread-safe scenegraph, while Xith3D implements non-thread-safe one, and here is a major performance difference.

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

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #31 - Posted 2004-07-02 06:32:28 »

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).

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline pepe

Junior Duke




Nothing unreal exists


« Reply #32 - Posted 2004-07-02 08:05:23 »

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.

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #33 - Posted 2004-07-02 14:54:39 »

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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline pepe

Junior Duke




Nothing unreal exists


« Reply #34 - Posted 2004-07-03 02:58:46 »

Shocked
Do you realize that:
Quote
 The internal message passing system and synchronisation effects associated with it are a major performance killer.

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

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?

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #35 - Posted 2004-07-03 03:36:07 »

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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Yuri Vl. Gushchin

Senior Duke




Speak Java!


« Reply #36 - Posted 2004-07-03 07:16:30 »

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

Yuri Vl. Gushchin
JProof Group
Offline pepe

Junior Duke




Nothing unreal exists


« Reply #37 - Posted 2004-07-03 08:23:07 »

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)

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #38 - Posted 2004-07-05 14:33:23 »

Quote

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


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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (49 views)
2014-10-17 03:59:02

Norakomi (38 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (34 views)
2014-10-15 16:18:58

TehJavaDev (65 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (54 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!