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.

Code Snippets / [DBP] LOD terrain code

Author
Message
hmm
20
Years of Service
User Offline
Joined: 11th Oct 2003
Location:
Posted: 18th Feb 2009 03:17
Hello,

Been playing with the idea of LOD lately and I love big/endless worlds so used the vertexdata commands to have an automatically updating terrain mesh with different levels of detail further from the camera. Significantly reduces the number of vertices needed for big terrains (i.e. 512x512, 1024x1024) and gives great speed.

As yet to add height, texturing and normalisation to the code but should be very simple.

look with mouse and move forward/back with LMB/RMB. Hope it is informative. Will post updates soon.

Kohaku
19
Years of Service
User Offline
Joined: 3rd May 2004
Location: The not very United Kingdom
Posted: 18th Feb 2009 19:46
Nice code!

I plan on delving into this myself at some point for a new level format that I'm thinking up.

Look forward to seeing the updates.



Mr Tank
21
Years of Service
User Offline
Joined: 25th Nov 2002
Location: United Kingdom
Posted: 19th Feb 2009 00:54
That's really nice. Runs fast. When you go over the far edges of the terrain, it doesn't seem to do the best it could - the edge of the terrain doesn't have the smallest divisions. Other than this works great.

I guess your heightmap will have to have variations that scale such that the size of the variations is proportional to the length over which they change. A perlin type thing would be good for this.

Mr Tank
21
Years of Service
User Offline
Joined: 25th Nov 2002
Location: United Kingdom
Posted: 19th Feb 2009 04:59
BTW i you you can write >>n instead of /(2*nstep) for a pretty much unmeasureable speed boost. I'm going to have a proper read through this tomorrow hopefully. It's really impressive.

Back when i was making my flight sim thing, i using around a 22 by 22 matrix and hitting framerate limits. You could fly up into the sky and blatantly see the whole map. With a system like this i could make something way better.

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 19th Feb 2009 15:28
You need to add frustum culling. LOD doesnt make as much difference in FPS as Frustum culling does. Indexbuffering is also a good improvement in FPS. Very nice work though. My LOD terrain system is about 2500 lines long you seem to have the very basics done in under 250.

Mr Tank
21
Years of Service
User Offline
Joined: 25th Nov 2002
Location: United Kingdom
Posted: 19th Feb 2009 16:47 Edited at: 19th Feb 2009 16:47
kaedroho - how do you do index buffering? I googled it, and it seems this is the jargon for the superior way memblock meshes used to work in DB classic, with a sixth the number of vertices. I don't know how to use this format in DBP. If you can link me to some info then i'd really appreciate it.

I imagined the "frustrum culling" wouldn't be too great an idea since, you'd need to change the terrain as you rotated the camera, which could require a lot of change, instead of altering a few polys as you move. Perhaps i am wrong though. If you can change most of the vertices in a single frame then this is great!

kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 19th Feb 2009 18:17
I used a command called 'make object new' in the matrix1utils. Find them in the dll talk section.

Splitting up your terrain into smaller "sectors" seems to be the only way I could find on doing Frustum Culling. Thats what I use and it all works fine (check the sig and download the demo).

CuCuMBeR
21
Years of Service
User Offline
Joined: 11th Jan 2003
Location: Turkey
Posted: 20th Feb 2009 18:53
nice code, but there is something terribly wrong with the uv coordinates

There is always one more imbecile than you counted on.
hmm
20
Years of Service
User Offline
Joined: 11th Oct 2003
Location:
Posted: 20th Feb 2009 19:17
Thanks for the comments guys!

Have added a simple heightmap to it and it works straight off. Very nice.

@ CuCuMBeR: Haven't really done UV's properly yet. Since I hope to use the Texture Splatting Dll thats floating around I'll need to do some UV thats based on overall world position of each vertex. May kill my computer.
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 20th Feb 2009 19:17
Thats pretty easy to correct. Just use:

u=x/terrainsize
v=z/terrainsize

Siddy
15
Years of Service
User Offline
Joined: 16th Dec 2008
Location:
Posted: 22nd Feb 2009 14:00 Edited at: 22nd Feb 2009 14:02
I like what you have done.

But the LOD is based on the camera's position only on one plane. This works fine if the camera is locked to close proximity to the map, but not if the camera moves away from the map (ie, a birds eye view).

I think this pic explains what i am saying:


Note how the LOD directly bellow the camera is still high.
Maybe after the camera moves a certain distance from the base level the LOD should be set at lowest?
Monk
15
Years of Service
User Offline
Joined: 25th Sep 2008
Location: Standing in the snow =D
Posted: 22nd Feb 2009 22:25
Im sure that would be easy enough to solve, just add a height check

What a uv co-ords?

Login to post a reply

Server time is: 2024-05-02 04:01:18
Your offset time is: 2024-05-02 04:01:18