A very flexible terrain library for jME 2.
Feature list and several demos are available on the project home page.
Today I reviewed and adjusted terrain traversal speeds to accurately reflect human male walking and running speeds (in the Modeler example) and jogging speed (in the SimpleGame examples); and I added added surfacize() methods to make it easy to plug in other surface traversal systems or to automatically place models onto the world surface.
human walk speeds with regards to what? heightmap fidelity of one height value per "jME unit" or what?
MrCoder said:
human walk speeds with regards to what? heightmap fidelity of one height value per "jME unit" or what?
The only thing that makes sense with respect to human walk speeds... with respect to the scale of the game world used in those examples (fidelity to jME height maps or anything else without a game world scale does no good since one jME unit could correspond to any real world size at all). It isn't arbitrary. (1) When in surface traversal mode, the cam height is at the exact position of an average sized human male walker/jogger/runner. (2) The dirt texture is sized exactly to show gravel, etc. in the correct magnitudes (I wasn't as careful when scaling the other textures, which I adjusted by eyeball). Both of these factors result in the ability to viscerally feel when the traversal speeds are unrealistic. Consider these mental experiments: (1) You drive down the world in your car looking out the windows. Then everything outside the car, the road, signs, bushes are made 10 x as big. Drive again and it feels like you are going 10 x as slow. (2) Drive down the road in a high pickup truck. Drive down the same road on a go-cart. It feels like you are going much faster in the go-cart because you are much closer to the road.
It makes it even easier to get a feel to for realism of the traversal speeds by putting terrestrial objects on the surface. You can do this easily with Modeler (make sure the surfacize option is set in Settings). Adjust your model, before loading, so that the origin is where you want the item to sit on the terrain (e.g. origin would be around the sole of the feet of animals with feet). Your models need to conform to my game world scale, which is 1 game world unit = 1 m.
The terrain system has intuitive settings to scale both terrain (laterally and vertically) and textures to your own game world scale. You can also independently set resolution as desired (according to your own performance compromise) for height mapping (laterally and vertically) and texture bordering (the resolution of individual textures will be a consequence of the resolution of your input texture image files).
i'm mostly interested in the technology aspects behind it. saying anything about achievable flying speeds or sizes of terrain you can render in km etc is useless without knowing the fidelity of the terrain geometry in respect to the units used. not saying you are doing exactly that, but it's very common to hear things like "we can fly over a 100000 mile terrain without hickups" and it proves to be a 16x16 heightmap scaled up a lot (or slow cam close to the ground) 
MrCoder said:
i'm mostly interested in the technology aspects behind it. saying anything about achievable flying speeds or sizes of terrain you can render in km etc is useless without knowing the fidelity of the terrain geometry in respect to the units used. not saying you are doing exactly that, but it's very common to hear things like "we can fly over a 100000 mile terrain without hickups" and it proves to be a 16x16 heightmap scaled up a lot (or slow cam close to the ground) :)
You were asking about where I wrote, "Today I reviewed and adjusted terrain traversal speeds to accurately reflect human male walking and running speeds". All that is required to model realistic walking/running speeds as I reported is to set the speeds correctly with respect to camera height and texture scales, and I did that. I agree with you that if somebody makes your hypothetical performance claim, they are making assumptions about resolutions, but I was not making any performance claim, I was just reporting that I was accurately modeling walking/jogging/running speeds (independently of game or engine performance).
I'll now answer the implicit question about performance and resolution. Vertical height-map resolution is to 1 cm. Horizontal height-map resolution is to .3 m. The texturing resolutions vary from example to example, depending on what I am trying to exhibit and the performance aspects of the TerrainProcedures used in that particular example, so you'll have to look at code and the API spec to find that out for a particular example. If you're looking for a performance assertion, I'll say that what you see in the examples is realistic human walking/jogging/running speeds with terrain height map resolutions of 1 cm (vertically) and 30 cm (horizontally) + varying texture resolutions. Procedural Terrain System is designed to allow the user to tune all of these settings without modify any PTS code.
cool, thanks for the info! not trying to be a smartass, just curious since i love terrain engines (and love to learn more)
Hi blaine,
i have a question on your pts: How do you handle the terrain and physics on serverside, with several users on?logged Do you have multiple "worlds" shareing the blocks and unloading / loading the blocks for all users all the time? I dont think it would be neccassery to hold the complete world data in memory…
And whats about phyiscs? On each block load you add a collider / physics representation to your physics world and unload it when the block is unload?
At weekend i read your tutorial on hotbj and blender, it is very good work, thanks!
Regards
snare
snareoj2 said:
Hi blaine,
i have a question on your pts: How do you handle the terrain and physics on serverside, with several users on?logged [sic?] Do you have multiple "worlds" shareing the blocks and unloading / loading the blocks for all users all the time? I dont think it would be neccassery to hold the complete world data in memory...
The details depend a lot on your Client/Server design, but terrain blocks are a client-side construct for the most part. The client knows the details about camera position, culling, and so forth, and the updates can't afford network transfers every time that the camera moves. The TerrainTexturizer part should certainly do nothing on a server.
The server will have to manage map instances so that every player interacts with a consistent, shared world. Using earth as an example, you could have maps for Europe, Africa, and South America, and since lots of users log onto Europe, you may have 3 instances of that map. So here your server would manage 3 + 1 + 1 = 5 world map instances. It's an implementation detail whether to keep those instances in memory, a database, or somewhere else. For a tiny world it may be simpler to keep all in memory. For a large world where users can runtime excavate and so forth, you don't have to keep anything in memory. In this case, PTS gives huge performance advantages by letting you share the procedural terrain definitions and then storing only the modifications to apply on top of them. These modifications need to be transmitted to each client as they connect, and if you support runtime terrain changes, the runtime changes must be broadcast to all clients as they occur. If modifications are a common thing and your world is large, you will need to filter mod-transmittals to the area around each client's cam.
snareoj2 said:
And whats about phyiscs? On each block load you add a collider / physics representation to your physics world and unload it when the block is unload?
That's too app-specific for me to answer. Where to do that depends on where the physics state is persisted or where it's derived from, whether such state needs to be shared, whether client-side would be vulnerable to cheating, etc.
snareoj2 said:
At weekend i read your tutorial on hotbj and blender, it is very good work, thanks!
You're welcome.
snareoj2 said:
Regards
snare
Wow, thanks for that detailed and fast answer. I'll have to think more about separating the clients and the server side of game applications. I hoped to be able to reuse most of client code on serverside, but now it seems that this isnt the way to go.
Thx and good night,
snare