Procedural terrain

@dpwhittaker

That is a good idea for modifying the editor. I won’t do it yet, no time for it at the moment. But it is open source so I hope people can submit some code to help improve it. Fingers crossed :slight_smile:

Much more will have to be changed in JMP to allow for infinite maps: centering on 0,0,0 and moving the map when the camera moves to not lose accuracy.

Well hopefully TerraMonkey takes care of that bit at some point and in jMP you then set like “terrain location” or something?

@anthyon

The TerrainQuad in TerrainLodControl is temporary, I forgot to remove it. It is supposed to refer only to Terrain, and I need to make Terrain extend Savable.

Thanks for pointing it out.

Well I had to put the terrain things aside for a few days, and work on other parts of our project as we’re getting out of time. :slight_smile: Also it was good for me to think over how much we need true infinite terrain. The first steps we made are promising, but has many drawbacks, so we’ll be using the current code to produce as large heightmaps as we can. This way the alphamaps and such can also be generated with no extra cost, and we’ll stick to the current terrain system.



But… as the terrain will be still large, we’ll need that “paging” option @Sploreg talked about. Are there any documents or code samples on how to do it in the most effective way?

anthyon said:
But... as the terrain will be still large, we'll need that "paging" option @Sploreg talked about. Are there any documents or code samples on how to do it in the most effective way?

No documents yet on how it could be extended, although I have posted on the forum a few times how it can be done. I'm looking for those posts and I will link to them when I find them.
I can also write up how it could be done again if the posts aren't enough. I should have time to do that tomorrow. Just remind me if you don't hear from me :) It's the busy time of year at work and I often get sucked into very long days.
Sploreg said:
I should have time to do that tomorrow. Just remind me if you don't hear from me :) It's the busy time of year at work and I often get sucked into very long days.


I tried to do my homework alone using the search function on the forum but I could not find anything for terrain chunk neither terrain paging, so if you could look up the links for me, it would be a great help :)

damn, I can’t find the message either.

Ok, here is the gist of what has to be done. TerrainQuad has several methods, that are used for LOD, for getting the neighbours. So if there is a grid of terrain quad trees, they will need to be able to go over to their neighbours by leaving the current tree. The methods that will have to change are:

findRightQuad()

findDownQuad()

findTopQuad()

findLeftQuad()



Right now they stop when they hit the edge of the tree, as you can see in this code:

[java]

