Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 15th Jul 2012 18:44
I had a play around with a LOD landscape idea over the weekend. I needed a little break from the relentless Carnage work and was inspired by the Arma engine shown in DayZ. I had a go at this years ago before the VertexData commands were introduced. It just wasn't feasible back then, because the only suitable commands were memblock/mesh commands, and they were way too slow.

Anyway, after a few attempts, I came up with a system which I think has real potential. The concept is basically a bunch of meshes with decreasing resolution, which move along with the camera and are updated from a height map. Where the meshes join each other there are some funky transition vertices which are moved about to create seamless joins.

In this vid I have a 3km map and a 1km draw distance, with 1 grid square = 1 meter. I've literally just got the mesh component working (with normals), but haven't even started to think about texture blending and all that stuff.

The coolest thing is this runs between 1300 and 1500fps on my 9800GT. I literally was blown away at how fast it was. I could easily double this draw distance to 2km with very little performance hit. So it has real potential to be a great platform for a massive outdoor game.

Here's a vid ...



The bad thing is I'm unlikely to do much work on this for some time, as I'm putting all my efforts into Carnage. But every now and then I may revisit this at weekends and build on it. The next step would be a skysphere to make it look prettier, and then multi-texturing.

Matty H
17
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 15th Jul 2012 19:02 Edited at: 15th Jul 2012 19:03
Ha ha, I too just wrote a LOD terrain system over the last few days

This looks great and seems like huge terrains would not be an issue which is cool.

My motivation was to create a static LOD terrain. You may have a huge map but only one part of the map is highly detailed while the rest gets less and less detailed into the distance. This would be for a game where all the action takes place in a specific area but the landscape goes on for miles.

Once I completed it I realised is was only a little extra work to turn it into a dynamic LOD system, so I did that too.

My method is similar to blitz terrain I think, although now I think your method has some advantages. I think your method would be less memory but more real time manipulation of vertices which may not be quite as fast? And huge seamless maps would be easier with your system of course.

Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 15th Jul 2012 19:57
Everyone wants to make a terrain engine. We all dream about being able to create a Skyrim or Arma landscape so we can realise our crazy visions for interactive mega worlds. Not surprised you made one too!

The only system I know if is "Chunked LOD" where the map is split into loads of meshes, each with different levels of detail and the closer you get to them, the more detail they show. Is that how Blitz terrain works?

There are a bunch of things I don't like about that:
1) You have to have all these premade meshes, or you make a load of meshes on the fly from height data.
2) Large portions of the map suddenly change their geometry, resulting in noticeable detail changes.
3) There are issues with the seams between different meshes which seems tricky to resolve.

This system seems to avoid all of those issues. Only thin lines are updated as the camera moves, reducing noticeable geometry changes. Also there is just the one set of meshes in memory which are updated, and since all the meshes are connected already (have touching vertices), there are no seam issues.

Two negatives are:
1. It is really only for FPS or "Close to ground" games, because the meshes directly beneath the camera will always have full detail. This isn't much of an issue, but it isn't as efficient as a chucked lod system, which would reduce detail on that mesh as you went up.
2. It has a finite draw distance, where as chunked LOD could show the whole map. This is limited by the meshes made.
3. Also, as you said, there is definitely a performance overhead with having to update the meshes. This is really negligible though, as shown in the 1500fps frame rate.

The other positive is the landscape can be as big as the heightmap you can store, since there is no extra mesh data for larger maps.

Here's a quick wireframe example.


Matty H
17
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 16th Jul 2012 00:12
Quote: "The other positive is the landscape can be as big as the heightmap you can store, since there is no extra mesh data for larger maps."


Agreed, this is a good feature. You could hold your height data in a file or on-line and have mega worlds

Quote: "3) There are issues with the seams between different meshes which seems tricky to resolve."


This is a problem, you can change the index data around the edges of each mesh(and remove 1 triangle), so the resolution is the same at the edge as the adjacent mesh of 1 detail level lower. This gives you a seamless join but you can only drop resolution 1 step at a time or it does not work. I think Blitz Terrain calls this 'quad rotation'.

I have not implemented that method yet. I just have it so you can lower the edges of the lower detail meshes, this hides gaps and works pretty well. It's not as elegant a solution but you can drop detail as much as you like and it still works within reason, more fps.

Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 16th Jul 2012 09:54
Quote: "I have not implemented that method yet. I just have it so you can lower the edges of the lower detail meshes, this hides gaps and works pretty well. It's not as elegant a solution but you can drop detail as much as you like and it still works within reason, more fps."


