> Date: Mon, 25 Sep 2000 17:38:03 -0700
> Sender: Discussion list for Java 3D API <[EMAIL PROTECTED]>
> From: Jack Pien <[EMAIL PROTECTED]>
> Content-Length: 3344
>
> when i try to reconstruct my new scene graph using CompressGeometryFile
> object, Java3D doesn't seem to unclamp the compressed coordinates - the
> coordinate data are all still between (-1,1).
> [...]
> do i have to know the range which my original coordinates span and store the
> range and rescale myself when i create my Shape3D with the compressed
> geometry?
Yes, that's true. The compressed geometry format described in Appendix B of
the Java 3D specification does not encode any original bounds information, so
the quantized coordinates are treated as model coordinates. A
CompressedGeometry object is like other geometry objects in that its scale,
position, and orientation in world coordinates are intended to be set by using
transforms in the scene graph.
> Date: Tue, 26 Sep 2000 11:27:15 +0200
> Reply-To: Discussion list for Java 3D API <[EMAIL PROTECTED]>
> From: Ingo Brunberg <[EMAIL PROTECTED]>
>
> you are right, Java 3D doesn't rescale the coordinates of the
> compressed geometry. You have to do this by hand. Notice, that since
> Java 3D 1.2 there are two Point3Ds called upperBound and lowerBound in
> the CompressedGeometryHeader, which you can use to store the original
> scale of your geometry.
No, upperBound and lowerBound in the CompressedGeometryHeader object are used
to specify a tight bounding box for the quantized coordinates themselves.
Although all compressed objects are bounded by the [-1.0, +1.0] cube, this is
not a tight bound. The largest representable number in the quantization space
is one quantum less that +1.0, so the upper bound will be determined by the
number of bits used to quantize the position coordinates.
These fields are provided so that the GeometryCompressor utility class and
other third-party compressors can provide an accurate bounding box for picking
and culling purposes, allowing Java 3D to avoid decompressing the geometry in
software if decompression is directly supported by the graphics rendering
hardware.
You can use these fields as set by GeometryCompressor along with the original
bounding box to derive the transforms you'll need to scale and position the
quantized coordinates back to their uncompressed locations.
> Nevertheless, I find this very inconvenient and suggest you try to save your
> geometry instead as a gzip'ed file, because somebody on this list pointed out
> a few weeks ago, that the compression you can achieve with the conventional
> gzip algorithm is in some (most?) cases better than with CompressedGeometry.
gzip'ed indexed representations may indeed have a good chance of producing
smaller files than those produced by using the current GeometryCompressor and
CompressedGeometryFile utilities, since GeometryCompressor as yet does not
perform any meshification to reduce the number of duplicated vertices. If an
indexed representation is not available then a .cg file produced by those
utilities should be quite a bit smaller than a straight binary or ascii
encoding compressed by gzip.
This is still work in progress. We will be able produce much better
compression ratios by exploiting the mesh buffer provided by the compressed
geometry format, which theoretically will allow us to approach 0.5 vertices per
triangle, the same as an indexed representation but with the further space
advantages of quantization along with delta and Huffman encoding.
If anyone wants to experiment with using the CompressedGeometryFile utility
class as part of a scene graph file storage mechanism, be aware that the .cg
file format is intended only as a resource file to store the compressed
geometry bits and a few other pieces of vital information; you'll have to store
metadata specific to the scene graph in a separate file.
If you go this route I would recommend storing all your compressed objects in a
single file since using the read() method for multiple consecutive objects is
the most efficient way to get the bits off disk. You can store metadata such
as materials and bounds in a different file and associate them to your
compressed objects through indices corresponding to their order in the file.
-- 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".
