Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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 7882 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2005-08-16 15:10:47 »

Show me the money.

Cas Smiley

Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #31 - Posted 2005-08-17 06:57:03 »

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

Yes and no ... not publically available.

But at least I have been an eyewitness (JavaOne2003) of these things. No cheats, his stuff ran on the same machine as my FlyingGuns demonstration. Yet much smoother, do cell-shading, shadow-casting ... with 70fps.

FlyingGuns hardly reached 25fps running very unsmooth...

There must be a secret ....

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

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #32 - Posted 2005-08-17 09:33:28 »

Secrets are no good. The whole idea of Java3D was that it was supposed to be clever and do all the secret stuff for you.

Cas Smiley

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

Senior Devvie




AFK


« Reply #33 - Posted 2005-08-18 13:14:55 »

ok im going to have another play with j3d... just couldnt get most of it working last time- no real docs. but then
there none for most api anyways Smiley.. jme is the best of them so far i have found, xith is also very good but needs
help with ui... at the end of the day use whatever... im sure j3d is rocking- it was just abit to closed
for my liking and no MacOSX support until Panther... worth a look at again is my thought... wonder if it works on
Tiger??

blablabla im not sure about that link- seems abit out of date... maybe im reading it wrong...
Offline Jeff

JGO Coder




Got any cats?


« Reply #34 - Posted 2005-08-18 22:05:30 »

Secrets are no good. The whole idea of Java3D was that it was supposed to be clever and do all the secret stuff for you.

Cas Smiley

Heh.  You knwo better, right Cas?

The more compelx a system is, generally the more sublte the knobs are that have to be twisted Smiley

It does a lot of stuff for you yould have to write yourself, but you still have  profile and tweak.  In some ways you coudla rgue you need to do a bit mreo rpofiling sicne you know less innately about the actual interior.

Shawn has never been shy about sharing his knwoledge though. Im sure he'd be happy to answer any and all questions.

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 #35 - Posted 2005-08-18 22:08:40 »

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


All of Shawn's stuff has been publicly playable at the demos we've done (GDCs and JavaOnes).

Up til now Shawn has been paid to create demos, not releases. As a result there has been no budget or incentive to get it to relasable form.  Anyoen who has actually done a real release should be appreciative of how much relase engineering really needs to be done to make anything of significant complexity releasable in a  way that will install sucessfully on the majority of platforms out there.

Shawn is working on an actual product.  That will likely be the first thing of his that is made releaseable.

Meanwhile as Ive offered before youcna doewnload the JWN base as I work on it if you like.  i am not anywhere near a real release but I trust you guys to be technical enough to handle that...

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 #36 - Posted 2005-08-18 22:22:36 »

My summation:

Using Java3D is a trade off.   Its a scene graph API talking to a closed renderer.  Thsi means it has certain limitations:

You can get better  performance with a custom renderer taking game specific cheats.  Thats a given. 

Similarly,in some situations, you may be able to get better culling performance out of game and data specific dodges.

Finally it will likely always lag at least a little behind the bleeding edge of techniques you can do on raw OGL or D3D.

Java3D also carries a legacy of beign designed around VRML and Vis/Sim type apps and thus carries some code with it that is probably not needed in a game environment.  Thus I am quite willing to believe there is some size bloat, though in my experience its trivial next to the size of the data we deal with in 3D applications.

But I've looked and seen no evidence that Java3D is not as fast or faster then any other equally general and equally correct scenegraph API.  It is a mature API that has been around long enough to be mostly bug free and there is a fair body of knowledge available, thanks to the pioneering work of people like Shawn, as to how to effectively use it.   

Now that there is a team on it again its is continuing to evovle at what I cosndier a reasonable pace.   One thing to remember is that the team is very serious about maintainign a foward direction with abckward compatability for the API.  This means once they commit to a mechanism they really really do not ever want to have to chnage it out from under users.   This means they sometimes purposefully delay adding features where the standards are not eyt clear.  A good example of this was shaders where they waited until glsl happened.

