What is the fastest way to render a massive vertex array consisting of more than 10,000 vertices?
Printable View
What is the fastest way to render a massive vertex array consisting of more than 10,000 vertices?
CopyMemory using SSE/MMX instructions maybe?
Indexed read only vertex buffer...? :confused: ? what do you mean?
- ØØ -
Ohhh...saw your other thread now...so this is a terrain. Well terrains is a big science in it self. Well it happens that I know a LOT about the theory here, but NOT so much about the implementation..:)..I am playing with an idea these days and I am reading more about it each day..:)
So if it is a big terrain, then you should devide the terrain up in many pieces. Then use Space Partitioning to find out what parts of the terrain to render. For outdoor rendering I would recomend Quad trees if the terrain is fairly flat, or Oct tree if it is a lot of HIGH mountains.
But the problem comes when the terrain is so big, that it starts to be to big to hold in memory all the time. That is what I am reading up on these days. the best solution I have found so far is to CONSTANTLY have a thread running in the background to read from a file or more that contains terrain info. Your app have to guess what terrain parts the player is going to need next time. So you can see the problem here. The trick is to devide the terrain parts in so small parts that it is possible for the other thread to read it all in before you need it. You probably understand that it is not possible to start reading it in from a file WHEN you need it. Then your whole app will stop each time you move over to a new terrain part.
Well, hope that helped you a bit.
- ØØ -
Im going to split up the massive vertex array into chunks and render it using partions. Ill see how that goes first.
See attachment, I got it working ;)
The map is a 128x128 heightmap. Split into 16 partions, so each partion is 32x32.
Partion 0 contains 5766 vertices
Partion 1 contains 5952 vertices
Partion 2 contains 5952 vertices
Partion 3 contains 5580 vertices
Partion 4 contains 5952 vertices
Partion 5 contains 6144 vertices
Partion 6 contains 6144 vertices
Partion 7 contains 5760 vertices
Partion 8 contains 5952 vertices
Partion 9 contains 6144 vertices
Partion 10 contains 6144 vertices
Partion 11 contains 5760 vertices
Partion 12 contains 5580 vertices
Partion 13 contains 5760 vertices
Partion 14 contains 5760 vertices
Partion 15 contains 5400 vertices
Render only the polygons that are visible on screen as well ;)
Yeah, im getting to that next, with a massive heightmap. ;)
How large is the vertex array now with partioning?
Edit: I should scroll up first instead of drooling of pictures and replying after that :)
The vertex array is fairly larger but now I can render maps larger than 128x128 with little performance hit, I am trying to do that right now.
Ya know.. the grassy skybox makes it a bit hard to distinguish between floor and sky. Any chance the next screenshot will have a sunny afternoon hawaiian background? :D
512x512 heightmap, partion size is 64 and viewdistance is 128. I get 30 fps. There are 2 solutions for lower end pcs (Mine is a 3.2 Prescott, 9800XT)
1-Decrease viewdistance and in doing so, reduce partion size too
2-More fog
But the camera is overlooking the whole zone right? Not zoomed in as it will be in-game.
What if your on a hill overlooking the map?
Mmh.. true. At that point fog would help a lot.
Also using LOD to simplify far-away vertexes would be beneficial.
Righto, im going to work on LOD using lower resolution heightmaps.
Dang it. I cant seem to get LOD to work correctly. And in the center of a 256x256 map, the fps drops to 11 but in the center of a 128x128 map scaled to the same size, the fps is 30.
Sounds like it's imporoperly simplifiying partions? Count any increase in vertexes when your in the middle of map?
No, just an increase in visible partions, but it is an improvement from the 8 fps I get without using partions.
What kind of LOD technique are you using?
- ØØ -
Currently, no LOD, I will get to that once I have slept/woken up in the morning... er... make that later this morning.