I’ve made a small video with the editor in use:
youtu.be/VDFHQEppq5k
By next weekend I hope to have all the planed features ready, if someone has any ideas or suggestions now would be a good time to speak 
Hi,
I tried the latest github version today (I’m running Ubuntu 13.10, my graphics card is a Nvidia GTX650) and after fixing two small problems your editor ran perfectly fine.
- The default value of the “input” argument of GenerateCollisionEgg has a backslash (input=‘data\collision3k.egg’). This is in collisiongen.py
- Upon running I got
:display:gsg:glgsg(error): An error occurred while compiling shader shaders/fxaa_f.glsl
0(27) : error C7531: global function texture2DLodOffset requires “#extension GL_EXT_gpu_shader4 : enable” before use
I added the suggested line in the shader file and it fixed a general red tint I had observed before.
Thank you for your effort! I like the usability, feature set, speed and extensibility of your editor already - and I suppose it’s still improving 
Cheers
Thanks for the input, made the changes in the repo.
Just added two new features:
-multi-paint
-wall-paint
Multi-Paint:
It is quite common that I have multiple similar objects, like rocks, bushes, boxes etc. Painting them one by one is tedious, and even more so if you have say 3 rock models and you want to paint 20 of them, each one wit a bit of rotation and scaling to make it look as if there where 20 unique rocks. Multipaint helps with that. Just drop all the models into one directory inside the ‘models’ dir, in multi-paint mode the editor will select at random one of the models, rotate it (heading only) and scale a bit (+/-10%), and if you don’t like the selected model/scale/rotation just press [TAB] to roll a new, random one.
Wall Paint:
It’s not for painting textures on wall, it’s for painting the walls themselves. You place the first element of a wall, just like any other object, but then next segment will be placed auto-magicaly where the first segment ends and it will ‘lookAt’ the mouse cursor. Pressing [TAB] will change the current wall model to another (random, if there are any other models).
For this to work with custom models, they need to have a node named ‘next’ with the start position of the next wall segment.
Made a short film to show it:
youtu.be/IgGFvJowwf8
Some features where added, whoever fallows the code on github should know
The topic turns into something like a dev-(b)log, but I think the comments on commits are enough, I’ll talk more about the features when all are done (maybe I could hijack the panda3d blog for that?), for now I’ll talk about what will come soon… a new terrain shader.
In a way it’s basic. It’s what I would expect from a terrain shader - 8 color textures (+8 normal map textures), fog, shadows. The shadows will have to wait for the 1.9 to hit the shelfs, but the rest is more or less done.
Most would expect that 8 splattered textures need 2 rgba mask textures, but I got them all in one texture and I’m not even using the alpha channel - it’s not TobiasSpringer quality, it has it’s quirks, but I’ve seen worst (and made a few myself!). Speedwise - the old version run at ~500-600fps, the new at ~150-250fps, but with 14 more textures used I wouldn’t expect anything else.
The thing is… should I make the new shader the default solution or should I make a fork?
Teaser:
So I made a fork.
github.com/wezu/koparka/tree/Multitexture
On my PC is is much slower, but still usable. At this moment it will probably rebel if you try to save or load, but apart from that it should work 
I’ll fix that today.
Bug reports and opinions are welcome.
I’ve added a small demo based on Roaming-Ralph that shows how to load and use the data created with the editor.
On my PC it runs at about 100fps, and thats good enough so I think I will make the multitexture branch the master, unless someone is willing to use that old version. Is there someone like that?
I’ve pushed all the changes to the master branch and deleted the ‘multitexture’ branch (I know that’s not the’proper way to do it, but I’m a still new to git…)
Some changes so far:
-In the bottom right corner there a 3 new buttons Raise, Lower and Level. The first two are nothing new, but they work as expected now, the last one allows to paint patches of even (leveled) terrain of given height (level). W and S keys to set the height (level).
-the demo uses a depth-o-field fog (actually just blurs the scene based on the amount of fog - it’s merged with the fxaa shader, and the default terrain shader writes the ‘fogfactor’ to a aux render target)
-shaders got fixed (but bug reports from nvidia are welcome, my ati driver forgives a lot). Some of the fixes are: normalized normals, things that can be done in the vertex stage are done there, specular highlights and gloss maps (in normal map alpha), some settings work as shader inputs (fog color/distance, ambient light)
-there’s some alternative grass, but I can’t say it’s better (it has more details on close-up and a few less polys, but looks bad from top and it’s animations is a bit stiff)
-the default terrain now is 35k polygons (give or take a few) and the default collision mesh is ~10k (cut into a 3 level quadtree - if I got it all right)
-and some others…
If you want to run the demo - make a map Look in the demo.py file for “app=Demo(‘save/default3’)” and replace the name of the dir to one that is not empty.
What’s planed?
-shadows (if I can get some working with glsl)
-water and sky from my other project
-terrain shader with 1 and 2 extra point lights
-more textures and models
-placing lights in the editor - but that would only make sense with deferred lighting
-bugfixes
-binary version
Link:
github.com/wezu/koparka/
Looks really good, kinda skeptical about the menu style, looks outdated, though that isn’t really an issue.
Anyway, keep up the great work!
Thanks.
The icons are simple, but I think they do their job - on the other hand, if you would want to make better icons then I would put them in the repository
Models are also welcome if it comes to that
I definetely can use it! Thanks. A lot of progress since the first version. I have question - can we delete objects?
Yes you can. Pick it up (click on the arrow icon somewhere on the right, and then on the object you want to delete), then press Esc on the keyboard.
If it’s a custom model then make sure it has some collision geometry or else you won’t be able to pick it up.
I will write a manual at some point, but not this week, not next week… not pyweek, but some day.
I’ve spend a better part of a day reverse-engineering the “navigation mesh csv” used by PandAI… then I noticed there’s the blender exporter for it written in python, that could probably save me some time, but oh, well, got a script that takes not a mesh but an image and turns that into a PandAI ‘navigation mesh’.
Now you can paint parts of the map that are ‘unwalkable’ and save it in a format understandable by PandAI, so you can have some pathfinding. The map is a small 64x64, I think I may make it twice as big in the future but I need to test how fast the AI works with that kind of ‘navigation mesh’.
I know that PandAI is a bit aggressive and frame rate dependent, but if you run the update not per frame but say every 0.1 seconds with a doMethodLater task and a LerpPosHprInterval to move the actual actor inside the same task, entities can move at the same speed regardless (more or less…) of framerate.
I also had to revert a fix tho the fxaa for nvidia cards, because it didn’t work for the 1.8.1 version as the fixed relied on int shader inputs that where added to later versions (but now I’m supplying the troublesome inputs as explicit floats so I hope it will work).
SCREEN:
SOURCE:
github.com/wezu/koparka
EDIT: changed the default nav-mesh-map-thing to 128x128, it now generates a ~4MB file, but the pathfinding works more or less with the same speed, so I’m gonna leave it at that. Made the script accept any image size if someone wants to use just that part.
Same changes have been made. Backward compatibility is broken (again), with a bit of luck this is the last time.
Changes:
80k mesh
80k mesh used for terrain and collisions (no significant impact on framerate on my test machine). This allows for more detail and relative bigger maps, but generating the collision mesh can take some 30+ seconds, loading it is also slow-ish, but that can be solved baming it.
Grass
Grass mesh now has ~2.5k verts, 850 polys, a more detailed mesh could look better but slowed the thing down too much. Some improvements are still needed here - for example I’m using binary transparency to get rid of artifacts, but there must be a better way.
Textures
The terrain now uses 6 detail textures (+6 normal map textures) and two ‘attribute’ maps telling the shader how to splat the textures. Now you can mix the textures as you like. This needs an additional buffer and an extra image file.
Some cards (Nvidia?) provide only 16 samplers in a shader so there won’t be more textures, the current setup uses:
-6x diffuse (alpha wasted - could be emission or height)
-6x normal +gloss
-2x attribute maps (both alpha wasted)
-1x height map (1 channel, 3 wasted )
-1x walk map (1 channel, 3 wasted )
This sums up to 16, but the walk map is not needed outside the editor, and the height could be stored as alpha in one of the attribute maps, that means there could be 2 samplers used for shadows in a ‘game’ shader.
I will provide some new textures in the next week, the ones now included were meant for the 8 texture setup where the textures could only be mixed in certain ways.
The textures are now dds compressed - this gave a big boost on my test machine
Lights:
Fixed, until proven otherwise.
UI:
-There a ‘change texture’ button on each texture
-the save/load dialog won’t ask for file extensions and in fact you should not try to provide them
Demo:
Probably broken for now.
Bugs:
Do report them!
Link:
Same as it was: github.com/wezu/koparka
I’ve added new textures to the repo, added a way to edit the brushes with numerical values (click the ‘gears’ icon), and to edit the placement of objects (you can change the hpr, pos, scale of selected objects by providing new, numerical values for them).
There are also some small fixes that makes the editor less annoying (zoom speed, brush size speed change).
Still waiting for bug reports, have a big screen as an encouragement:
how do I use the levels in my game?
Any way you want to.
The data that the editor writes is not even panda specific.
There’s a height map - a grayscale image that stores the height of the terrain at each point. You can use it to generate a geo-mip-terrain as the manual explains it, use the shader and terrain plane from the editor (it uses the image in a vertex shader to move the verts) or write your own terrain system.
There are two ‘attribute’ maps used to tell where texteres are painted -and again you can use the shader from the editor or make one yourself.
There’s a grass map, the red channel is used to store where the grass grows, and in the last updates I put a ‘blend factor’ in the blue (?) channel -it tells how much of each (2) grass color textures to use (one is lush green, the other wilted yellow). The map itself is an image -it tells nothing about how to grow the grass in your game, but again you can use the same idea as in the editor - this time there are 8 tiles using hardware instancing, each tile is drawn 256 times (8x8) and then moved to the right spot and animated by a vertex shader. I’m not saying it’s the best way -most games use LODs to fade and remove distant grass, but playing Skyrim and watching as the grass pops up from underground made me make this system of mine.
There also is a ‘walkmap’ and a ‘navmesh’ for PandAI. The manual has info how to use PandAI, and you could use the walkmap to limit where the player can go without collisions -or not use it at all.
The collision mesh exported is just a collision meshe for the terrain with some quad-tree improvment. You load it and you can run collisions against it.
The last thing is a json file with the hpr, pos, scale of all the objects placed in the editor and also some info about the scene (textures used for terrain, but it will also have fog color, water and sky settings…soon) . You can use the json parser from the editor (it can now load shaders referenced in egg files) or write your own.
tl;dr:
Panda has no common ‘level’ or ‘scene’ format so you’re on your own here, but you can use the data from the editor the same way the editor uses it.
At some point I’ll make a function like LoadLevel(‘my_level_dir’) but it will never be 100% universal, it will load and display a level as I wanded and that may not be as You wanted it.
I’ve updated the editor for 1.9, there’s bug free water, shadows, depth of field (sort of, blurred fog really) and sRGB color.
Some screens:
The bad thing is that it now runs at about 30fps on my PC (used to be around 60+fps) 
I can’t record a video tutorial on the machine I use at the moment.
Turns out I can make a video tutorial - I just needed to cut the resolution a bit (to 854x480)… some parts of the editor didn’t fit that size, so I had to shrink and/or hide them.
Here’s a link:
youtu.be/6gAjg1eMBso
As a side note - you may have problems running the editor if your gpu can only sample 16 textures in a shader, I need to make some sort of trick to kick one texture out because now it’s using 17, so I suppose there will be shadows or the walkmap displayed. It’s not a problem for a in-game shader, the walk map is not something that should be displayed anyway, and the height map can be packed into one of the attribute maps alpha - but for the editor it is what it is.
I finally updated the demo that ships with the editor. Now it has a point and click interface and makes use of the navmesh exported from the editor. Click somewhere on the terrain and the character (borrowed from Avolition) will run to that spot. Click and hold the right mouse button to move the camera around. Mousewheel to zoom (+ctrl to zoom faster, +alt to zoom slower).
Video showing the demo:
youtube.com/watch?v=cmWHYBXafWU
Code still where it was:
github.com/wezu/koparka