In the end, you have to decide what is the right tool for you.  There are many good reasons not to use Java3D.  Maybe you are doing soemthing ins sucha limtied space you really cant afford the weight of the API.  (Java3D would be a abd chocie for today's cell phones or most PDAs for instance.)  Maybe your render needs are so simple then the over-head and API complexity isnt worth it.  (2D games are best done right ontop of OGL for instance.)  Maybe you are doing a cutting edge type product that has to release soon and can't afford to wait for Java3D features that don't exist yet. (For JNWN I really need multi-pass rendering because I really want to avoid the over-head of calculating dynamic shadow volumes on the CPU.  As it happens, JNWN doesnt have a hard release date and, after seeing the J3D team's plans, I feel I can afford to wait for it.  But someone who had to release this Christmas might not.)

But chose your API for the right real reasons, not because of unprovable (or maybe even disprovable) myths like "Java3D is slow."

I'm done.

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 #37 - Posted 2005-08-18 22:34:19 »

ok im going to have another play with j3d... just couldnt get most of it working last time- no real docs. but then
there none for most api anyways Smiley..

I use the Javadocs and have found them very complete.

Byond that if you have questions feel free to ping me Smiley

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 Bombadil

Senior Devvie





« Reply #38 - Posted 2005-08-19 09:22:01 »

Thanks Jeff for all your valuable infos.

Regarding the sad Winblows Vista matter of a possible OpenGL discrimination:
One thing which could also become a plus then for Java3D - and it has some ironic in it - is its possibility to use either OpenGL or D3D with the matter of a runtime switch.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #39 - Posted 2005-08-19 09:57:13 »

blablabla im not sure about that link- seems abit out of date... maybe im reading it wrong...

If that's the case, you need to *tell me what needs changing*. I can't do much with "seems a bit out of date", I'm afraid Wink

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Tomas

Junior Devvie




Agency9


« Reply #40 - Posted 2005-08-19 10:36:01 »

Quote
This means once they commit to a mechanism they really really do not ever want to have to chnage it out from under users.   This means they sometimes purposefully delay adding features where the standards are not eyt clear.  A good example of this was shaders where they waited until glsl happened.

How does this work with their dual pipeline strategy Direct3D/OpenGL ?!?! 
Seem odd to me.

// Tomas

CTO Agency9
Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #41 - Posted 2005-08-19 12:08:51 »

Thanks Jeff for all your valuable infos.

Regarding the sad Winblows Vista matter of a possible OpenGL discrimination:
One thing which could also become a plus then for Java3D - and it has some ironic in it - is its possibility to use either OpenGL or D3D with the matter of a runtime switch.


Once I voted for dropping the D3D support in favor of the OpenGL stuff. Advantage: only one codebase.

This seems to turn out to be a big mistake...

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

JGO Coder




Got any cats?


« Reply #42 - Posted 2005-08-20 05:41:36 »

Quote
This means once they commit to a mechanism they really really do not ever want to have to chnage it out from under users.   This means they sometimes purposefully delay adding features where the standards are not eyt clear.  A good example of this was shaders where they waited until glsl happened.

How does this work with their dual pipeline strategy Direct3D/OpenGL ?!?! 
Seem odd to me.

// Tomas

glsl support on d3d is an interestign question.  Ill ask Kevin on monday.
I knwo the whoel point of GLSL was that it was suppsoed to be hadrware neutral so I imagine it could be translated, but i dont know what they are actually doing yet Smiley

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 Devvie




Cut from being on the bleeding edge too long


« Reply #43 - Posted 2005-08-24 17:00:44 »

Go away for a week and look what happens!  Grin

Right, where to start....  Jeff, thanks for taking the time to have a look at Xj3D. Few pointers there and the text bug we know about and have fixed a couple of months ago in CVS.

Performance differences between NWN and Xj3D. Yes, that's to be expected. One is a fully optimised game engine player that deals with a very specific content set. The other is a general scene graph and runtime engine that is optimised for nothing in particularly. It has it's own runtime model that must be evaluated every frame etc. The core point is that the entire runtime structure is identical for both renderers. The only time you get to runtime-specific structures is once you get down to the individual node. We have an X3D/VRML scene graph which then overlays the renderer-specific scenegraph (AV3D or J3D) because the structures don't map cleanly through (eg a VRML Transform node has separate scale, translate, rotate vector values that need to be combined into a single matrix to send to the renderer). The only time either of them update is at the end of the eventmodel evaluation for the frame. In effect, the interactions between the real code and the renderer is relatively minimal. Rendering speed is thus determined by how quickly the underlying renderer returns back to userland code.  We use no Java3D behaviours other than WakeupOnElapsedFrame(0) so that we clock it every frame. Java3D has nothing other to do than process and push polygons, and perform picking at the start of the next frame.  This makes is a very good comparative performance between  rendering technologies because there is absolutely no optimisation for a specific rendering API beyond polygon pushing.  Comparing a general purpose rendering engine versus a content-specific engine won't be of any use because that is like comparing apples with motorcycles.

