Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (537)
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  
  is Java3d dead and what are the alternatives?  (Read 7511 times)
0 Members and 1 Guest are viewing this topic.
Offline Usul

Senior Newbie




I hunt bugs


« Posted 2005-08-09 11:04:47 »

hi,

I am getting second thought on Java3D.  It doesnt seem that many people still use it.  So I have a few questions.

1) Is it dead?  I mean do people still use it?
2) Or can the fact, that Java3d is now open source rescue it?
3) Does the fact, that it is now open source mean that Sun doesnt support it anymore and that only the community is supposed to improve it?

I read about the alternatives (jogl, lwjgl, jme, xith3d).

questions to the alternatives:

4)  Is it possible to distribute applications using the alternatives via webstart, so that the user only needs to follow webstart-link in order to start it?  (because for me, none of the jogl demos worked)
5)  Is it possible, to distribute applications using the alternatives without webstart, while the user still should only need to double-click the *.jar file so that it runs?
6)  jogl and lwjgl seem to be pretty low level.  Does one have to write more code compared to java3d in order to achive the same?  For example when loading models.
7)  is xith3d a good alternative, because of the scene-graph approach?



If you dont want to answer all the questions, then thats fine too.  Any input is appreciated.

thanx,

Usul

It's times like this that I wish I'd listened to what my dad used to tell me.
Yeah? What was that?
I don't know. I never listened. 
- Dr. Venkman and Mr. Zeddemore
Offline kevglass

JGO Kernel


Medals: 123
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2005-08-09 13:02:56 »

Java3D is not dead, the Java3D Interest is very lively, it just doesn't seem to be used for many games recently. Java3D being open source is good for the community since its takes the future of the API out of the hands of businessmen and puts it back on community need basis.

However, Sun do still seem to be supporting it and providing people's time to update it. This is very impressive and should be applauded.

4) Yes
5) Yes
6) Yes, scenegraphs are simpler to use but lead to more generic solutions, which generally are slower. However, unless you know what you're doing pretty well at the low level you're unlikely to beat the performance (poly for poly) of a highlevel scenegraph written by people who do know the details.
7) Xith3D is very nice and better suited to game. You might also consider AgentFX, JMonkeyEngine, JPCT (see I didn't forget) and JExpresso

Kev

Offline tom
« Reply #2 - Posted 2005-08-09 13:18:23 »

1) It's not dead, but as you say, not many people are using it for games.
4) Yes, you can use webstart with the alternatives. Not always easy to get webstart to work for everyone though.
5) The alternatives will work with a double-clickable jar if you put the native libs in the same directory as the jar. You can not put the libs in the jar. Never, ever, put a native lib (dll) in any of the jre directories.
6) Yes, you have to write more code. It's also not easy to write fast opengl code.
7)Xith3d is a good alternative for Java3d if you wan't to make games. It's twice as fast and designed for games.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Usul

Senior Newbie




I hunt bugs


« Reply #3 - Posted 2005-08-09 16:06:48 »

Thank you both.

So I'll continue my current project using Java3d.  Since its a small game anyway and I'm not able to create fency modells or special fx, I guess it makes no difference.

It's times like this that I wish I'd listened to what my dad used to tell me.
Yeah? What was that?
I don't know. I never listened. 
- Dr. Venkman and Mr. Zeddemore
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #4 - Posted 2005-08-09 17:49:50 »

No, it's not dead, but it isn't progressing particularly fast either. All the Java-based competition has many more features than it and seem to be accelerating away from it in those feature collections. That's probably the biggest issues around it's current development.

Probably the major achilles heel for Java3D right now is it's speed. It's dreadfully slow when compared to all of the competition - gaming oriented or otherwise.  I don't know of any scene graph API that doesn't provide at least twice the frame rate and significantly less memory footprint when running the same content.  While it may be fine for small games that don't need fast framerates, that's not acceptable for other larger and more complex systems.  For commercial application developers like ourselves, that is not acceptable to our customers and they've all migrated away from J3D to other APIs.

The advantage that it has is the huge collection of utilities already around it - particularly the file format loaders. No other API can come close to that right now and probably won't for some time yet.

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 Jeff

JGO Coder




Got any cats?


« Reply #5 - Posted 2005-08-12 06:40:13 »

No, it's not dead, but it isn't progressing particularly fast either. All the Java-based competition has many more features than it and seem to be accelerating away from it in those feature collections. That's probably the biggest issues around it's current development.

Probably the major achilles heel for Java3D right now is it's speed. It's dreadfully slow when compared to all of the competition - gaming oriented or otherwise.

I would REALLY like to see the benchmarks on this.  I have yet to see a convincing one.

Java3D has some overhead that makes it slower on trivial microbenchmarks.

That same overhead is there for calculations that give it massive performance improvements on significantly compelx scenes.

Im getting great performance eo far on JWNW.  Well exceeding what the native NWN client delivers  on my hardware...

Java3D is used by folks like NASA for imaging applications.   Shawn Kendall at FullSail abandoned his custom scenegraph and went back to J3D.
You'ld probably want to ask him why.


