Hello,
Paul Byrne emailed me a BSD licensed Java3D binding for Odejava and I have uploaded this to odejava.dev.java.net.
Check it out here: https://odejava.dev.java.net/servlets/ProjectDocumentList?folderID=1837
He notes:
If needed we can move the files into version control.
Thanks Paul!
Cheers,
Will.
that’s fabulous !!
Great news. Can’t wait to try it. unfortunatly, it will not be soon, but i’m already happy to be able to when my project enters the physics simulation stage.
YUM !!!
I suggest adding these to the CVS and giving Paul developer access so he can commit future changes, if Paul (or anyone else) feels up to keeping it up to date with Odejava.
Cheers, Jani!
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?
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.
Will.
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.
VincentWhat 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…
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.
Some support for Jeff’s argument: http://www.java-gaming.org/forums/index.php?topic=11748.msg93616#msg93616
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.
Xith3D suites my needs so that’s what I use.
Regards,
Will.
can any one tell me how to configure odejava-java3d
i am having hard time here on the first steps
thanks a lot
hi all any one here can tell me how to get every thing installed
so i can compile any odejava-java3d file
thanks a lot
please email me if u can help
m_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.
take a look at these classes from Odejava, it will help you:
org.odejava.display.BoundDisplayObject;
org.odejava.display.DisplayBin;
Java3D/Xith3D are just bindings, a bunch of utility classes that you really won’t need as I found out after playing a little with Odejava, they unnecessarily scare newbies shitless.
^^ I meant Odejava-java3d/Odejava-xith3D bindings of course. I hope I didn’t confuse anybody, it was late and I felt very revolutionary.
I agree entirely !
can someone remove the sticky flag - it’s quite outdated…
Two years later, I echo this sentiment…
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.
Just use JBullet, and an unsticky would be nice…