Turning Glue Editor into a level editor for Ogre

Update: 9 June 2012
I've released the pre-alpha version. Please download it from the blog and let me know what you think
http://www.craftworkgames.com/blog/the- ... a-release/


As some of you may already know I've been continuing the development of Glue Editor. Things are coming along nicely as the end of the first iteration approaches. I would like to share with everyone what I have planned for Glue Editor in the coming months and find out if I'm heading in the right direction. Your honest opinion is appreciated

Motivation
Building a game with Ogre or Mogre has never been an easy task. The Ogre graphics engine provides incredible rendering capabilities and great flexibility to build whatever type of game you can dream of. However, putting together a complete and finished game takes a considerable amount of programming effort "gluing" the graphics engine to physics, sound, GUI, networking and so on. Once all that's done the various art resources are created such as meshes, textures, sounds and collision shapes.

Many of these resources can be created with your favorite modelling program, paint program or sound generator. Yet, there's still something missing. Placing all of these resources together into a game could be hacked together in code and exported from modelling programs with a little blood and sweat but it never feels nearly as productive as it could be.

Intention
Glue Editor's primary purpose is to fill the missing gap. To provide a productive tool to piece together the various resources into levels for your Ogre game projects. Then to be able to save the levels into a file format easily loaded into your game containing the data to let the graphics, physics and sound engines to do what they do best. To help you provide the best interactive experience for your players in the shortest development cycle possible.

I'm developing Glue Editor using an "Agile" approach in my spare time in monthly iterations. At the start of each month I set some goals to achieve during the iteration focusing on what I can do to provide the most value towards the ultimate goal. The main goals of an iteration are called stories and are from the perspective of the user, for example: "As a user I want to be able to rotate objects so that I can make more natual looking scenes". Then these high level goals are broken down into smaller tasks, prioritised and picked off one by one. At the end of an iteration any half finished features are polished, removed or disabled to get the program ready for a release and/or the remaining work is rolled over into the next iteration.

Results
I've made some great progress this month, using the Agile approach and defining some clear goals have really helped focus on the important features and not get distracted by the less important stuff. The project has already come a long way from where I left it a few years ago. I had to pull it apart and put it back together to lay the foundation for new features so many things are still broken. The one question remains, what should I really put my blood and sweat into next interation?

It's very nice to see that you still work on your great looking tool.

