The byref is only slower if you are not updating it every frame. We are using float[] by ref. That means you can update the floats right in the array and then the floats are streamed over every frame. There is no additional copies made. Think of it this way, when you set the attributes to allow you to update the geometry, Java3d will not use a display list, so its sendnig the data every frame anyway. If you use anything other than byref float[] then Java3d keeps its own internal copy, so every time you make an update it has to move stuff around. By using byref float[] you can basically work right with the data.
Now there are extensions in java3d 1.3 which help with some of this, and I have not worked with them yet. The NIO buffers might be a big speed up. You also are supposed to be able to set a policy on geometry for "update infrequently" which will tell java3d that you will be changing the data, but not every frame. Then Java3d can use display lists. I am hoping that will be helpful in optimizing our skin and bones system so we can choose to only update some animations every 4 or 5 frames (ones further away) to improve frame rates. Dave Yazel ----- Original Message ----- From: Marc Palmer <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 31, 2001 2:42 PM Subject: Re: [JAVA3D] Best way to deal with many "duplicate" objects such as particles? > The trick we are doing is to build a composite texture whcih consist of all > the small particle textures, generally in greyscale with alphas. Then we > use a geometry updator against dynamic byref arrays of floats. We vary the > texture size and orientation for every visible particle on every frame. > Another trick is to change the texture coordinates to cause the texture to > rotate, although you can do the same thing with the vertices. Our particle > system manager actually manages all the visible particles in a single > geometry updator. All the various emitters feed the manager, who then owns This is interesting - I like your ideas (especially the texture coord adjustment to simulate rotation trick!) However, surely the use of byref lookups for texture coords would be much slower than passing the actual float[] (as it is the same for most particles in my example)? The Java3D docs seem to indicate that byref for most things is slower than providing all the data when it is needed (which makes sense). At this stage I'm less worried about memory usage than I am about performance. I also noticed something, probably obvious, but calling TriangleArray.setCoordinates can be very expensive! I changed my code from using one call to setCoordinates containing all geometry to calling setCoordinates once for every particle, with just the vertices for that particle. Of cource there is java method call overhead here, but it was at least 50x slower! Yes, I was calling it 1000 times per frame, but hey ;-) Cheers ========================= 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".
