ChimpED
As for many games, ours will also ship with an own editor. It’s not as that trivial, but easy to use after a few minutes of watching whats going on there. We decided to make the map design as easy and intuitive as possible, without BSPs or octrees. We came up with the idea of using puzzle pieces. This is something like.. eh.. ya.. 3D tiles. You can choose between the availble puzzle pieces within the editor and simply drag and drop them into the world. There also is a raster system which perfectly fits the puzzle pieces for easier and symmetric placement.
You can’t imagine what can be done with a small set of pieces! This is our first test set:
And thats what you actually can do with it:
So this kinda rocks!
But I have to admit that ChimpED is only a What-You-See-Is-What-You-Might-Get editor, cause there are no shadows. After a few secs of compiling that babe (grouping meshs, welding vertices, calculating better normals etc.), its ready for the game:
Et voilà, there are shadows! Compare that screenshot with the one of ChimpED. Its hard to difference the heights of the platforms without shadows, isn’t it?
If you wanna try out this editor, feel free to drop me a line 
PS: While writing this post, the impossible happened:
At least there is no “Send debugging shit to Microsoft”.. lol 
Trackback
RSS Feed
7 comments
1.
Zaknafein wrote at Friday, August 1, 2008 / 16:08
Very cool!
One thing I’m wondering is, do you do any kind of tile visibility culling after the level is “compiled”? It doesn’t sound possible (other than at per-polygon level) since you’ve welded all the pieces together…
2.
Eichi wrote at Friday, August 1, 2008 / 16:54
I can’t agree on that
It isn’t possible to do good culling on that, since every neighbourd tiles get merged into a large one. I’m hoping that TV3Ds TVMesh.GenerateOctree will be there soon, but due to the words of Sylvain, this won’t be implemented since the final release 
Maybe you have a good idea for that?
3.
Zaknafein wrote at Friday, August 1, 2008 / 17:39
Can’t agree? You sound like you do agree!
Anyhow, my suggestion would be the same thing I do in Fez; sacrifice duplicate vertices and hidden geometry for culling. If you keep everything tile-based, or perhaps larger chunks of tiles as separate “groups” or whatever, you’ll be able to test them against the view frustum and selectively render them.
But this would probably only be beneficial for really big levels.
Another idea : use minimeshes to render tile batches. If you keep everything at tile-level, you can make one minimesh system per tile kind, and render as many minimesh systems as there are tile varieties. Minimesh = geometry instancing = very fast to render a lot of identical objects! And when you instance, it’s so fast that you can forget about culling…
4.
Eichi wrote at Friday, August 1, 2008 / 18:44
Hm.. mini meshing is a good idea for lots of identical meshs, thats true, but what about physics? I would have to store the welded, compacted mesh within the map file, too, to have a good convex hull for use with newton game dynamics.
On the scene you see in this post, there are only three meshs to render. Each one is very large and theyre visible almost the whole time. Passing the whole bunch of vertices to the GPU is maybe faster than doing it in a culled way. I don’t think that an “advanced” scene grahp would make sense here, would it?
5.
Zaknafein wrote at Friday, August 1, 2008 / 19:27
You’re probably right. I’m overthinking.
6.
Eichi wrote at Friday, August 1, 2008 / 19:35
Nice to hear that! That proves that to much coffee doesn’t harm my brain, lol!
7.
Eichi wrote at Tuesday, September 30, 2008 / 10:26
Its been a while, but I was bored and tried to mini mesh thingy for some reason. My result was, that its 20% faster to push a few large meshs instead of thousands of instanced mini meshs. Even with culling, it wasn’t faster as before :/