I think when I was trying a solution like this years a go, I averaged our the heights of the higher res mesh. So if a 4x4 mesh buts up against a 1x1 mesh, the verts on the 4x4 mesh that meet the 1x1 mesh verts will be the same height. The remaining verts along that edge are a smooth gradient between the two, so it matches the 1x1 edge.

Really happy with my solution though. I'll have another look at this next weekend if I need a Carnage break.

mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 16th Jul 2012 11:30 Edited at: 16th Jul 2012 11:33
I saw an interesting solution for anno 1404, i'll try to post it later (video)

«It's the Pony, pony me this, pony me that» — Bronies
«Socks are sexy. You should wear them!» — Bronies
«I sell apples and apple accessories» — Applejack
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 16th Jul 2012 23:57
Looks like a neat method. I'll try to remember to use something like this.
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 17th Jul 2012 04:18
Anybody remember Delta Force?

how on earth did they do their terrain? I ask because what was mentioned in the OP reminded me of it... and the video too...

love this, keeping this in mind too...

enderleit
19
Years of Service
User Offline
Joined: 30th May 2007
Location: Denmark
Posted: 17th Jul 2012 08:34
Quote: "1. It is really only for FPS or "Close to ground" games, because the meshes directly beneath the camera will always have full detail. This isn't much of an issue, but it isn't as efficient as a chucked lod system, which would reduce detail on that mesh as you went up."

Couldn't you just reduce the LOD as you get farther from the terrain, height-wise?

mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 17th Jul 2012 11:36 Edited at: 17th Jul 2012 11:40
Sorry guys I can't upload video now, so here it is rough picture of funky method.
It was used for 3d ocean. It would be awesome if someone implement this.
Grid is always fits camera view - we have constant polygon rate.
Height is taken from height map that is projected from sky.


«Socks are sexy. You should wear them!» — Bronies
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 17th Jul 2012 12:28
That sounds a very interesting suggestion. I like it.

It might wreak havoc with some of my shaders which assume a simple rectangular grid but it should be possible to get around that.

I might try implementing your suggestion before trying the other ideas. You need to get the maths right of course but it shouldn't be too difficult.
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 17th Jul 2012 15:22
Maybe you find anno 1404 developers video with that technique.

«Socks are sexy. You should wear them!» — Bronies
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 17th Jul 2012 15:44 Edited at: 17th Jul 2012 15:46
Sorry MrHandy. The problem with that technique is the landscape will always be changing. If the grid moves at all, you have to update the points, which results in a landscape that looks like a moving ocean.

If you imagine a flat height map, with 1 single really high point (100 high) in it. When you move the camera and your grid moves, that point will move between the grid vertices. When it is in the middle of a grid square, between 4 vertices, what do you do?
a) Average out the heights, so the verts on the grid square around that height point are an average between 0 height and 100? The result is a grid with heights changing all the time. (Wavy ocean terrain!)
b) Set all four grid verts to that height? So you end up with blocky, then sharp, blocky, then sharp geometry, with the blocks jumping around as different verts suddenly map to the high point.

It just won't work. The grid needs to marry up precisely with the height map, otherwise the geometry will change and not work. The trick is to make the minimum possible movements/changes to the grid, for performance and visual quality reasons.

As it stands, the method above is a fixed poly rate anyway. The meshes are premade and no verts are added/removed and no indice data is changed. It just jumps, based on the view of the camera, in steps according to it's resolution. So the mesh that is 8x8 units per grid square moves only in jumps of 8 units. If it moved in a jump of 1, then it'd constantly be mapping to different height points, and you'd get the strange wavy ocean effect.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 17th Jul 2012 17:10 Edited at: 17th Jul 2012 17:16
I take your point but most terrains will change height slowly in which case accurately interpolated points might not jump about noticeably if at all. I agree there will be problems near cliffs and ledges - but not elsewhere. I'll reserve judgement till I see it in action. A lot depends on the no. of polys used I guess.

Also, I'm surprised at the visual defects allowed to pass into well-known commercial games. Things like distant hills jumping in and out of view as the camera changes. Would this be worse than any of those? I guess it might in the foreground.

Edit

Looking at mrHandy's diagram again I see what you mean - the effect you're warning against could be quite noticeable in the middle to far distance.
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 17th Jul 2012 17:32
Anyway it would be perfect for real 3d ocean storm without dx11

«Socks are sexy. You should wear them!» — Bronies
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 17th Jul 2012 18:16
I'd love to see it working though! You have to try these things to find out. It's hard to visualise exactly how it would look so you may come up with a good solution.

