I have been wondering about the Elder Scrolls III Morrowind terrain system. I know the system is database driven where the level is split into blocks and at any given point in time there are only 9 blocks held in memory. I want to create somting like this to display a large terrain based world. does anyone have any sugestions where I would start in jMonkey with teramonkey, standard terrain pages, or somthing diffrent intirely?
Basically, it’s really simple, i’m doing something equal to this in my game:
You have 9 Blocks:
+---+---+---+
| 1 | 2 | 3 |
+---+---+---+
| 4 | 5 | 6 |
+---+---+---+
| 7 | 8 | 9 |
+---+---+---+
The player is alway in block 5. Once he crosses the border to an adjacent block, you simply load & attach the newly needed blocks. For example, when the player goes to block three, you load a new row of three blocks and attach them at the top and drop the last (bottom) row of blocks.
I#m keeping those blocks in a WeakHashmap as cache, so as long as there is enough memory, they are held in memory and re-used (Although this is a very crude approch, i am thinling about swithcing to an real LRU cache that will be far better).
You can eventually make it more sophisticated, but this is how it works fine for me.
A and yes, im using standard terrain quads.
this is exacly how morrowind/oblivion/fallout3/vegas/skyrim works.
don’t know why, but the lowest number of blocks in Skyrim can be 5… :?
but BTW, it should not be hard with JME terrain since it’s splitted, but it need also to unload all objects on this block.
even block or not, most of objects loading is not affected by block, but by distance from player. This is how it work in bethsdesa system.
interesting is also, that after some hours of play, game works slower, because every changes(like drop weapon/etc) are stored.
I’m pretty sure TerrainGrid already does exactly this 
2 Likes
I think, since they offer panoramas, that Oblivion and Skyrim kind of mostly use a very good mip mapping of the terrain.
Oblivion, has a small map… and from nearly everywhere, you can see the capital city wall’s (which is centered on the map).
Skyrim has a way bigger map and therefore, I guess, has some adding/removing of zones depending on what zones you can see or simply depending on where you are… contrarily to Oblivion, they compartimented (by putting big mountains in the middle of the map so they can remove lots of stuff.
There is at least one quest in Skyrim where you raise very high and can see a lot of the terrain, with very low terrain detail.
Buuuut, I’m no expert… this is just my opinion. Sorry in advance if the info is incorrect.
I guess they do use a 3*3 grid for displaying non terrain stuff such as buildings, npcs etc… but, some buildings are displayed whatever the distance.
Vegetation reacts exactly like our Forester does… adding / removing depending on distance (I hope I’m not giving false info, but I’m slacking on a space game so just tried Androlo’s Forester, loved it, cursed and moved on).
TerrainGird does something similar with only 4 blocks. When I first saw terrainGrid I thought that 4 blocks would not work, and I would have to write my own with 9 blocks, but TerrainGrid is very efficient and works well with large terrains, so there really is no point in making your own.
2 Likes
Yes, if you use larger blocks 4 is sufficient. The advantage of 9 is that you are loading smaller chunks at a time, but that can be mitigated.
For showing buildings in the distance you don’t actually need any special logic. Either just add the building (at different LOD levels) to all the grids it should be visible from or add it as an object independent of the grid.
Actually you can stream j3o files as grid, including objects either as actual geometry in the file or with AssetLinkNodes… We plan to add editing of such terrain to the SDK but I think it’ll take some time til we get that in still.
2 Likes
How do you use j3os with TerrainGrid?
Theres a test class, basically you just give the assetmanager folder which should then contain j3os named by their x-y position in the grid.
1 Like
Thats assume! Now is there an example of how to stream in j3o files as a grid? I know theres examples of the terrain grid.
@normen said:
Theres a test class, basically you just give the assetmanager folder which should then contain j3os named by their x-y position in the grid.
1 Like
@normen said:
Theres a test class, basically you just give the assetmanager folder which should then contain j3os named by their x-y position in the grid.
What is the test class called :?
Have you created the JME Tests project in the SDK?
If so I guess if you look in jme3test.terrain some of those would be helpful…
TerrainGridSerializationTest
1 Like
@normen said:
TerrainGridSerializationTest
You have answered my prayers :D
I know what I am going to do after I finish that hole Unity FPS to jMonkey Project ;)
Terrain grid also stitch the neighbouring terrainquads together, so that LOD works well and doesn’t cause weird seams etc. This is important.
I agree also the 4x4 grid of terrain grid is a bit hard to work with, but it’s a great system and keeps being updated and extended, and it works well together with the rest of the engine (might not be the case with a custom solution).
I heard something about Sploreg making an alternative system as well that lets you use any number of quads, and it finds the neighbours and stitches them. Not sure about the details yet tho, he was gonna post something.
Also, keep in mind, if you use only one cache (like terrain grid does for example), it pokes old tiles out whenever new ones are added. This means if you move back and forth over an “edge”, it will keep loading/reloading tiles. I solved this in Forester by using a secondary cache, so when tiles are popped out, they are stored for a set time in the secondary cache before being de-referenced. When a tile is loaded (2,3 for example), it checks the secondary cache for a tile with indices (2,3). If the tile exists, it’ll be re-attached and doesn’t have to be reloaded.
Even got a “hot spot” system to store very active tiles for longer periods of time (basically just “bumps” a tile every time it’s re-used, and the decay timer is extended for each bump).
It adds a bit of memory overhead, obviously, but saves a whole bunch of processing. Got no exact data yet, but I’m guessing the memory overhead is around 15-25% depending on grid-size and cache timer. Gonna do some profiling before releasing the next snapshot.
Hmm, an easier fix for that is to make the switch point be at 40% from an edge instead of 50%, so that you have to cross 20% before it triggers a switch, then go back and reverse your track for 20% to trigger the next switch.
@skidrunner said:
You have answered my prayers :D
I know what I am going to do after I finish that hole Unity FPS to jMonkey Project ;)
Actually I am wrong, I mean TerrainGridTileLoaderTest, the code used to create the tiles has been deleted but is preserved in this revision: http://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/test/jme3test/terrain/TerrainFractalGridTest.java?spec=svn8678&r=8678