Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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  
  OpenGL.org: Xj3d now twice as fast without Java3D  (Read 5277 times)
0 Members and 1 Guest are viewing this topic.
Online princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2004-07-19 09:13:55 »

(Or so they claim Wink)

Current headline on OpenGL.org

http://www.web3d.org/x3d/applications/xj3d/

<smug mode>So much for Java3D being such a great scenegraph eh? The one thing it might be supposed to do well it's slow at. How many times did we hear about scaleability and how small scenes were a poor test of its performance?

Oh well, I shouldn't gloat, but you know....

Cas Smiley

Offline Spiff

Senior Newbie




Java games rock!


« Reply #1 - Posted 2004-07-19 10:14:35 »

Do you have a pointer to the types of scenes they used to determine that the new renderer is twice as fast? Or any actual numbers for that matter? Pretty much every VRML scene I've seen in the past has been tiny, but perhaps that has changed...
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #2 - Posted 2004-07-19 15:56:19 »

The main browser app that is included with Xj3D has a frames per second counter on it as the simple guide to rendering speed.

The big test scenes we use we can't redistribute as they come from some of our users. The three typical test scenes we use for large-scale rendering is


  • Planet9 datasets, which are in the order of 15MB for the geometry and about half a gig of textures.  Not high on the polygon count (about 20-30K  polys), but heavy on textures.

  • CAD training demo. If you've ever seen any of our live demos, this is the one with the encapsulation machine. There's about 2hrs worth of animation data in the file - it's about 16MB. There's about 100K polygons, almost no textures.

  • Several tests scenes from Elumens - Cityplaza (internal scene, heavy textures) and arboretum (external scene, heavy billboarding and transparent textures).