EDIT: JNWN btw is a slow-progressing ebcause Im very busy, but active game project. RIght now Im workign with Shawn on pure-java collision and simpel physics for J3D.


EDIT 2: BTW, Java3D just added shaders, a major feature upgrade.  The next big one that is out there is multi-=pass rendering.  The team tells me they are looking at that for the major release after this one.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline uj

Junior Member





« Reply #6 - Posted 2005-08-12 11:33:55 »

I would REALLY like to see the benchmarks on this.  I have yet to see a convincing one.

Java3D has some overhead that makes it slower on trivial microbenchmarks.

That same overhead is there for calculations that give it massive performance improvements on significantly compelx scenes.

I asked about performance at the Xith3D forum. There seems to be no "official" benchmark available to back up any claims but there's some indication Xith3D may be about twice as fast as Java 3D.

http://192.18.37.44/forums/index.php?PHPSESSID=62e16784a0bff25282d30b6bd1bd7237&topic=10174.0
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #7 - Posted 2005-08-12 17:00:38 »

Try running Xj3D. It has renderers for both Java3D and our own scene graph. Our own scene graph does everything Java3D does, including multithreaded pipeline rendering and is at a minimum twice as fast, typically more. The bigger the scene the more Java3D falls behind. Look at the games like the old MagicCosm that went from J3D to Xith3D. Again, at least twice the framerate speed increase, though with a more gaming oriented implementation of the same API.  Shaders are nice, but all the competition has had them for more than 12 months now.  Other features missing that the competition already have are compositing, multipass rendering, access to other buffers than just the framebuffer etc.  What the competition miss is a big community around it and as a result a lot of utility code like file loaders, input device handlers etc. When implementing an application, that can be a big factor.

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 tom
« Reply #8 - Posted 2005-08-12 22:17:53 »

Java3D has some overhead that makes it slower on trivial microbenchmarks.

That same overhead is there for calculations that give it massive performance improvements on significantly compelx scenes.

Java3D is used by folks like NASA for imaging applications.   Shawn Kendall at FullSail abandoned his custom scenegraph and went back to J3D.
You'ld probably want to ask him why.

I think it's a myth that Java3D give such massive performance boost on complex scenes. A complex scene will run slow no mather how smart J3D is. Besided, games are all about custom culling that cuts down the scene size.

I'll bet there is quite a difference between NASA imaging applications and the games we wan't to make. Besides, I don't think NASA puts performance very high on the list of priorites. After all, they can just buy a more powerful workstation / super computer.

Offline Jeff

JGO Coder




Got any cats?


« Reply #9 - Posted 2005-08-13 06:40:55 »

I would REALLY like to see the benchmarks on this.  I have yet to see a convincing one.

Java3D has some overhead that makes it slower on trivial microbenchmarks.

That same overhead is there for calculations that give it massive performance improvements on significantly compelx scenes.

I asked about performance at the Xith3D forum. There seems to be no "official" benchmark available to back up any claims but there's some indication Xith3D may be about twice as fast as Java 3D.

http://192.18.37.44/forums/index.php?PHPSESSID=62e16784a0bff25282d30b6bd1bd7237&topic=10174.0


Without a benchmark to discuss, this is  a pretty meaningless staement.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #10 - Posted 2005-08-13 06:43:28 »

Try running Xj3D. It has renderers for both Java3D and our own scene graph. Our own scene graph does everything Java3D does, including multithreaded pipeline rendering and is at a minimum twice as fast, typically more.

Pointer pelase?

Quote
Other features missing that the competition already have are compositing, multipass rendering, access to other buffers than just the framebuffer etc.

Stencil Buffer has been added already.

As i mentioend before Multipass is the big "next thing" to do and the J3D team are quite aware of it.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #11 - Posted 2005-08-13 06:48:46 »

Quote
I think it's a myth that Java3D give such massive performance boost on complex scenes. A complex scene will run slow no mather how smart J3D is.

A stamenet of beleif with no supporting data cannot be dsicussed or argued with except to point out that it IS pure belief.

The same reason I do not debate with rabid Evangelicals.  (No offense to the Nice, reasonable, intelligent Evangelicals out there.)

Quote
Besided, games are all about custom culling that cuts down the scene size.

Java3D has very sophisticated and high performance view-frustrum culling.  The oevrhead of that is aprt of what makes "pump triangles to the visible screen" microbenchmarks meaningless.

 What more are you looking for?

Quote
I'll bet there is quite a difference between NASA imaging applications and the games we wan't to make.

I dunno.  The Mars rover simualtor I downloaded seemed pretty game-like to me **shrug*

Quote
Besides, I don't think NASA puts performance very high on the list of priorites. After all, they can just buy a more powerful workstation / super computer.

Sorry but I have to chuckle 'cause I KNOW people at ames reserrach. You have any idea how badly the republicans have cut their budgets over the past 6 years??  You probably have a bigger budget for your workstation then my friends have.

Besides, these days they are producing Apps to be run be anonymous downloaders from the net

