A 3D level editor

Started by
5 comments, last by Wacov 12 years, 3 months ago
I've spent the last month or so working on an MFC / DirectX 9 application which will allow the user to edit game levels in 3D - in my computing course, we basically get to decide what we want to do, and I thought this would be something interesting to try wink.gif

It's worth pointing out that I'm probably not going to use this to create a game... at least not during the course of my A-Level. If I was creating a game, it'd be an off-road racer (homage to motorstorm), so beyond basic object manipulation, that's where any new features would be aiming.


There's a lot of basic functionality working already - a renderer with per-pixel lighting and texturing, object insertion from .X files, a camera system, drag and drop object hierarchy, and most recently, save/load to a custom file format with embedded meshes and textures. I'm currently working on object picking, and I'm planning to add object transformation and material editing tools.

Current UI:
[attachment=5350:Level editor.png]


The ideas I've had so far (I won't be able to do all of them) are:
  • Basic terrain grid creation and editing tools with heightmap import/export
  • Road editor (would tie into terrain)
  • Improved renderer, with normal & specular mapping, maybe shadow mapping
  • Vehicle spawn placement
  • Sprites with billboarding (foliage and crowds) and spray tool
  • Multiple light sources as special objects

I'm looking for feedback on these ideas, as well as any new thoughts on tools, features and the UI (stuff you would want if you had to use this), but I'm new to both MFC and DirectX (and these forums!) so all advice is appreciated.
Advertisement
Nice job so far, especially for being new to both DirectX and MFC!

I would view the ability to add custom types as pretty crucial. If I were designing a level editor then I would provide a scripting language so that it can be easily customized... It would have been a bit cooler to see a program developed in something like QT or wxWidgets with an OpenGL based renderer that was cross platform... but this is cool too. I am not really crazy about the .X file format.

So my ideas would be:

1. Provide the ability to script plugins/importers/exporters
2. Make sure you can view the object from different perspectives at a time (split windows, ect).
3. Add a grid with customization options/snapping to the grid.

Really though the best way to really make sure this editor has the correct features is to use it to help create a game... Even using it to create a relatively simple game would do wonders for helping you focus on the crucial features.
Thanks for your input!

When you say 'custom types', do you mean custom object types? I actually save a 'type' byte with each object, it's just not used yet. I was thinking of having a dialog which allows the user to create and remove types, along with the type ID, then change which type an object uses through its properties pane. A game loading the object could then recognize the type ID and put the object to special use.

Having cross-platform support would be great, but I'd have no way to test it sad.gif
I have .X file import pretty much because my DirectX book explains how to do it... I'm O.K. with that for now, but if I provided a scripting interface for plugins, what language would be best? Everyone seems to use Python, but I've heard Lua is easier to embed...?

[color="#1C2837"]Make sure you can view the object from different perspectives at a time (split windows, ect).[/quote]
I can definitely give that a shot. Would DirectX viewports be a good way to do this?

[color="#1C2837"]Add a grid with customization options/snapping to the grid[/quote]
Never thought of that - I can see how it'd be useful, shouldn't be too hard to do either (that's always good biggrin.gif)
For the terain - it is quite simple:
1. Define a custom vertex format (in case you need multitexturing)
2. Create the terrain based on a grayscale map pixels' values (x, y, color[x,y].r *scaleFactor+ minZ)
3. Create the terrain designer to update vertices values based on heightmap changes ( u can define different pencils ttpes and so on...)
4. Make the material editor to be able to modify terrain layer's material.
5. Though, multitexturing must be done in HLSL or not ?
You can google for details about this tech, or we could give u some help.

Deferred shading could solve some of the problems with multiple lights, normal, specular, bump, shadow mapping but it will be complicated to work with semitransparent visuals or to do billboarding...
I've hit a little snag - I've got a transformation tool for objects working, at least for translation, but it gets very hard to use as you zoom out. I really need the size of the on-screen tool to remain the same no matter the distance from the camera, but I have no idea how this would be possible?

These pics show the problem:
[attachment=5760:editor problem.png]

Edit: Scaling everything based on the distance to the camera sort of works, but it's not perfect. Is there a better way? unsure.gif
Zoom problem:
Scaling the gizmo is not a bad idea, IMHO. If you don't care about occlusion (meaning that the gizmo is always drawn on top), maybe you could just translate the gizmo towards the camera, so that it will always be the same distance from the camera. Maybe that screws the perspective projection, I can't tell. Just an idea, I guess there are lots of ways to do it.

Back to the features:
Multi-level Undo/redo feature. Implement it before other manipulation features, because undo/redo with some kind of command stack will affect your whole program and how you program it in a pretty fundamental way. Multi-level Undo/redo is a must, and according to my experience, better to implement it as soon as possible, before you have too much stuff to refractor...
After a lot of hard work, I finally got translation, rotation and scaling all working nicely together. After looking at Crytek's Sandbox editor, I decided to always do translation along the global X,Y,Z axes, but rotation and scaling along each object's local axes.
The key to it was figuring out that I had separately store the matrices for each type of transformation, since they go weird (especially rotation and scaling) if you mix them in the wrong order. You end up with:

toWorld = localScale * localRot * localTranslate * GetParent()->GetToWorld()

I do this recursively, to make sure the children are also correctly updated after a change.

Also, I got the gizmo scaling properly: I just draw with no depth testing after everything else, using a ray/plane intersect to determine the distance to the object and doing a linear scale based on that. Oh yeah, and there's a toolbar and keyboard shortcuts for switching translation mode biggrin.png

[attachment=6562:Transform Cap.JPG]

I've also got materials working properly, with an Editor pane which can add new materials and edit existing ones, as well as allowing you to pick and paint materials in the viewport. Since MS were kind enough to add a color property for property grids, the basics of the editor were easy, but the cool part is the material preview. I did this with a miniature D3D renderer, which renders a sphere painted with the material to an off-screen surface, using my standard shader. I then copy this to a lockable surface, and use a DC to paint that to the Editor window.

Since the editor supports textures, I also decided to add spherical U/V mapping options, which pretty much let you arbitrarily texture anything the editor can load. Wooden car, anyone?

[attachment=6563:Materials.jpg]


Multi-level Undo/redo is a must, and according to my experience, better to implement it as soon as possible, before you have too much stuff to refractor...




I made the mistake of not including Undo/Redo support from the start, and I won't be able to add this till after the coursework is complete: right now, all my time goes into doing the write-up.

Still wanna do terrain too...

This topic is closed to new replies.

Advertisement