The process of making a level editor
Author
I have decided to help out my artists and develop some tools such as a level editor for my engine. Right now the workflow involves exporting chunks geometry data from blender then editing a text file to list the file address of each chunk and its position as well as the position of entities like monsters or lights. I was hoping to create a tool that would generate that file and let the artist move each chunk or entity and see the results graphically. I was wondering is the level editor usually using the same engine (mine is made in house) as the game itself or is it usually an original piece of software? Are there any universal editors than can be scripted to export to a custom map format? Also how does 3d selection work I would assume it involves ray-casting? Can someone point me in the right direction for making a level editor?
The editor will be a stand-alone project that links to and uses your actual in-house engine (meaning you need to add support for multiple views to it and remove its game loop if it has one built-in).
Valve Hammer Editor does not export in custom formats, but the .MAP/VMF files it exports are easy to parse and convert to something in-house, though it is unlikely to be suited for your purposes since it cannot load your terrain/models.
You will find that to be a common theme among all editors, so it is generally easier to make your own primitive editor and add it to over time.
3D selection does involve ray-casting. If that worries you, you may not be comfortable enough with 3D math to be able to complete a usable editor.
L. Spiro
Valve Hammer Editor does not export in custom formats, but the .MAP/VMF files it exports are easy to parse and convert to something in-house, though it is unlikely to be suited for your purposes since it cannot load your terrain/models.
You will find that to be a common theme among all editors, so it is generally easier to make your own primitive editor and add it to over time.
3D selection does involve ray-casting. If that worries you, you may not be comfortable enough with 3D math to be able to complete a usable editor.
L. Spiro
Author
3D selection does involve ray-casting. If that worries you, you may not be comfortable enough with 3D math to be able to complete a usable editor.
No. That doesn't worry me it's just I already use raycasting(provided by bullet physics) to check if my player can grab something among other things. I was just wondering if 3d selection worked the same way with a mouse as opposed to a rotating view. I was thinking just cast a ray from the mouse into the screen and select whatever the ray hits.
Have you considered custom properties? They work like a charm for me.
[attachment=11797:CustomProps.png]
Here's how my (hopefully) final workflow goes.
This way you still get the benefit of having an editor "almost ready to go".
Couldn't you encode this in collada directly? It's very likely but it's my understanding that AssImp won't load the data so I found another way.
Edit.
As a side note, make sure you write the custom props in the correct place. It is possible to put custom props pretty much everywhere. In nodes and materials for sure. I think meshes also have a custom prop capability but I'm not sure. Sure there are other places where custom props could be used but I'm not all that good with Blender.
[attachment=11797:CustomProps.png]
Here's how my (hopefully) final workflow goes.
- Level geometry is generated normally.
- Adding static meshes. The meshes are authored externally and imported. The basic mesh is annotated with a special customprop instructing the filter to alias those meshes.
- Adding other resources such as gameplay elements. They are similarly annotated.
- When done, export to collada.
- A python script in blender walks over the scene graph (it's basically a vector in blender) and pours out a nodename, properties set for each annotated node. It dumps everything to json.
- Filter loads the exported collada, short-circuiting parsing of anything having an allocation. Done.
This way you still get the benefit of having an editor "almost ready to go".
Couldn't you encode this in collada directly? It's very likely but it's my understanding that AssImp won't load the data so I found another way.
Edit.
As a side note, make sure you write the custom props in the correct place. It is possible to put custom props pretty much everywhere. In nodes and materials for sure. I think meshes also have a custom prop capability but I'm not sure. Sure there are other places where custom props could be used but I'm not all that good with Blender.
Just keep it as simple and practical as possible at the beginning. When I did a simple 3D level editor(simple as in 1 weeks work) I made sure It was a completely separate entity to my game. Therefore, the only thing I needed to do was to decide how I was going to store the data, so I could parse it accordingly when my game loads the level. It did however use alot of the code from my game, most notably the render and input code, with modifications to suit the editor;
Because I had such a short amount of time, I decided to limit the artists abilities to just translate,scale and rotate objects. I also decided to leave out the ability to add textures in the editor. I believe as a starting point, this is what you should aim to do.
You would have to make a decision as to whether or not you want to load the models from within the program dynamically, or to load them before hand. Clearly the dynamic option would be more use to the artist, as they wouldn't need you to dig around the code to load another model, but as a start, the pre-load method is adequate.
For ray-casting, you need to make sure you are only casting inside the "viewport" where your scene is being rendered. Otherwise, you will end up with a bogus cast because of the mouse position taking the entire window into account.
Because I had such a short amount of time, I decided to limit the artists abilities to just translate,scale and rotate objects. I also decided to leave out the ability to add textures in the editor. I believe as a starting point, this is what you should aim to do.
You would have to make a decision as to whether or not you want to load the models from within the program dynamically, or to load them before hand. Clearly the dynamic option would be more use to the artist, as they wouldn't need you to dig around the code to load another model, but as a start, the pre-load method is adequate.
For ray-casting, you need to make sure you are only casting inside the "viewport" where your scene is being rendered. Otherwise, you will end up with a bogus cast because of the mouse position taking the entire window into account.
(1) Just keep it as simple and practical as possible ... (2) It was a completely separate entity to my game .. (3) decide how I was going to store the data, so I could parse it accordingly ... (4) use alot of the code from my game, most notably the render and input code, with modifications to suit the editor;
Because I had such a short amount of time (5), I decided to limit the artists abilities (6) to just translate,scale and rotate objects. I also decided to leave out the ability to add textures in the editor.[/quote]
Sorry but I disagree on some of the concepts here and I need to point those out so people can properly relate to the efforts involved.
(4), (2) We could discuss that. There's a code dependancy.
(3) this is not future proof. How my code loads its own data is the last of my concerns. What concerns me is compatibility across other DCC tools as...
(6) telling artists "you must use my editor" and "you cannot do that" is pretty far from best practice.
(1), (5) If I'm in a hurry, I don't write a level editor. I bolt my features on pre-made programs. Took me two days to write the blender scripts, and a week to refit the whole asset workflow. And I can guarantee my feature set is pretty rich.
My first (and last) attempt at a "slick" 3D level editor is something around 2001-2004 I think. Words fail to describe how limited it was and how much effort it required. In the end, it was just easier to filter input from other programs (not to mention this is required anyway as there's a large availability of test data on the net).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
