[WIP] Level Editor

I just checked in WIP version of Level Editor codes under direct/src/leveleditor.

To run the sample editor, type
from direct.leveleditor import LevelEditorStart

To add an object to the scene, drag and drop from ObjectPalette tree to the 3D view.

To select an object in the scene, either click or draw marquee using left mouse button.

To manipulate objects, press ‘v’ key to show widget while selecting the object. You can change widget size by pressing ‘,’ or ‘.’. (Hotkey editor will be implemented later)

To delete an object, press ‘delete’ key while selecting the object.

To move camera, press ‘alt’ key and press left mouse button for rotating, middle mouse button for panning, right mouse button for dolly (same as Maya’s camera control)

To use this Level Editor in your game, you need to create your own ObjectPalette.py inheriting from ObjectPaletteBase.py, your own ObjectHandler.py and LevelEditor.py.
Refer comments in sample files for guide.

ObjectGlobals.py : contains constants
ObjectPaletteBase.py : Base class to define ObjectPalette
ObjectPalette.py : Sample ObjectPalette
ObjectHandler.py : Sample ObjectHandler

ObjectMgr.py : manages objects in the scene
FileMgr.py : manages data files

ViewPort.py : stole from pro-rsoft’s code with permission :slight_smile:
LevelEditorUI.py : main UI
ObjectPaletteUI.py : UI for ObjectPalette
ObjectPropertyUI.py : UI for objects’ property control

LevelEditorBase.py : Base class for Level Editor
LevelEditor.py : Sample Level Editor class
LevelEditorStart.py : To Start Level Editor

testData.py : Sample data file

Let me know if you have any questions,
and remember this is WIP :slight_smile:

1 Like

This is great news! However, it depends on wx.lib.agw (I believe its for the FWS. I didn’t even know it existed) and there’s no ubuntu package containing that module - I’ll try building it from source.

Maybe in official releases we should just ship our own build of the AGW like we ship Pmw too.

FYI, agw is included in wxPython from version 2.8.9.2

Ah, I see. The wxPython in the ubuntu repositories was just a tiny bit older than that. I upgraded to the one from the wx repo’s, and it works great!
I really like the editor, especially the dragndrop and drag-to-select features.

this is great news, i’m very happy to hear (and hopefully see, once i’ve compiled panda) that there’s progress on this topic.

looking trough the code i’ve seen 2 things that i think are worth mentioning:

save file: i think it would be great if we had a official scene-file type, pro-rsoft suggested that this could be collada (but that will take some time, a collada writer would be required as well). important would be that it could contain lights, sounds, models, nice if scripts could be attached to nodes as well.

loading of save files: looking at the code generated in the savefile, i’d suggest that the models are created first and special settings applied later. take a light as a example, it needs to be already created so you can setLightOff on any other node.

  • load all nodes
  • apply special settings on nodes
    that is how i did it in my “editor”

pressing + starts to move the desktop window under gnome (ubuntu), (mouse2 is used for scaling). It’s impossible to control the camera this way.

i know it’s WIP, but maybe it helps considering these things early.

can you tell us what the mayor focus of the future developments are?

That’s why I open this earlier, thank you for your comments.

About the scene file format, I think mine is one of the suggestion, we can discuss and decide proper format. One of the goal in developing this Level Editor is rewriting ToonTown LE and Pirates LE based on this, since both game require different file formats, I was going to support multiple file formats.

And while loading the saved file, currently it only create and set properties of individual objects. Inter-objects relationship is not defined yet. Like your example about lights, we can define some convention of light-link table at the end of the file format, so after creating all nodes, we can apply that relationship.

Actually it also supports Panda’s camera control mode, I’ll add an option to the menu so you can change between these two camera control mode. But in the meantime, you can switch to Panda’s camera control mode by

base.direct.cameraControl.useMayaCamControls = 0

Future development plans are like below:

Object Duplication
Grid Snapping
Grid Resizing
Custom Hotkeys
Easier Asset Integration for fast prototyping
Context Menu
Scene Graph Viewer (Where you can easily see/manage hierarchy)
Undo System
Layers, Layer Browser

Universal Timeline (So you can create cutscene movie)
Camera Animation
Add/Edit Event (Event in here means some sort of predefined codes which could be started according to universal timeline)
Keyframe Animation for any property
Render View/Window
Screen Capture/Render
3D Curve Editor (So you can create mo-path inside of LE)
Graph Editor (So you can easily control animation curves)

and so on…

I really welcome your inputs and participations.
Thanks.

one thing i’ve found useful, especially because of the recursively defined functions like setLightOff, hide etc. is parenting (and reparenting), which you havent listed in the todo’s.

