This project is read-only.

Scene xml format... Opinions?

Jan 7, 2008 at 4:13 PM
What are your opinions about this structure for the xml scene files?

<?xml version="1.0" encoding="utf-8"?>
<!--Scene Settings-->
<Settings>
<Scene>
<SceneName>Scene1</SceneName>
<SceneCode/>
<Camera>
<CameraID>1</CameraID>
<CameraTarget>
<x>0</x>
<y>0</y>
<z>0</z>
</CameraTarget>
<CameraPosition>
<x>0</x>
<y>0</y>
<z>0</z>
</CameraPosition>
<cameraYaw>0</cameraYaw>
<cameraPitch>0</cameraPitch>
</Camera>
<FarClipPlane>20000</FarClipPlane>
<FogEnabled>false</FogEnabled>
<FogStart>1</FogStart>
<FogEnd>1000</FogEnd>
<FogColour>255;128;128;128</FogColour>
<AmbientColour>255;128;128;128</AmbientColour>
<SunLight>
<SunLightIntensity>1.0</SunLightIntensity>
<SunLightPosition>
<x>-20.0</x>
<y>20.0</y>
<z>10.0</z>
</SunLightPosition>
</SunLight>
<Sky>
<SkyModel>Sphere</SkyModel>
<SkyEffect>skyEffect</SkyEffect>
<SkyTexture>cubeSphere</SkyTexture>
<SkyCode></SkyCode>
</Sky>
<ObjectCount>4</ObjectCount>
<Object>
<Id>0</Id>
<ObjectModel>p1_wedge</ObjectModel>
<ObjectName>Ship</ObjectName>
<ObjectPosition>
<x>0</x>
<y>0</y>
<z>-5000</z>
</ObjectPosition>
<ObjectRotation>
<x>0</x>
<y>0</y>
<z>0</z>
</ObjectRotation>
<ObjectScale>1</ObjectScale>
<ObjectShadow>false</ObjectShadow>
<ObjectVelocity>
<x>100</x>
<y>100</y>
<z>-100</z>
</ObjectVelocity>
</Object>
<Object>
<Id>1</Id>
<ObjectModel>asteroid1</ObjectModel>
<ObjectName>Asteroid</ObjectName>
<ObjectPosition>
<x>-3000</x>
<y>1000</y>
<z>-5000</z>
</ObjectPosition>
<ObjectRotation>
<x>0</x>
<y>0</y>
<z>0</z>
</ObjectRotation>
<ObjectScale>1</ObjectScale>
<ObjectShadow>false</ObjectShadow>
<ObjectVelocity>
<x>100</x>
<y>-100</y>
<z>100</z>
</ObjectVelocity>
</Object>
<Object>
<Id>2</Id>
<ObjectModel>p1_wedge</ObjectModel>
<ObjectName>Ship</ObjectName>
<ObjectPosition>
<x>0</x>
<y>0</y>
<z>-15000</z>
</ObjectPosition>
<ObjectRotation>
<x>0</x>
<y>0</y>
<z>0</z>
</ObjectRotation>
<ObjectScale>1</ObjectScale>
<ObjectShadow>false</ObjectShadow>
<ObjectVelocity>
<x>300</x>
<y>100</y>
<z>100</z>
</ObjectVelocity>
</Object>
<Object>
<Id>3</Id>
<ObjectModel>asteroid1</ObjectModel>
<ObjectName>Asteroid</ObjectName>
<ObjectPosition>
<x>3000</x>
<y>1000</y>
<z>-5000</z>
</ObjectPosition>
<ObjectRotation>
<x>0</x>
<y>0</y>
<z>0</z>
</ObjectRotation>
<ObjectScale>1</ObjectScale>
<ObjectShadow>false</ObjectShadow>
<ObjectVelocity>
<x>100</x>
<y>-50</y>
<z>100</z>
</ObjectVelocity>
</Object>
</Scene>
</Settings>
Jan 7, 2008 at 4:46 PM
Looks good, but I dont see any referance to a height map. Is this a delibaerate ommission, or am I being stupid? :D
Jan 7, 2008 at 6:47 PM
While I do acknowlegde the work put into this, I can't see that you can put it this way. We do not know the properties available on the entities so we can not pre-determine the layout of the scene xml.

And it should not matter anyway, the scene should just be able to persist itself, using serialization. This way anyone can write their own entities and it would stille be persistet correctly.

We haven't currently discussed how the scene, or rather come to a conclution, should persist itself. If everything would implement ISerializable then we would be home free, and at any point in time we could simply serialize the scene safe it to disk and then later restore the game to exactly that point again (I know that there is more to a game than the scene, but you get were I'm going).

I think that shaw had the biggest objections (sorry if I remember wrong), but can't remember what they were. Since this is at load time I have no problems with using xml and serialization, even it this means a few more secs, it's only done seldom (relatively in game terms).
Jan 7, 2008 at 7:13 PM
I agree with Sturm, about Serialization. I think it simplifies a lot of code, and allows us to abstract the scene.
Jan 7, 2008 at 7:41 PM
No, there is no heightmap overthere, because my scene doesn't have one yet.
I am using this approach because it is more flexible and easy to understand.
ISerializable is not bug free. It is giving a few headaches to a few people, including myself.
And if you watched any of my scene editor videos, you can see that the editor already saves and loads any scene from the disk right now without any bug or problem. And when I add any object inside the scene editor, and click the save button, the editor add it to that file for me.
Jan 7, 2008 at 7:52 PM