In each case the OpenGL renderer (Aviatrix3D) easily twice the framerate of Java3D.  We have one CAD file test scene that is pure static polygonal geometry where we're just marginally faster than J3D by about 10% or so. We'll be optimising that one shortly (right now we're not making use of VBOs or interleaved geometry).

Edit: Forgot to add that this is moving through the scene. Aviatrix3D has some optimisations where if nothing is changed in the scene graph for that frame that it just skips the culling and sorting steps and just reuses the previous rendering loop. Sometimes this can quadruple or more the framerate (cityplaza for us goes to about 150 FPS from 47FPS using this technique when you aren't moving) To get a good idea about real differences you either need to have animation running or be moving about in the scene.

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 118
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2004-07-19 17:42:58 »

But isn't Aviatrix3D a scenegraph?

Kev

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #4 - Posted 2004-07-19 17:59:36 »

Quote
Aviatrix3D has some optimisations where if nothing is changed in the scene graph for that frame that it just skips the culling and sorting steps and just reuses the previous rendering loop. Sometimes this can quadruple or more the framerate (cityplaza for us goes to about 150 FPS from 47FPS using this technique when you aren't moving) To get a good idea about real differences you either need to have animation running or be moving about in the scene.


Hm .... couldn't you optimize it the other way round?

I'd prefer high framerate when moving over seeing the same still image 150 times/s Smiley



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

Senior Member




Friendly fire isn't friendly!


« Reply #5 - Posted 2004-07-19 18:09:13 »

Quote
But isn't Aviatrix3D a scenegraph?


It is. Meanwhile it gets really difficult to find the right scenegraph to use. In good'ol times there was Java3D..... kind of a standard.

Now we have at least 4 (Java3D, Aviatrix3D, Xith3D, OpenMind). Somehow this corresponds to having a variety of OGL bindings.....

So Sun is so eager to keep Java itself closed, but on the library side it heavily diverses.....

(Does it come thru that I dislike that fact? Makes my life harder!)

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

Senior Newbie




Java games rock!


« Reply #6 - Posted 2004-07-19 18:31:17 »

Thanks for the numbers, it is always good to know that "real" scenes were tested Smiley

Now, if Aviatrix3D is a Java scene graph on top of an OpenGL binding (much like Java3D, just a better implementation) does anyone know the reason for the OpenGL.org headline:

"Xj3D Toolkit vM9 adds native OpenGL API renderer that is twice as fast as the Java3D version"

Makes it sound like "they dropped Java, went native and got a 2x speedup"...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2004-07-19 18:38:46 »

Quote


It is. Meanwhile it gets really difficult to find the right scenegraph to use. In good'ol times there was Java3D..... kind of a standard.


Nah, it's easy Wink...

OpenMind - who? Seriously, doesn't seem to be going anywhere, doesn't seem to be used much. Haven't seen even one real game (let alone a good one) using it yet. Can't even find games links on the main website. No webstart demos.

jME - no documentation at all, hence far too risky

Aviatrix - if you fit with it's specialist aims, it's a perfect fit

Xith - easier to use than J3D in some respects, steals J3D's good SG, is utterly rubbish at 2D overlays. Great if you need no HUD, or can tolerate simple manual-rendered HUD and GUI

Java3D - Either you already know it and so it'll be by far the fastest for you to code with, or you don't and it's not worth using for at least another 6 months / until the next major update appears (with bugfixes! And better performance!)

malloc will be first against the wall when the revolution comes...
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #8 - Posted 2004-07-19 19:40:43 »

Quote


Hm .... couldn't you optimize it the other way round?

I'd prefer high framerate when moving over seeing the same still image 150 times/s Smiley


We can add more optimisations to the moving part, but just haven't done so. Basically what that entails is making use of inter-frame coherence on the view frustum culling step.  We could employ some other techniques as well that don't use this, but right now our aim has been to complete the coverage of OpenGL abilities first.  We're almost done - all I need to do now is rasters/bitmaps and multipass rendering support as part of the scene graph structure and we're finished on the structural side.

At least with what I know about the codebase, I still have about a 30% increase in performance I can wring out of it without having to head into heavy algorithmic changes like the interframe coherence work. Mostly just stuff with the way we set and stop state at the renderer level.

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 Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #9 - Posted 2004-07-19 19:44:39 »

Quote
does anyone know the reason for the OpenGL.org headline:

"Xj3D Toolkit vM9 adds native OpenGL API renderer that is twice as fast as the Java3D version"

Makes it sound like "they dropped Java, went native and got a 2x speedup"...


No idea as we didn't write it. The webmaster of OpenGL.org is also the same guy who does Web3d.org and Khronos.org. Seems he picked up our release announcement on the Web3D  end of things and reslanted it for the OpenGL crowd. Though we know about his connections and we've chatted informally about getting Aviatrix3D announcements posted to opengl.org, he pretty much told us about it after the fact!  I saw this on the weekend and it was as much a surprise to me as it is to you guys. He managed to get a few little things wrong too (Immersive profile support is not complete yet, we're about 6 nodes out of 70 odd short).

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #10 - Posted 2004-07-19 19:56:49 »

Quote

Aviatrix - if you fit with it's specialist aims, it's a perfect fit


We're not quite as specialist as you might imagine.  We still have full coverage of OpenGL as a complete scenegraph. Where we are different compared to, say, Xith3D, is that our optimisation strategies are targetted for handling multi-CPU/multi-display machines, where Xith3D is purely single CPU/thread setup.  As such, we're hitting almost an identical target audience as Java3D, just doing it a lot more efficiently Smiley  So, on a given PC, Xith3D will be faster than us, and we're faster than J3D, if that gives you a good idea of the performance comparisons.  We've already got all the required bits like GLSlang shaders, subtexture updates, various culling and state sorting capabilities etc,

And.....

To answer Kev's question:

Yes, AV3D is a scene graph.  Xj3D is a loader and toolkit that works as a scene graph as well but layers X3D/VRML semantics over the top of a lower level renderer. As such, it uses either Java3D or Aviatrix3D for the low-level rendering (it also could use GL4Java as we still have some of that code in the codebase, but it has probably suffered serious bit-rot by now).

Because we needed to build a rendering system over the top of OpenGL bindings to ensure our long-term financial future that was independent of Java3D, we decided to create a scene graph system too. However, we felt that, although our development of AV3D is going to be mainly using Xj3D over the top of it, that others may be interested in the work as a separate project.  So, we split it off and it has a life of it's own that is independent of Xj3D. The majority of the real-life testing of Aviatrix3D is done by the use of Xj3D over the top of it, so we do get to play with a lot of very varied content structures that exercises the entire codebase quite extensively.

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 darkprophet

Senior Member




Go Go Gadget Arms


« Reply #11 - Posted 2004-07-19 21:35:14 »

Quote

jME - no documentation at all, hence far too risky


are you kidding me? all those demos on how to use it, with comments on each line? all that wiki? and the user guide? my site has some tutorials.

All that, and no documentation?

Not forgetting the javadocs.....

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2004-07-19 22:57:38 »

Quote

are you kidding me? all those demos on how to use it, with comments on each line? all that wiki?


"Source code is not documentation".

Quote

and the user guide? my site


Yeah, that FANTASTIC </sarcasm> user-guide, which has (almost) no pages!

http://mojomonkeycoding.com/pmwiki/index.php/UsersGuide/UsersGuide

(95 sections, of which barely 10 are filled in, and more than a third of those are introductions!)

Having a UserGuide which emphasizes how much documentation you don't have, and making it hard to find anything better are classic ways of scaring away any serious developer who doesn't have time to risk on incomplete untenable technologies that probably won't be around in 2 years time. Shrug. That's life.

Quote

All that, and no documentation?


Put it another way: we wanted to try jME for Survivor-v2 (thought it might be a better for the new stuff than Xith is), until we discovered there was no real documentation and decided it was far too risky. IIRC this was a unanimous decision, that each person came to separately.

Quote

Not forgetting the javadocs.....


Method docs are the last refuge of people who can't (or can't be bothered to) write real documentation. Most people who say "but we've got javadocs" don't even bother to write package comments in their javadocs, and that's inexcusable really if you're claiming you have real documentation...

Really, we wanted (certainly *I* did) to use jME, but until someone sufficiently finishes it off to make it properly usable...

NB: Xith of course is saved by the fact that it's almost identical to Java3D, which is plentifully documented. But even Xith devs are not happy about the doc status...

malloc will be first against the wall when the revolution comes...
Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #13 - Posted 2004-07-19 23:29:57 »

Jesus Christ, I'm being attacked pretty hard here...

First, DP, while a very strong supporter of jME, doesn't represent jME, I do.

Quote
Yeah, that FANTASTIC </sarcasm> user-guide, which has (almost) no pages!

http://mojomonkeycoding.com/pmwiki/index.php/UsersGuide/UsersGuide

(95 sections, of which barely 10 are filled in, and more than a third of those are introductions!)

Having a UserGuide which emphasizes how much documentation you don't have, and making it hard to find anything better are classic ways of scaring away any serious developer who doesn't have time to risk on incomplete untenable technologies that probably won't be around in 2 years time. Shrug. That's life.


Documentation has just begun, if you'd taken the time to look at the edit dates, you might notice that they all started these last couple days. It has started, and is the primary focus of myself. It takes time, you should know this, looking at the small amount of useful material on your OWN site, you should keep the rocks in the pocket.

Quote
Put it another way: we wanted to try jME for Survivor-v2 (thought it might be a better for the new stuff than Xith is), until we discovered there was no real documentation and decided it was far too risky. IIRC this was a unanimous decision, that each person came to separately.


Too bad, but not suprising. Kevin had already use Xith3D quite a bit before hand, he'd be a fool not to go with a technology he knew with the time constraints of the contest looming overhead.


Don't send a man to do a monkey's work.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2004-07-19 23:48:12 »

Quote
Jesus Christ, I'm being attacked pretty hard here...


Sorry, I probably wasn't clear, and so you've misunderstood me. I wasn't attacking jME, although I do rail against any claim that javadocs and some source code count as documentation.

Quote

Documentation has just begun. It takes time, you should know this,


If you re-read my post carefully you should be able to see that I've no issue with that - only with the claim that was made that it was well-documented already.

Quote

looking at the small amount of useful material on your OWN site,


If you're referring to grexengine.com, that's an entirely different issue. The GE has tonnes of documentation - it's just that we don't have *any reason* to post it on a website for random surfers to come along and gawp at. It's mostly nicely laid-out PDF's and hardcopy printed manuals...

Quote

Too bad, but not suprising. Kevin had already use Xith3D quite a bit before hand


I was referring to AFTER the competition - last month, both I and Kev wanted to try jME, and so I got everyone to go and check it out. I can't speak for KG on this, but we don't have the luxury of saying "Hey, if we wait XXX weeks then perhaps technology YYY will be sufficiently user-friendly that we can use it without wasting lots of time trying to learn it". Like any commercial game, we have a few days to a couple of weeks to make final decisions on what tech we're using - if it's something as fundamental as the rendering engine for an arcade 3D shooter then it's purely a case of "What's available *today*?".

I'm still hoping that by the time I next do a 3D game jME will be at the state where I can just pick it up and run with it. Sadly, I probably won't get much choice when the time comes, but I can hope...

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #15 - Posted 2004-07-19 23:50:49 »

Quote

Having a UserGuide which emphasizes how much documentation you don't have, and making it hard to find anything better are classic ways of scaring away any serious developer who doesn't have time to risk on incomplete untenable technologies that probably won't be around in 2 years time. Shrug. That's life.


I'm v. tired (it's been a > 16 hour working day today) and that one long sentence was intended as two separate concepts. The first relating to jME (the userguide at the moment is deeply scary to people evaluating it for a non-hobbyist project) and the second describing the issue at stake for the evaluator (potentially any tech you aren't paying for could do this to you, and that will dearly screw you over, probably causing the cancellation of your project, so you have to be always wary of it as a possibility).

malloc will be first against the wall when the revolution comes...
Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #16 - Posted 2004-07-19 23:59:34 »

Ok, I've cooled down a bit.

First point, if you have to add a sarcasm tag, best not use the line at all. I tend to take offense to your posts now and then as the tend to absolutely drip with arrogance. Whether that represents you in anyway, I have no idea.

Second, I know you were responding to DP, but you did so at jME's expense. I would be the first person to admit documentation is what is most needed (that's why it's all I am doing at the moment). And again DP does not represent the opinions of jME... yadda yadda.

I'll leave it at that.


Don't send a man to do a monkey's work.
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #17 - Posted 2004-07-20 00:08:26 »

Just to put in my unwanted 2 cents...  Smiley

jME has had some great results internally and the developers tend to be emotionally tied to it.  (Well, at least I am.)  I think over the next release or so we'll get it to a point where you don't have to know it already to love it.  Any constructive comments to help us move towards that goal are always welcome, especially if you have time to drop them on our own board over at http://www.mojomonkeycoding.com/jmeforum/.

Thanks!

Renanse  (ruh-NON-say)
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #18 - Posted 2004-07-20 09:24:42 »

blah, i was merely trying to point that that there is some documentation, for my tastes its plenty, but for you, obviously it isn't.

And why isn't source code considered documentation? I use the code all the time to find out what the method does. Just look above the method and youd find alot about the method. If your not sure about the class, just look over the class declaration to see a paragraph if not more describing what the class is.

And yes, most people down at jME HQ are emotionally tied to it. I am too, and I take offence directed at me at the slightest offence to jME.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline zingbat

Senior Member




Java games rock!


« Reply #19 - Posted 2004-07-20 14:06:00 »

I dont know about this new M9 relesae of xj3d but what i can say from the previous ones is:

xj3d allways made me happy for the idea of mixing x3d with java with a limited x3d editor like x3dedit and get a easy prototyping solution for games.

But after downloading M7 or M8 (dont recall) a couple of months ago and see its critical lack of documentation, and i mean compared to xj3d i have seen the project you guys are complaining here is amazingly documented.

Not only that but i had to run their browser with a dos batch file that didnt worked becausethe command was too long and  there wasnt enough memory for dos input line or something like that.  :-/

Worst, everything comes with a douzen of mini-jars, you get almost no ocumentation (one or two html pages), and rely only on examples and minimaly comented javadocs.

Besides i used their simple brower with a very simple vrml example and it gave me an error. I know that example worked in almost every other vrml plugin and browser cause i have tried it.

I also tried x3dedit at the time but same dos solution and a program slow like hell drove my computer to his knees without ever loading anything.

I will download xj3d M9 and the new auto-installer for X3DEdit but if i see a dos batch file with a 500 chars command i wont ever bother running it. And if this is not the case im only tempted to decipher their examples and learn how to use it for just that tad amount of time.

I have tried xj3d something like 3 times now. If i get dispointed with this one once more im thinking on forgeting about it completely. The idea is good but they seam to be working on a product for internal usage only.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #20 - Posted 2004-07-20 16:16:56 »

I do understand your criticism on the lack of Xj3D documentation. It's something that I'd like to make better, but to be honest, we're still not even at version 1.0 yet. Things are changing on a daily basis and keeping up to date docs about changing the internals is rather hard to do.

We basically have two main classes users of Xj3D - those using either the SAI or EAI to create a browser and work with it at the X3D/VRML spec level, and those using it as a Java3D loader. It's extremely rare that we see anyone using it any other way. As such, there has been no demand for external documentation for doing other work that is down in the weeds with it.  In both cases, the usage documentation is well specified elsewhere.

If your interest is in creating new nodes or changing something about the implementation, then there's documentation on the Xj3D website about how to do that. Properties that can be used to control the functionality are documented on the front page (overview) and in each package overview.

Apart from those, what else do you want to see in the way of documentation?

As for things not working, that's correct, we have bugs. Sorry, but the X3D and VRML specs are horribly complex things to implement. X3D is now three separate specifications with over 2000 pages of spec docs.  Another thing that we run into time and again is that it's not our bugs, its the user's VRML files that are not spec compliant.  Blaxxun and Cortona are notorious for completely ignoring the specification and letting all sorts of stuff through that is illegal.  OTOH, we are strictly compliant to the spec and will refuse to run a file that is not spec compliant and point out the error.  Are you sure you haven't confused that behaviour with a full-on crash?  

Just to explain a little more - In earlier versions of Xj3D, whenever we got errors we would report these as exceptions from the guts of the nodes. However, our output code like the consoles weren't particularly intelligent about how they handle them and would dump stack traces for stuff that really wasn't a genuine error and some of the reporting paths for errors were not hooked up. Something like a colour value out of range would still end up with the complete exception trace being dropped to the command line.  M9 and some recent work post M9 have pretty much removed all of those now and will just report the correct error and line of the file it occurred on.

As for the lots of jar file comments, well that's a personal preference and one which I don't agree with. Since Xj3D is designed to be segmented and used in parts, our users prefer having the ability to take just the JAR files they need rather than one huge file that is around 4MB in size.  If you look at other projects of similar size, such as Batik or JBoss, you'll see they take exactly the same approach as us - a lot of smaller jar files that allow the code to be segmented and only the appropriate parts needed. For reference, the Xj3D library is now over 450K lines of code. Add in all the external libraries like j3d.org, URI handling etc and we're well over 700K lines easily.  Aviatrix3D I did a quick wc -l on last night and it was 75K lines alone!

Edit: As for the javadoc being pitiful comment, I reject that completely. Xj3D has the best javadoc of any project I've ever seen. You're telling me http://www.xj3d.org/javadoc/ that that is poor javadoc, then I'd like to see what you classify as "good" javadoc. Considering every single method variable and class is commented with more than just "sets the size" sorts of comments, then I fail to see what else could be done, unless you'd like us to comment it in Z to formally prove the function of each method call!

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 blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #21 - Posted 2004-07-20 16:47:22 »

Quote

Edit: As for the javadoc being pitiful comment, I reject that completely. Xj3D has the best javadoc of any project I've ever seen. You're telling me http://www.xj3d.org/javadoc/ that that is poor javadoc, then I'd like to see what you classify as "good" javadoc. Considering every single method variable and class is commented with more than just "sets the size" sorts of comments, then I fail to see what else could be done, unless you'd like us to comment it in Z to formally prove the function of each method call!


It does, at least, have package comments. Which puts it in the "better than average" category. Modulo your comments above it sounds like you're not aiming for much documentation anyway, so perhaps for your situation that's very good.

However, my rule of thumb rating for jdocs of generic projects claiming to have good ones would rate you quite poorly. I take the average number of more-than-one-sentence paragraphs in the package comments and mulitply by 20 to get a percentage score. On that basis, you get somewhere between 20% and 40%. Not great. But the sad truth is that I've used software with 7-figure licensing costs whose *entire documentation* was jdocs which would only get about 10% to 30% on that basis. Wasted about half the development time just trying to invent our own documentation (although there wasn't much wrong per se with the jdocs, aside from the odd class [our of several hundred] whose method docs were useless)

malloc will be first against the wall when the revolution comes...
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #22 - Posted 2004-07-20 17:13:56 »

Quote
But the sad truth is that I've used software with 7-figure licensing costs whose *entire documentation* was jdocs

Wow, what Java based software has a 7 figure license?   Shocked

Renanse  (ruh-NON-say)
Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #23 - Posted 2004-07-20 17:20:56 »

Quote
However, my rule of thumb rating for jdocs of generic projects claiming to have good ones would rate you quite poorly. I take the average number of more-than-one-sentence paragraphs in the package comments and mulitply by 20 to get a percentage score. On that basis, you get somewhere between 20% and 40%. Not great. But the sad truth is that I've used software with 7-figure licensing costs whose *entire documentation* was jdocs which would only get about 10% to 30% on that basis.


What is the basis for your "rule of thumb"?

Don't send a man to do a monkey's work.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #24 - Posted 2004-07-20 17:36:08 »

Quote
However, my rule of thumb rating for jdocs of generic projects claiming to have good ones would rate you quite poorly. I take the average number of more-than-one-sentence paragraphs in the package comments and mulitply by 20 to get a percentage score. On that basis, you get somewhere between 20% and 40%.


That's a pretty poor metric. That's like reading the first 5 unnumbered pages of a book (ie the copyright notices, printer information and acknowledgements)  and determining whether the writer had a good story.  Your metric uses an entirely arbitrary mulitplier for something that is already an average value. If every package was documented with 2 sentence paragraphs, then you'd end up with a rating of 200%, which makes no sense at all.  Most of the useful information is not at the package level but in the individual classes. If you applied that metric-style analysis to the class headers rather than the package docs, I would agree that it's a pretty good determinant of how well documented a project is in javadoc. Packages, because they contain a collection of very loosely affiliated sets of functionality aren't really a good way of documenting code. The usage of the individual class, however, is where the good value documentation can be found.

Though, it is a funny thing that you talk about that.  Each time I write one up, I always try to put a lot of text in there, but usually I come up with a blank as to what exactly I should be saying Huh  The short ones are not for lack of trying to put something useful in there, that's for sure!

Mojomonkey - anything like the big J2EE app servers could easily run into that sort of licensing costs. Also, I could see the Oracle licensing being up there as well for a big site.  

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 blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #25 - Posted 2004-07-20 17:46:06 »

Quote

Wow, what Java based software has a 7 figure license?   Shocked


DB stuff...dig around in the enterprise computing "niche" and high software costs are not uncommon. IIRC DAoC (an MMOG) was quoted $800,000 for their Oracle licenses during development...

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #26 - Posted 2004-07-20 18:00:44 »

Quote


That's a pretty poor metric.


It's not scientific, it's based on experience. If I'd said "this is the formal metric company X uses" then it would be ludicrous, especially seeing as it can be easily gamed. (although obviously I use some common sense - clamp it to 100% and you would need an average of 5 x 2-sentence paras per package to get that)

The point is that I tried to find what was in common between the well-documented stuff I'd used, and what distinguished effectively inside the grey area of "OK but not great", and even the best documented stuff has the odd package with just a sentence or so (c.f. below).

If I were attempting something more formal I'd do a weighted score of package and class comments - I agree entirely that the class comments contain substantially more information, but there are two lessons from experience:

1. People who document poorly NEVER write package comments; people who document sort-of-OK almost never write package comments, people who document well typically write package comments. They are a quick-n-dirty (hence, rule of thumb) way of estimating the doc quality.

2. It's bloody hard to visually/manually rate class comments for non-trivial projects in trivially short time. It took me a minute or two to analyse your package comments - how many hours would it have taken to look at every class? - although, obviously, if you were doing something more formal you could (and would) put it all in an automated script (wahay!). Indeed, I've used java-centric testing tools in the past that do exactly this (but with more detailed heuristics for scoring) as one of their measurements of how "complete" a class / package / application is (lots of different metrics for: how good is the unit testing? how good is the documentation? etc)

Quote

Most of the useful information is not at the package level but in the individual classes


Yes. BUT...most of the useful information for the user to generate a mental map of the system/software/library is contained in the package level.

If your software is only used by people who already know how it works, and just need your implementations docs (e.g. OpenGL) then there's almost no need for package comments, beyond one/two sentence descriptions. Indeed, most multi-pkg software seems to end up with a couple of such packages IME - and this may explain the situations where you couldn't think of much to say; e.g. I encounter similar stuff when doing networking systems: a pkg dealing with a protocol doesn't need much package commentary. E.g. a codec for HTTP I'm not going to explain the concept of requests, responses, HTTP pipelining etc - I just put a package comment "uses the same terminology of RFC XXXX".

Quote

Though, it is a funny thing that you talk about that.  Each time I write one up, I always try to put a lot of text in there, but usually I come up with a blank as to what exactly I should be saying Huh  The short ones are not for lack of trying to put something useful in there, that's for sure!


Good documentation is hard and time-consuming to produce. The time isn't taking writing it, it's working out what to say. c.f. above sometimes there just isn't much worth writing (without duplicating the text of a formal spec, which would phrase it so much better than you could!). But if you often have much trouble with a pkg comment then perhaps your pkg is not as well pkg'd as it could be, and needs refactoring, or perhaps you just need a bit more practice of writing user-level docs (so that it comes more naturally) - it seems that most programmers today get little or no practice at this stuff, so why should they expect to find it easy?

malloc will be first against the wall when the revolution comes...
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #27 - Posted 2004-07-20 19:09:40 »

Fair enough. My testing tends to be based on random sampling of the javadoc - click in each package and look at 2 or three of the classes and packages. Usually you get a decent idea just from looking at the overview to see how many classes have class docs and then at the methods and variable summaries.

One thing to note with the Xj3D javadoc is that we only run javadoc on about 30% of the packages. All the individual node implementation packages we don't both running as we think it's wasted effort and makes it harder for a user to make sense of what is going on.  We try to cut down on "over documenting" because it leads to more confusion rather than just running javadoc on the essential parts that an enduser that wants to extend Xj3D would use.  60 packages of "This implements the Box node in OpenGL" is useless to almost everyone, including ourselves (I use my own Javadoc as I develop too as the codebase is so big I forget what a lot of my own methods do, so I document for myself as much as for anyone else).  

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 zingbat

Senior Member




Java games rock!


« Reply #28 - Posted 2004-07-21 16:43:02 »

Quote
Edit: As for the javadoc being pitiful comment, I reject that completely. Xj3D has the best javadoc of any project I've ever seen. You're telling me http://www.xj3d.org/javadoc/ that that is poor javadoc, then I'd like to see what you classify as "good" javadoc.


Well what i wanted to say is that javadoc is just the minimal documentation being done well or not. My sugestion is to document pre/post conditions and invariants on the interfaces or classes if you dont provide an interface for that class. The profs at my univ recomend we use iContract for generating code to validate preconditions. And they also recomend we use UML extensively not just the class model diagrams.

The reason why i mentioned the multitude of jars is because java1.5 already comes with much of the funcionality you get from the extra apis you include in xj3d. So my guess is all the extra apis you bundle with xj3d could be replaced by java apis and reduce the distribution size.

This is important because if a person wants to make an apllet to display x3d forcing the guy who is loading the applet to wait several long seconds (minutes) is very bad. See the size of blaxxon plugin. Maybe this is not your development target but a small size applet is essential for a x3d viewer.


I have downloaded M9 and tried it. I think there is a problem in your full install executable. I have used the installer but at some point he tells me to delete old xj3d and to press ignore on the dos window prompt that follows if there was no previous instalation. Man using dos prompts with a nice install wizard interface ?? Then it installs a javavm and asks me to reset but after reseting, the installation process is forgoten. I was able to install xj3d by answering no to reboot after installing the javavm again.

I only have a simple request for you Mith abolish every mixture of java and msdos in your applications. Msdos is not like bash. Using msdos is even worst than using qbasic mixed with java. Wink Right now i cant even launch the browser on xp the msdos version of xp has been severely tunned down by Micro$oft.

There are so many other possibilities. You could use a .ini file as a command file; a bash version compiled for windows; an executable to launch your class with an .ini file to setup your classpath; a .js file (windows .js); a java class file; a jar with a properly setup manifest file; use java web starter.

ANYTHING BUT MSDOS. P ! L ! E ! A ! S ! E !
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #29 - Posted 2004-07-21 21:35:51 »

Quote
Well what i wanted to say is that javadoc is just the minimal documentation being done well or not. My sugestion is to document pre/post conditions and invariants on the interfaces or classes if you dont provide an interface for that class.


That's there already (mostly). Everything I write javadoc for has that information already written.  I've been coaching (more like hassling...) Alan and the other coders into provide better detailed javadoc, but they're much more hacker oriented than I am.

Quote
The profs at my univ recomend we use iContract for generating code to validate preconditions. And they also recomend we use UML extensively not just the class model diagrams.


This works well up to a point and is nice in theory. We already have large-scale architecture and runtime UML documentation in place. Look under the architecture docs on the Xj3D site and the docs/arch in CVS.  The large-scale architecture of Xj3D hasn't changed in 2 years. Some of the details have, but not the basic philosophy and runtime interactions. Keeping detailed architecture docs up to date with our day to day coding is close to impossible.  Last time I ran a project this side, I had 15 developers working under me, it it was far easier to keep more detailed docs current. Right now, there's myself and one other fulltime developer, and one part-timer.  Since the large scale architecture is unchanged in such a long time, I see no need, nor do we have the resources to maintain detailed parts.

Quote
The reason why i mentioned the multitude of jars is because java1.5 already comes with much of the funcionality you get from the extra apis you include in xj3d. So my guess is all the extra apis you bundle with xj3d could be replaced by java apis and reduce the distribution size.


Nice in theory but doesn't work in practice. We have some of our users that we're attempting to drag off 1.3 right now.  They're fighting kicking and screaming all the way too.  Moving to be solely 1.5 is an impossible pipedream for the next 3 years or more.  The only reason we're pushing these users to 1.4 is because JOGL has it as a hard requirement and they want to use that for the renderer for the better performance and not use Java3D.

Also, the stuff in JDK 1.5 does not actually support about 3/4 of what those JARs do. URI handling is a joke, so is the extended protocol handling (particularly URL handling that has to do more than just fetch a static webpage). The regexp in java.util.regexp is so buggy as to be non-functional.  The only other library jars that we bring in from other projects are the j3d.org code and Aviatrix3d, both of which JDK 1.5 doesn't do Smiley

Quote
This is important because if a person wants to make an apllet to display x3d forcing the guy who is loading the applet to wait several long seconds (minutes) is very bad.


That is of no concern to us as we are not targeting that audience. It would be impossible to use Xj3D in any applet form without installing it first - either because of the JOGL/J3D requirements, or because of all the other non-safe stuff we do down the bottom, such as messing with threads, external network handling, property configuration etc.

Quote
I have used the installer but at some point he tells me to delete old xj3d and to press ignore on the dos window prompt that follows if there was no previous instalation. Man using dos prompts with a nice install wizard interface ??


It's actually a native C app that is there to deal with some of our really old users that still have stuff installed in the wrong place. It's quick and dirty hack, as we're not Win32 developers, that is not intended to remain long term as part of the installer. The intention is to leave there for about another 12 months or so until we can be reasonably assured that there are no more pre-M7 users floating around out there. If someone wants to spend some time in VisC++ to write us a sexy version of the same code, that would be cool, but it's not really of any interest in us doing so.  However, it has to work for everything from Win95 and upwards, hence the simple  pragmatic nature of the current setup.

Quote
I only have a simple request for you Mith abolish every mixture of java and msdos in your applications. Msdos is not like bash.


Well, in the way that we have to use it, it is perfectly suited. It's just a simple launcher window that happens to integrate better with the OS than any of the other suggestions you've made, with the exception of the native launcher. All the others have problems dealing with drag and drop starting, controlling Java commandline parameters like heap size etc.

We could go for the full-on native launcher, but right now that hides way too much important information for us. We're still not rock-solid stable, and the commandline allows our users to quickly drop back stack traces with minimal effort.  In order to make a better toolkit, it's more important to us to do it that way than to hide the code right now. In addition, most of our users, don't use the standalone (dos-prompt) code. They use Xj3D as something integrated into other applications, typically through the SAI/EAI so it's less of a pressing issue for us.  The standalone browser is almost an inconsequential afterthought to us as not many of our users want to use a standalone browser.

Then, there's the other part of this - we do stuff we're paid to work on. Considering we have a large amount of paid work, anything like that, which is inconsequential to the daily usage of the code gets pushed right down to the bottom of the priority ladder. If someone wanted to pay us a few grand to spend a week developing and testing a nice native launcher app that integrated with a given operating sytem, then we'd quickly include it (or if they wrote one and asked for it to be included in the CVS code and agree to maintain it). The reality is that nobody has, nor do any of our existing clients show any interest in such activity, so that's not likely to change right now.

Quote
Right now i cant even launch the browser on xp the msdos version of xp has been severely tunned down by Micro$oft.


Considering that our development machines are all XP and a couple of Win2K laptops, which it works on just fine, I would say you've got something messed up in your base environment setup. Perhaps you've accidently reduced the maximum command line length in numbers of characters or something like that.

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.

ctomni231 (33 views)
2014-07-18 06:55:21

Zero Volt (29 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (26 views)
2014-07-16 23:30:00

Cero (41 views)
2014-07-16 00:42:17

Riven (43 views)
2014-07-14 18:02:53

OpenGLShaders (31 views)
2014-07-14 16:23:47

Riven (30 views)
2014-07-14 11:51:35

quew8 (29 views)
2014-07-13 13:57:52

SHC (65 views)
2014-07-12 17:50:04
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

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24: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!