Jacob, I hope one of the SUN engineers will take up the challenge and run the benchmark within a development environment. I suspect you have found a compilation bug in 1.3B1.
I also agree with David Y. that this is not a representative 3D *application*. However - but we should be able to get performance close to that of GL4Java. Sincerely, Daniel Selman Author - "Java 3D Programming" http://www.manning.com/selman -----Original Message----- From: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED]]On Behalf Of Jacob Marner Sent: Wednesday, March 06, 2002 6:46 AM To: [EMAIL PROTECTED] Subject: Re: Java 3D performance. Hi Daniel, I am glad you like the report in general. I expected some feedback from this list since Java3D is the only thing that a find to perform poorly. If this turns out to be a programming/knowledge error from my side I will be happy. > 1. You are setting the clipping distances correctly. Good, I thought so too. > > 2. We don't seem to be getting any real appreciable benefit from > compilation, and I can't get the compilation debug properties to output any > info either. Perhaps someone from SUN can comment on this? Yes, I just tried it as you did and compilation doesn't seem to do much. This mystifies me since I believe it was more effective previously. Now that I think about it I think it might have to do with the shared Appearance nodes - I think I remember seeing a performance drop from being a factor of 2 slower than C++ to being a factor of 2.5 when I added appearance. Maybe I stubled into a bug in the java3d 1.3 beta. In that case I will have to work around it. Judging a system based on a bug in a beta would not be fair. > > 3. On my machine the frame-rate is being limited by the V-sync on the > monitor. When you disable V-sync the framerate goes from ~85 Hz to ~320 Hz. > Presumably this does not explain your performance differences however, as > all the OpenGL applications should have been subject to the same limitation. > As you can see below all the other changes I made had no appreciable > effect - the scene is too simple for my GeForce II Ultra. I ran all the tests with v-sync off. I might have forgotten to mention this in the report. > display method seems like it could be optimized. It performs several trig > functions, calls lookAt and invert on a matrix etc. Presumably this is > called on every frame. I asked about this in this list some time back (13. feb. 2002) and chien yang just told me to go ahead with that approach since putting the lookAt() at the top of the geometry scen graph might hinder compilation. I tried it both there was no measureable performance difference - so I decided to let it be the "recommended" way. > Using QuadArray for geometry may not be the fastest option. Why not try an > IndexedTriangleArray for example? A test using BY_REF with > j3d.optimizeForSpace=false would be interesting as well. Am I incorrect when I say that the performance difference present when using IndexedTriangleArray() only is present during the creation of the scen graph. At run-time the node should have been converted to display lists (I hope) and the original representation will have no importance. Somebody also commented that I should use triangles instead of quads since quads might be treated wrongly by some drivers. However since quads also are used in gl4java and c++ with the same driver this should not be an issue. > > Anyway, good work! Thanks. But I am baffled that you find that compile() does nothing. I have gone to some great extent to ensure that nothing should prevent that: * Geometry is *not* accessed by ref. * Appearance is accessed by ref. * There is no capability bits set in the part of the scene graph with the geometry. So the the SHape3D nodes should be able to be merged and the transform group nodes eliminated using java3d 1.3 optimazations. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