xnasorcerer wrote:
I am using this approach because it is more flexible and easy to understand.


I disagree on the flexibility part, If you start to add custom properties and entities, you can get into trouble specially if you start allowing sub item based on parent types.


xnasorcerer wrote:
ISerializable is not bug free. It is giving a few headaches to a few people, including myself.


I've used ISerializable for many years/projects and never had any problems which wouldn't be overcome, then main issue is always DIctionaries, but there are plenty of patterns to solve that.


xnasorcerer wrote:
And if you watched any of my scene editor videos, you can see that the editor already saves and loads any scene from the disk right now without any bug or problem. And when I add any object inside the scene editor, and click the save button, the editor add it to that file for me.


Try to add entities/terrain with custom properties.
Jan 8, 2008 at 5:11 AM
Edited Jan 8, 2008 at 5:12 AM


Sturm wrote:

xnasorcerer wrote:
I am using this approach because it is more flexible and easy to understand.


I disagree on the flexibility part, If you start to add custom properties and entities, you can get into trouble specially if you start allowing sub item based on parent types.


I don't see any trouble at all!
The flexibility of having a scene format like that comes when anyone can make a plugin for any model editor to export a entire scene to the engine. For example, I own a license to a engine that and I made a plugin for 3dsmax to export the complete max scene to that engine with all engine properties configured inside 3dsmax. This way, 3dsmax became my scene editor for that engine. I just had to export it and run the engine for the game to be running.
I will convert that plugin to export to this engine also. And anyone can make the same thing for any modeler software that can export with the formats supported by the engine. And if I have time, I will also make a plugin for export the scene from Blender.


Try to add entities/terrain with custom properties.


I will! It is not there yet because I am also working on a Terrain editor, not just the interface. ;)
Jan 8, 2008 at 5:26 AM

Sturm wrote:

I think that shaw had the biggest objections (sorry if I remember wrong), but can't remember what they were. Since this is at load time I have no problems with using xml and serialization, even it this means a few more secs, it's only done seldom (relatively in game terms).


My biggest worry was the control we'd have over the serialization process, especially on Xbox where the serialization functionality is very limited. I was in favor of a custom serialization process. Our scene manager could have a Serialize method, that writes all pertinent scene information into a known XML format (I actually prefer binary, but that's not important). Each entity would also implement a custom ISerializable interface, and thus also implement Serialize methods. Each entity type would be responsible for writing all pertinent data into a given stream. Deserialization would be the same way. The actual serializer could then be completely customized for our needs, and handle all type conversions and instantiations properly.

I'll be the first to admit that I haven't used .NET's serialization functionality in any serious projects. However, from what I have seen, I'm not sure how it would work for something like scenes. You can have hundreds of different entity types (classes) embedded in the XML file, and from what I see you deserialize based on a known type, not an abstract base type.
Jan 8, 2008 at 6:40 AM
Using IXmlSerialable (or ISerializable for that matter) we can create any custom serialization behavior we want. This means that we can serialize the type information along with the serialized object, then during deserialization that information is used to instantiate the needed XmlSerializer instance.

Using the XmlSerializer we actually need to do some custom serialization/deserialization as we are most likely going to be using dictionaries, which do present a challange here, but it's easily overcome.
Jan 8, 2008 at 4:18 PM
If possible, go with ISerializable, and then convert that to XML. I really dont want to send xml over the net, as binary is more efficient. Im thinking of joining games in progress, as ive no problem sending xml to load the game initially. On that subject I saw a nice zip library, with netowrk streaming built in. We could adapt this if needed.
Jan 8, 2008 at 6:44 PM
That only factors in when you send user content over the wire.
Jan 8, 2008 at 6:58 PM
xml can be compressed a lot before sending it, it's not as optimal as a optimized binary compression, but I think it's well worth the price.
Jan 8, 2008 at 7:06 PM
Of course. As computers get faster and memory gets smaller and cheaper, we spend more and more processor cycles and memory usage on frivolous data formats. :)

XML can be nice for some limited data formats, including some scene data formats, but a lot of times I just find it too verbose. I mainly use it since that's what everyone else wants to use.

Seriously, I've seen people represent bitmap images with XML... why?!

<image>
    <dimensions>512, 512</dimensions>
    <data>
        <pixel>
            <red>255</red>
            <green>128</green>
            <blue>54</blue>
        </pixel>
        <pixel>
            ...
        </pixel>
        ...

Tell me that's not an awful waste of perfectly good disk space!
Jan 8, 2008 at 7:36 PM
IM sorry sturm, I jsut dont get it. If its not going to read and edited by a user, whats the harm in binary storage? Especially if the reading/wrutung is also done automatically, even for the coder. ANd especially with network, every byte counts.
Jan 8, 2008 at 7:36 PM
You are right from a optimization standpoint this is a little waste of either diskspace or CPU, xml can be compressed very good, specially larger files. But at the cost of CPU time. But I find that when I have to debug data and data states I love XML over binary.