EDIT:  Let me make this clear.  I don;t care WHAT scenegraph you or anyoen choses to use for their project.  What I DO care about is the promulgation of what are potentially myths and misinformation.  As long as the data youa re makign your decisions on is clear and well established, use whatever fits your tastes and project best.   If someone will give me a pointer to Xj3D or some other sufficiently complex test case Id be happy to look at it, and maybe even hand it off to the J3D team for analysis and comments.

What I do know is that there is a fair bit of real rocket science inside of J3D to deal with performance issues, some of which is actually sufficiently novel that it is patented by Sun.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline EgonOlsen
« Reply #12 - Posted 2005-08-13 18:42:07 »

JPCT (see I didn't forget)
  Grin

Offline Jeff

JGO Coder




Got any cats?


« Reply #13 - Posted 2005-08-13 21:32:28 »

6) Yes, scenegraphs are simpler to use but lead to more generic solutions, which generally are slower.

Important note. Java3D is NOT a scene graph renderer.

It is a scene graph translator.  Trying to render directly from a scene graph is a very inefficient way to render. J3D converts the scene graph to internal sortyed and organized lists of operations that are much more efficient to render from.

Part of that patented magic I was mentioning.

And yes, you would have to write a LOT of code in JOGL or LWJGL to start even matching J3D performance for anything at all complex.   Having said that if you are a John Carmack, working on the OGL level you can take cheats that are not correct in the general case but you can design your game around. If you do that it is possible, with a lot of work, to get better performance from a lower level like OGL.



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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline tom
« Reply #14 - Posted 2005-08-13 23:59:31 »

6) Yes, scenegraphs are simpler to use but lead to more generic solutions, which generally are slower.

Important note. Java3D is NOT a scene graph renderer.

It is a scene graph translator.  Trying to render directly from a scene graph is a very inefficient way to render. J3D converts the scene graph to internal sortyed and organized lists of operations that are much more efficient to render from.

Part of that patented magic I was mentioning.

And yes, you would have to write a LOT of code in JOGL or LWJGL to start even matching J3D performance for anything at all complex.   Having said that if you are a John Carmack, working on the OGL level you can take cheats that are not correct in the general case but you can design your game around. If you do that it is possible, with a lot of work, to get better performance from a lower level like OGL.

Your splitting hairs. Of course it organizes the geometry behind the scenes. That is the point of having a scene graph, and everyone does it. The code may be complex, but the theory is simple:
1) do state sorting to minimize state switches
2) batch geometry to maximize threwbut

When the scene gets bigger there is potenially more state switches and the scenegraph can sort this out for you. Even so, scenes in games are usually quite small. Microbenchmarks, like the one made by java cool dude will give a pretty good indication of how the performance will be in a real game. From what I've seen and heard, J3D is slow.

Offline Jeff

JGO Coder




Got any cats?


« Reply #15 - Posted 2005-08-14 02:30:36 »

6) Yes, scenegraphs are simpler to use but lead to more generic solutions, which generally are slower.

Important note. Java3D is NOT a scene graph renderer.

It is a scene graph translator.  Trying to render directly from a scene graph is a very inefficient way to render. J3D converts the scene graph to internal sortyed and organized lists of operations that are much more efficient to render from.

Part of that patented magic I was mentioning.

And yes, you would have to write a LOT of code in JOGL or LWJGL to start even matching J3D performance for anything at all complex.   Having said that if you are a John Carmack, working on the OGL level you can take cheats that are not correct in the general case but you can design your game around. If you do that it is possible, with a lot of work, to get better performance from a lower level like OGL.

Your splitting hairs. Of course it organizes the geometry behind the scenes. That is the point of having a scene graph, and everyone does it.

 Not the traditional scene graphs such as Inventor.

Nor do the scenegraphs msot people are taught to write in basic college classes.

Its an important distinction.  "Scene Graph" in this case describes the API but not the render.
Sicne you are talking ABOUT render speed, thats a critical diffrerence.  A pure scene graph based renderer WILL be slow because it does a lot of extra matrix manipulation, does a lot of work on thinsg that never get drawn at all,  and doesnt render  in the ideal order.

Quote
The code may be complex, but the theory is simple:
1) do state sorting to minimize state switches
2) batch geometry to maximize threwbut

You left out a few things. Such as matrix concatenation and view/frustrum culling...

Quote
When the scene gets bigger there is potenially more state switches and the scenegraph can sort this out for you. Even so, scenes in games are usually quite small.

 Compared to what?  They are among the most complelx I've ever dealt with...
 
Quote
Microbenchmarks, like the one made by java cool dude will give a pretty good indication of how the performance will be in a real game.

Not knowing the microbenchmark in question I cant comment. In genreal microbenchmarks fail to predict real-app performance because they do not act like real apps. Its really that simple.

The most common "look how slow J3D is" benchmark I see... and I see this over and over, is a pure pixel throughput benchmark where all triangles drawn are visible in the rendered view.  These are by definition totally worthless.
 

Quote
From what I've seen and heard, J3D is slow.

Again, point me at a real benchmark and we can discuss it.  Oterhwise this is just assertion and mythology.  (And by 'point' I mean give me source code so I can do a proper analysis.  Its quite easy to make J3D performance bad by using it badly...  This is true of ANY API.)

