Glue Editor: Map editor in Ogre

[Zonder]

If your going to have an export system then the editor native format can be xml? The internal .NET serializer is quite fast.

I wrote a binary serializer at work based on reflection and the xml one was still better. This was needed for silverlight and .net so we couldn't use the standard ones

So if you are using an object model at the moment in the editor it will put saving/loading off the list quickly

Here's the code in VB the company I work for uses a mix

Code: Select all

	Function Object_GetXML(ByVal Obj As Object) As String
		Dim objWriter As New System.IO.StringWriter
		Dim objXML As New System.Xml.Serialization.XmlSerializer(Obj.GetType)
		objXML.Serialize(objWriter, Obj)
		Return objWriter.ToString
	End Function

	<System.Diagnostics.DebuggerNonUserCode()> Function Object_Create(ByVal XML As String, ByVal Type As System.Type) As Object
		Dim objReader As New System.IO.StringReader(XML)
		Dim objXML As New System.Xml.Serialization.XmlSerializer(Type)
		Dim objResult As Object
		objResult = objXML.Deserialize(objReader)
		Return objResult
	End Function

[Beauty]

Here's the code in VB the company I work for uses a mix

I converted the last snippet to C# by an online converter. This is more easy to read

Code: Select all

public string Object_GetXML(object Obj)
{
	System.IO.StringWriter objWriter = new System.IO.StringWriter();
	System.Xml.Serialization.XmlSerializer objXML = new System.Xml.Serialization.XmlSerializer(Obj.GetType());
	objXML.Serialize(objWriter, Obj);
	return objWriter.ToString();
}

[System.Diagnostics.DebuggerNonUserCode()]
public object Object_Create(string XML, System.Type Type)
{
	System.IO.StringReader objReader = new System.IO.StringReader(XML);
	System.Xml.Serialization.XmlSerializer objXML = new System.Xml.Serialization.XmlSerializer(Type);
	object objResult = null;
	objResult = objXML.Deserialize(objReader);
	return objResult;
}

[Beauty]

If you also want to add complete models, you also can add binary information to a tag.
Or put your own data format into a tag.


For example a vertex list:

In pure XML it could be this:

Code: Select all

<vertexList>
  <vertex>
    <x>0</x>
    <y>0</y>
    <z>0</z>
  </vertex>
  <vertex>
    <x>1</x>
    <y>1</y>
    <z>1</z>
  </vertex>
  <vertex>
    <x>2</x>
    <y>2</y>
    <z>2</z>
  </vertex>
  <vertex>
    <x>0.75</x>
    <y>2.2</y>
    <z>1000</z>
  </vertex>
</vertexList>

Instead you could add this list to your own format:
Comma seperator for X,Y,Z and pipe seperator between each vertex.

Code: Select all

<vertexList>0,0,0|1,1,1|2,2,2|0.75,2.2,1000</vertexList>

This could downsize the XML file and maybe increasing the parsing time.
But you have to implement coding/encoding methods.
Ok, for my vertex list example this could be easy when you use Regular Expressions. (I really like Reg Ex very much!)

By the way - loading and saving a scene will be done only once or a few times. Not at render time.
So if this would take some seconds this shouldn't be a big pain.

[Xypher]

Doesn't that kind of defeat the purpose of XML?
Wouldn't you want to do something like...

Code: Select all

<VertexList>
    <Vertex X="0.2" Y="0.6" Z="0.8" />
    <!--> ... More Vertex Elements ...
</VertexList>

[Beauty]

Oh right, there are also tag properties! Good hint.
I forgot them, because in my current project I just use the "automatic" serialization method of .NET ("copy whole class content to a file") which doesn't use the property feature.
The property way I would prefere instead of binary coding.

[jacmoe]

Consider making a CAMPing trip...

<edit>
Especially using this -> http://dev.tegesoft.com/projects/camp/wiki/Camp_xml

[zarfius]

Wow.. some really great feedback this morning

If your going to have an export system then the editor native format can be xml?

