We're also interested in the finding, and will look into this after Java 3D 1.3beta2 code freeze. Thanks for your interest in Java 3D.
- Chien Yang Java 3D Team. > Date: Wed, 06 Mar 2002 09:43:44 -0700 > From: Daniel Selman <[EMAIL PROTECTED]> > Subject: Re: [JAVA3D] Java 3D performance. > To: [EMAIL PROTECTED] > MIME-version: 1.0 > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > Content-transfer-encoding: 7bit > Importance: Normal > X-Priority: 3 (Normal) > X-MSMail-priority: Normal > Delivered-to: [EMAIL PROTECTED] > > 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". =========================================================================== 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".
