> Date: Thu, 24 Aug 2000 17:30:25 +0200 > From: Silvere Martin-Michiellot > <[EMAIL PROTECTED]> > > To J3D developpers, on a side track: My purpose using VRML97 loader was to > build up an exporter to J3D CompressedGeometries. I managed to do so. > However, to my surprise, my compressed files (that I zip furthermore) are > larger than a standard gzipped WRL file. (my files contain only indexed face > set). This is disappointing since it is mean to be a very efficient > compression format. Can anyone explain ? Sorry for the late response, I was temporarily cut off from the mailing list. Have you tried using the Stripifier utility on your indexed data to reduce the number of vertices that need to be compressed? The .cg file format doesn't directly support indexed representations. When you compress such data directly with the GeometryCompressor utility class it is expanded into non-indexed form before it is compressed, so that every index becomes a distinct vertex. If you store geometry on disk in an gzipped indexed representation then it is possible that it may be as space-efficient or even more so than than the representation that results from directly compressing it. Indexed representations are compact for storage in that ideally no vertex information is ever duplicated between faces. There is an explicit separation between the vertices and their connectivity. It is problematic for accelerated rendering since there is no commercially available hardware today that can use indexed representations directly; the vertices must instead be expanded in index order into linear arrays of host system memory and streamed to the hardware with implicit connectivity. One of the requirements of the CG format is to reduce memory usage, so it doesn't make sense to encode indexed representations which need to be expanded into RAM to begin with. Another major requirement of the CG format is to be able to directly render it on graphics accelerators equipped with decompression hardware. This is difficult to do in hardware with indexed geometry, for the same reasons that graphics accelerators find it difficult: you would have to be able to store a good number of vertices locally on the board, shuttle between vertices in non-linear order, and page between data that is stored on the board and the rest of the object in system memory which doesn't fit. The compressed geometry format does provide a mesh buffer that allows up to 16 previously compressed vertices to be saved and reused. Unfortunately, the GeometryCompressor utility class currently does not implement the topological analysis needed to reorder vertices to use the mesh buffer most effectively. We plan on developing a full-featured meshifier for GeometryCompressor in a future release of Java3D, and with that facility we expect compression ratios to improve significantly. -- Mark Hood =========================================================================== 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".
