Dave: > 1. If we use a geometry updator and use the set() methods on non-ref > geometry, but only update the normals and coords does the texcoords and > colors still get sent to the card that frame? Yes. All components (changed or not) will be sent down every frame. Typically, there are several primitives in a scene and therefore when a part of a primitive changes we still have the send down(define) the whole primitive. > 2. If we use a call geometry updator but don't use by-ref geometry, and > within the updator we do not do any set() methods is anything sent to the > card in that frame? Is it still considered "dirty"? In the current release, yes. In the by-copy case, If you are not calling any set() methods, why are you calling the geometryUpdater()? In any case, this will be fixed in the upcoming release. > 3. If we have all our information stored in arrays of floats and the colors > in arrays of byte, will any slow translations happen during geom.setNNN() > calls? In other words, is there any format like point3f(), float[], > double[] etc which is most optimal for you to work with. I am especially > interested in anything that is not vertexCount() dependent for speed. In > other words is there any format that does not require you to "loop" through > the data to transform it for display list. I presume, you are talking about by-ref case, since in the copy case, Java3D makes an internal copy. In the case of by-ref, we strongly recommend that you use the basic types such as float,double byte. If you use the basic types, there is no additional processing done during the set(). In the case of by-ref we use vertex array for rendering. > 4. Other than the copy caused by doing set(), is there any additional > overhead in performance between using the setters and using the geometry by > reference? Yes. In the by-copy case, If the geometry is not editable, then Java3D uses display list to render the geometry - this path gives the most performance. In the by-ref case, Java3D *always* uses vertex array. As I mentioned in an earlier mail, it is a question of performanceVsSpace. So, if you change a by-copy geometry often (or even if you have the capability bit set), then Java3D will make a copy internally and we will use vertex array to render it. If you application changes data often - You are better off using by-ref with basic data types. > 5. If you use the setters to frequently update the geometry does this cause > a lot of memory deallocation/allocation or is the data laid down into the > internal structures without allocations being neccessary? > In the case of by-copy - Changing setters will not cause deallocation/allocation. In the case of by-ref with basic data types - there is no copy. -Uma > Delivered-To: [EMAIL PROTECTED] > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 > Date: Fri, 22 Jun 2001 14:42:58 -0400 > From: David Yazel <[EMAIL PROTECTED]> > Subject: [JAVA3D] performance By-ref versus using setNNN methods > To: [EMAIL PROTECTED] > > Question for the Sun folks ( and anyone who knows the internals) . > > We have coords, colors, texcoords and normals in a piece of geometry which > we want to update often, but not always every frame: > > 1. If we use a geometry updator and use the set() methods on non-ref > geometry, but only update the normals and coords does the texcoords and > colors still get sent to the card that frame? > > 2. If we use a call geometry updator but don't use by-ref geometry, and > within the updator we do not do any set() methods is anything sent to the > card in that frame? Is it still considered "dirty"? > > 3. If we have all our information stored in arrays of floats and the colors > in arrays of byte, will any slow translations happen during geom.setNNN() > calls? In other words, is there any format like point3f(), float[], > double[] etc which is most optimal for you to work with. I am especially > interested in anything that is not vertexCount() dependent for speed. In > other words is there any format that does not require you to "loop" through > the data to transform it for display list. > > 4. Other than the copy caused by doing set(), is there any additional > overhead in performance between using the setters and using the geometry by > reference? > > 5. If you use the setters to frequently update the geometry does this cause > a lot of memory deallocation/allocation or is the data laid down into the > internal structures without allocations being neccessary? > > Thank you very much for your responses in advance, > > > > Dave Yazel > > =========================================================================== > 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".