Optimised design stuff: Aviatrix3D was designed to be an efficient API for large scale visualisation - scientific, medical etc. We're not designed for gaming, nor for any Xj3D-specific purpose either.  None of the work that has gone into it particularly special. Everything is based on common strategies such as view frustum culling, state sorting, etc. We looked at almost every visualisation API out there that we could get our hands on - Open Scene Graph, OpenSG, Inventor, Performer etc etc and built something that did what these guys could do. Java3D is nothing special in those terms. If it has anything patented, who cares as it would have to be so implementation-specific that it doesn't effect anyone. The one bit that is patented is the geometry compression and Sun has already granted us the use of those patents for use in the X3D spec about 12 months ago.  If you want to try running the patent FUD trick, go for it, but we'll just completely ignore you.

Rendering differences between the two APIs. Yes, that's an odd one.  The same data is being passed to both, so I don't know why they sometimes come out diffferently.  I do know that at the Xj3D level we haven't yet mapped some of the rendering qualities through that Java3D has (eg mipmapping and some filtering options). I also know that J3D reorders some of the rendering calls in very odd ways occasionally that can lead to somewhat bizarre rendering artifacts that we weren't expecting to see.  One of the worst problems is the frame lag for transformations versus geometry. If you have a single behaviour and set  a transform matrix, a vertex change and some material changes, you'll see the changes appearing in 3 separate frames, not all together as they should be.

Herkules: One of the tricks to get Java code running fast is to write it like it was C code. This is a point I continually make here and yet you get people that claim that garbage collection is good and fast. The fact is that it isn't.  Every time that GC runs or that you create new object instances, you're loosing CPU time. The same tricks as before Java still apply now. Don't waste time creating and destroying objects. Reuse them. Don't make the system do work it doesn't need to.  GC pauses are very visible in graphics applications regardless of how short they are. It's something the eye picks up on very easily.  I know that once we did a garbage pass through Xj3D that we gained about 30% better framerates and all the stuttering completely ceased.

Hmmm... other points I was going to make but the reply box here is only showing the last page or so of the thread... DOH!

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 #44 - Posted 2005-08-24 20:14:31 »

Go away for a week and look what happens!  Grin

Right, where to start....  Jeff, thanks for taking the time to have a look at Xj3D. Few pointers there and the text bug we know about and have fixed a couple of months ago in CVS.

Performance differences between NWN and Xj3D. Yes, that's to be expected. One is a fully optimised game engine player that deals with a very specific content set. The other is a general scene graph and runtime engine that is optimised for nothing in particularly.

No.

JNWN is my NWN client,. It uses Java3D.  In fact, the runtime is almost exclusively Java3D outside of the physics behavior.

AIUI however Xj3D DOES have its own full internal graph structure in addition to J3D and is only using J3D for render.  If thats true then I'd grant you are certainly using memory unecessarily in maintaining two structures.  You may also be wasting some processing power in not leveraging Java3D's maintainence of bounding volumes and such.  If so, O'd wodner why you are using a scene graph API at all, really, and why you just don't render from the XJ3D structures directly to JOGL...

Quote
It has it's own runtime model that must be evaluated every frame etc.

See above. Sounds like your wasting a lot of what J3D has to offer.

In any event, they key point was that the two APIs were not comparable for performance because they werent producing the same result.  Id be happy to take another look when they do although the SECOND almost as important point was that FPS readings were so wildly all over the place ontop of either scene graph to draw any meaningful conclusions.,

Quote
Java3D has nothing other to do than process and push polygons, and perform picking at the start of the next frame.

Which means you are using it as JOGL and should use JOGL instead, nest ces pas?

Quote
This makes is a very good comparative performance between  rendering technologies

