The Dawn of the level editor

[AndyCR]

The original design for the RF2 level editor very closely resembled RFEditPro. It would have CSG operations and would be primarily generated geometry with meshes for decorations. It would be a native-ish Windows application (wxWidgets or Qt) which embedded the engine inside the 3D view and possibly the 2D views. Scenes would use a combination of lightmapping and dynamic lighting.

No work really ever got done on the level editor; it simply wasn't needed yet. I started on an editor in Qt with Ogre and a custom widget to embed it, but due to licensing concerns we found ourselves in a bit of a bind. Paradox and I then had two choices: switch back to wxWidgets for the tools, or do them entirely ingame.

It's now more or less a foregone conclusion that RF2's editor will be more a scene editor than a level editor, at least at first. CSG and lightmapping are too time-consuming to implement unless we know we absolutely need them, and often times modern games do not need either.

It was Paradox's idea to create an ingame level editor. It certainly isn't a new idea, but I was completely against it. I had been wishing for an UnrealEd-style application for RF2, with everything integrated into a nice, native application.

I couldn't really quantify what made me so hesitant, though. I decided to give it a try. The editor would be written in such a way that it could be compiled out with a simple compile flag for a version of RF2 used for a released game.

An ingame editor requires an ingame GUI, and as such we need an Ogre GUI library. I have tried many of them, and fail to find one that is satisfactory. One main problem is that none are geared towards tools; all are geared towards games, and as such lack support for the things tools need.

CEGUI is fast, but lacking. It has no toolbar, and it is even difficult to get buttons to display images on them for a fake toolbar. The skins are extremely difficult to make and manage, and doing things like displaying a game material on a control (for a material browser, for instance) are nearly impossible. Programming for it is a rather bland task, but it's easier than some things.

QuickGUI is nice, because it uses Ogre overlays to render everything and can easily tie in with the Ogre features we need it to tie into. QuickGUI is also not nice for the very same reason. Ogre overlays are fine for simple things like game HUDs but are extremely slow for complex GUIs. Even their sample program runs quite slowly on a very modern machine with only about 20 widgets visible. On Linux, mouse clicks and hovers don't work quite properly, and it would be worth fixing that and using it if it weren't for the speed issue.

Navi is not bad, but lacks flexibility in some areas and would constrain us only to Windows, which we have been very careful to avoid. Right now RF2 runs unmodified on Windows and Linux, and I imagine it would run with about an hour's tweaking on OS X as well. I would prefer to keep it that way.

MyGUI is unstable, to put it simply. I cannot elaborate too much on this since I did not try it, but Paradox implemented it in RF2 a while back and took it back out rather quickly due to all the issues it had.

None of the above options are very ideal for a complex application such as a level editor. Incidentally, some code was just released for Ogre today which solves these issues - it is fast, looks good, and... is completely and utterly barebones. http://www.ogre3d.org/phpBB2/viewtopic.php?t=41365 If we chose to use it, it would solve the above problems but add development time to create a GUI library around it.

Even if the perfect GUI library existed which did all these things correctly, we would still lack things like color pickers, file dialogs, and so on which would eat up a very large amount of development time. It could take months to get everything working perfectly under those conditions.

So we come to a fork in the road. On the left is wxWidgets, embedding Ogre into a wxWidgets editor and using the platform's native controls to create an editor much more quickly than the above option. On the right is a great deal of extra work finally resulting in a very dynamic editor which is simply a button press away while playing your game.

There is, however, a third road; one which I had not thought of. Instead of bringing the editor to RF2, we could bring RF2 to the editor.

If we embedded RF2 into the editor, we might achieve the best of both worlds. We would be able to take advantage of the controls already in the OS as well as the ingame aspects it would bring. We could do this by splitting the meat of RF2 into a DLL and calling that DLL from both the shell and the editor, or by having the editor be inside RF2, by creating a window and then feeding it to wxWidgets instead of vice-versa.

I have done some prototypes, but no work on what will likely be the final editor has been done. I know how it has to work, I know how the level format has to look, but as always the design decisions are what are worth tripping over.

I'm simply not sure where to go at this point. All roads lead to a usable editor, but which is the right one?

[ArKanuS]

So we come to a fork in the road. On the left is wxWidgets, embedding Ogre into a wxWidgets editor and using the platform's native controls to create an editor much more quickly than the above option.

On the right is a great deal of extra work finally resulting in a very dynamic editor which is simply a button press away while playing your game.

There is, however, a third road; one which I had not thought of. Instead of bringing the editor to RF2, we could bring RF2 to the editor.

