Hi Boris,
Your approach to storing serializable data in the J3f IO framework is correct,
it's the method used to store a number of objects in the file already. The
method is in com.sun.j3d.demos.utils.scenegraph.io.retained.Controller if I
remember correclty (I don't have the source handy at the moment).
The reason that the IO system uses DataInput and DataOutput instead of
ObjectInput/Output is that for file IO (as apposed to streams) we use
RandomAccessFile which does not support ObjectInput/Output. The use of
RandomAccessFile allows the branchgraphs in the file to be loaded in any order
and/or to only load a subset of the graphs in the file.
Leyland Needham summary (included below) of the differences in file sizes is
correct, the j3f file includes every piece of data from the Java3D
scenegraph. So the size sill depend on what the VRML loader added to the
data when it was loaded.
>For number 2, I have been down a similar road for the j3f file format with
>obj files. One thing I forgot about was normals, that j3f stores the normals
>and the obj files I was using did not. The one thing I did learn also was
>that j3f files store texture maps internally, when you realize that it also
>includes the texture maps inside it can cause the size to be larger, this is
>something that may be relating to your problem. The other thing is, when I
>compressed the texturemap(s) and obj files down in a single zip file, and
>then compared them to a compressed j3f file, I noticed that the j3f file was
>smaller in size then the obj texture map one.
>This was just my initial observation, I think there is probably other ways to
>optimize the geometry and other properties inside of java3d so that the
>output will also be optimized memory wise. I'm currently examining the source
>code to the j3d fly through demo IO code to see how it works so that my
>utility program can possibly optimize the output. But I have to hold this off
>until I get some other issues settled with Java3D, I want to get a basic
>framework done for interface and other elements required in games before I
>decide to move to other things.
Having said that I believe the j3f file size can be reduced and it's something
that will be investigated as we moved forward....
Rgds
Paul
----------------------------------------------------------
Paul Byrne Email : [EMAIL PROTECTED]
Sun Microsystems Phone : (650) 786 9926
Visualization Software Group Fax : (650) 786 5852
----------------------------------------------------------
>MIME-Version: 1.0
>Date: Fri, 4 May 2001 21:15:12 -0700
>From: Boris Zeldin <[EMAIL PROTECTED]>
>Subject: [JAVA3D] j3dfly "serialization"
>To: [EMAIL PROTECTED]
>
>Dear friends.
>
>I tried to use j3dfly externalization framework to
>save some of my
>scene. I get stumbled on these 2 issues.
>
>1. The way Sun envision j3d externalization is to
>implement the
>following method in any custom object that extends a
>SceneGraphObject
>
>public void writeSceneGraphObject( java.io.DataOutput
>out ) throws
>IOException;
>
>You can store any primitive type members of this
>custom object and
>there is a clever procedure to store unwarranted
>SceneGraphObject
>references.
>My trivial question is how to store a simple
>serializable object
>members. The only way I see it right now is to
>serialize these objects into
>ByteArrayOutputStream. Count the number of bytes
>resulting from this
>procedure, say NBytes. Then, write NBytes into a
>DataOutput and then write
>byte_array representing serializable objects. Is this
>awkward procedure
>is the write way to save my costom sceneGraphObjects?
>Why
>writeSceneGraphObject() does not take ObjectData
>instead? Everything would be much
>easier.
>
>2. The first thing I did with externalization
>functionality of j3dfly
>is the following simple test.
>I took a simple but large VRML file of size 700K.
>Loaded into the
>j3dfly and saved resulting scene. The result had size
>= 2.2M. It is an
>enormous memory waste if you consider that
>corresponding 3ds file has size
>only 140K. Am I doing something wrong here? I naively
>thought that .flt
>files should be of the same size as 3ds files since
>internally they
>represent data in a binary format (unlike VRML files).
>
>Any insight into these issue will be greately
>appreciated.
>
>Thank you
>
>Boris
>
===========================================================================
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".