Glue Editor saves the scene in a special XML format.
For easy usage it would be nice to have a Mogre loader class. (Maybe it's already avaliable.)
So in most easy case you just need to load the file (with the class) and its content will be loaded to Mogre. (create SceneNodes, attach meshes, load/apply materials, etc.)

Maybe try to embedd the Ogre Procedural Geometry Library for easy creation/embedding of some more complex object types. (e.g. create twisted pipes)
The library offers an API to apply modification chains (e.g. extruding steps). This is difficult for GUI integration. My idea: Glue Editor can create "blank" objects with a connection to a file (or a section in an XML or config file). There the user can write the wanted API calls. Inside of Glue Editor you would only apply position + rotation + scaling + textures + calling a "script editor" for the related section.
For Ogre script editing the editor Yaose seems to be useful. It offers syntax hightlighting and code completion. (I suppose currently there are no rules for the Ogre Procedural Geometry Library, but this could be added later by other users.)

There is a nice video about the CryEngine, created at the Games Developer Conference. Ok, 30 minutes is much time, but it shows interesting details of a great "professional" scene editor. I know, Glue Editor will never reach such a level, but maybe you are interested to see it. Maybe you will get some inspirations. I enjoyed to watch the video:
http://nvidia.fullviewmedia.com/gdc2012/03-crytek.html


For my application I can't use Glue Editor, because the Terrain Scene Manager is not supported.
It seems so that there are not many people using it anymore. Additionally it was removed in Ogre 1.8.
With TSM support it would be very interesting for my application, because you can create walls and don't need to worry about texture coordinates while scaling. (This Glue Editor feature is very sweet.) On the other hand I don't know if I have time to integrate it to my application. Currently I work on my diploma thesis and then my university study is finished. As consequence I will not continue the work on my scientific Mogre application. I will move to the city of my girl friend and work in an other engineering company. So don't focus to my TSM dreams.

Nevertheless I think terrain support could be useful for several users. In this case put your focus to the new Terrain Component. (instead of TSM)

I have no wishes. These are only ideas.

I forgot to tell an important point for the Ogre Procedural Geometry Library:

Currently it's only available for Ogre (C++).

The best would be to have a .NET wrapper. So further features (and bugfixes) can be used very easy.

An other solution would be to port the code. (For this it isn't needed to port everything to C#. It's enough to create a class with manages C++ from it, which connects to the Mogre API.)
The downside: It's much more difficult to maintain the code (related to changes in the original library).

A third way:
Glue Editor calls an external Ogre application (command-line based) to create a mesh from the "script code". Then load the generated mesh into the Glue Editor. Everything is controled from Glue Editor, although the API processing is done by a native Ogre C++ helper appliation.

Ok, maybe this is a too much time consuming task for Glue Editor. But it's an idea. (Perhaps somebody needs this library and helps in developing.)

Thanks for your kind comments Beauty


Glue Editor saves the scene in a special XML format.
For easy usage it would be nice to have a Mogre loader class. (Maybe it's already avaliable.)
So in most easy case you just need to load the file (with the class) and its content will be loaded to Mogre. (create SceneNodes, attach meshes, load/apply materials, etc.)
The current open source version of Glue Editor saves scenes in the dot scene format. As far as I'm aware there are already a number of implementations of the DotScene loader available on the wiki. The DotScene format is good for saving and loading scenes for Ogre but it's not particularly easy to adapt to a game engine that includes physics and sound, etc.

For these reasons, I'm currently working on improving the format and interface for saving and loading levels. In my new design I'm thinking about how I can provide an interface and implementation to allow users to load the levels into thier own games with minimum effort including physics and sound. There are a number of things to consider and I haven't worked out all the details yet but I'm open to ideas.

I would definitely like to support Terrain editing of some kind, constructive solid geometry for building rooms (like Valve Hammer and UnrealEd) and possibly procedural geometry. I'd also like to provide a plugin interface so that people can add to the editor with things I don't need or have time to implement.

The really hard question to answer is what I should be doing first. What is going to provide the most value to the most number of users with the end goal of making games. It's very easy to spend a lot of time implementing features that look cool but are hardly used. I've fallen into this trap before and I'm being careful not to do it again.

I was thinking the other day, perhaps it's a good idea to team up with people who are already building a game and seeing how I can gear the editor to help them. I think this would be a good way to put a priority on important features focused on the ultimate end goal of creating games. Do you know of any game projects going on at the moment that could use a level editor?

The current open source version of Glue Editor saves scenes in the dot scene format.
Oh, this suggestion I wrote long long time ago.
I think there are 2 DotScene importers for Mogre, which both have advantages and disadvantages.
Which way do you import the Glue scenes to your game?
If by DotScene - which importer you use?

I would definitely like to support Terrain editing of some kind
A first important step would be just to load terrain (without edit functionality). So people can create/modify terrain as they want (by generators or Ogitor). As second step the people can load the terrain in Glue Editor and add entities, sound, etc.
Editing on realtime is great, but needs more effort. Keep is as second step somewhere in the future.
Even terrain of "levels" can be edited after adding entities. It can be done by external tools. After this load the modified terrain in Glue Editor again. Well, it's not so nice to edit terrain, when you don't see entities, but it's a possibility.

Do you know Artifex Terra?
It's a fascinating Ogre scene editor, including terrain modification. It uses the Editable Terrain Manager for terrain.
The project website was dead for more than one year. All sources were gone. After asking Nauk (the author) more than one times, he re-published his editor. I also created the wiki page about it.
One month ago Nauk decided to continue his work on his great looking editor. Look to his post here.
Zarifus, I recommend to look to this editor, because you can get ideas for Glue Editor. Additionally you can look to his source code.
Additionally Nauk wants to publish (re-publish?) a converter for DotScene.

If the exchange format (DotScene) works well for both editors (without conflicts), it would be possible to combine the power of both. For example create terrain and modify it's texture in Artifex Terra. Then load the terrain to Glue Editor and add entities, sounds, etc. (or create entities like walls). If further terrain edits are needed, the scene including entities (without sound) can be saves to DotScene and loaded by Artifex Terra. You see all entities, which can be much better for specific terrain modifications. When you switch back to Glue Editor you just import the modified terrain. Not the whole exported/converted scene to avoid trouble (different settings, lost audio information, etc.)
The best would be when Artifex Terra supports the new Terrain Component of Ogre. Maybe Nauk will switch from ETM (Editable Terrain Manager) to the "official" Terrain Component, because will be (or already is) the new terrain standard solution. Also the accepted Google Summer of Code project Improve and Demo the Terrain System will increase the interest in the Terrain Component. An other accepted GSoC project is Volume Rendering with LOD aimed at terrain (Voxel technique).
So this could be good extra motivation for Artifex Terra to switch to the Terrain Component.

If you like, you can reply to Nauk in the Artifex Terra topic. Unfortunately there was not any feedback for his future plans until today. You could tell him the existence of Glue Editor. He could be interested in.


perhaps it's a good idea to team up with people who are already building a game and seeing how I can gear the editor to help them
My suggestion:
Publish your project in the Ogre showcase forum.
There are much more people than here in the Mogre forum.
Also native Ogre users (C++) can use Glue Editor, because it's independent of the target application. It's "just" an external modelling tool, which outputs can be loaded to every Ogre application.
But they need to know!


Question:
With Glue Editor you can create walls (including accurate texturing). How the results will be saved?
Do you create them by ManualObject and save them as mesh file?

Ok, enough for today. I have to stand up very early.

Which way do you import the Glue scenes to your game?
If by DotScene - which importer you use?
I find the DotScene format insufficient and cumbersome to use for games. What I currently have is a simple XML format that contains "MapNodes" with a Position, Orientation, Scale and a string property to indicate the "NodeType". I'm currently making improvements to it to handle the new features I'm adding to Glue Editor. Here's an example:


<?xml version="1.0" encoding="utf-8"?>
<GlueMap xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:xsd="http://www.w3.org/2001/XMLSchema">;
<Nodes>
<MapNode Name="barrel05_0" Type="barrel05" Position="-9 0 -2" Orientation="1 0 0 0" Scale="1 1 1" />
<MapNode Name="barrel05_1" Type="barrel05" Position="1 0 2" Orientation="1 0 0 0" Scale="1 1 1" />
<MapNode Name="barrel05_2" Type="barrel05" Position="-4 0 5" Orientation="1 0 0 0" Scale="1 1 1" />
<MapNode Name="barrel05_3" Type="barrel05" Position="-3 0 -2" Orientation="1 0 0 0" Scale="1 1 1" />
<MapNode Name="Light_4" Type="PointLight" Position="-4.987907 2.254517 2.037796" Orientation="1 0 0 0" Scale="1 1 1" />
</Nodes>
</GlueMap>


I'll be posting more information about this on my blog soon.

A first important step would be just to load terrain (without edit functionality). So people can create/modify terrain as they want (by generators or Ogitor). As second step the people can load the terrain in Glue Editor and add entities, sound, etc.
Editing on realtime is great, but needs more effort. Keep is as second step somewhere in the future.
Yes, I've had a quick go at loading the new Terrain and Paging component within the editor. Unfortunately it crashed and I haven't had time to get back to it yet.

Do you know Artifex Terra?
It's a fascinating Ogre scene editor, including terrain modification. It uses the Editable Terrain Manager for terrain.
I've heard of it but I've never used it. I will take a look when I get back to the Terrain job.


My suggestion:
Publish your project in the Ogre showcase forum.
There are much more people than here in the Mogre forum.
Also native Ogre users (C++) can use Glue Editor, because it's independent of the target application. It's "just" an external modelling tool, which outputs can be loaded to every Ogre application.
But they need to know!
I plan to do this when I have more of the improvements complete. At this stage the editor is not working and it would be a bad time to tell many people because they will be disappointed to find out it's not even close to being usable. I'm hoping I'll have something reasonably usable by the middle of May.

Question:
With Glue Editor you can create walls (including accurate texturing). How the results will be saved?
Do you create them by ManualObject and save them as mesh file?
The wall creation feature is only half complete too. It uses ManualObject to render them in the editor, but there's no direct tie to Ogre and they could be exported in any model format in theory. However, they certainly can't be included in a DotScene format directly and my current thinking is that it should be saved to a separate file so that "rooms" can be used in multiple levels. This is one of the features I'm most excited about, but it's also very difficult to implement.

Question:
With Glue Editor you can create walls (including accurate texturing). How the results will be saved?
Do you create them by ManualObject and save them as mesh file?
The wall creation feature is only half complete too. It uses ManualObject to render them in the editor, but there's no direct tie to Ogre and they could be exported in any model format in theory. However, they certainly can't be included in a DotScene format directly and my current thinking is that it should be saved to a separate file so that "rooms" can be used in multiple levels. This is one of the features I'm most excited about, but it's also very difficult to implement.
I've been thinking very carefully this week about what feature I'm going to focus my time and energy into and I've decided to do the wall creation feature. There are a number of reasons for this decision:
1. It's the feature that is most important for my game.
2. No other scene editors compatible with Ogre projects have this feature as far as I know.

I think this feature will provide the most value to the Ogre community. Focusing on this feature means I won't be able to put my time and energy into other features like Terrain, but there are already a number of other Ogre editors with Terrain support. I find a get a lot more work done when I focus on a single feature at a time and the quality goes up. I've given a lot of thought to this decision and I hope everyone will understand and won't be disappointed that I don't have time to implement every feature suggestion. Rather than trying to commit to implementing many features I'm going to commit to implementing this one feature first and revisit the other requests once the wall creation feature is complete.

I think it's a good decision to focus on one single feature.

From my own project I know that it can cause trouble to work on several features at the same time. Especially time management will be problematic. And when there are problems you read here and there, try out something and at the end of a day (or week or month) the head is blown up.

I think it's a good decision to focus on one single feature.

From my own project I know that it can cause trouble to work on several features at the same time. Especially time management will be problematic. And when there are problems you read here and there, try out something and at the end of a day (or week or month) the head is blown up.

sorry ot

you can work on multiple features but you should branch your project for the features. it comes down to how you handle your source control.

e.g.
Trunk - Contains all completed features / version used for bug fixing
New Feature 1 - Branch of trunk that is merged back when the feature is completed
New Feature 2 - Branch of trunk that is merged back when the feature is completed

you can work on multiple features but you should branch your project for the features. it comes down to how you handle your source control.
I know it's *possible* to work on multiple features at the same time. I just find it really distracting with my limited spare time to work on the project.

I am waiting for a binary file. I think I will be fine.

I am waiting for a binary file. I think I will be fine.
It's good to know at least one person is waiting for a release but if I release a binary file now it will be buggy and broken and probably won't do what you want.

Not in a hurry. I'll wait.

The current open source version of Glue Editor saves scenes in the dot scene format. As far as I'm aware there are already a number of implementations of the DotScene loader available on the wiki. The DotScene format is good for saving and loading scenes for Ogre but it's not particularly easy to adapt to a game engine that includes physics and sound, etc.


though I had replied to this already seems I didn't :S

The scene format is just the basic information needed for ogre to load the scene but the idea is you add custom attributes/nodes for physics and sounds or game related information like triggers. Blender currently exports this information and some loaders give you a userdata section to access the other info

But to be honest I always make my own loading/saving code and don't use it

The scene format is just the basic information needed for ogre to load the scene but the idea is you add custom attributes/nodes for physics and sounds or game related information like triggers. Blender currently exports this information and some loaders give you a userdata section to access the other info
I've fleshed out the design for a scene import / export plugin system so there should be no reason not to support the DotScene format this way. However, I can't use DotScene to save all the other data that the editor needs (or maybe I could but it would be very painful) so the primary format will be something a bit more custom.

At some point, when I have time, I'd like to do some example plugins and tutorials. Perhaps the DotScene format would be a good starting point for this. Ultimately though, the main motiviation would be if someone actually uses the format in thier game and wants to use the editor for creating levels.

But to be honest I always make my own loading/saving code and don't use it
Yeah, me too. Are you working on a game? I'd be interested to know what other suggestions you have regarding the file format and how you'd go about making loading / saving easier.

Well I'm not working on anything at the moment I still have spinal problems, I'm back at the neurosurgeons next week to see if I need an operation.

Now I have 2 ways I approach storage Memory Aligned and Serialized.

Memory Aligned (Fast)

Basically a structure that can be loaded straight from disk into a structure with no parsing, I believe the ogre mesh format does this.

The reason to do this is optimal loading speed you simply can't get any faster. Well with one exception sometimes its better to compress the data if the storage is slow and the cpu is fast as the load time can drop a lot. Example reading from disc medias.

I developed a world format years ago which loaded terrain chunks (huge world) and scene and it took milliseconds to load what actually slowed it all down was the texture loading and meshes.

Serialized (Slow)

I use serialized data when the format needs to be flexible and keep storage down. This is always based on an object model and serialized to and from that (I believe you are probably doing this).

I never use XML with serialized objects normally I use binary. Only time I do is for config files or if I need to possible edit the contents my self.

I don't use the internal serializer in .net either I use this one http://www.sharpserializer.com/en/index.html it performs a lot better loading and size of the data is a lot smaller

These days I am primarily in c# hence the .net only serializer.

Now making loading / saving easier it has to be using a serialized model its the simplest to maintain overall

I don't use the internal serializer in .net either I use this one http://www.sharpserializer.com/en/index.html it performs a lot better loading and size of the data is a lot smaller
Wow, thanks for letting me know about this. I've never been a big fan of the .NET serializer but I didn't really know of anything better. The current task on my todo list is saving and loading the geometry of the level so I'm going to take a look at this now

just posting to say that I'm also looking forward to this, as my current "map editor" is 3ds max and editing text files, which is okay for placing stuff but makes later changes really difficult

just posting to say that I'm also looking forward to this, as my current "map editor" is 3ds max and editing text files, which is okay for placing stuff but makes later changes really difficult
Thanks. It's always good to know someone is looking forward too it.

I'm trying to get to an alpha release out soon but I've ran into a couple of problems. Firstly, the editor won't do much without saving and loading so I've made that my top priority. It was almost working but I had to do a big refactor and broke a few other core features in the process.

Secondly, my wife and I have just had a new baby. This is great news for us but it throws my normal routine a bit out of wack and it's hard to know when I have time to work on the editor. I'm still getting heaps done since I'm also on holidays from my day job. It's little chunks of work at random times though, so it can be a bit chaotic.

Secondly, my wife and I have just had a new baby.

Congratulations, hope they start sleeping through soon, I know how it is got a 2 year old and a 10 month my self

I've released the pre-alpha version. Please download it from the blog and let me know what you think
http://www.craftworkgames.com/blog/the- ... a-release/