ROAM terrain rendering, help us make spring much faster!
Moderator: Moderators
Re: ROAM terrain rendering, help us make spring much faster!
So, a year later, with a bit more knowledge behind my back, I'm revisiting this.
I abandoned the tri-stripping algorithm I built (the algo had a bug I couldnt track down, and only resulted in 2*n vertices for n triangles, AND needed face culling disabled) to just push the raw triangles. Insane performance.
Now the hard limit seems to be the cpu-gpu connection.
My old 8800 gt can easily render 2,000,000 triangles at 30 fps with normal mapping, but roam starts to choke (90 fps, all cpu use is in drvpresentbuffers, which is cpu copying to gpu) when I make it push 80,000 triangles per frame.
Why is this? Because units are display lists, thus their geometry data is stored on the gpu already, while I am transferring all of this data each frame.
80,000 triangles * 3 vertices per triangle * 3 floats per vertex * 4 bytes per float * 100 frames per second * 2 push passes (one for shadows one for terrain) ~= 500MB of data per second (very bad)
The question is: Would it make sense to store the ROAM optimally tessellated terrain patches in displaylists, and only updating the display lists on terrain change? What is the performance cost of making a display list? Is it similar to just pushing a vertex array?
Any other methods of storing the mesh data on the gpu? Should I read up on other possibilities?
I abandoned the tri-stripping algorithm I built (the algo had a bug I couldnt track down, and only resulted in 2*n vertices for n triangles, AND needed face culling disabled) to just push the raw triangles. Insane performance.
Now the hard limit seems to be the cpu-gpu connection.
My old 8800 gt can easily render 2,000,000 triangles at 30 fps with normal mapping, but roam starts to choke (90 fps, all cpu use is in drvpresentbuffers, which is cpu copying to gpu) when I make it push 80,000 triangles per frame.
Why is this? Because units are display lists, thus their geometry data is stored on the gpu already, while I am transferring all of this data each frame.
80,000 triangles * 3 vertices per triangle * 3 floats per vertex * 4 bytes per float * 100 frames per second * 2 push passes (one for shadows one for terrain) ~= 500MB of data per second (very bad)
The question is: Would it make sense to store the ROAM optimally tessellated terrain patches in displaylists, and only updating the display lists on terrain change? What is the performance cost of making a display list? Is it similar to just pushing a vertex array?
Any other methods of storing the mesh data on the gpu? Should I read up on other possibilities?
Re: ROAM terrain rendering, help us make spring much faster!
can't you just send the mesh once or twice a second ?
Re: ROAM terrain rendering, help us make spring much faster!
Thats the plan, the question is how.
Re: ROAM terrain rendering, help us make spring much faster!
optimizing the displayed part of the map, and use a fixed size mesh for the rest of the map until the mesh gets updated, the thing is it seems you already have ideas, why don't you just try the one that seems the best and see if it's good or not ...
and btw nice job just to make that roam working, i checked the spring ground rendering once and it made my eyes bleeding, not a single comment, tons of random variable name, crappy algorithm for crappy result, no coding rules .... wtf code, so good job :)
and btw nice job just to make that roam working, i checked the spring ground rendering once and it made my eyes bleeding, not a single comment, tons of random variable name, crappy algorithm for crappy result, no coding rules .... wtf code, so good job :)
Re: ROAM terrain rendering, help us make spring much faster!
Vertex Buffer Objects could be an alternative. I think compiling a display list is pretty fast too though.
But better wait for the people with more recent OpenGL knowledge for a definite answer
(And yeah, the ground rendering code is evil indeed, so the sooner we have something better, the better )
But better wait for the people with more recent OpenGL knowledge for a definite answer
(And yeah, the ground rendering code is evil indeed, so the sooner we have something better, the better )
Re: ROAM terrain rendering, help us make spring much faster!
Yes, VBOs could reduce the bandwidth needed to 1/3, since I only need to send an index, but it would require 12 megabytes of gpu ram for a 16 by 16 map.
Re: ROAM terrain rendering, help us make spring much faster!
You can VBO the indices too as far as I know.
Personally I would go for display lists at first though, much easier to implement and (in my experience) fast enough for most things.
VBOs would become a good alternative when you want to update small parts of it without needing to send over the whole batch to the GPU again.
12 meg of video ram sounds like a tiny amount, map texture surely takes a lot more?
Personally I would go for display lists at first though, much easier to implement and (in my experience) fast enough for most things.
VBOs would become a good alternative when you want to update small parts of it without needing to send over the whole batch to the GPU again.
12 meg of video ram sounds like a tiny amount, map texture surely takes a lot more?
Re: ROAM terrain rendering, help us make spring much faster!
@Beherith:
can you push the changes to your github repo or is it in an unusable state?
can you push the changes to your github repo or is it in an unusable state?
Re: ROAM terrain rendering, help us make spring much faster!
I'll have to brush up again on my git skills, because I just based the new roam off a recent master build. If you are interested in looking in to it, I can push an unfinished version. There are some bugs left to squash, and lots of code beautifying still needed.
Re: ROAM terrain rendering, help us make spring much faster!
Is this something we can expect in the next release, or something that needs more work and testing and will be delayed till the following release?
As much as I'm looking forward to this, we're already massively behind schedule on the next release as it is.
As much as I'm looking forward to this, we're already massively behind schedule on the next release as it is.
Re: ROAM terrain rendering, help us make spring much faster!
Foolish me, two bugs caused me to push 6 times as many triangles as I should have, so the real bus limit is closer to its advertised 8GB/s at a working 4.5GB per sec.
Also, at nearly 250,000 triangles, map looks flawless across the board, and I still get 190 fps with LOS shader and shadows enabled as well.
Conclusion: I'll stick with triangle arrays for now, and just iron out the rest of the quirks.
Also, at nearly 250,000 triangles, map looks flawless across the board, and I still get 190 fps with LOS shader and shadows enabled as well.
Conclusion: I'll stick with triangle arrays for now, and just iron out the rest of the quirks.
Re: ROAM terrain rendering, help us make spring much faster!
Behe told me (the other day on lobby) there's no chance of it for 0.83.AF wrote:Is this something we can expect in the next release, or something that needs more work and testing and will be delayed till the following release?
As much as I'm looking forward to this, we're already massively behind schedule on the next release as it is.
...Goes to show 0.84 will be just as awesome as 0.83?
Re: ROAM terrain rendering, help us make spring much faster!
@Beherith:
yes, would be nice if you could push it. i'm unsure if i can really help, but maybe others can! :)
yes, would be nice if you could push it. i'm unsure if i can really help, but maybe others can! :)
Re: ROAM terrain rendering, help us make spring much faster!
we can wait 1 or 2month more to have it in 0.83
Re: ROAM terrain rendering, help us make spring much faster!
computer games- were the reinvention of black&white + static is celebrated as innovation
Sorry Behe, great work. But who m i telling news here.. anything you touch gets gold..
Could this effect be customized? For example if i wanted this bleeding out ghosteffect of lord of the rings (when the ring is worren) and would write such a shader.. could i put this on?
Sorry Behe, great work. But who m i telling news here.. anything you touch gets gold..
Could this effect be customized? For example if i wanted this bleeding out ghosteffect of lord of the rings (when the ring is worren) and would write such a shader.. could i put this on?
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: ROAM terrain rendering, help us make spring much faster!
^^ this, very much so. Imo this should be a top priority. We are talking about one of the most broken parts of the engine.Satirik wrote:we can wait 1 or 2month more to have it in 0.83
Re: ROAM terrain rendering, help us make spring much faster!
Thirded. Something like this is worth an extension.Satirik wrote:we can wait 1 or 2month more to have it in 0.83
Re: ROAM terrain rendering, help us make spring much faster!
that makes no sense.
what might make sense, is to make an other release right when ROAM is usable.
what might make sense, is to make an other release right when ROAM is usable.
Re: ROAM terrain rendering, help us make spring much faster!
I hate to be a Debbie Downer;
But will it be done in 2 months?
My guess is, (and this is in no way a sleight towards Behe's great work which I really do want asap) probably not.
0.83 is long overdue and will probably come with a whole slew of issues to upset the playerbase with (even after keeping engine and game devs busy throughout the testing/RC phase, ) purely through how long the release cycle has been; it is all but inevitable.
I'm not sure adding / waiting for something this big at this stage is really the wise move.
edit: and/or +1 to hoijui
But will it be done in 2 months?
My guess is, (and this is in no way a sleight towards Behe's great work which I really do want asap) probably not.
0.83 is long overdue and will probably come with a whole slew of issues to upset the playerbase with (even after keeping engine and game devs busy throughout the testing/RC phase, ) purely through how long the release cycle has been; it is all but inevitable.
I'm not sure adding / waiting for something this big at this stage is really the wise move.
edit: and/or +1 to hoijui
Re: ROAM terrain rendering, help us make spring much faster!
I ran into an issue:
I would like to somehow hook the CBasicMapDamage::Explosion function into BFGroundDrawer class, so I can create a list of explosions that happened, and can update each effected patch's variance tree. How do I do this?
My OO skills are very rusty, as I've been spoilt by python lately.
I would like to somehow hook the CBasicMapDamage::Explosion function into BFGroundDrawer class, so I can create a list of explosions that happened, and can update each effected patch's variance tree. How do I do this?
My OO skills are very rusty, as I've been spoilt by python lately.