All I can say is, when I played around with the design above over the weekend, I went through a few iterations of various techniques. The conclusion I came to was you need to minimize the amount of updating to keep the hills smooth. Every time you resample a height and replot a vertex, the hill is effectively moving, which isn't natural.

Also, don't forget about UV coords. I can't imagine the nightmare required to accurately map textures to a grid that is rotating with the camera! Remember, these need to be in the exact same place if you don't want scrolling grass.

@Green - Yeah, I've noticed a lot of landscape glitching in some top games. It's surprising. Means we can get away with more foul ups though!

Matty H
17
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 17th Jul 2012 18:50
I have the free version of Triton.

I think this uses the technique being discussed. Not sure I've heard of anyone using it for terrains.

I had Triton up and running in Irrlicht with DX9, I might set it up with DarkGDK if I get the chance. Anyway that's oceans, we are talking terrains

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 17th Jul 2012 20:16
Quote: "Also, don't forget about UV coords. I can't imagine the nightmare required to accurately map textures to a grid that is rotating with the camera!"


Doesn't need to be a problem at all - depends on how you've UV mapped the terrain of course. For example, several of my demos just use suitably scaled world XZ coordinates as UV coordinates. In other words if you can calculate the XYZ coords of the vertices you are effectively done regardless of the alignment of the polys.

Some of my other demos might be affected since they use rather different methods of texturing terrains. I'd have to re-examine my old code to see what the effects might be.

It's certainly an issue to think about but hardly a nightmare - quite the reverse really.
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 18th Jul 2012 10:03
Yes, you're right when I think about it. Yes, if you configure your textures in the right way, that'll work fine. You wouldn't be able to use texture atlases, but so long as it's 1 image per texture and 1 texture per layer, that would work fine.

So you gonna have this a bash GG? It'd be interesting to see how it'd turn out. You may come up with some solutions for the problems I outlined above.

mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 18th Jul 2012 11:21
I saw many LOD demonstrations, most of them has vertex issues. For example, steep hills in the distance were looking like spikes due to vertexes lack.

«Socks are sexy. You should wear them!» — Bronies
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 18th Jul 2012 13:24 Edited at: 18th Jul 2012 15:29
Quote: "For example, steep hills in the distance were looking like spikes due to vertexes lack."


I'm sure you're right. That's one reason fog is so useful.


Quote: "So you gonna have this a bash GG? It'd be interesting to see how it'd turn out."


I'm certainly tempted but won't have much time for a while.


Quote: "You may come up with some solutions for the problems I outlined above."


I'll make sure I test the method using an ocean scene.

Edit I've been thinking about how I might implement this and I suspect there's a big problem in deciding how to position mrHandy's grid on an uneven terrain. Once you have the corners I guess the rest is just simple linear intpolation on the XZ coordinates followed by reading the Y coords from the heightmap. But how do you define the XZ coords of the four corners in the first place? I suspect that mrHandy's images were deceptively straightforward cases.

mrHandy Do you have any thoughts on this?
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 18th Jul 2012 20:22 Edited at: 18th Jul 2012 20:24
@Green Gandalf
I've posted an article, it could be useful for you:
http://forum.thegamecreators.com/?m=forum_view&t=198737&b=1

«Socks are sexy. You should wear them!» — Bronies
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 18th Jul 2012 21:16 Edited at: 18th Jul 2012 21:16
Thanks - but water is rather different from terrains. Are you talking about this bit?

mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 18th Jul 2012 21:47 Edited at: 18th Jul 2012 21:49
Yep. Water surface is just xz dimension (zero level). We just need to scew terrain to camera frustrum. Maybe using some snap to avoid noticable dancing vertices during camera movement.

And now I am sure that it can be used as a terrain.

«Socks are sexy. You should wear them!» — Bronies
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 18th Jul 2012 22:20
of course it can, some guy made that in xna and it works great and fast

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 19th Jul 2012 01:33
Good - any chance of some details of how they calculated the four corners?

I suppose you could simply use the XZ coordinates of the view frustum as a starting point and proceed from there. That would be awkward if the camera rotated about its own Z axis.
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 19th Jul 2012 01:37
Quote: "Good - any chance of some details of how they calculated the four corners?"

sorry, i don't remember any details, i read it several months ago

mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 19th Jul 2012 09:10 Edited at: 19th Jul 2012 09:12
I am sure that mesh transition is made in vertex shader. Using screen space data and matrix. But how exactly I dunno. I need to make a research.