EDIT: Oh and I suggest if what you say is true, then you havent seen very much in  J3D.  Certainly you havent seen Shawn Kendall's demos we showed every year for years at GDC...


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2005-08-14 02:44:30 »

Another BTW...

Java3D is also very good at parallel scene processing.

This isnt that important today, but as multiple core machiens become more and more common its soemthing to consider.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #17 - Posted 2005-08-14 05:24:03 »

So here's a real game benchmark for you with real game data...

JNWN on my laptop, (Sony VAIO PCG-GRT290ZP) with physics currently turned off and no particles, but oterhwise running the real starting map from the "DEMO-The Cat Lady" module and one movign animated character (a lioness) is running at a reliable 250fps.

Frankly, that easily falls into my "fast enough" range.

Edit: As a side note, this is without any serious profiling.  At one point I did have a sudden, mysterious, serious slow down. I ran the profiler and discovered a leak in the J3D pick code.  Paul fixed it and the problem went away. 

This does however point to the real need to keep a profiler handy when coding any game code.  Sometimes you will do something or run into a bug that causes a slow-down. At that point you want to be able to understand why the slow down is ocurring bewcause its usually a simple matter to fix.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #18 - Posted 2005-08-14 06:01:06 »

Jeff,

I don't have any direct benchmarks for you to play with. However, you can go and download Xj3D yourself from here http://www.xj3d.org/downloads.html  Then, using the commandline switches of -ogl and -j3d you can run the Xj3D browser with exactly the same X3D or VRML file and watch the framerate counters yourself.  Apart from the low-level scene interaction, all of the runtime infrastructure (file loading, X3D event model evaluation, input device processing etc) are common.

One thing I can directly comment on - have a look at the video of the JavaOne main keynote. Xj3D was shown off there for about a 5 minute stretch. WHen given the option of the renderer to chose -either Sun's official Java3D or the OpenGL renderer, they chose the later, not the former because of that huge performance difference. We're not talking trivial rendering either, we're talking large-scale terrain visualisation with a lot of realtime input from systems such as autonomous underwater vehicles, DIS (distributed interactive simulation protocol) and more.  Xj3D is the benchmark you are looking for because we cannot take any game-specific hacks to make one renderer faster than another. We have  to deal with random content from any user from anything as simple as a rotating cube up to full geospatial applications running realtime input from hundreds of sources simultaneously, or medical visualisation, or skeletal animation systems, rigid body physics and more.  Basically everything including the proverbial kitchen sink is run over both renderers.  In our case, the OpenGL scene graph that we coded, called Aviatrix3D, does do everything Java3D does, including parallel scene processing, multipipe and multi-stage rendering etc. In fact, the API looks a fair bit like Java3D's. Our stock development boxes are dual Xeons running HT to make it look like many of our deployed users' systems - multi-cpu visualisation machines.  Java3D certainly is not unique in these capabilities, and that's what I'm trying to point out. Even on equivalent systems, with equivalent scene graph capabilities, it is very far behind the ballpark right now in performance and capabilities terms.

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 Jeff

JGO Coder




Got any cats?


« Reply #19 - Posted 2005-08-14 06:09:16 »

Jeff,

I don't have any direct benchmarks for you to play with. However, you can go and download Xj3D yourself from here http://www.xj3d.org/downloads.html 

Is there source?  Without the ability to  profile and see what is actually going on I cant really asses this.

As I mentioned above, a single screw up or hitting a bad bug corner case of an API can significantly imapct your performance results.

A question-- have YOU tuned your API for this test case?  If so then its a pretty bogus comaprsion until J3D is equally tuned, isn't it?  (Remember the bad old days of seive-generators in C compilers? Same fundemental idea here.
 
Quote

One thing I can directly comment on - have a look at the video of the JavaOne main keynote. Xj3D was shown off there for about a 5 minute stretch. WHen given the option of the renderer to chose -either Sun's official Java3D or the OpenGL renderer, they chose the later, not the former because of that huge performance difference.

Id ask if you have that actual statement from them as to motives.  or if thats supposition on your part, but its irrelevent really because of the above issue,

Quote
Java3D certainly is not unique in these capabilities, and that's what I'm trying to point out. Even on equivalent systems, with equivalent scene graph capabilities, it is very far behind the ballpark right now in performance and capabilities terms.

Again, the performance thing is at this point is assertion .  You have one test case.   If you can point me at full source Ill actually take the time to do a  bit of analysis.  You could also download JNWN, its open source, and port it to your scenegraph if you wish for comparison purposes.

Features that are useful for game development we havent begun to talk about really, except that J3D currently needs  multi-pass rendering. Its well known. Its on the plans.

I'm glad your proud of your accomplishment, but you've also got a bit of a bias and something to prove here.. nes' cest pas?

EDIT: And once someone is running a recent game's real content at 250fps, one has to ask if performance is even worth makign an issue of,  doesn't one?

EDIT:  The URL you gave above generates a 404 error.  Ill poke around that site a bit I guess.

