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 using obj2cg on the server machine.
2) In my applet, call out to the servlet on the server machine where the .cg file is stored.
3) Inside my servlet, read in the .cg file and send it back. It might look something like this:
File f = new File(fileLocation);
System.out.println("Will read from: " + fileLocation);
if ((f.exists()) && (f.isFile()))
{
ServletOutputStream out = response.getOutputStream();
InputStream iStream = new BufferedInputStream(new FileInputStream(f));
System.out.println("Starting read now");
byte[] buffer = new byte[2048];
int tmp = 0;
while ((tmp = iStream.read(buffer)) != -1)
{
out.write(buffer, 0, tmp);
}
out.flush();
iStream.close();
}
4) Inside of my applet on the client machine, assemble the stream that was read into a byte array by creating my own CompressedGeometry file.
This is where I get confused. I know that you can create a CompressedGeometry object given the buffer area that I will get back from the servlet, but you also need a CompressedGeometryHeader but that I'm not sure how to build. I know that I will need to create a CompressedGeometry object twith something like this:
byte buffer[]...//get data from servlet
...
CompressedGeometry gc = new CompressedGeometry(SOME_HEADER, buffer);
Where does the SOME_HEADER come from? Note that I googled for "new CompressedGeometry(" and found no examples to clue me in on this.
In short, what should the code inside of the applet look like to reconstiture the byte array that was the .cg file that was sent from the servlet?
Thanks!
-------------- Original message from Mark Hood <[EMAIL PROTECTED]>: --------------=========================================================================== 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".
> > Date: Sat, 21 May 2005 18:24:36 +0000
> > 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 in the applet reading the
> > file.
>
> As Laurent Gilson suggested, you may want to re-assess your usage of
> CompressedGeometryFile. Unfortunately it was really not designed for
> data transmission, as you've become aware.
>
> When all this was implemented the standard Java file I/O API was
> horribly slow, and we had many gigabytes of CompressedGeometry objects
> that we wanted to be able to read and load very quickly for various
> projects and demos. CompressedGeometryFile was written as a highly
> specialized, mostly read-only mechanism for retrieving thousands of
> models from a compressed object library. The random access feature was
> an extremely important requirement for this task, and there's a
> significant amount of overhead that goes into creating the structure of
> the file when it is being written, or even when it is just being
> instantiated from an existing file.
>
> The code was eventually released as a Java 3D utility, but it turns out
> not to have been very useful outside of Sun's original purposes. Most
> people need a file for streaming over the Internet, and this is still
> possible to implement. The source code for CompressedGeometryFile is
> readily available and could be useful in designing and implementing a
> strea mable version.
>
> -- 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".