«Socks are sexy. You should wear them!» — Bronies
Jane Doe
19
Years of Service
User Offline
Joined: 29th Jun 2007
Location:
Posted: 19th Jul 2012 09:49 Edited at: 19th Jul 2012 09:50
The problem with a terrain LOD scheme that's based on the distance from the camera is that the height and slope of the ground will change as the camera moves around. That's going to cause problems with the trees and buildings and whatever else you put on the terrain.

I suggest using an LOD method based on the how smooth or undulating the terrain is as shown below:



- Jane

Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 19th Jul 2012 10:37
That's a nice idea in theory, and again, looks fine in wireframe or with a flat texture, but how do any of these methods perform texture blending?

If you want grid point 0,0 to be Sand, and grid point 1,1 to be Grass, and you want to smoothly blend between them, how can that be done if the grid resolution is bigger than 1? If a low res grid is used, there is no way to blend between textures in the middle of a polygon.

The same goes for this terrain idea that is adapted from the camera. I can't see how they could achieve nice static looking geometry with accurate blend points.

Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 19th Jul 2012 11:49
the blending is based on a pixel not on a vertex so grid size doesn't matter

Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 19th Jul 2012 13:11
I'd really like to see an example. It sounds very interesting and might be a good technique to have a go at.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 19th Jul 2012 13:18
I agree with Brendy Boy about the blending. I don't see why grid size should affect that at all. How are you doing the blending at the moment? I often use a texture blending map so the blending will be at the pixel level.
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 19th Jul 2012 15:13
When I had a look at this last weekend, I got to a point where I'd added vertex diffuse colour blending. Working on the principle of 4 texture layers, the height map contains opacity settings for each layer in a single DWORD (RGBA colour). Each vertex in the grid then has it's diffuse colour set to this value. The pixel shader then just uses those interpolated colour values and multiplies them against their respective tex2D lookups when drawing the grid.

A texture blending map (in a texture layer) sounds like a good solution. I hadn't thought of that. The only negatives being a layer taken up and maximum resolution. I'd like to achieve landscapes over 5000 units in length. Thinking about it though, so long as the texture required wasn't too huge, it's a very good solution.

Max P
16
Years of Service
User Offline
Joined: 23rd Jan 2010
Location:
Posted: 24th Jul 2012 19:10 Edited at: 24th Jul 2012 19:11
Here is a test I made using projected terrain/water (See attachement).
It looks good when used for water, but when you try to use it for terrain you get a lot of floating points cause the mesh is constantly changing.
It's a bit slow now because I am using a workaround for some math (not that good in math), so if someone can rewrite this function for me that would be a huge help:


Controls:
WASD - Move
Mouse - Look
1 - enable/disable wireframe

Max P
16
Years of Service
User Offline
Joined: 23rd Jan 2010
Location:
Posted: 24th Jul 2012 19:13
Forgot to attach the water texture, put it in the same directory as the exe.

Andrew_Neale
16
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 24th Jul 2012 21:03 Edited at: 24th Jul 2012 21:08
This looks to do the same as what you had before:



[Edit]
I would've assumed an interpolate method would be more along the lines of this where the 'dist#' parameter is a value between 1 and 0 representing how close to complete the interpolation is but without knowing how you're using it obviously I'm probably mistaken!


[Edit]


Previously TEH_CODERER.
Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 24th Jul 2012 21:19
Quote: "Good - any chance of some details of how they calculated the four corners?"

here's the link to the article i mentioned

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Jul 2012 23:48
@Brendy Boy

Thanks. I'll check that out.
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 25th Jul 2012 00:42
Fallout, there's a simple optimisation you can do to speed up your terrain even more

There are multiple ways of implementing it, but the idea is to not draw/update anything behind the camera.

If the camera is guaranteed never to get too high, you can do it by cutting the terrain mesh in half, and then rotating it to multiples of 90 degrees at runtime so that it stays in front of the camera.

A more flexible but less memory efficient way is to divide the terrain mesh into blocks and only update and draw blocks that lie in the viewing frustum.

Also, you could try experimenting with updating the terrain less frequently. If you make two meshes you can hide one and update it very gradually over tens or even hundreds of frames, so that it is ready to be swapped with the visible one when the time comes.

[b]
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 25th Jul 2012 10:44
Quote: "A more flexible but less memory efficient way is to divide the terrain mesh into blocks and only update and draw blocks that lie in the viewing frustum"


That's pretty much what is done already. There are about 40 meshes which are culled if off screen. The updating is really fast though. There is very little changed or calculated. I do update the meshes off the camera, but that's just because it's very fast, and I don't want to have any minute slow downs if the player spins round 180 degrees.

Login to post a reply

Server time is: 2026-07-08 12:26:45
Your offset time is: 2026-07-08 12:26:45