a very important aspect i have encountered at a later time during working on the editor is that there should be some type of automatic optimization (flattening of nodes) in the editor. othervise it will slowdown heavily when creating larger scenes.

a method to place objects on another object, using the normal that the uderlying face has can be useful as well (snapping onto the objects/terrain, including normals). this can be really useful for plants onto terrain.

Actually parenting/reparenting features are already in DIRECT.
You can set the Active Reparent Target by pressing ‘p’ while selecting the object.
Then select another object and either press ‘r’ to reparent wrt or ‘R’ to reparent under the target.

I was going to give you more easy way for parenting by dragging and drop in the Scene Graph Viewer later.

About the flattening I thought user can define their own flattening routine in their createFunction, but having an automatic optimization seems better. Indeed, in Pirates LE we have automatic optimization.

Snapping between objects is a great idea, I’ll put this to my task list.
Thank you very much! :slight_smile:

RE: File format, why not leverage what already exists? From what I understand, most components of PandaNode have the ability to serialize themselves for output through the Egg interface.

Actually, that’s only partially true. Many Panda components can serialize themselves through the bam interface. The egg interface is really another layer detached.

The bam format is not really suited for level editor-type storage. There has been an attempt to build a level editor that wrote its files using egg format before (this was the so-called “SceneEditor” which is still in the tree but no longer maintained), but the egg format is clumsy to extend.

David

there is another thing that pops into my mind right now. it may not be really the topic you’re working on atm, but it may have influence on how you design the editor.

geomipterrains are one of the things that are hard to plan, when painting it in a graphics programm. having the possibility to view it together with models, and possibly edit it in realtime could enhance a editor a lot. it may be possible that it doesnt affect the current development, because buffers and mouse positions could be created as a “plugin”, but after that party and a lot of beer it cant remember if the code allows this :wink:

the idea i’m having may be summarized, that a element that can be placed, should have a onEditStart, onEditStop function, that is called when the object is (de)selected. another example of usage is when creating a particlesystem, it could open the particle-editor used in the samples.

another thing that occured me during dev or my editor: if you are going to have selectable models, the relative path to the model is important (relative to the scene-file, or the model-path), having a absolute path, where relative paths can be calculated from may be useful (could require that the user saves the scene at the moment of creation, and maybe require a onCreate function).

Thanks Hypnos for valuable ideas. I’ll keep them in mind :slight_smile:

For anyone can’t get it from CVS, here is the current version zipped:

4shared.com/file/132931643/f … itter.html
4shared.com/file/132931645/1 … ditor.html
4shared.com/file/132931644/6 … lider.html

If you don’t have latest wxPython installed, get fourwaysplitter.py from above link, save it in leveleditor directory

and change

from wx.lib.agw import fourwaysplitter as FWS
to
import fourwaysplitter as FWS
in LevelEditorUI.py

If it’s complaining about WxSlider get WxSlider.py from above link and save it in direct/src/wxwidgets (or direct/wxwidgets)

[EDIT]
Link updated…

Broken link?

With gyedo’s advice I tried it on the Mac, using the fourwaysplitter and WxSlider in Panda3D//lib/direct/wxwidgets/

Unfortunately I get this error with libpandagl.dylib crashing Python:

>>> from direct.leveleditor import LevelEditorStart 
Known pipe types:
  osxGraphicsPipe
(all display modules loaded.)
2009-09-15 23:52:21.933 Python[7015:613] *** -[NSHIObject windowNumber]: unrecognized selector sent to instance 0x1d5acda0
2009-09-15 23:52:21.947 Python[7015:613] An uncaught exception was raised
2009-09-15 23:52:21.947 Python[7015:613] *** -[NSHIObject windowNumber]: unrecognized selector sent to instance 0x1d5acda0
2009-09-15 23:52:21.947 Python[7015:613] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSHIObject windowNumber]: unrecognized selector sent to instance 0x1d5acda0'
2009-09-15 23:52:21.948 Python[7015:613] Stack: (
    2435887371,
    2427117115,
    2435916554,
    2435909900,
    2435910098,
    113893864,
    113899674,
    48505712,
    113895962,
    48507912,
    113865706,
    48284044,
    48284151,
    48328316,
    48516780,
    48810755,
    1635614,
    1642867,
    1636253,
    1642867,
    1291400,
    1185029,
    1637584,
    1642867,
    1636253,
    1636096,
    1642867,
    1291400,
    1185029,
    1220154,
    1185029,
    1459097,
    1435022,
    1185029,
    1636402,
    1642867,
    1291400,
    1185029,
    1220154,
    1185029,
    1615917,
    1204335,
    1185029,
    1636402,
    1642867,
    1643104,
    1708821,
    1710140,
    1713857,
    1715060,
    1716100,
    1716250,
    1597429,
    1185029,
    1615917,
    1632569,
    1642867,
    1643104,
    1738812,
    1746091,
    1746425,
    1747499,
    1792599
)
Trace/BPT trap

