Terrain Question
-
This spring I put together an agent-based terrain generator as part of my research. I'd love to be able to point to the paper, but its out for review. This generator created PLSM compatible heightmaps, as well as in a format used by UNT's Sage engine. So we had two different renderers for the terrain. The PLSM based generation created a texture atlas and an index (akin to a decal), plus cultural information (meshes, their locations and orientations). The user comments were positive, and I think the ideas are sound.
It would be interesting to be able to use that generator with Ember at some point. Now a lot of my work is going to conflict with the established way of doing things (at least that is my fear). Although with some config settings we might get the best of everything. I'm happy to share the generator, once we've published. And certainly sample terrain files.
Anyhow this type of change can either be something I keep local, or something I push your way as-is once it works. I'm fine with either way.
In the meantime I took a brief look at components/ogre/terrain and am wondering where to diverge. I could subclass TerrainPage, but I'm not sure if there is a better place to use as a jumping off point. There is also the question of where to place the terrain files (both Ember and Cyphesis would need them, and it has never been a problem for me to keep them locally). Off the top of my head, ember-media-dev/shared/common looks like a potential home, or I could drill down deeper into resources/ogre.
I like Ember's splatting. I could probably take my shader program and Ember's splatting and create some hybrid. I really, really hope that one day I'll be able to get my texture atlas code to work right. As near as I can tell, the partial derivatives used in the texture lookup and getting messed up. The result is a radical change in mipmap level. This is a major digression, but if anyone is interested I have an 8-page or so document put together which illustrates the issue. But in the short-term, avoiding the atlas and just limiting myself to the 12 or so textures which Ember is currently using is a fair way to go.
I was really trying to avoid doing too much to start out, since there is enough "drinking from the firehose" going on without adding to my misery. This is not the type of project which will please my advisor. But I am not comfortable with the idea of plugging my own AI code in just yet. -
Hi, this sounds really interesting. As you've seen in the Worldforge project setup one really important aspect of the whole system is to detach the clients from the servers, through the use of a common Atlas protocol. As such we want to avoid introducing features on the server which are bound to just one client.
The terrain conceptually wise is pretty straight forward: you have a heightmap which is just a 2d bitmap, and then you have a couple of coverage maps for different surfaces which optionally can be applied, depending on the renderer.
All of this is currently happening through the Mercator library. I don't know how familiar you are with Mercator: I can give a brief overview if you want.
If you want to provide the terrain data from another source than Mercator you're absolutely right that the easiest way would be to subclass TerrainPage. In it's current implementation that class is however way to fat, and should be slimmed down and split into different components and interfaces. But if you just want to get something working you can probably use that (after marking some methods "virtual").
I looked at using atlas splatting and had some POC code a couple of years ago, but abandoned it in the end. There were so many small issues and corner cases that I deemed it not worth the effort, If you've managed to more successfully implement it I would be interested to take a look.
If you plan to do modifications to the code I think it would be best if you had your own remote git repo set up to which you can push changes. That way the community can give feedback and ideas. If you're interested in that you should talk to Kai.
Another thing: the forum is really a bad place for these discussions. It would be much better to use the general mailing list.
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
- All Discussions317
- General90
- Programming34
- Games15
- Clients109
- Servers48
- Media21