OK, I'll forget about using the CompressedGeometryFile entirely as you and Laurent Gilson suggested.
He did say that there should be a way to assemble a CompressedGeometry file in the client applet though.
Does something like this sound plausible?
1) Convert my .obj files to .cg files
> Date: Sat, 21 May 2005 18:24:36 +
> From: Darrin Smith <[EMAIL PROTECTED]>
>
> Again, it isn't the decompression that is slow, nor was it the reading of the
> compressed image off of the server or the transmission speed (local Intranet
> witha fast network). The problem was somewhere
Either I'm not understanding what you mean or you didn't understand my problem.
Here is thescenario:
I have the images in .obj format on the server. These can be compressed there before hand or on the fly using a servlet into the .cg format.
The destination of these images will be an ap
Darrin,
First I think you'd have to decide whether you want lossy or lossless
compression. You're going to always have a trade-off issue between
network performance vs amount of data you send. i.e. there is no
"magic" solution that is going to send huge models without some loss of
information.
Hello
> Using the Java3D compression mechanism (objtocg) works VERY well as the
> files get down to around 400K to 600K, but the CompressedGeometryFile was
> not written to allow the use of URLs.
Why do you use CompressedGeometryFile at all ?
Create the compressed data as usual. On the client-si
I have some large models that need to be displayed in a Java3D applet. The
files are 8 or 9 meg each in .obj format, and two will be needed each time
the applet runs. What happens is the applet calls back to a servlet using
a URL that has a file name (the name of the 3D image) attached as a
paramet
