Procedural terrain

Troubleshooting terramonkey
61

done :slight_smile: awaiting critics :smiley:

62

Works nicely for me. Maybe you could prepare the data for the new quads on a separate thread to avoid the “freeze frames” when the new data is generated? Also, its not really endless as you will hit the float accuracy barrier some time, no? Coordinates will just rise when I continuously move in one direction, right? Any ideas on how to keep the coordinates in a sane area? Like resetting to zero over a certain threshold or something? Apart from that, amazing work, endless terrain with physics, awesome :D.

Edit: Ah, and is the physics optional? I guess some people dont need/want a physics collision shape. Didn’t look yet at the javadoc, maybe you can write one or two sentences about this system on the wiki?

Edit2: Also got these, but I think you already mentioned it as “Known Issue”:

http://i.imgur.com/dbpo7.png

63

Works well for me anthyon.

I have the same issues/comments as normen has.



I’m thinking we can make the grid implementation the base terrain implementation. Most users will probably want just one terrain quad group, but if they decide otherwise, they can attach more of them. Mostly thinking in terms of adding this to the terrain editor and allowing the user to “grow” their terrain without starting from scratch.

64

Thanks :slight_smile:


  1. some quads are not translated to their proper location (sometimes they can be found elsewhere, maybe the LOD update runs parallel in a thread and miscalulates the position based on the previous quad? I could not track it down yet. :confused: )


  2. As far as I know true infinity does not exist in computer science :smiley: But the terrain can be made so large that the user can get lost easily :smiley: I’m using 3D noise (x, y, 0) for generation of 2D map, so when it comes near the float accuracy barrier I think it can easily shift the third component and start calculating back the x and y coordinates that would provide “barrier”^3 cells instead of ^2. Also the barrier can be a parameter, so the user can scale what is acceptable for him/her. :slight_smile:


  3. Physics: the update looks for a RigidBodyControl attached to the terrainGrid. If found, its physicsspace is saved temporarily, the body is removed from it, and after the changes made, a new body is created and added. I could not find a way to replace the data in an existing RigidBodyControl. :confused: This also means, if the control is not found, no action is taken regarding physics. :slight_smile:


  4. Temporarily I gave upon realtime procedural terrain, until I find a fast and procedural way of erosion (which seems impossible from what I learnt recently, but still hoping :smiley: ) So currently it runs on pregenerated heightmaps as you can see. A benefit of doing it from heightmaps is, that they can be altered later (by the developer or even by the endusers shooting missiles for example.) So I would like to stick to using procedural technics to generate a terrainquad if it’s the first time it is accessed, and served from the heightmap data otherwise.
65

Cool. About the RigidBody: You just need to generate the CollisionShape, not the whole Body, you can do that on another thread too, then use setCollisionShape().

66
anthyon said:
1. some quads are not translated to their proper location (sometimes they can be found elsewhere, maybe the LOD update runs parallel in a thread and miscalulates the position based on the previous quad? I could not track it down yet. :/ )

It's probably not the LOD messing them up; it just changes the indexes of the geometry, not the position or vertexes.
67

okay, to test if it is or isn’t LOD, just don’t add the LOD control to terrain and see if that changes it.

68

@normen: I tried that :wink: did not work… I’ll run a second round later…

@Sploreg: I’ll try to do some tests to see if the translation is working well. :confused:

Edit: but first I deactivate LOD :smiley:

69

OK… with the LOD disabled I could find no misplaced quads. I’ll upload the modified test in a few minutes, also with physics disabled, so the cam look farther. :slight_smile: Could you please confirm that it works?

70

If this is a threading issue maybe the LOD update can get some callback interface so all of this type of parallel processing can share one thread. This would also solve the problem of sequential processing.

71

I’ll try one more thing out… I just saw that I misused the update(Vector3f) method from the LOD control… I create my own control, and see if the issue can be resolved that way… (I doubt it, but I need to separate my code from the LOD )

72

finally…



I have kept the whole update process in the lod update cycle, as somehow calculating the new tiles are related to the lod in my opinion. Also I have implemented the new tile loading as Runnable and install a new thread in the TerrainQuad’s executor. It still needs some optimizations, but the performance is much better. :slight_smile:



I have also created a new class hierarchy based on noise generated heightmaps. Don’t know if you’re interested in it. :slight_smile:



I’ll upload the files as soon as I have cleaned up the code.

1 Like
73

Cool :slight_smile:

74

updates committed to svn. I need someone to confirm, that it works :slight_smile: And I have added a noise.jar I created, as I could ot find the right place to put the sources to, and it can be used for more than just creating terrains. :slight_smile:

75

just tested it, works and looks awesome :slight_smile:

76

The alphamap that is provided for terrainQuads does not map nicely to TerrainGrid, so I have committed my own material definition I called HeightBasedTerrain.j3md with a vertex and a fragment shader. The triplanar mapping is from the original shader, but I’m mapping the textures using the fragments height (inPosition.y) and it’s normal vector (slope information).



The test is updated to use this material.

1 Like
77

Its orgasmic :stuck_out_tongue:

Awesome work!

78
anthyon said:
The alphamap that is provided for terrainQuads does not map nicely to TerrainGrid, so I have committed my own material definition I called HeightBasedTerrain.j3md with a vertex and a fragment shader. The triplanar mapping is from the original shader, but I'm mapping the textures using the fragments height (inPosition.y) and it's normal vector (slope information).

The test is updated to use this material.

Oh excellent, that material will be very useful.
79

Excellent! and very fast, good work!

80

The terrain now only works on OpenGL3? I cannot run the TerrainGridTest anymore…