Hi Chien, >On Thu, 4 Apr 2002 16:14:18 -0800, Chien Yang <[EMAIL PROTECTED]> wrote:
>Raj, > Let's do some math. A sphere geometry with resolution 15 division, >in Java 3D, will generate 480 vertices. Let's assume only coord. and normal >is needed, each sphere requires a minmum of 480 * 24 = 11520 bytes. >That is likely to be 4X the memory footprint of TransformGroup + Shape3D + >shared Geometry (~3600 bytes, calculated base on 50K spheres). > >Your idea will be great if each geometry is small, eg. a quad in the particles >example. > Many more than "a quad". Please feel free to correct my stats below. If 3.6k/geometry is the budget I have to work with, it is equivalent to 150 verts = 50 UN-indexed tris, and a lot more if I use indexed tri strips. May or may not be good enough for a sphere depending upon the sizes of the spheres relative to the overall scene. However, for many routine glyphs - cylinders, cones, arrows etc. - I could do a pretty good discretization with that count. Also, I think that the TG + shared geometry approach will run into problems if there is a local color variation within each glyph. The DX Explorer dataset in the ViewPerf OpenGL benchmark, similar to my tube extrusion, is a good example. For cases such as this, the TriangleStripGeometry approach indeed appears to be optimal, especially with help from the USE_COORD_INDEX_ONLY capab. bit. It is indeed nice to note that the TG and Shape3D memory footprints have been optimized to the extent that they are getting to be quite competitive in such cases. Regards Raj =========================================================================== 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".
