hi all here are two videos und screenshots of our jmmorts-editor which was made for an MMORTS game.
sorry but the videos are quiet slow (bad wink configs)
http://www.raum200.de/test4.htm
http://www.raum200.de/test.htm
in the first video shows the heighttool and i tried to show how big maps are but not enough webspace for more than two hours of video.
the second shows the height and splattool.
about jmmorts editor
It works client/server based so the map is stored on server
a team(how many editors really work is not tested but more than 4) can edit one map realtime.
it works with our ServerMapStorage “Scape” and our own TerrainEngine called “Aalpaca”(sorry llama ;)) which is inspired by llama’s terrain package(but llama maps were too small for us).
It can create huge maps so the only limit is the storage capacity of your server biggestmap tested is 200k*200k kilometers by 1 meter = 1unit.
the editor is pluginbased that means easy to create new Tools.
1138 said:
(but llama maps were too small for us)
How's that? llama's engine was created to allow virtually infinite maps!
Are you refering to float coordinates for the terrain cells and the inherent problems with large number precision?
Could you elaborate on how your own system is better suited for "infinite" worlds?
hevee said:
1138 said:
(but llama maps were too small for us)
How's that? llama's engine was created to allow virtually infinite maps!
oh mmh sry the last version i tested the biggest map i could create before running out of mem was 16*16 kilometers with llama. In our System the server holds the map data and its is streamed to the client that means the map is only limited by the diskspace of your server.
Looks very interesting. ^^
1138 said:
oh mmh sry the last version i tested the biggest map i could create before running out of mem was 16*16 kilometers with llama. In our System the server holds the map data and its is streamed to the client that means the map is only limited by the diskspace of your server.
In that case I have to clear up a misunderstanding - although it is probably too late for you but not for others who may read this thread :)
Llama's terrain engine jmeterra is capable of doing exactly what yours does, you are by no means forced to keep all your map data in memory at all times. You could have implemented both the server and client side of your system using jmeterra.
I am using terra for a client side disk based "infinite" world which is loading tiles from disk, but it would be perfectly possible to stream them fron a server as well.
So you have created a map-editor for this? Like a terraforming tool? Is it open-source? What formats does it export in?
so it exports nothing at the moment because the server is our map storage but export would be not a big thing to add. Maybe it will become opensource we are thinkabout it.the tools are used in the videos.
Maybe it might be better to clarify some things about this system.
First one, this system is based on the idea of concurrent editing and using. This means, that several editors are able to edit the world the same time, while players are using the map.
For this, the system uses tiles and a simple listener concept for notifying clients of map changes.
This feature was implemented to get some sort of persistence in the world, like explosion craters or even long time healing of damaged nature parts or growing woods.
The second realized idea was to get only whats needed to the clients. A gameserver usually is not interested in the different splat levels of the map, but in the height and terrain type. Therefore the architecture supports selected subscriptions to different channels of map data.
Third, the package should be nice and easily integrable into our concept demos. To achieve this, the package is accessed through a rpc client, which handles all map data access, subscription to channels and tiles and updating through asynchronous callbacks, with configurable internal caching. The server was required to use as little as possible ressources, besides bandwith. Bandwith consumption should be as little as possible, too. This was achieved through zip compression and the usage of a small byte protocol as well as through logical reduction of the data, like reducing the height to one byte per location, but providing a baseheight per tile). An easy to use terrain manager (Aalpaca) was another big part and the framework for the editor with some tools, like heightpaint and texturing, too.
Due to some changes in our plans, it might be possible to release the unclean, unfriendly and not very good code to the public in a near future. However, this is not decided yet.
I like this idea of a concurrent map editor. It reminds me of the Verse protocol. Have you looked at this: http://verse.blender.org/
And for the tooling, i'll invite you to take a look at the MonkeyWorld3D platform 
Like hevee said, you would have (easily) been able to create a plugin that does all the loading over TCP/IP, which would have givven you infinite maps (I've used earth size maps even, though these did require hacks).
However, the concurrent editing would probably still require a lot of modfications. Did you reuse any of my code?
And, nice name for the terrain engine you picked!
We need to make this on the wysiwyp MW3D.