> Date: Thu, 6 Apr 2000 09:05:20 +0300
> From: Iyad Hijazi <[EMAIL PROTECTED]>
>
> Hi, Is using Shape3D with CompressedGeometry suppose to decrease the
> memory consumption ? I tried that but did not see and change in memory
> size. The CompressedGeometry class has this statement "Using compressed
> geometry reduces the amount of memory needed by a Java 3D application and
> increases the speed objects can be sent over the network."
Here's a long response to your question since it raises some issues that are
important for anybody on the list wondering how to use compressed geometry
in Java 3D effectively.
Your understanding that compressed geometry uses less space is correct, but
in order for Java 3D to render it on a platform that doesn't support the
direct rendering of compressed geometry it must perform a software
decompression into memory. The decompressed geometry is retained for
further renderings in order to provide reasonable performance. When run on
such a platform your application will consume as much memory as the
non-compressed version.
A memory savings will result only if you are certain the underlying OpenGL
or D3D graphics renderer supports hardware decompression; since the Java 3D
API doesn't provide a way to find out, most Java 3D applications should
avoid this strategy for saving memory for now. Currently the only platforms
which support hardware decompression are newer versions of the Sun Elite3D
graphics accelerator running with Solaris OpenGL 1.1 and later. Future
versions of Sun graphics hardware will also support hardware decompression
(but not the currently shipping Expert3D), and hardware from other vendors
which license the technology may as well.
What, then, are more appropriate uses of compressed geometry that will
effectively exploit its advantages? Typically you won't want to compress
and render geometry in the same application: you should bundle compression
facilities with data producers (servers, modelers, digitizers, etc.) and
decompression facilities with data consumers (clients, viewers, plotters,
etc.).
For example, you might have an application on a web server that compresses
part databases from engineering, coupled with web clients that retrieve
parts for local viewing, or perhaps a modeler that writes compressed
geometry to a file for an animation program. Such applications will realize
shorter web download times and smaller file sizes.
There are also significant advantages for applications loading a native Java
3D representation such as compressed geometry directly, as opposed to
geometry expressed in formats such as the .obj file. I sometimes use a
fairly large .obj file for testing, 1668926 bytes. On an Ultra-2 Elite3D,
ObjLoad takes about 34-35 seconds to load it and display it. Compressed,
the file is 469480 bytes, and cgview takes 9 seconds to load and display it
using the Java 3D software decompressor.
The Java 3D software decompression itself takes about 2 seconds with the
above example. The decompressed geometry is retained for performance
reasons, although it *is* technically possible to implement compressed
geometry in Java 3D so that compressed geometry is sent to an OpenGL
software decompressor, which will decompress it on the fly with each
rendering (with the obvious performance hit). This would only be possible
with Solaris OpenGL until the compressed geometry extension is implemented
by other vendors.
For example, here is a micro-benchmark using retained decompressed data from
a 200x200 quadrilateral grid, followed by a second run with an experimental
version of Java 3D that uses OpenGL to software decompress with each frame:
% cgspin GeomCompressTest.cg 0
GeometryDecompressor: decompressing 448904 bytes...
done in 2.305 sec.
decompressed 80800 vertices at 35054.23 vertices/sec
vertex data present: coords normals
bytes of data in generalized strip output: 1939200
compression ratio: 0.23148927
fps : 55.9872484558677
fps : 55.931528662420384
fps : 56.155075939248604
fps : 55.853707016497715
fps : 56.132640831002796
% cgspin -unretained GeomCompressTest.cg 0
fps : 5.85480093676815
fps : 5.874290189935382
fps : 5.865102639296188
fps : 5.8570870753611874
fps : 5.893909626719057
The 10x performance hit is the reason the decompressed geometry is retained
at the expense of increasing memory usage. It may be possible to add some
sort of "performance/space" decompression toggle in some future version of
the Java 3D API if that trade-off is acceptable to some applications and the
facility is requested.
The greatest advantages to compressed geometry are of course fully realized
when the rendering platform supports hardware decompression, which should be
more common in the future. Such platforms can decompress geometry with no
loss in rendering speed, or even faster if the bus bandwidth is the gating
factor.
-- 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".