Ok The 1st road would this be like using Ogre's level editor?
2nd: This is edit-in game? (not much accuracy can be done, such as exact edge matching, unless in like a no-clip view...)
3rd road I do no understand. Would the editor itself become the actual engine/builder for the game? If so, this can be great, with an in-built tab for script editing built in, a tab for actor converting, etc.!

I vote the 3rd road, if it is a correct image. Be sure to build in a no-clip level test.

[AndyCR]

I don't know what you mean by "Ogre's level editor", but the first road would be like RFEditPro if RFEditPro used OpenGL or Direct3D for it's viewports. The second option is edit ingame, yes, and accuracy can be made up by showing the mouse cursor, having modeling program-style move/scale/rotate widgets, and having a "noclip" camera. Option 3 is like editing ingame except with wxWidgets for the interface rather than an ingame interface (picture RF embedded in the RFEditPro 3D viewport).

[Jay]

I am completely for way number 3. Putting most stuff of RF2 into a DLL (even if it is also possible to extract functions from EXE files like from DLL files) also gives us the flexibility to develop derived projects that are standalone from the editor without much effort. Also, it makes it VERY easy to make the WYSISWG (What-You-See-Is-What-You-Get) Editor we want. And then you just press a switch like 'start simulation' and the game begins inside the editor. So it's the game inside of the editor, not the editor inside of the game, lol.

[Danimita92]

As long as you can see the level in a simple 3d view and the other 2D views like in RFedit and practically every 3D designing software, I'd like it. If it's programming the level without actually seeing it untill you try the level, I'ts just not worth it.

[AndyCR]

As long as you can see the level in a simple 3d view and the other 2D views like in RFedit and practically every 3D designing software, I'd like it. If it's programming the level without actually seeing it untill you try the level, I'ts just not worth it.

Yes, it will certainly support viewing the level during editing. I am not entirely certain about whether there will be 4 viewports, only one, or a configurable setup allowing either - it's certainly possible to have 4 with Ogre SVN at the very least since the Ogre lead develop did a program with 4 viewports, and perhaps with the stable version as well. I'll probably begin testing with 1, since I don't see much need for 4 anymore.

[scott]

user defind is the best way to go, IrrEdit has the best way in my opinion, it creates a viewport by a menu/ button then you can change that view port to any type you want, 3D, top, left and best of all, you can have multiple 3D windows, see the same area from different angels and updates in real time in all viewports, this is an awsome feature, but yea my opinion is user defined multiple windows

[bernie]

Yes I'm with scott on this one. User defined multilple windows is the best way in my opinion.

[AndyCR]

Ok. I'll probably set up one viewport for my own testing purposes, but adding more shouldn't be too difficult, assuming Ogre doesn't have the same multiple viewports bugs some engines have (and I assume it doesn't, since the editor Sinbad made has multiple viewports).

[AndyCR]

I'm starting the process of splitting the meat of RF2 into a DLL. Once this is complete, I can go back into the shell and make it just call the DLL I am writing. Once that is complete I can start on the level editor.

[jonas]

Awesome! I'm really looking forward to playing around with this in the future.

[AndyCR]

Well, it's split into two binaries now - RF2Shell and RF2DLL. I haven't committed it yet, though, and I need to take some of the functionality out of the dll and put it into the shell before I can use it in the level editor as I want to (the setup script shouldn't be called in the case of the level editor, since the resolution is dictated by the viewport size, etc.).

[AndyCR]

For those who are building and using RF2 from SVN source (all 2 or so of you ), some changes are coming. trunk/realityfactory2-old is going away (we don't need it anymore and it's in revision history for the odd case that we do). Most of trunk/realityfactory2 is being split off into trunk/realityfactory2-dll. The shell is going into trunk/realityfactory2-shell, which obviously uses the DLL. The editor, when started, will go into something like trunk/realityfactory2-editor, trunk/dawn, etc. A special folder called trunk/realityfactory2 is what all of the above will actually build into and what also contains the VC++ solution file (under a /build folder for cleanliness); the rf2-dll project will build trunk/realityfactory2/realityfactory2.dll, the rf2-shell project will build trunk/realityfactory2/realityfactory2.exe, the rf2-editor project will build trunk/realityfactory2/tools/editor.exe, and so on. Samples will be created and placed in trunk/realityfactory2/scripts, and sample media will be under source control somewhere under the trunk/realityfactory2 folder as well. I think this will be the best way to do things - each project gets it's own folder but they all build together into the same folder in the end.

[AndyCR]

Very little progress has been made; I went out of town on Tuesday and just got back. I didn't get a chance to work on RF2 during the trip.

[ardentcrest]

Didnt notice you were gone

Andy start your coding.....