> 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".
