This sounds really interesting. If you can do this I will have to edit my conclusions about Java3D to the better.
Cheers, Jacob ----- Original Message ----- From: "Doug Twilleager" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 06, 2002 18:13 Subject: Re: [JAVA3D] Java 3D performance. > 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". > =========================================================================== 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".