I slept on the idea and now I'm sold. I'm going to make the native format for the editor XML and let the exporters do the work of binary output for the game.

The internal .NET serializer is quite fast. I wrote a binary serializer at work based on reflection and the xml one was still better

By the way - loading and saving a scene will be done only once or a few times. Not at render time. So if this would take some seconds this shouldn't be a big pain.

Yep. For the purpose of loading and saving the world in the editor the .NET XML libraries should do the job just fine. However, due to some of the complexities of integrating Ogre and PhysX into the editor it's not going to be as simple as using the .NET serialiser. Way back in the early days of the editor I did have this partially implemented and a learned a few lessons.

Instead you could add this list to your own format: Comma seperator for X,Y,Z and pipe seperator between each vertex.

Code: Select all

<vertexList>0,0,0|1,1,1|2,2,2|0.75,2.2,1000</vertexList>

Doesn't that kind of defeat the purpose of XML? Wouldn't you want to do something like...

Code: Select all

<Vertex X="0.2" Y="0.6" Z="0.8" />

I like both of these suggestions to some degree. Since I won't be using serialization I think the properties would be the way to go. To make implementation a bit simpler though, remember that Ogre already has some string converters built in for it's types.

So for example the simplest way to read a Vector3 from a string is like this:

Code: Select all

string input = "1 2 3.1415";
Vector3 vector3 = Mogre.StringConverter.ParseVector3(input);

With this in mind it would be better to keep values in the XML code space delimited to avoid extra code extracting the individual X, Y and Z values out. So maybe the XML could look something like this:

Code: Select all

<VertexList>
    <Vertex position="10 20 30" colour="1 1 1 0.5"  normal="0 1 0" textureCoord="0.0 0.1" />
</VertexList>

Consider making a CAMPing trip...

Wow. XML serialization for C++. I was looking for something like that in a past project. For the editor project though I don't think it will be needed. Perhaps for writing a C++ loader that people can use in their own C++ game projects, after all not many people are going to be using C# for implementing their game engine like me

[Zonder]

Yep. For the purpose of loading and saving the world in the editor the .NET XML libraries should do the job just fine. However, due to some of the complexities of integrating Ogre and PhysX into the editor it's not going to be as simple as using the .NET serialiser. Way back in the early days of the editor I did have this partially implemented and a learned a few lessons.

what were the problems you were having with physx and serialization in .net since once it's a native type it shouldn't be an issue or you wrap the information in a property and update the native type?

[Xypher]

If there's any way to ease plugin design as well, that would be awesome. Perhaps a plugin Type enum of some kind, like...

Code: Select all

enum PluginType
{
  PLUGTYPE_INVALID = 0,  //Unable to determine plugin type, can not load [PLUGIN NAME] 
  PLUGTYPE_IMPORTER = 1, //This plugin imports from specific file types
  PLUGTYPE_EXPORTER = 2,  //This plugin exports to specific file types
  PLUGTYPE_OBJECTTYPES = 4,  //This plugin defines new object types
  PLUGTYPE_PHYSICSINTERFACE = 8,  //This plugin defines a physics interface
  PLUGTYPE_AUDIOINTERFACE = 16,  //This plugin defines an audio interface
}

If you get my drift? of course that may not be necessary if you define plugins as having an accessable class constructor method, so the inherent classes within cross the DLL barrier, like Ogre plugins do.

Just thought it was pertinent to bring up.

Also, I know Irrklang is easy to work with, but its fairly featureless. I would suggest switching to FMODex if possible. They have a Geometry occlusion library integrated! I may be able to help with this.

[zarfius]

what were the problems you were having with physx and serialization in .net since once it's a native type it shouldn't be an issue or you wrap the information in a property and update the native type?

It's not so much that Ogre and PhysX objects can't be serialised. It's just that there's limited access to the underlying classes to customise what gets serialised and what doesn't. To be honest it could have been more to do with my initial design than anything else. I haven't really looked into it for a while.

If there's any way to ease plugin design as well, that would be awesome.