EDIT: Found it. Downloaded it. Now the question arises of content.  I want a variety of things to try and explore.  Can you give me general directions on how I download and run an X3D file and soekm repositories thereof?


EDIT:  P.S.  Just an observation.  If you really do *everything* J3D does then you are almost certainly in patent violation.  Luckily Sun doesnt sue folks generally over such things.  Thats not a promise, just an observation.

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #20 - Posted 2005-08-14 06:58:15 »

First attempted comparison:
http://www.web3d.org/x3d/content/examples/StudentProjects/AllenDuttonVillage.x3d


Ran with the Xj3d browser with the -j3d flag.  Got frame rate whiel rotating of app 8.5

Ran again with Avaitrix, blew up with the following exception...

java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
        at org.j3d.geom.CharacterCreator.createNewGlyph(CharacterCreator.java:418)
        at org.j3d.geom.CharacterCreator.createCharacterTriangles(CharacterCreator.java:162)
        at org.j3d.renderer.aviatrix3d.geom.Text2D.setText(Text2D.java:609)
        at org.web3d.vrml.renderer.ogl.nodes.text.OGLText.setupFinished(OGLText.java:165)
        at org.web3d.vrml.renderer.common.nodes.shape.BaseShape.setupFinished(BaseShape.java:399)
        at org.web3d.vrml.renderer.ogl.nodes.shape.OGLShape.setupFinished(OGLShape.java:352)
        at org.web3d.vrml.renderer.common.nodes.BaseGroupingNode.setupFinished(BaseGroupingNode.java:319)
        at org.web3d.vrml.renderer.ogl.nodes.group.OGLTransform.setupFinished(OGLTransform.java:191)
        at org.web3d.vrml.renderer.common.nodes.BaseGroupingNode.setupFinished(BaseGroupingNode.java:319)
        at org.web3d.vrml.renderer.ogl.nodes.group.OGLTransform.setupFinished(OGLTransform.java:191)
        at org.web3d.vrml.renderer.common.nodes.BaseGroupingNode.setupFinished(BaseGroupingNode.java:319)
        at org.web3d.vrml.renderer.ogl.nodes.group.OGLGroup.setupFinished(OGLGroup.java:159)
        at org.web3d.vrml.renderer.common.nodes.core.BaseWorldRoot.setupFinished(BaseWorldRoot.java:270)
        at org.web3d.vrml.renderer.ogl.nodes.core.OGLWorldRoot.setupFinished(OGLWorldRoot.java:149)
        at org.web3d.vrml.renderer.CRMainSceneBuilder.endDocument(CRMainSceneBuilder.java:546)
        at org.web3d.vrml.renderer.ogl.OGLVRMLSceneBuilder.endDocument(OGLVRMLSceneBuilder.java:406)
        at org.web3d.x3d.jaxp.X3DSAVAdapter.endDocument(X3DSAVAdapter.java:496)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:786)
        at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endDocument(XMLDTDValidator.java:990)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:564)
        at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1899)
        at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1803)
        at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipSpaces(XMLEntityScanner.java:1304)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(XMLDocumentScannerImpl.java:1253)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:372)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:844)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:774)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1255)
        at org.web3d.parser.GeneralisedReader.parse(GeneralisedReader.java:246)
        at org.web3d.vrml.nodes.loader.DefaultWorldLoader.loadNow(DefaultWorldLoader.java:145)
        at org.web3d.vrml.nodes.loader.DefaultWorldLoader.loadNow(DefaultWorldLoader.java:95)
        at org.web3d.net.content.Utf8ContentHandler.getContent(Utf8ContentHandler.java:114)
        at org.ietf.uri.ResourceConnection.getContent(ResourceConnection.java:297)
        at xj3d.browser.Xj3DBrowser.load(Xj3DBrowser.java:884)
        at xj3d.browser.Xj3DBrowser.run(Xj3DBrowser.java:1222)
        at java.lang.Thread.run(Thread.java:608)
                                               

Will try some other examples.



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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #21 - Posted 2005-08-14 07:09:30 »

Next test:

http://www.web3d.org/x3d/content/examples/StudentProjects/PlayRoom.x3d

7 to 8 fps on Java 3D
12-14 fps on Aviatrix BUT the floor textures, which rendered properly in J3D, were all messed up in Aviatrix.

These are not terribly complex scenes.  Honestly, getting 8 to 25 FPS on a machine which gives me 250fps  on a full NWN map strongly suggests to me that your bottleneck is NOT your renderer but merely that the choice of renderer is in some minor way impacting your primary problem. 

(My first guess would be memory consumption and that the Xj3D veiwer is gobblign up memory in its own inetrnal structures to represent the data in X3D format.  I can easily believe that J3D might be using a bit more memory then some other scene graph, its has some pretty complex internal structure itself.  In general J3D apps dont maintain other scene description structures in parallel to the J3D ones.)

Anyway, if you can point me at source I may do some basic profiling to prove the 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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #22 - Posted 2005-08-14 07:26:58 »

Odd program.  very unstable performance wise

I moved max mem up to 900M and removed the other -XX flag from both.

