I’d like you guys to list features that a level editors usually have, and especially the ones which 3d modeller plugins can’t provide. The only one thing I can think of is seeing your changes in realtime, but then again most level editors don’t have that feature.
Anyway, let me know what a usual level editor has.
The current Panda level editor doesn’t seem to run for me. Also, it seems to export Python script file, which I’m not sure is a good way of storing levels. egg files seem to support enough already, and if that wasn’t enough, a scene format would seem better than a Python script.
For me the primary feature would be to save the ‘level’ in a way that allows to load it afterwards (writing it all as an egg could work).
Apart from that:
Load and manipulate models
Scale, rotate, move centre point, bake transforms, tag/name geometry, add collision solids and mask, add/change textures and materials, generate tangent/binormals, optimize (delete unneeded vers and bones), changing vertex color and alpha, burning AO into vertex color or textures, octree for collisions.
2.Heightfield map
Either generating a mesh or painting a bitmap. Should support brushes (shape, size, ‘softness’) and loading external images (like from L3DT).
A terrain shader would be needed if it is to meet modern day demand. You should be able to paint textures, but a diffuse texture is not enough. Normal, gloss, glow or bust. 3 texture limit also seams a bit low for the XXI century.
But(!) it also should be possible to make a terrain for the fixed-function-pipeline, not everyone is making a next-gen game.
3.Tilebased support
Snap to grid movement of elements, welding overlapping vertices of adjacent tiles.
Other stuff
Navmesh generation, particle panel, animated billboard textures (like egg-texture-cards), mopaths, empty nodes (for waypoits etc), occluders/portals(?), lights setup.
Good LOD for both placed items and terrain. Automated update of models placed in map (have a source dir of model files, when they change, run what ever preprocessing is needed on them, then reimport to the map, and reexport map, or perhaps just places references to the models in the map file).
Its important to do all the model/material/collision processing in a way thats easily adaptable to people’s needs. My approach is a “model compiler” that imports all my various model formats, sets up custom material stuff, and export bam files, which are in turn loaded into the map generator which builds all my procedural stuff, and exports some more bam files. Bam files can contain LODs, and I use that heavily.
Eventually I plan to make per model config files that direct the model compiler to inject various effects (particle effects, lights, and some extra shader effects via tags my shader generator will use). My map editor will just make a simple object listing which can be “compiled” using the other “compiled” models to produce a usable bam (or set of bam tiles to lazily load with my tiling system).
Loading a map can be slow, so its good to get all possible preprocessing done and cached in a “compiled” map. This includes collision, binormals, flattening etc. I’m using a bam file for this, and aside from the lack of support for storing shader inputs, its working pretty well. I Dump the needed shader inputs into tags, and restore them when loading.
There’s a risk in using bam files. If there’s a version change you could end up with unuseable files. Can’t it be done with egg files and only turn them to bam when packing the app for the end user?
If you follow a compiler like design there is no risk there, just regenerate them when needed from the original models. I use bam files since they load fast, and I don’t have issues with some special settings getting saved properly. The egg versions are 100+MB in my case, and take forever to load/save. There is no reason to store generated files in a human readable or cross version compatible format. Thats just my editor design, you may find a better one.
But yes, you are right, don’t put anything that can’t be regenerated in a bam file, ever!