[ Soc 2009 submitted ] another XML Scene Serializer

[mcinek]

Hello!

First of all I'll start with introducing myself. My name is Marcin Undak.
I live in Warsaw, Poland. I'm a fifth year student of
Warsaw University of Technology. My specialty is robotics.

My main profession is programmer. I work in a small company which provides
custom made software for specific clients request.
Currently I'm running a project involving embedded Linux solutions.

My journey with programming started ten years ago with C and C++.
In work, besides Linux stuff, I develop for Windows using C#.
I use Linux as my main os since 2002. I used many various distros over the years,
like Slackware, Debian, Gentoo, Ubuntu, currently OpenSUSE.

I have experience in software development alone and in team. I was a part of many
successful projects and ran couple of myself. However, I didn't really
participate in Open Source community. What is worthy meaning here, is that
I am a very strict person when it comes to timelines and deadlines.

That is all about me I can think of right now. Proceeding to merit, I would like to
implement full scene serializing in Ogre. Why? Please let me explain.

Speaking the truth, I've never heard of Ogre before. I bumped on it browsing
Google Summer of Code mentor list. When I saw that it is an Open Source 3D engine
project I was very skeptical. I thought it were yet another project with
big pump start and quick death, due to no developers nor people
wanted to use it. But then I saw screenshots... That led me to demos, and then
I just loved it! I very like the idea it is not Linux specific and run also on
most popular platform. So I want to help. I browsed your things to do list
and picked scene serializing. Why?

Currently, as my masters project at University, I work on robust algorithm for
multi robot exploration. As a simulation environment we use simulation module of
Microsoft Robotics Studio. It is a very good 3D graphics engine with also
embedded physics. It keeps the scene state (like objects, objects properties,
lights, cameras and so on) in a single XML file. It is very useful, because you
can fire up an editor, build your scene using built-in or imported objects,
set up lights and all necessary parameters and simply save it to a file.
Because it is a XML file you can browse it and edit every object parameter,
like size and position by hand. Next you just simply start engine with this
state file as parameter and you end up with fully configured scene without even
single line of code!

I think this is a good mechanism and it will work great in Ogre.
Of course single XML files are good for a single scene and it should be
also a mechanism to pack many scene states in one place, so the game could simple
load all scenes by one time and create different scenes when necessary.

To make all simple I think of creating an interface, something like ISerializable,
which will ensure all classes (entities, light, etc) implementing it will serialize to XML
correctly. Then, just add Save() and Load() methods to SceneManager, which will
run through every object in the scene. Simple, isn't it?

So, you my ask why a person who never used Ogre and even didn't downloaded the
source code yet is right for the job? Well, to sum up:

* I've got a specific idea how to make it done
* I'm sufficiently skilled to do it
* I'm open for suggestions and advices
* My favorite development methodology is Agile, so you will hear from me
often and you could test and make comments instantly

I hope I've put enough necessary information, If you want anything else,
just email me at: mcinek@gmail.com.

Looking forward for your response!

With best regards,
Marcin Undak

PS. I wasn't sure if I should create new thread or continue, previous
http://www.ogre3d.org/forums/viewtopic.php?f=13&t=48984
but I decided to create new one, because this is another application and another approach.

[sinbad]

Thanks for the post & application - yes you did right by creating a new thread.

DotScene is an existing XML scene format used by some OGRE users, although it doesn't handle absolutely everything. While XML is great for readability and data interchange, for efficiency a binary format is far better at runtime. Typically with our other formats we offer a dual solution - binary for runtime, XML for interchange and debugging. This would be the kind of approach we'd be looking for here too. Any thoughts on that?

Also, the problem with the implementation you suggest is that it would require an XML library to be available in the core. We've avoided that in the past because it's an unnecessary overhead - the XML tools are entirely separate, meaning at runtime there is no (often large) XML library hanging around.

[Assaf Raman]

Can you you post some previous 3d work demos and code you have created?

[mcinek]

I'm sorry, I can't give you any recent source code, especially 3D graphics.
All programming I've been doing lately regards my commercial work or
very boring study projects.

However I've put something here:
http://cyborg-msrds.googlecode.com/file ... 20.tar.bz2

This is five years old C++ code, so forgive me if it won't compile with
new autoconf/automake. In this archive is a binary file (in ./src directory)
which runs on my computer. This project was my idea of creating my own, great 3d engine

I have also another, a bit newer version of this engine and a Sony PSP
emulator which ran Doom 1!. I'm not posting it, because it doesn't run
and I don't have time right now to fix this. If you want to take a look on the code,
let me know and I'll post it.

Back to the subject, I think it is a good idea to have both text and binary
data format for scenes. I'm not really familiar with current usability and
limitations of DotScene format. We can leave it as it is or extend.

What I think is important to have serialization code inside objects, it means
all objects should know how to serialize only itself and we don't have to create
robust algorithm and universal parser. We can implement two methods:
SerializeXML and SerializeBinary (and Deserialize of course) for every object we want to save.

Back to XML, personally I don't think this few megabytes in memory is too much overhead,
but here you propably have more experience. Remember that scene parameters
dont't include meshes, textures, and other memory consuming things,
so they could be loaded once at startup (or level loading) and kept for later use.

Best regards,
Marcin Undak