next »

[Mathias 'cylab' Henze]

I remember there was once some scenegraph serialization code available. What happend to it?

If that's (apparently) not available anymore, what needs to be done to read and write xith3d scenegraphs from disk? I thought of using xstream, but it is just too brute force. Another option would be to create a utility that constructs an xml document by traversing the scenegraph. The resulting xml could be used to recreate the graph using some digester rules.

The question is, how can scenegraph serialization be achieved with a minimum effort and a maximum modularity. Creating a monolitic serializer with lot of instanceofs poisons extensibility. Maybe it would be better to create a set of Annotations (or reuse existing?) to configure the way an element is stored. Maybe simply implementing load(ObjectInputStream) and save(ObjectOutputStram) methods for each node is the best solution in this case.

What do you think? Any other options?

Edit: looking at their page, XStream Annotations seem promising...

[Marvin Fröhlich]

I don't think, we should fix our API to one single XML serialization API. And XStream needs so many jars (ugly).

I would suggest to write an interface called XSGSerializable (or something like that), that has a method, that returns a string (maybe XML), that contains every information, that is necessary to recreate the Node instance. This way a Model would only need very few information like model type, model resource, skin, current animation and anim-time, etc. If you would naively serialize the Model, you would need to serialize any sub-Node of it. Additionally the XSGSerializable interface would need to have a method, that tells the serializer if it is a leaf or not. E.g. a Model would be a serialization-leaf, while it is not a SceneGraph Leaf Node.

Just my one cent.

Marvin

[Mathias 'cylab' Henze]

I don't think, we should fix our API to one single XML serialization API.

I may agree...

And XStream needs so many jars (ugly).

It only needs the xstream.jar AFAIK

I would suggest to write an interface called XSGSerializable (or something like that), that has a method, that returns a string (maybe XML), that contains every information, that is necessary to recreate the Node instance. This way a Model would only need very few information like model type, model resource, skin, current animation and anim-time, etc. If you would naively serialize the Model, you would need to serialize any sub-Node of it. Additionally the XSGSerializable interface would need to have a method, that tells the serializer if it is a leaf or not. E.g. a Model would be a serialization-leaf, while it is not a SceneGraph Leaf Node.

There is a Scribable interface for the old terrain implementation that looks a bit like this and I think the java API has this in form of the Externalizable interface. The only downside is, that it more or less links the serialized representation to the class and not to the serializer.

I think I will toy a bit with xstream without using annotations and configure the fields and mappings in the serializer class to avoid a direct dependency. Something that is needed in any case is rework of some classes to correctly specify transient fields (my first try serialized my whole application ) and implement some readResolve()-method on the nodes like described here. If once done fully, this would have the benefit of being able to using standard JDK serialization as well.

And for the curious, I started a terrain browser to help me debug my terrain code, but think it would much more useful to have a scenegraph editor and for that a scene graph serialization is essential.

[kukanani]

What would be even cooler (in my opinion) would be to have a special COLLADA Baker class, which would work in the opposite way of Amos's up-and-coming COLLADA Loader.  Then you could use the Baker to save your scene, and the loader to load it, and so on...

[Mathias 'cylab' Henze]

I agree, that here should be an exporter for collada, but a "native" xith serialization as well, since we would be a lot more flexible. The terrain for instance will be a single xml-entry with some configuration properties. If loaded, it will expand to a scene branch with quadtree like groups, multiple TerrainTiles consisting of LODShapes etc. This would (afaik) not be possible with collada.

['n ddrylliog]

What would be even cooler (in my opinion) would be to have a special COLLADA Baker class, which would work in the opposite way of Amos's up-and-coming COLLADA Loader.  Then you could use the Baker to save your scene, and the loader to load it, and so on...

While that's an interesting idea, I agree with cylab here.
My goal with the COLLADA loader is to provide support for a format which support skeletal animation sufficiently well for modern games. I have no plan to implement support for whole scenes, for that another format would be needed, because 3D editors aren't game editors. Well, that's what I believe. Now, there's nothing in the COLLADA loader preventing you to add whole scene support.

[mhermann]

Is there no possibility except the xstream? To save one sphere took about 500k space.

[Marvin Fröhlich]

Is there no possibility except the xstream? To save one sphere took about 500k space.

Well, we should have a Xith3DModel file format similar to the JCDModel (to be found in the org.xith3d.demos.phong.utils package), that stores all relevant data of a Shape3D in an efficient way. I think, this was once suggested before. But it needs to be well planned and designed. So, it is not a thing to be implemented in a day. Please try to use something like XStream till then.

JCD's model file also containse data like tangents and binormals, which are needed for bumpmapping. Bumpmapping is a really amazing feature, btw. One should always try to make use of it in a game.

Marvin

['n ddrylliog]

mhermann, there are always possibilities.. it's just a matter of time.

Well, we should have a Xith3DModel file format similar to the JCDModel (to be found in the org.xith3d.demos.phong.utils package), that stores all relevant data of a Shape3D in an efficient way. I think, this was once suggested before. But it needs to be well planned and designed. So, it is not a thing to be implemented in a day. Please try to use something like XStream till then.

Yeah.
For other solutions while you're waiting, mhermann, can't you just use plain old java serialization ? It's not XML, it could be smaller..

JCD's model file also containse data like tangents and binormals, which are needed for bumpmapping. Bumpmapping is a really amazing feature, btw. One should always try to make use of it in a game.

Nope. Use normal mapping instead. Much better.