I now get apout 100 - 250fps from J3D moving in and out and
125 - 400 fps for aviatrix moving in and out

BUT

If I keep the (minorly) complex play room onscreen and move side to side I get only 100-150 fp from Avaitrix and  200 -400 fps from J3D!

There also appears to be some serious memory leak problems in this app as while I was typing this, Aiviatrix dropped to 14 - 16 fps on the sideways test.  I havent tried it with J3D yet but, as thats the range I was geting initally before I doubled memory, Id guess Id get a similar drop over time from J3D.
I'm willing to postulate that, in any event.

Short answer:

This app is very unstable and inconclusive as a benchmark.  Depending on what you are doing and when either API can appear up to 2x faster then the other.  My gut says that Aviatrix in general does better on scenes wher there is not a lot of veiw frustrum clipping and J3D pulls out ahead when there is a lot of view frustrum clipping.  That would explain what I'm seeing but its far from conclusive due to the general instability of the tests.

More importantly, the two renderers do not produce the same visible results and there is no gaurantee that Aviatrix, in fixing its mapping problems, woud retain the same render characteristics.

I still find it perplexing that this app renders scenes much less visually complex then an NWN  map and without the dynamic animation  at significantly slower rates then JWNW renders.  (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently... but that wouldnt work for a real game.)

Finally, its clear to me that bad memory management issues in this App are complicating the entire test.


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline tom
« Reply #23 - Posted 2005-08-15 02:10:48 »

Quote
When the scene gets bigger there is potenially more state switches and the scenegraph can sort this out for you. Even so, scenes in games are usually quite small.

 Compared to what?  They are among the most complelx I've ever dealt with...


Take an indoor game as an example. After disabeling what is not visible using pvs or portals you've left with a couple of rooms including content. It's not that far off from what you can reproduce with a benchmark.
 
Quote
Quote
Microbenchmarks, like the one made by java cool dude will give a pretty good indication of how the performance will be in a real game.

Not knowing the microbenchmark in question I cant comment. In genreal microbenchmarks fail to predict real-app performance because they do not act like real apps. Its really that simple.

The most common "look how slow J3D is" benchmark I see... and I see this over and over, is a pure pixel throughput benchmark where all triangles drawn are visible in the rendered view.  These are by definition totally worthless.

Ok, you've made the view-frustum culling point over and over again, but I disagre. Every engine you can compare J3D against will have frustum culling, and you'll expect it be fast. I don't believe J3Ds implementation is so much better than all the others, that it will have a huge effect on the rendering speed. Given that it is more or less a constant, you don't have to take this into consideration when doing a benchmark.

I know you'll disagre so I'll ask now: What makes J3Ds view-frustum culling so much better than the others?
 
Quote
Quote
From what I've seen and heard, J3D is slow.

Again, point me at a real benchmark and we can discuss it.  Oterhwise this is just assertion and mythology.  (And by 'point' I mean give me source code so I can do a proper analysis.  Its quite easy to make J3D performance bad by using it badly...  This is true of ANY API.)

EDIT: Oh and I suggest if what you say is true, then you havent seen very much in  J3D.  Certainly you havent seen Shawn Kendall's demos we showed every year for years at GDC...

Ah yes, the GDC demos. Well I've seen the videos, but never got my hands on anything I could actually run. Please post a link if you've got one.

Besides, I've made a game with J3D and can draw my own conclusions.

Quote from: Jeff
I still find it perplexing that this app renders scenes much less visually complex then an NWN  map and without the dynamic animation  at significantly slower rates then JWNW renders.  (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently... but that wouldnt work for a real game.)

Why do a static scene render more efficiently if it is represented as a BSP?

Offline Jeff

JGO Coder




Got any cats?


« Reply #24 - Posted 2005-08-15 02:28:52 »

Quote
When the scene gets bigger there is potenially more state switches and the scenegraph can sort this out for you. Even so, scenes in games are usually quite small.

 Compared to what?  They are among the most complelx I've ever dealt with...


Take an indoor game as an example. After disabeling what is not visible using pvs or portals you've left with a couple of rooms including content. It's not that far off from what you can reproduce with a benchmark.

Your getting confused by the term "complexity".  Its a lot more then just polygon count. Its the comlexity of the organization of those polygons.  How many are  in or out of the view frustrum at one time.  How easy it is to desitinguish one from the other, etc.

A microbenchmark is typically way too un-complex in these areas.
 
Quote
Quote
Quote
Microbenchmarks, like the one made by java cool dude will give a pretty good indication of how the performance will be in a real game.

Not knowing the microbenchmark in question I cant comment. In general microbenchmarks fail to predict real-app performance because they do not act like real apps. Its really that simple.

The most common "look how slow J3D is" benchmark I see... and I see this over and over, is a pure pixel throughput benchmark where all triangles drawn are visible in the rendered view.  These are by definition totally worthless.

Ok, you've made the view-frustum culling point over and over again, but I disagre. Every engine you can compare J3D against will have frustum culling, and you'll expect it be fast.

You realize you just FIATed away the question by saying "Im going to ASSUME the other API asi as good at view frustrum culling as J3D"?

