Separate the concepts of 'World' and 'Terrain'.

[StLoch]

This has been a source of confusion for a bit now. We need to solidify the concept of Terrain as the actual ground in the world and the World as the actual overarching object that maintains all actors, the terrain, the cameras, etc...

• DONE :: All of the old 'World generation' stuff should become 'Terrain generation'.
• DONE :: A new class called 'MHTerrain' should be created with ruby bindings to back it up.
• DONE :: All of the TestSceneManagers should effectively become subclasses of Terrain, instead of MHSceneManager.
• MHSceneManager should be implemented as a generic octree scenemanager for now. Depending on future developments, it should either implement some MH specific optimizations or be moved over to the Render target.
• DONE :: The terrain class should provide an interface that allows any possible changes to the terrain to be made. This will be what the TerrainBuilder process will use and will be what the actual game uses to make modifications to the Terrain.

And just to clarify:

• Terrain contains the Tiles and keeps track of the associated memory and allows for modification of the geometry in as easy a manner possible. It is what manages the tile entity blocks and handles things like uploading/downloading geometry, updating positions and normals accordingly when terrain changes, and things like geomipmapping and terrain paging.

World contains camera, terrain, and objects and provides the basic container for typical world state and an interface that the EventTranslator and various ruby scripts can call into to affect the world in various ways. It's essentially the object that the user works on when he's doing stuff.

[datalurkur]

I'm thinking we should try storing the terrain in a 3-dimensional array once more. Hopefully we can store all the information we need in very little space (basically, a type, which I imagine will fit into a byte; we can always promote to short later if we need to).

Something else I've been thinking about is how to handle liquid. We definitely need to decide whether liquids are Objects or Actors. One could argue that liquids have more of a direct effect on the things they touch than tiles do (such as water eroding a tile it passes over or lava melting a dwarf who falls into it), which would seem to suggest that it needs to be an Actor. If that's the case, we need to discuss whether we'll allow the TerrainBuilder to use Actors to erode itself, or if it will just use some pseudo-water/-lava algorithm instead.

[datalurkur]

Something else to consider is the effect of large bodies of water on performance. I think we should consider treating liquids specially and have a concept of liquid "pools". Basically, we keep track of contiguous pools of liquid and treat them like one actor, checking the edges to see if things enter/exit/affect the pool. If we're clever enough about it, we might even be able to use this to simulate things like pressure.

[StLoch]

"I'm thinking we should try storing the terrain in a 3-dimensional array once more. Hopefully we can store all the information we need in very little space (basically, a type, which I imagine will fit into a byte; we can always promote to short later if we need to)."

This is already how we're doing things. I have other suggestions as to how to actually store things. They should be ACCESSIBLE as a 3 dimensional array, but it's unlikely this will be the actual representation within the Terrain object. I'll expound on this in a separate comment or ticket.

Liquid won't be an actor. It will be handled separately. Actors are for objects in the world like plants, trees, dwarves, doors, etc...

I'm also tempted to consider liquid as just a property of tiles, simply tracking how much liquid is in a given tile, sort of how DF does it.

[datalurkur]

Issue description updated to reflect the progress that has been made.

[datalurkur]

Loch, can you explain a bit more indepth the relationships between MHSceneManager, TestSceneManager, and Terrain in this new implementation you're describing? I'm not sure I grok why you want to subclass TestSceneManager from Terrain. In our current implementation, the World class creates the Terrain object, so am I to assume that either World has knowledge of the TestSceneManager (mixing gamestuff and renderstuff?) or the Terrain object is created externally and passed in as a pointer to World?

[datalurkur]

Issue updated to indicate that MHTerrain now populates the MHSceneManager directly, rather than via TestSceneManager.

[datalurkur]

Loch, currently MHSceneManager doesn't do much scene managing. The method we use to keep track of entities is basically attaching them to the root node in SceneManager. Do we want to just bypass SceneManager's code and write the octree in MHSceneManager without regards to its superclass, or properly abstract SceneManager and make MHSceneManager a concrete implementation of it?

[StLoch]

Nuked it.