I fix is in the works.

As gyedo’s request, I’m posting my idea for a terrain editor/generator here. I believe it could potentially be integrated into the general editor.

My work with procedural planet generation ( f-g.wikidot.com/ ) has given me some ideas for terrain design and rendering

Really there are 3 parts, specifying/designing/editing the terrain, baking the terrain into the various things needed to render, and actually getting it onscreen with proper LODs and such (The renderer).

Generally for a map, we have a height map, with some detail textures alpha mapped, maybe triplanar projected, decals, vegetation, and various placed/designed art such as buildings. Then there are also caves, overhangs, and the stuff that pisses of heigh map users to no end, and generally gets added much like the buildings. These items, their locations, and the various height maps, and detail texture masks would come from the baker, and be passed off to the renderer.

For now, I shall ignore the renderer to a major extent, but lets assume it uses some sort of large tile based height maps (maybe used via geo mip map).

My procedural system resembles this process, but has no editor. There is a baker that generates information handed off to the rendering system. Adding an editor does not have to fully overwrite this.

The editor can apply things along the lines of alpha masked height maps to areas. The alpha channel allows it to fade off to procedural terrain. This means you can stick flat spots in procedural terrain where you need them. There could also be alpha masked vegetation maps. This would allow the editor to specify areas which should be devoid of procedurally placed trees, or even bias specific types of trees (so you could make some areas creepy with dark trees or what ever). Of course, where the artists/level designers want full control, they can simply mask out all procedural content, set a custom height map and ground texture, and place all vegetation with the editor.

The procedural content would be generated by the baker by using a collection of shaders that generate maps for each of the parameters. The shaders will procedurally generate maps, then overlay any corresponding maps specified in the editor (which remember, are alpha masked). An example is a height map, but they have some specific issues I will discuss below. A common complex example would be a forest density map. The editor could specify forest density in different areas, which would over write the procedural values, or it could leave the procedural one. This map would then be fed into a shader to generate maps for the distribution of different tree types, which, like all maps, could be controlled through the editor, or not. These maps could then be used to place the corresponding tree models. This whole process could be adjusted through adding/removing and editing the various map generation shaders. When procedural content is not desired, the shaders could simply output a constant (say, 0 for no forest) which would be overwritten as needed by maps set in the editor.

The baker would run all the shaders, and reduce the whole set of maps the maps for the various terrain tiles which are actually needed for model placement and rendering.

The editor would thus need to be able to take in artist created alpha masked map images, and place, scale, rotate and specify what type of map they are (forest type, height, water, grassland, what ever).

The issue with height maps is that suppose you wish to simply make a flat spot. You would need to make a heigh map that was flat, and at the right elevation. To solve this, there could be some sort of offset tool that would allow you to offset the heigh map to the correct heigh value easily.

The system for processing all the maps in the baker would have some complexities, but it would basically be a bunch of shaders that optionally took in maps, and each produced a single map. Thus each shader would just be named after the map it makes, and include a list of the ones in needs as input. The bulk of the shaders would be fixed, and thus could be auto generated, so all they would need is a list of inputs and one expression to do math with the input values, and produce and output value, and this would be turned into a shader.

Edit: I’ve started work on the terrain bakery which should generate procedural terrain until it is hooked up to an editor of some sort. I guess I better lay out a rendering system for testing it too. When I have something interesting, I’ll upload it somewhere.

Bradamante, not being able to reparent Panda windows to WX windows is a known bug in Panda:
bugs.launchpad.net/panda3d/+bug/273608
I hope someone with a mac gets a chance to fix it, one day.

looks good so far, but i havnt test it. one thing i cant see, is it possible to set triggers and some other interactive stuff, instead a editor wont make many sense and peoples wont use it. but im very curious what comes along. i started with a editor a long time ago - it sleeps well on a old hd of mine.

one thing, change the gui, i love to see something different to the old know windows or mac style.

greetz
dirk

I don’t agree. I think sticking to the os-native theme is the way to go here - an editor like this should be straightforward and simple to use without much bells and whistles like a custom UI (look at how they screwed it up in the latest 3dsmax!)

Well, that may be, but i LOVE blender’s UI.