There hasn't been any work started on plugin design as yet so any idea's are welcome. As far as I know implementing plugins in .NET is pretty easy using interfaces and creating your own DLL project. The main changes to the editor will probably be the interfaces to expose access to existing functionality / data and plugin loading.

Also, I know Irrklang is easy to work with, but its fairly featureless. I would suggest switching to FMODex if possible. They have a Geometry occlusion library integrated! I may be able to help with this.

Yeh, I only chose IrrKlang because it was easy to get up and running in C#. Apart from some initial prototyping I haven't done a lot in the sound department so changing to a different API shouldn't be hard. The main issues to consider is that it needs to be compatible with the open source license of the editor and doesn't force people to use it in there own work.

The idea is to let people place sounds around the world and attach sounds to the objects then they can load this data into there own game engine. The sound API of the editor doesn't have to be the same as the one in their own game engine.

[Xypher]

FMODex is free for noncommercial use, and if it were used in the editor you'd be able to get a much better feel for what it sounds like in a particular area with that occlusion, reverb effects, etc.

[zarfius]

FMODex is free for noncommercial use, and if it were used in the editor you'd be able to get a much better feel for what it sounds like in a particular area with that occlusion, reverb effects, etc.

Your welcome to have a go at putting it in. Does it have a stable C# wrapper already?

We could always implement different sound / physics engines as plugin's to the editor in future but for now I'd rather focus on getting something working. My motto is keep it simple and implement what you need when you need it.

[Jabberwocky]

My motto is keep it simple and implement what you need when you need it.

Ahh, the motto of someone who might actually finish an editor. There have been so many over the years that didn't quite make it.

While I'm currently an Ogitor convert (landscapes are my biggest issue, and I'm very pleased with its usability already), an indoor editor will surely find great use in many projects.

As someone who has integrated several external editors into my project (Ogitor, 3dsmax/OgreMax, and a some others previously), I just want to encourage the data-driven approach you're taking. To me, the key things are:
1- Let me import meshes into the editor
2- Give me a good editing workflow for positioning, aligning, and snapping meshes together
3- Let me place point lights with configurable range and colour
4- Let me define custom properties on an object, like your spawn point example.
5- Let me export everything into xml, and take it from there. Custom exporters are nice, but that can also be done by the end-user via a project-specific post-processing tool that reads your xml format and converts it into whatever format (binary, xml, whatever) I need.

#2 is key, and where, from an end-user standpoint, I'd recommend focusing your efforts.
Some key features (most already mentioned above) are:
- good movement and camera controls
- good mesh selection
- undo
- snap-to-grid with customizable grid spacing
- group select and group rotate/translate
- a speedy clone mesh shortcut
- an easy way to reuse a set of properties, so I don't have to re-enter all the properties on each object as I place them.
- keyboard shortcuts for common operations like select, move, and rotate. Bonus points for making them configurable - a text keyboard_options.ini file is fine.

Good luck!

[zarfius]

Thank you for your excellent post Jabberwocky. This is a perfect example of the kind of feedback that drives development in the right direction. The most important goal here is to build an editor that helps people achieve the end goal of creating levels for use in games. If we can't do that all the fancy features in the world won't help.

With that thought in mind, I'd like to propose a task that everyone can do to help. Take a look at a map from one of your favourite games and try to figure out how you would go about creating it. What you'll find is that some of the tasks can't be done with the editor yet and others can be done with workarounds but could be made easier. From there we can build a feature list and prioritise it.

[Xypher]

To build on that Idea, perhaps I'm just a fan of configurability, however if the controls were easily configurable and saveable in XML that would also be very nice. I've had to learn a few editors that had much less than desirable key configurations (Cough, blender, cough)...

[Beauty]

I created a wiki page for this editor.
http://www.ogre3d.org/tikiwiki/tiki-ind ... lue+Editor

It would be great when somebody adds details.

Also one or more screenshots would be nice.
How to add images you can read here:
http://www.ogre3d.org/tikiwiki/Help+-+Images

More help you find in the wiki menu at "Ogre Wiki Help".