protected TerrainQuad findDownQuad() {



else if (quadrant == 4) {

TerrainQuad quad = pQuad.findDownQuad();

if (quad != null)

return quad.getQuad(3);

[/java]

You can see in this code it doesn’t return a quad if there isn’t one below it. The findQuad() methods should change to get the next quad tree neighbour, and traverse that tree then.

Also in the find
Quad() methods it stops if it is at the parent. Here you have to change it too go over to the neighbour.



So I can see having a class on top of TerrainQuad, that allows for quad tree neighbours to live in a grid. And also changing find*Quad() to not stop when it is at the top of the quad tree, but to continue onto its quad tree neighbour, if it exists.



I believe the patches might cache a reference to their neighbours… that reference will have to be removed if a quad tree is removed from the scene.



I hope that helps. And when you start implementing it, feel free to poke me and I can help out. I can give you my gmail IM id to make it easier, if you would like.

Thanks… I took a short look at the code, and sketched up a TerrainGrid class that’s extending the TerrainQuad - so it can be used almost anywhere. I plan that it will hold an instance of a real TerrainQuad as center and delegate all method calls to this, except the find*Quad-s, and will contain the 8 surrounding quads. But it will not work with a simple heightMap array, so I prepared a HeightMapGrid interface as well, that has only one method: getHeightMapAt(Vector3f location).



In the TerrainGrid.update I’ll check if the camera is still in the center quad and update the center and it’s sourroundings as necessary. But, the update takes a list of camera locations. Does it mean I have to maintain as many 3x3 quads?



I’ll be able to spend more time with it after easter. But I just wanted to know, I’m heading the right direction. :slight_smile:

1 Like

The list of cameras is if you have multiple views in the scene (ie split-screen), and want to have the LOD work from each of those camera positions; so one camera doesn’t solely affect the LOD causing chunky terrain for the other camera if it is a long ways away. It’s not fully implemented right now, so it can probably be removed. But I know as soon as I remove it then someone will post wanting to add in multiple camera LOD support :stuck_out_tongue:



It looks like you are on the right track, and yes you will have to abstract out the heightmap array. If your attempt here works out, I would like to add it into the terrain classes permanently, as a default feature.



I will be online most of this week, so feel free to message me with questions.

cheers :slight_smile:

Well, it’s just started to work on my machine :slight_smile: the LOD handling seems to be broken, but I have to check a few methods if they’re redirected to the right places. But one thing seems to be a little problematic:



When I use simple terrainQuads, I can create RigidbodyControls easily to check for collisions. But in general this terrainGrid will be changing from time to time, so shall the physics control atteched to it. What’s the best solution? I can create a usePhysics(BulletAppState) method, and everything can be handled inside if this is set to non null value. Or is there any control that can be notified of the changes inside the terrain, and can do it separetly?



thanks

I’m not sure if there is a listener for when a physics control is removed. Maybe bullet physics master @normen has an idea.

I had a second round around the problem and collected a few more requirements.


  1. The physics engine should be notified and the corresponding PhysicsControl should be updated as the grid moves
  2. Also the whole world should be notified as well, so objects on unloaded parts of the grid can be freed, and objects on new grid elements can be loaded as needed.
  3. If the terrain implements the requirement to be centered around the origo (Vector3f.ZERO), then also the whole world should be notified, so it can update the localtranslation of it’s objects.



    The first that came to my mind, is that I can create a callback interface, that can be registered with the terrain grid so I can notify every listener on changes.



    That’s what I came up with so far. :slight_smile:

Ah yes, all the objects in the world will want to unload too. Fun times! :slight_smile:

A callback interface is the way to go.



Zero-centered terrain won’t be used by as many people, so I wouldn’t spend too much time on it now. It also will cause issues in jMP. Speaking of which, I will have to modify the terrain tools to handle the grid terrain.

the infinite, procedural terrain with editing and saving in compressed formats been done before, including lod, near intinity and massive multitexturing.perhaps a look at culling is in order, this is the part thats really missing in terrain systems.

@lanmower: if there’s a real infinite terrain based on jme3 then please show me, I don’t want to reinvent the wheel. :slight_smile:

I’m progressing with the TerrainGrid really fast. I guess next week I can provide some stable codes. Until then here are a few new videos from my updated procedural terrain generator. (I generate only heightmaps now with a small C utility I created, cause the Java versions were too slow. :frowning: )



http://www.youtube.com/watch?v=yk2q3GuJiso



http://www.youtube.com/watch?v=TrC7026A2NE

anthyon said:
(I generate only heightmaps now with a small C utility I created, cause the Java versions were too slow. :( )

Lol? Why is that? You do something wrong in the java version ^^ Theres no reason c code should be faster than java code.. Actually with JIT java code is faster.
normen said:
Lol? Why is that? You do something wrong in the java version ^^ Theres no reason c code should be faster than java code.. Actually with JIT java code is faster.


I might be wrong, but I was taught, that compiled c code is much faster, than running java code in a virtual machine (JVM)... I'm using this code outside the java project just to create pngs.

I have a serious licencing problem though... I'm not quite familiar with the different opensource licences. :( I found a library that is licenced under GPL, and has some great stuff for generating terrains. Also I found the document that describes only the algorithms. I understand that using the library I have to release everything under GPL as well. But if I just seperately create png heightmaps, are those derivative works? Or if I simply build my own implementation based on the documents they provide?

Yes, GPL makes your code GPL too, LGPL you can use as a library without forcing your app to become GPL. Your knowledge/prejudice about Java is from the pre-1.4 era of java. As said, java now uses a JIT compiler / HotSpot VM to compile the code to native code before its executed. Since it then knows the exact architecture of the platform being run on its optimized for that platform too, not optimized for some platform you select on compile (as with C or C++).

ok, so I cannot use the codes, if I don’t want to go GPL which is not compatible with JME (neither my plans). But what about the paper itself, if it does not mention any licencing stuff? Can I reimplement the algorithms scaled to my needs? Sorry for this, but I would like to avoid any trouble. :slight_smile:



So if that’s true for java, then I guess I have to review my codes, and find more ways to optimize it. :slight_smile:

Well since you now said you looked at the code that would arguably be a violation of their rights… Back when people copied the BIOS of IBM PC’s to offer compatible machines the programmers had to prove they did not look at the code in the original IBM BIOS to be able to use that… So back engineering is ok, just looking at the code, copying it and renaming some variables is not :confused: