Thanks to Sean and Arthur for your responses. Using GeometryByRef again requires that I keep my data in a format expected for strips or triangles, etc. I am disappointed to discover that I can't keep my data in a representation that I would like. The graphics library should not be telling the application how to represent it's data. There are pleanty of reasons to store data in other representations. Additionally, applications that deal with large numbers of points and elements, say 10 million would drop to their knees if copies were made.
I would like to see Sun provide several new interfaces that a visualization application could implement. Perhaps there would be an interface that would be used to build a set of triangle strips, or simple triangles, or a line strip. Then an application could implement this interface over the top of their data as-is and Java3D could decide when it needs to call the application to populate its display lists or whatever else it wants to do. Michael Sean Sylvis wrote:
Yes, I believe the Geometry object normally makes copies of all data (coordinates, normals, etc.). Have you looked into using the by-reference capability provided by the Geometry classes? This allows you to store your data in a particular representation (point array, strips, etc.) and have an Geometry object reference this data. In addition, you can update your data (through the updateData() method) and the update will be reflected in the representation of the Geometry object. Sean -----Original Message----- From: Michael Saunders [mailto:michael@;AMTEC.COM] Sent: Tuesday, November 05, 2002 3:13 PM To: [EMAIL PROTECTED] Subject: [JAVA3D] Best approach for memory intensive data I am resending this message in the hope that the subject line will attract a response unlike my previous post for which I did not receive any responses. When delivering points to a GeometryArray or one of it's subclasses does the Java3D library make copies of this data if display lists are used (when I say "copies" I don't mean the display lists I mean an intermediate representation before the display lists are generated)? If so, is there an interface in Java3D that I can implement so that I don't have this overhead. In other words, my data is represented in a format that is not necessarily in a geometry point, array, or strip format, however, if the Java3D library provided an interface for "fetching" points for building the triangle strips, quad strips, etc I could have my internal model implement this interface and eliminate the extra storage overhead. Looking at the Geometry classes it appears that each of them holds onto their own representation of the data thereby doubling the space requirements. Can I get hold of the source code for the Java3D library so that I could answer some of these questions myself? Thanks, Michael =========================================================================== 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".
