Simple LEvel Editor for Panda3D (WORKING!)

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 :mrgreen: 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 :wink:

Models are also welcome if it comes to that :mrgreen:

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) :neutral_face:

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

ok i might just be really stupid, so sorry before i ask if it’s just trivial but:

when i try to run main.py i get this error “IOError: cannot load model file(s): data/mesh80k.bam”

the thing is when i check my data folder, the file is actually there…
not sure where this leads me

Ok, that is strange.
Can you open the mesh80k.bam using pview?
The bam was made on 1.8, 32bit windows, maybe you are using some other os and version that can’t read that .bam file. I think there should also be a .egg version of that file, it will load a bit slower the first time but it should work just fine.

i was using panda-1.7.2, updated to 1.8.1 and it works fine (ps i m on windows 7, 64bit).
Thanks, i knew it was something really obvious , just could’nt put my finger on it :stuck_out_tongue:

The last few updates could break things for 1.8 as well, shadows, water and I’m not sure what else where made for the upcoming 1.9

I’ve done some updated to the demo (new water, some post-process filters), if someone, preferably with a (powerful) Nvidia card, could give it a shot and tell me how/if it runs then I’d be very grateful.

I have a GTX560Ti. Not that powerful but NVIDIA. =)
I got this error:

Known pipe types:
  glxGraphicsPipe
(all display modules loaded.)
Traceback (most recent call last):
  File "main.py", line 1425, in <module>
    app=Editor()
  File "main.py", line 115, in __init__
    self.final_quad.setShader(Shader.load(Shader.SLGLSL, "shaders/fxaa_v.glsl", "shaders/fxaa_f.glsl"))
AttributeError: 'NoneType' object has no attribute 'setShader'

I can get the code to run if I replace

self.final_quad = manager.renderSceneInto(colortex=colorTex, auxtex=auxTex)

with:

self.final_quad = manager.renderSceneInto(colortex=colorTex)

The screen was black with some glitches.
On a side note I was having a error with the fxaa in the 09feb version. Then I just commented the fxaa code.
It seems the fxaa is more tied to the system now than the previous version - it’s not as easy to turn off)

If I comment the block of fxaa (114-121) I can run the code, but the terrain don’t show any textures (although grass appear normal).

I guess I have to enable the auxbit in some place, but don’t know why it works to you and not to me (I’m using the last commit of panda3d)

Looks like I’ve broken something :blush:
Can you try running the demo.py? Is it the same?

EDIT:
I think I got it fixed (it works on my end now). It’s a crude fix, and I need to disable the glare/flare on the cursor in the editor and also make the editor use the water from the demo (it’s so much better in my opinion)