Thats not an argument, thats presuming the answer you want.

The fast of the matter is there is a LOT of stuff in J3D to make the view frustrum cullign efficient.  It has a highly efficient bouding volume system, for instance, thats used both by the culling and by the pick code.

Quote

I don't believe J3Ds implementation is so much better than all the others, that it will have a huge effect on the rendering speed.


Your doing it again. Arguing your beliefs, not facts.  In fact, what your really saying is "I BELIEVE this so I refuse to consider testing that belief."

Good argument for religion,  Lousy for science.

I wont argue your beleifs or religion with you.  You can believe the moon is blue cheese. Its your business.

Quote
 
Quote
Quote
From what I've seen and heard, J3D is slow.

Again, point me at a real benchmark and we can discuss it.  Oterhwise this is just assertion and mythology.  (And by 'point' I mean give me source code so I can do a proper analysis.  Its quite easy to make J3D performance bad by using it badly...  This is true of ANY API.)

EDIT: Oh and I suggest if what you say is true, then you havent seen very much in  J3D.  Certainly you havent seen Shawn Kendall's demos we showed every year for years at GDC...

Ah yes, the GDC demos. Well I've seen the videos, but never got my hands on anything I could actually run. Please post a link if you've got one.

They belong to Shawn. Ask him.

JNWN is a project right here you can grab the CVS of.
https://jnwn.dev.java.net/

To run JNWN you will need a copy of the NWN data.  You can either get that from an NWN installation or download it here:

http://nwn.bioware.com/downloads/linuxclient.html#lininstall


Quote
Besides, I've made a game with J3D and can draw my own conclusions.

A poor workman blaims his tools. And thats ALL I'm going to say on that.

Other then that you can ask others how often the "I KNOW Java is slow 'cause I tried to write something in it and it was slow" argument comes up from the Java-ignorant who stick their noses in here.

Im honestly sick and tired of dealing with it.

Quote from: Jeff

Quote
I still find it perplexing that this app renders scenes much less visually complex then an NWN  map and without the dynamic animation  at significantly slower rates then JWNW renders.  (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently... but that wouldnt work for a real game.)

Why do a static scene render more efficiently if it is represented as a BSP?

Your kidding, right?  Or are you not familair with BSP trees?

A BSP is a terrific structure for determining incredibly fast what is "behind" the view and thus eliminating approximately half the scene from ANY consideration or furtehr testing for inclusion in the render set.

Furthermore, the BSP makes finding front to back order trivial, which helps with things like distance-culling.   
There are other things you can do with it too, some of which are less imprtoant  in these days of big Z buffers, but others which can still be important. (Such as ordering for scenes with a lot of transparency.)

Unfortunately, it only works for static geometry.

EDIT: On considering this whole exchange, I do have one  more things to say. 

Kesselman's Definition of Religion:  Religion is a belief that has been invested with an emotional stake by the beleiver.

IMHO thats exactly what we have here.  You tried to write a program. You didnt hit your performance goals initially.  Youd ecided it was the fault of the tools and thus vindicated yourself  Yoiu now have an emtional stake in that belielf.   And therfor there is little point to trying to discuss it.

Already been there, done that, I know from experience its pointless,  Believe whatever makes you feel good, just make clear to others thats what you are spouting-- pure religious belief.

If you have honestly blinded yourself to the poitn where you cant understand why one API, which spends more effort on view frustrum culling, as opposed to another that spent less on such culling,  would process scenes with NO view frustrum cuilling slower but scenes with ALOT of view frustrum cullign faster, then I really don't see how I can help you understand.

I think its time to do this....

PLONK

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #25 - Posted 2005-08-15 11:13:03 »

Since I'm normally the one arguing like Jeff above, and he normally chimes in after I've had a few rants, I thought I'd return the favour Tongue

IME, java3d performance *at the moment* is bad, really bad, on most non-trivial scenes *on many computers, but not all*. Quite a few java3d games came my way because of JGF and got tested on a wide variety of machiens with similar processors (within factor of 2 CPU speed, and factor of 2 performance gfx cards) got FPS that on some machines was 40+ and others was 0.25 or worse, consistently. I can think of several explanations for this, all of which come down to "insufficient time spent testing and fixing scenarios where it's behaving badly, and could be driver bugs or could be SG bugs", which is par for the course in a typical OSS project. From conversations with people on the j3d team and others at sun, it sounds as if that kind of task isn't on the agenda much, they're instead concentrating on doing more for the people for whom it already works (adding features etc) (yes? no?).

That, of course, is a major problem for games devs who have to support *all* machines, as opposed to e.g. research centres where they only have to support literally a handful of make/model combinations. YMMV, I'm only passing on what I gleaned - it may no longer be the case. But, given how much time it takes to do that sort of thing, and how it doesn't impact some users at all, tis easy to see how it might get deprioritized.

