How terrain editor works when each patches are different Geometry?

Hi Guys,
This might be the silly question but I want to know how procedural or any terrain editor works.

I am trying to make Hexagonal tilled terrain. Each hexagon tile is geometry which carries mesh data.
In my implementation I have created one hexagon tile and deep cloned to create its neighbour tiles.
Now I have number of tiles added in one node called terrain. Every mesh in terrain has same data because I have cloned them from one copy, If I iterate through each mesh data I’ll get Vertex3f(0.0, 0.0, 0.0) at first index as its centre of Hex Mesh.
e.g. See below image. There are hex A, B and C are cloned copy of one hex mesh. now the coordinates at local level are cloned but same as original for all hex mesh. In image the coordinates of Edge L of A will be same as Edge L of hex B.

The Edge R of hex A and Edge L of hex B seems to overlapping because each geometries are places accordingly.
If I want to raise the height of Edge R of hex A than I need to raise the height of Edge L of hex B to show that terrain is single piece because these edges are connecting two tiles.
In my Implementation one single mesh has almost 3000 vertices, so there are hundreds of overlapping vertices.

So how to identify those overlapping vertices at local level and apply same height while editing terrain?
Sorry if my question is not understandable…

You know. If I didn’t know any better I’d almost say you’re attempting something very similar to what I’m trying since I ran into this issue (and solved don’t worry :wink: ) just a week ago.

What my solution was for this very issue was when I was making custom shapes I first made a system in which to generate all the vertices and plop them into a common array of vertices (remember Java passes stuff by reference). My process went like this:

  1. Generate the first shape and add all points to a common array.
  2. Make the next shape but when I generate the vertices for that shape check the common array for identical points
    2.1 If point is not in array create point and add to array.
    2.2 If point is IN array make that point in this shape equal to the found point.
  3. Rinse, lather, repeat for each shape.

To optimize this a bit for my shape I made 2 arrays. 1 was all the points and the other was just the edge points that could be used in other shapes. This just ensured that in my shape there was like 1/1000th the number of points to scan through.

In your case when you go to edit a height you’d just see where your mouse is pointing, find the nearest set of points (vertices), alter their heights and voila. All the shapes that use those common points would be altered.

I’m sure that there are other techniques out there but this was the way I did mine.

In JME’s terrain editing, the editor is modifying an array of heights (in MVC this is the ‘model’) and then the meshes are rebuilt from their section of the heightmap array (sort of)… that would be the ‘view’ in MVC.

It’s not editing the mesh directly. It’s editing an underlying data structure. You should do the same.

huh. Cool. So I basically reinvented the wheel with my code. Awesome. :blush:

Heheh…

There are two kinds of developers… those who understand and use MVC and those who will soon understand and use MVC. :slight_smile:

1 Like

I also thought something similar little bit as you two suggested.

  1. Clone the Mesh & Geometry.
  2. Add all tiles to main node(Terrain)
  3. Go through each attached hex tile and prepare mapping data like prepare extra array as world coordinates where each index array points to original local position.
    I have some fear complex with adding extra bulky data to visual objects.

Edit: Is it possible to prepare world coordinates before attaching it to main node?

What I ended up doing for that was I made a new “node” class that was a collection of the meshes I needed to create my shape. Then you just attach the node to the root node in your main application.

This lets you do all your complicated math or whatever isolated from the rest of the code. :slight_smile:

BTW here is initial screen shot of my program.

Hi, what should be the ideal vertices count per tile of 32.0f radius for performance as well as quality?

here is rough test of subdividing triangles until it crash.

Subdivision: 0
Subdivision End with vertices: 72

Subdivision: 1
Subdivision End with vertices: 288

Subdivision: 2
Subdivision End with vertices: 1152

Subdivision: 3
Subdivision End with vertices: 4608

Subdivision: 4
Subdivision End with vertices: 18432

Subdivision: 5
Subdivision End with vertices: 73728

Subdivision: 6
Subdivision End with vertices: 294912

java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:693)
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
at com.jme3.util.BufferUtils.createFloatBuffer(BufferUtils.java:872)
at com.jme3.util.BufferUtils.clone(BufferUtils.java:916)
at com.jme3.util.BufferUtils.clone(BufferUtils.java:90)
at com.jme3.scene.VertexBuffer.clone(VertexBuffer.java:1024)
at com.jme3.scene.Mesh.deepClone(Mesh.java:246)
at mygame.HexTileMesh.clone(HexTileMesh.java:56)
at mygame.HexTile.clone(HexTile.java:180)
at mygame.HexTerrain.createClone(HexTerrain.java:180)
at mygame.HexTerrain.addAsGrid(HexTerrain.java:154)
at mygame.CustomMeshDemo5.simpleInitApp(CustomMeshDemo5.java:146)
at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:220)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:130)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:211)
at java.lang.Thread.run(Thread.java:745)

Unless someone corrects me that is a pretty complicated question to ask since the answer is “Whatever works for you.”

Scale in a game is kinda up to the developer. For instance in my game I’m making a planet. It has a radius (right now) of 8.0f. Does that mean that your tile is larger than my planet? I mean… Yes. Based on the float you set. But in my game I’m saying 8.0f is roughly the radius of the planet earth (for now).

So vertice count per tile for quality depends on what effect you’re trying to achieve and the detail you require.

I mean if I target to make game for an ordinary graphics card… and my plan to make about roughly 50Km2 of open world area. for this I’ll need lot of tiles so I can’t load all tiles at a time.
Now even if I scale down my scene may be like from 1 meter as 1 unit to 1 km as 1 unit, I still need to decide should be in single tile because it will impact on loading unloading tiles.

Edit: My plan is to load 3 layers of tiles surrounding to central tile. the central tile will change as player moves. the last layer will be very low quality ( almost 1/4 of actual triangles ) , second last will be 1/3 better, second layer will be 1/1.5 and central tile will be hugest quality. this is rough idea.

What would you classify as an ordinary video card though? I mean… there are literally hundreds of video cards currently available. I’ve heard people just assume that video cards have around 1 gig of memory as a safe number if that helps.

Welllllllllll this part can be solved with a neat thing called Load On Distance (typically shortened to just LOD). This can handle downsizing things so when/if you load all sorts of stuff your videocard doesn’t get overwhelmed with too much stuff and down samples the geometries. You can find a bunch of resources on LOD in these forums and the Wiki.

Given your edit text there you almost definitely want to use LOD.

LOD stands for “level of detail”. In that at different distances, you might have different levels of detail… but there can be lots of reasons to switch LODs.

That shows me for just googling the acroynm and going with the first one that fit. :expressionless:

My google must be seeded differently. :slight_smile:
http://imgur.com/Kr406ZU.png

Even better. The first hit I had was in a thread… Where the first comment literally is “I think LOD actually stands for Level Of Detail”… Sooooo ya. I’m doubly dense today.

/me scratches note down “never give advice out on a Monday”