This is exactly what I am doing, and I already have a couple of culprits. Once I finish my analysis, I will report to the whole list. We should see the performance a lot closer to GL4Java when I finish.
Thanks. Doug Twilleager Java 3D Team Sun Microsystems Daniel Selman wrote: >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".
