Hello Mark,
thanks for your answer.
>> I want to build a server application, that sends a set of
>> IndexedTriangleArrays to an applet. To minimize the amount of data, I
>> tried to use a compressed geometry build by the
>> com.sun.j3d.utils.compression classes. But I faced a lot of problems.
>>
>> First, it seems, that the normals or normal indices get lost or
>> corrupted.
>
>What version of J3D are you using? The following bug was fixed in 1.1.3 and
>1.2 alpha:
>
As I am developing on linux at home and on IRIX at the university I
have to use J3D 1.1.1 until blackdown or SGI release newer
versions. As far as I can see, there is no problem with the
colors. They look right. The resulting picture indicates that there
are indeed problems with the normals. I don't want to dive too deep
into the internals of the compression, but I think my
IndexedTriangleArrays are converted to StripArrays, because I
sometimes got errors about unclosed meshes. So the question is if
geometry compression is applicable to an IdexedTriangleArray if you
want to preserve the normals.
>> Second, somehow the geometry is scaled down.
>
>Yes, compressed geometry is defined within a normalized unit cube which
>ranges from [-1..1) on each axis. You need to rescale and translate in
>order to get the original size and position. Currently there is no explicit
>scaling and offset information provided by the compressor, but this is
>"Request For Enhancement" that will be implemented for 1.2 FCS.
>
Good to know!
>> Third, the compression calculation is awfully slow. On my 233 MHZ PII
>> running under linux with jdk1.2.2-RC3 it takes approximately 3 minutes
>> for 30 IndexedTriangleArrays (each ~2000 triangles I guess) with
>> normals and per vertex colors. On a SGI octane with 300 MHZ R12000
>> processor, which I intended to use as the server, it even takes
>> roughly 5 times longer!!! That's clearly to slow to consider.
>
>I don't know why the same app would be 5 times longer on an SGI; could have
>something to do with their Java implementation.
>
My fault. The speed is not so much a matter of the compression
algorithm. In the meantime I have finished some early versions of my
applet and the corresponding server applications that use the original
uncompressed geometry, and it's as slow as before!!!
Let me say, it's my first networked program. I built a frontend server
which I intend to run on the http server hosting the applet and a
backend server to run on a faster machine, which shall carry out the
surface calculation (with IBM's DataExplorer, by the way). The real
performance problem, I think, is caused by statements such as
dataOutputStream.writeFloat(dataInputStream.readFloat())
or
dataOutputStream.writeByte(dataInputStream.readByte())
in the case of compressedGeomtery
which I use in the frontend server in big for()-loops to send the data
from one socket to the other. Perhaps I'll have to experiment a bit
with reading and writing larger blocks of data to speed things up.
Regards,
Ingo Brunberg
===========================================================================
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".