OTOH...I have to say that many of the complaints against J3D do seem based mostly on hearsay and theoretical extrapolation (which is what I just did above: I've seen a dozen or so recent J3D games all have the same severe problems, so I'm *guessing* that it's not just coincidence and is a general problem - I may be completely wrong). The Aviatrix3D is the only stuff I know of that we can currently use for side-by-side comparisons, and I wonder how much this has to do with the way most people I know who've tried Xith3D for their game seem unwilling to go back to Java3D, even for a test? I've tried many times to get more people to try both side by side, but as soon as someone tries Xith seriously and finds they can use it at all (i.e. their code isn't too dependent on missing features from J3D) they don't seem to go back.

In the meantime, we've got a feature-list side-by-side comparison, which I'd appreciate any updates and/or additions for:
http://javagamesfactory.org/views/view-library-category-features?category=Graphics%20Engines

malloc will be first against the wall when the revolution comes...
Offline tom
« Reply #26 - Posted 2005-08-15 18:09:05 »

You realize you just FIATed away the question by saying "Im going to ASSUME the other API asi as good at view frustrum culling as J3D"?

Thats not an argument, thats presuming the answer you want.

The fast of the matter is there is a LOT of stuff in J3D to make the view frustrum cullign efficient.  It has a highly efficient bouding volume system, for instance, thats used both by the culling and by the pick code.

There are many game engines and scene graphs out there. Many are commersial engines used in real games. No, I don't know how they've implemented their culling, because that information is usually not available. No one knows for sure whos the best, not even you. But I find it logical that J3D is not the only one who has mastered this technology.

Quote
Quote

I don't believe J3Ds implementation is so much better than all the others, that it will have a huge effect on the rendering speed.


Your doing it again. Arguing your beliefs, not facts.  In fact, what your really saying is "I BELIEVE this so I refuse to consider testing that belief."

Good argument for religion,  Lousy for science.

I wont argue your beleifs or religion with you.  You can believe the moon is blue cheese. Its your business.

Facts are hard to come by. Seems to me you are just arguing your beliefs.

Quote
Quote
Besides, I've made a game with J3D and can draw my own conclusions.

A poor workman blaims his tools. And thats ALL I'm going to say on that.

Other then that you can ask others how often the "I KNOW Java is slow 'cause I tried to write something in it and it was slow" argument comes up from the Java-ignorant who stick their noses in here.

Im honestly sick and tired of dealing with it.

I made a real game with J3D. From my experience I found J3D a bit on the slow side. I don't see myself as a newbie when it comes to computer graphics, but I might have high thoughts about myself. Tongue

Quote
Quote from: Jeff

Quote
I still find it perplexing that this app renders scenes much less visually complex then an NWN  map and without the dynamic animation  at significantly slower rates then JWNW renders.  (Frankly, any static scene like this could be represented as a BSP tree and rendered extremely efficiently... but that wouldnt work for a real game.)

Why do a static scene render more efficiently if it is represented as a BSP?

Your kidding, right?  Or are you not familair with BSP trees?

A BSP is a terrific structure for determining incredibly fast what is "behind" the view and thus eliminating approximately half the scene from ANY consideration or furtehr testing for inclusion in the render set.

Furthermore, the BSP makes finding front to back order trivial, which helps with things like distance-culling.   
There are other things you can do with it too, some of which are less imprtoant  in these days of big Z buffers, but others which can still be important. (Such as ordering for scenes with a lot of transparency.)

Unfortunately, it only works for static geometry.

As long as you don't end up splitting the geomtry to much. Static geometry is best rendered in big chunks.

Quote
EDIT: On considering this whole exchange, I do have one  more things to say. 

Kesselman's Definition of Religion:  Religion is a belief that has been invested with an emotional stake by the beleiver.

IMHO thats exactly what we have here.  You tried to write a program. You didnt hit your performance goals initially.  Youd ecided it was the fault of the tools and thus vindicated yourself  Yoiu now have an emtional stake in that belielf.   And therfor there is little point to trying to discuss it.

I finished that program, and the performance was as expected. I'm not blaming anyone. It was an experience that I now draw my conclusion from.

Quote
If you have honestly blinded yourself to the poitn where you cant understand why one API, which spends more effort on view frustrum culling, as opposed to another that spent less on such culling,  would process scenes with NO view frustrum cuilling slower but scenes with ALOT of view frustrum cullign faster, then I really don't see how I can help you understand.

I think its time to do this....

PLONK


I draw the conclusion that J3D has a high overhead. There is no evidence that it will catch up as the scenes get more complex.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2005-08-16 12:34:45 »

One day someone will show me something fast and modern looking running in Java3D Smiley One day.

Cas Smiley

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #28 - Posted 2005-08-16 15:25:31 »

I failed to do so ...

But Shawn Kendall always has stuff that looks so much better! And its Java3D as well. There has to be a secret somewhere...

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #29 - Posted 2005-08-16 15:51:38 »

There has to be a secret somewhere...
Yes, his stuff is never playable or publically available. Roll Eyes

If Java3D really was so shit hot we'd have seen something amazing created with it already. All we end up with is rhetoric and empty promises.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
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.

CogWheelz (17 views)
2014-08-01 22:53:16

CogWheelz (15 views)
2014-08-01 22:51:43

CopyableCougar4 (20 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (42 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

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

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

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
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!