Llama, are you currently working on this?
I would really like to use it, and have some questions in this regard.
For instance, I want to know terrain height at some world x,z location - how would I access the TerraMesh at that location? Or, should I rather ask TerraManager somehow for the (interpolated) height map value at that point?
Second, I'd love to incorporate your terrain classes with a terrrain editor I have - but how should I approach setting the height values, and updating the meshes real time?
Also, is there currently a way to hook into mesh creation and replace it with an own implementation of TerraMesh? Maybe it would be nice to have, and in this spirit, it might also be useful to make TerraMesh an Interface? This would also simplify integrating your system with the jME TerrainBlock.
Personally, I would probably implement this "hook" using a Strategy or Factory Pattern approach for mesh generation. But that's just my point of view, of course.
BTW, I just combined your terrain engine with a shader-based texture splatting mechanism I am currently testing - it works great!
any screenie? 
Sure, look here: http://wwwhomes.uni-bielefeld.de/krabien/cgi/output.py?JMESplatting, second pic. The textures, esp. the alpha maps, make it look quite crappy, but the potential is there! (If only I could find some decent terrain textures for free…)
looks interesting… 
hevee said:
Llama, are you currently working on this?
Yes, I'm implementing some very big changes (mostly related to incremental loading) for a specific project. This is what's keeping me so busy at the moment.. spending time with it all the more makes me realize what a dog this thing can be to work with.. and I wish I had more time to fix that right now (but I don't). However after all that effort I'm doing now I certainly do not plan to abandon this project after that's done.
Of course I'd love to see additions made to this project, but in fairness there have been some other terrain oriented developements for jME lately, that are likely a little more friendly to work with. However I do think my work still has some pretty unique features.. and even more so once I get the latest work done. You'll be able to "view the entire world" and then zoom in as far as you like (and have data stored or generated). The pluggable loading/saving/compression system is also pretty nice.. and the "TerraPass" system could be nice when it's more.. well.. sane. If those things still sound good to you, let's code :)
I would really like to use it, and have some questions in this regard.
For instance, I want to know terrain height at some world x,z location - how would I access the TerraMesh at that location? Or, should I rather ask TerraManager somehow for the (interpolated) height map value at that point?
You can find the TerraMap (the IntBuffer containing the heightpoints) for your coordinate using findMap in TerraManger. There's already a convience method for finding an absolute point, that even does some caching, TerraManager.getPoint(). You'll have to steal the interpolation from TerrainBlock or something like it.
Second, I'd love to incorporate your terrain classes with a terrrain editor I have - but how should I approach setting the height values, and updating the meshes real time?
You should definatly set it in the TerraMap, after which you'll somehow recreate/update TerraData and TerraMesh that overlap this map section. I think someone I talked to already did this (mrCoder?) one time..
I plan to have a system that will remember what changes you make to the Terra maps, and then when you "commit" them will update the right data and meshes and/or recompress / resave etc. the mapdata. but this currently only exists in my head.
There's not even a setPoint equivalent to getPoint yet :cry:
Also, is there currently a way to hook into mesh creation and replace it with an own implementation of TerraMesh? Maybe it would be nice to have, and in this spirit, it might also be useful to make TerraMesh an Interface? This would also simplify integrating your system with the jME TerrainBlock.
Personally, I would probably implement this "hook" using a Strategy or Factory Pattern approach for mesh generation. But that's just my point of view, of course.
BTW, I just combined your terrain engine with a shader-based texture splatting mechanism I am currently testing - it works great!
You can already hook into the addition of new TerraMesh to the scene (using a special TerraPass, the LOD stuff using this). I also planned to make the entire mesh creation process customizable so what you suggest sounds like a good idea. At first I thought about making each little step in the mesh creation customizable, but I guess letting people write their entire own implementation is fine too, as long as the current code is reshaped into easy to use "helper" classes. You could also consider just hacking whatever you need in the engine to make it work for you, and worry about how we'll make nice interfaces for it later :P
Basically: feel free to add anything you think will make this engine more useful to yourself or other and/or easier for the developer. The merge with all my own pending changes will likely be a violent one, but I don't plan on letting any contributed code go to waste in the end, so I'll do my best to make everything play nice.
I don't have time right now to get the code cleaned up up and all that, but I am working with it, and I still have some big plans for this project :)
Llama, after toying around with your engine a bit, I doubt I can easily use it for the texture splatting system I am creating. I'd have to be able to generate texture coordinates, and, even more important, splat alpha maps that correspond directly to the height maps - but your concept of blocks overlapping several maps kind of blocks that path. The only way I see around this problem at the moment would be to break up all the (border) blocks into four sub-blocks each, and assign texture coordinates and TextureStates accordingly - but this sounds like it might have its own problems. I really don't have any better ideas atm, if you can think of something, please let me know!
I don't (really) see the problem there… alphamaps can be generated at the same time when a "block" is generated. If you want to pregenerate them it also isn't a problem since you know where the blocks will be in advance. Indeed what you need is a "hook" into the TerraData/TerraMesh creation. Also for making your own texture coordinates, if that's what you need.
The overlap is there because with dynamic loading it's important the edge data for the adjecent block is available (eg for making normal maps).
I've been reading trough the your LOD system but i'm confused.
What is the purpose of the different Passes like PASS_ADD, PASS_MAP, PASS_BLOCK, PASS_CURRENT
In LODUtils what is ret and extra
Also in LODPass it doesn't put any data in the indice buffer array so i was wondering how data gets in it or am i missing something in LODPass
It seems like you have an index buffer for each scenario: each lod and each possible side there could be a higher lod level on.
The Pass system is very confusing… I'll admit that much.
Basically it's a kind of event-handler… so all those types of spawn different "events" (at map or block locations) that you can register for.
If I remember correctly PASS_ADD registers for newly added blocks, MAP and BLOCK frequently give "events" for all map and block coordinates (I think the difference between maps and blocks is explained somewhere in this thread) that are in the "range" that you've set. CURRENT gives you all the blocks/maps that are loaded already.
As you can see in the source, aside from the PASS_ type, you also register a number. This number deterimes at which "pass" you want the "events".
So eg. the LOD pass registers PASS_ADD at pass 0, so it can set the correct indexbuffer for a newly added blocks before anything else. It also registers two passes of PASS_CURRENT, 1 to determine what the LOD level should be of
I'm trying to map individual textures to each block, instead of the entire set of blocks. I found the heightmap for the entire set, but how and where do I access the heightmap for an individual block?
I'm pretty impressed with what I've seen so far.
yes, this is supported but is external to jme
http://www.jmonkeyengine.com/jmeforum/index.php?topic=5170.0
also look at
http://www.jmonkeyengine.com/jmeforum/index.php?topic=5641.0
There are several ways to do terrain in jME. A search on the forums will return a lot of hits. Also, the wiki is your friend:
http://www.jmonkeyengine.com/wiki/doku.php?id=starter:hello_terrain&s=terrain
http://www.jmonkeyengine.com/wiki/doku.php?id=loading_the_terrain&s=terrain
http://www.jmonkeyengine.com/jmeforum/index.php?topic=5641.0
Good luck and welcome
Thank you for the links and information, I'll look it over and hopefully my questions will be answered.
Thanks again for the polite welcome.
My issue was a simple one, as it turns out. The image held values between 0 and 255, which was such a small scale that it was difficult to make out. Simply scaling the height made it look proper.
Thanks for the links and the information. So far, I couldn't be happier with having found JME.
Ah, here is what I changed in my copy of ViewJMEXTest, in the event some other person coming behind me is interested:
public TerraView getView() {
tm = getManager();
tv = new SimpleTerraView("my world", tm, taskManager, cam,
getProperties(0.2f, 1), false, loading, -1, rendering, lod,
false);
return tv;
}
Good to see you solved this on your own the scaling is like that cause when you want to generate detailed terrain you need a smaller scale…
I also updated the start post with a link to the development thread, should have done that sooner!
Has anyone looked at World Of Warcraft.
Just wondering what there scale is. If you look closely, there is texture shading to give the impressions of rounded dips and humps.
if you look carefully, it looks as though the pixels between points is roughly the width of a human character ( about 60 cm in real metrics )
WoW terrain uses a geometry model different from the one presented in this engine. This engine is built around a uniform grid of vertices, usually arranged in squares. WoW terrain has at least some optimization on top of that (large planes don't need to consist of lots of squares, so the middle ones can be optimized out withouh any loss in geometry detail). I suspect that with their LOD/geometry model it isn't really important how far vertices are apart from each other, so their level designers might have the freedom to add vertices where they feel more detail is needed, and leave them out someplace else where there's not much terrain variation going on.
This is a half-educated guess only, nothing too scientific (obviously :D)
That all said, I have come to the conclusion that for my own use (yet another huge world (o)rpg) 80 cm square sides are plenty enough for some pretty detailed terrain, I even think about making that 100 cm instead to save even more triangles.
Hi, I'd like to ask something: will theprism's version be completely exchangeable with this one? I mean, if I start using this version and later I want to switch to the new one, I mya have some compatibility problem…
Thanx in advance!
I think theprism changed a LOT of things. It also doesn't have all the features the old version did afaik.