Great ! .... mmm wait a minute. Isnt Xith3d supposed to be faster than java3D ?so where's the point ?

panzo

The point is thats a throroughly unproven assertion. We've been around that block a half dozen tiems and noone so far can show me a benchmark that at all approximates what a game is likely to do to back the assertion up.

It MAY have been specifically faster for Magicsom because it was originally written for Magicosm and coudl take advantage of game-specific knowledge, but I knwo fo no general case that proves the assertion "Java3D is slower" in the general case.

The point is also that Java3D is starting to see an eco-system of commercial components aroudn it (genesisFX, Shawn's as of yet unnamed pure Java physcis engine.)

Did you want another point?

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Java Cool Dude did do some one on one comparisons with his demos way back and found Xith3D to be quite a lot faster. These may not be full games, but they are far from being (inaccurate) micro-benchmarks either. I'm not sure if the renderer was tailored much to magicosm, though no doubt David implemented first the features he needed (as I am doing now).

dpanzo, the point is however that there are still people using Java3D for games and for other applications who may need Odejava, Paul was probably one of these people.

I will jut add to this that I started my project (a board game framework with 3D display) with Java3D and ported it to Xith3D later on. Xith3D proved to be around twice as fast as Java3D.

All the other posts I've seen around shown that Java3D was rather slow.So despite what Jeff is allways saying, Java3D is slower than its competitors. This is not a big deal since Java3D offers features that none of its competitors provide.

I don't want to flame any of the different 3D engine available around. I just think that the features and needs they fullfill should be clear.

Java Cool Dude did do some one on one comparisons with his demos way back and found Xith3D to be quite a lot faster.

What kind of demos are these. do they do ANY offscreen geometry? Do they contain a complex array of graphics states?

If not then I am sorry they ARE worthless microbenchmarks. At least as applied to any 3D environmental game. (Thy *might* have limtied applciation to doing 2D games in 3D but why yould use a scenegraph for that at all is abit beyond me.)

Same questions apply to your board game. I am perfectly willing to grant you that for very simple things a very simple API without some of J3Ds over-head might perform better. Thats not a general proof that "Java3D is slower" however, merely a proof that simple apps are better supported by a scene graph that does not have all the over-head needed to make complex things fast.

(The vast majority of modern games, it should be noted, fall into the "compelx" category.)

The reason I am so strong on this point is that every time I've actually looked at someones "proof" of this contention that Java3D is in general slower then some other scene graph, its always fallen apart on analysis. And I've looked at quite a few.

Do you have a pointer to them so I can see them run?

Edit: Also, have these benchmarks and test been run on a multi-cpu box? All the next gen consoles are multiple core. Thats available now on the desktop and I would expect we'll start seeing it stadnard in high end game rigs fairly soon. Another place you pay a small amount in J3D over-head is in support of the fact that is extremely parallizable and automatically handles multiple-cpus for you...

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

All the other posts I've seen around shown that Java3D was rather slow.

As a side note then you must've missed mine.

Im getting better framerate out of JNWN then NWN does on the same paltform.

The problem with "conventional wisdom" is its usually incomplete and often totally wrong.Remember that "java code has to be slow" was conventional wisdom for a long time, and you'ld be surprised how many out there still buy the "Java is slow" belief.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Jeff, I am not really interested in participating further in benchmarking arguments. Everyone either says that their fav API is the best when the benchmark supports it, or that "benchmarks are unreliable anyway" when it doesn't. Most people forget in the process that there is more to an API than the framerate anyway.

hi all any one here can tell me how to get every thing installed so i can compile any odejava-java3d filethanks a lotplease email me if u can helpm_ali_alex@yahoo.com

don't bother with odejava-java3d, all you need to do is write your own code that reads a Vector3f and a Quat4f from each body in your odejava simulation and writes them to a corresponding transformgroup in Java3D (or another API according to your preference) with each step of your simulation.

Wow, I didn't realize this thread was here. I experimented this a year ago without noticing that the latest release was in 2004. Besides being ancient, it doesn't work with modern Java versions either--I kept getting weird errors for the most basic things, even if I simply copied and pasted code from tutorial websites.

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