Large Terrain maps?
Author
Hello All
I have played about with OpenGL for a little while now, and I was thinking of getting into terrain maps.
I have brought a couple of Terrain programming books, but they seem to only show you how to do small maps like 1024 x 1024 using height maps.
I have tried to use larger height map files but that just seems to hammer me machine.
I have noticed that games like Starwars Galaxys and World of Warcraft etc use massive terrain maps.
Are they using a single massive map or are they using multipul of maps overlaid next to each other to look like its a massive map?
I would be gratefull for any help.
Thanks in advance
Paul
I know you can use doubles instead of floats to create larger maps, but this will not improve speed issues.
I am pretty new to 3D code with just a few months under my belt.
When dealing with overall speed of terrains, improving code is where I gained most my improvments. Culling, not computing verts more then once, reduction of triangles read over distance...
I am currently working on a map editor for large worlds if I come across anything I will keep you posted.
I am pretty new to 3D code with just a few months under my belt.
When dealing with overall speed of terrains, improving code is where I gained most my improvments. Culling, not computing verts more then once, reduction of triangles read over distance...
I am currently working on a map editor for large worlds if I come across anything I will keep you posted.
and allso for your information, a heightmap of 1024x1024 yealds over 2 million polygons.
There are no computers today that does not feel a little bit stressed out when rendering this mutch.
Most gamed that uses heightmap rendering uses something called pageing landscapes.
It's an array of small terrain pices, perhaps 256x256, that sit's end to end.
This is primarily done for memory management reasons and to make it easier fo it to be dynamicly loaded.
When it comes to rendering i suggest using VBO's, on a fast card it will beat any dynamic mesh resolution reduction method, if you feed it optimal meshes(tristrips) that is.
Allso when it comes to wow and starwarsGalaxies, they don't have that mutch of a highrez mesh, there is probobly something around 1 meter between each vertic, witch makes a 1024x1024 mesh reach over one kilometer, and you can rarely see that long in these games, you just gotta love that fog.
There are no computers today that does not feel a little bit stressed out when rendering this mutch.
Most gamed that uses heightmap rendering uses something called pageing landscapes.
It's an array of small terrain pices, perhaps 256x256, that sit's end to end.
This is primarily done for memory management reasons and to make it easier fo it to be dynamicly loaded.
When it comes to rendering i suggest using VBO's, on a fast card it will beat any dynamic mesh resolution reduction method, if you feed it optimal meshes(tristrips) that is.
Allso when it comes to wow and starwarsGalaxies, they don't have that mutch of a highrez mesh, there is probobly something around 1 meter between each vertic, witch makes a 1024x1024 mesh reach over one kilometer, and you can rarely see that long in these games, you just gotta love that fog.
Anything to render less vertices will help, but also spreading the vertices out as much as possible will help you render larger areas -- just a warning: larger vertex distance means less detail.
Also, you might want to read Chris Taylor's article entitled "The Continuous World of Dungeon Siege" about creating a massive world. I am sure the techniques in WoW and Galaxies are fairly similar: loading parts of the map on the fly and dealing with rounding and accuracy issues at great distances from the origin.
Here is the link:
The Continuous World of Dungeon Siege.
Also, you might want to read Chris Taylor's article entitled "The Continuous World of Dungeon Siege" about creating a massive world. I am sure the techniques in WoW and Galaxies are fairly similar: loading parts of the map on the fly and dealing with rounding and accuracy issues at great distances from the origin.
Here is the link:
The Continuous World of Dungeon Siege.
Author
Quote:Original post by visage
Anything to render less vertices will help, but also spreading the vertices out as much as possible will help you render larger areas -- just a warning: larger vertex distance means less detail.
Also, you might want to read Chris Taylor's article entitled "The Continuous World of Dungeon Siege" about creating a massive world. I am sure the techniques in WoW and Galaxies are fairly similar: loading parts of the map on the fly and dealing with rounding and accuracy issues at great distances from the origin.
Here is the link:
The Continuous World of Dungeon Siege.
Thanks, I will read that tomorrow after work.
Author
Quote:Original post by lc_overlord
and allso for your information, a heightmap of 1024x1024 yealds over 2 million polygons.
There are no computers today that does not feel a little bit stressed out when rendering this mutch.
Most gamed that uses heightmap rendering uses something called pageing landscapes.
It's an array of small terrain pices, perhaps 256x256, that sit's end to end.
This is primarily done for memory management reasons and to make it easier fo it to be dynamicly loaded.
When it comes to rendering i suggest using VBO's, on a fast card it will beat any dynamic mesh resolution reduction method, if you feed it optimal meshes(tristrips) that is.
Allso when it comes to wow and starwarsGalaxies, they don't have that mutch of a highrez mesh, there is probobly something around 1 meter between each vertic, witch makes a 1024x1024 mesh reach over one kilometer, and you can rarely see that long in these games, you just gotta love that fog.
Thanks for replying.
Ok, so if I create a heightmap of say 16384 x 16384 I could spice them up into 4096 peaces of 256 x 256 which could get loaded up when in the area before that section?
Well something on those lines.
Thanks in advance
Paul
A real simple way is just to load the 8 sections around you and the one you are in (Dungeon Siege had "door ways" so you knew which section to load next...which is certainly possible, but harder for expansive, wide open terrain and a FPS view). Then, when you switch sections, load the new 8 around that.
The issue really is storing all those sections in memory -- or coming up with a fast loading system from your HD (which would make sense to load the vertex data from if you have a huge world -- and that is where we get map files from).
The issue really is storing all those sections in memory -- or coming up with a fast loading system from your HD (which would make sense to load the vertex data from if you have a huge world -- and that is where we get map files from).
Quote:Original post by TheMightyDude
Thanks for replying.
Ok, so if I create a heightmap of say 16384 x 16384 I could spice them up into 4096 peaces of 256 x 256 which could get loaded up when in the area before that section?
Well something on those lines.
Thanks in advance
Paul
correct.
However writing a dynamic loading system is not easy though.
Either you load a small part for every frame or create some kind of multithreading thingey.
these things take time to learn.
So might i suggest that you limit yourself to somewhat less absolutley gigantic meshes.
Quote:Original post by visageHere is the link:
The Continuous World of Dungeon Siege.
Well, this ain't my thread, but thanks for this link anyway - very insightful ;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