No it makes it a very BAD comaprison because Java3D is designed to do a lot more then just push polygons to the screen.  If thats all your doing, the right technolgoy is JOGL.

JNWN uses Java3D as its intended to be used. Its also very stable on performance numbers.  I suggest you   put your scene graph under it and lets get a real benchmark.

'nuff said.



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 #45 - Posted 2005-08-24 20:42:14 »

Oh the answer to the shaders question...

If you want to go cross platform, but all OGL, use glsl.

If you want to go single platform (Windows) but cross API (OGL and D3D) use cgl, which is also supported.

Unfortunately, thanks to Micrsoft, there is no way today to hit both goals with the same shader programs Sad

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 Devvie




Cut from being on the bleeding edge too long


« Reply #46 - Posted 2005-08-25 17:01:11 »

Quote
Java3D has nothing other to do than process and push polygons, and perform picking at the start of the next frame.

Which means you are using it as JOGL and should use JOGL instead, nest ces pas?

No. It means that we're using everything that is useful to us. To use JOGL, we still need to implement some sort of rendering pipeline that does all our state management, culling etc. We're just not wanting to use any of the intrinsic behaviours because they are effectively useless for us.  If I have a rendering engine that needs to do terrain following, collision detection (both object-user and object-object), visibility and proximity detection etc, these cannot be done by the stock behaviours provided by Java3D.  It's not that we're not using what J3D has to offer, it's the fact that Java3D doesn't offer what we need to start with or goes out of it's way to make it very difficult to do. For example, the whole BranchGroup thing makes our scene graph typically 3 times deeper than it should be - every node is removable and shareable in X3D/VRML, so for every X3D node we need to use a Link->SharedGroup->BranchGroup combo!. In fact, the whole J3D model for behaviours is quite bad - it's very hard to guarantee any specific replicable result, which is what is required to implement the X3D spec.

As for memory usage. Yes, we have to pay a penalty for that. We really have no other option. There's a requirement by the X3D spec to be able to read all the fields as they were written at the X3D level. For example, trying to pull geometry data out of an indexed triangle array for an ElevationGrids heightfield can be quite a bad thing to do. Considering that many of our users are using extremely large datasets (in the orders of 10s of megs per geometry primitive) the cost over heads of creating passing around and then GCing those large arrays is staggeringly high.  And, as I said in the previous post - the X3D scene graph does not map cleanly onto either Java3D or AV3D (Xith, OpenSG or anything else for that matter) so there is a layer needed in between to merge the X3D user's view of the world versus the renderers.

Quote
No it makes it a very BAD comaprison because Java3D is designed to do a lot more then just push polygons to the screen.  If thats all your doing, the right technolgoy is JOGL.

Please justify this. Why is it bad? You keep claiming that there are no good benchmarks for comparing J3D versus some other scene graph. Every time you've stated this in past threads you claim that because the implementations are not the same when someone has done that (for example converting a J3D app to Xith3D). Yet, here I offer you one good, complex, non-microbenchmark example of exactly the same code running over the top of two very different scene graph implementations that have the same end goal (large-scale visualisation, not games) and now you claim that it can't work because it wasn't optimised for the specific scene graph. You can't have it both ways! So, which of these two contradictory arguments are you going to use here?

Consequently, if it is so easy to get such good numbers in Java3D, why is it that only you and the Fullsail guys seem to be able to do it and none of the rest of us (particularly those like myself that have been doing professional 3D graphics programming for more than a decade) cannot replicate those same results. If there is such a black art required to get them, don't you think this says something pretty important?

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.

Mr.CodeIt (10 views)
2014-12-27 04:03:04

TheDudeFromCI (13 views)
2014-12-27 02:14:49

Mr.CodeIt (25 views)
2014-12-23 03:34:11

rwatson462 (56 views)
2014-12-15 09:26:44

Mr.CodeIt (46 views)
2014-12-14 19:50:38

BurntPizza (92 views)
2014-12-09 22:41:13

BurntPizza (113 views)
2014-12-08 04:46:31

JscottyBieshaar (83 views)
2014-12-05 12:39:02

SHC (94 views)
2014-12-03 16:27:13

CopyableCougar4 (102 views)
2014-11-29 21:32:03
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!