Also I added to the wiki page DCC Tools.
Additionally it would be good to add it to the OGRE DCC Tools page.

[Beauty]

I contacted the author of the editor Ogre Studio. The development stopped in 2007. The download links were dead. But not I got an answer where to find the latest source code (on a sourceforge account). The wiki page I updated.
http://www.ogre3d.org/tikiwiki/OGRE+Studio

It's in C# and the latest version was using Mogre. (Not OgreDotNet like older versions of Ogre Studio.)
In the downloadable file is everything what's needed to compile (the author said).
Also the media files (in core/VisualOgreCore/bin/debug/media)

Maybe you can use some parts of its components or code snippets.
For example dotScene support (if you plan to embedd it some day).

http://sourceforge.net/projects/visualogrecore/files

[zarfius]

I created a wiki page for this editor.

Thanks Beauty. I'll fill in some details soon and the editor is just about ready for another test release.

This weekend however, I am getting married So I'm very busy and won't have much time to work on it until everything settles down. I'll be checking and replying to the forums because that's how much this project means to me

[Xypher]

Do NOT check the forums on your honeymoon, repeat do NOT check the forums on your honeymoon! Just...don't do it! Don't want that to be a REALLY short marriage do you? Congrats!

[Beauty]

Forget Ogre for a few days!
Look for your girl (or boy) - your own wedding isn't so often available in your life

[zarfius]

Do NOT check the forums on your honeymoon

Forget Ogre for a few days!

Don't panic I may be crazy but I'm not stupid. I won't be checking the forums on the wedding day or the honeymoon. I just wanted to let you know what's happening and how important this project is to me. We already have a kid and own a house together so the marriage is only a formality really. Life will be back to normal in 3 or 4 days anyway. Thanks for the best wishes though.

[jacmoe]

Congratulations!

[Xypher]

Finally snagged the source and deps, for some reason it crashes while trying to initialize:

System.TypeInitializationException was unhandled
Message=The type initializer for 'GlueEditor.Core.Editor' threw an exception.
Source=GlueEditor
TypeName=GlueEditor.Core.Editor
StackTrace:
at GlueEditor.Core.Editor.Update(Single deltaTime)
at GlueEditor.Forms.MainForm.renderTimer_Tick(Object sender, EventArgs e) in G:\Projects\Programming\SVN\glueengine\GlueEditor\Forms\MainForm.cs:line 81
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.SafeNativeMethods.MessageBox(HandleRef hWnd, String text, String caption, Int32 type)
at System.Windows.Forms.MessageBox.ShowCore(IWin32Window owner, String text, String caption, MessageBoxButtons buttons, MessageBoxIcon icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options, Boolean showHelp)
at System.Windows.Forms.MessageBox.Show(String text)
at GlueEditor.Forms.MainForm..ctor() in G:\Projects\Programming\SVN\glueengine\GlueEditor\Forms\MainForm.cs:line 41
at GlueEditor.Program.Main() in G:\Projects\Programming\SVN\glueengine\GlueEditor\Program.cs:line 20
InnerException: System.IO.FileNotFoundException
Message=The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Source=GlueEditor
StackTrace:
at GlueEditor.Core.Editor..cctor()
InnerException:

[zarfius]

Code: Select all

InnerException: System.IO.FileNotFoundException

The inner exception seems to indicate that it can't find a file. Probably one of the dependancies. You may be missing a DLL or perhaps the executable is compiling to a different directory. This can be tricky to debug because the exception doesn't provide a lot of information.

I'll upload a new dependancies file shortly because a lot has changed since the last binary update.

[zarfius]

Okay. I've prepared a new binary release in the downloads section of the google code website.

http://code.google.com/p/glueengine/downloads/list

If your having trouble with dependancies the easiest way is to extract the download into the Bin folder of the project and make sure that your executable is compiling to the same folder. This should be the case if your using the project settings that should be on SVN.

There's still an incredible amount to do before the editor is really usable but it's getting there. One of the more interesting features I've recently implemented is being able to preview your level by pressing the play button.