ROAM terrain rendering, help us make spring much faster!
Moderator: Moderators
Re: ROAM terrain algorithm implemented!
Yay, great work so far
Re: ROAM terrain algorithm implemented!
request:
could you give shorelines a higher/full LOD
btw, do you use indexed vbos know?
and yeah, great work :)
could you give shorelines a higher/full LOD
btw, do you use indexed vbos know?
and yeah, great work :)
- clericvash
- Posts: 1394
- Joined: 05 Oct 2004, 01:05
Re: ROAM terrain algorithm implemented!
So can someone put out in layman terms what this code will do? I mean what are the advantages of this?
Re: ROAM terrain algorithm implemented!
better fps.
Re: ROAM terrain algorithm implemented!
clericvash wrote:So can someone put out in layman terms what this code will do? I mean what are the advantages of this?
Answers it pretty wellPerformance:
DSD whole map is rendered at 150-200 fps, with no loss of terrain fidelity.
DSD front is rendered at 500 fps.
Re: ROAM terrain algorithm implemented!
What kind of hardware do you have? And how much of an increase in fps do you have? Also, with 1k peewees running around(and/or by playing a resource heavy replay) how much fps do you have before and after you apply this wondrous feature?
And for those who are just too lazy to compile it themselves, where can one find a download link for this? I remember there being a build server somewhere, but I'm also unsure whether that is what I'm looking for.
And for those who are just too lazy to compile it themselves, where can one find a download link for this? I remember there being a build server somewhere, but I'm also unsure whether that is what I'm looking for.
Re: ROAM terrain algorithm implemented!
I have an 8800GT, and I had about a double increse in frame rate, with a bit better looking map.
Adding 1k peewees wont change much, since its independent of that.
The real benefit here will probably be for those with weaker GPUs, since they get higher terrain detail at the same load, or less load with the same terrain detail they are used to.
Also, the main advantage for me is that cliffs no longer get warped when viewed from a bit of a distance.
Tobi is working on merging it into buildserv, so you can test it for yourself.
Adding 1k peewees wont change much, since its independent of that.
The real benefit here will probably be for those with weaker GPUs, since they get higher terrain detail at the same load, or less load with the same terrain detail they are used to.
Also, the main advantage for me is that cliffs no longer get warped when viewed from a bit of a distance.
Tobi is working on merging it into buildserv, so you can test it for yourself.
Re: ROAM terrain algorithm implemented!
Pushed merge of master + Beherith's roam branch, as 'roam' to Spring account on github, and fixed some tiny bugs to make it compile on BuildServ.
Binaries can now be found on BuildServ, search for 'roam' in the lists of executables/installers.
Binaries can now be found on BuildServ, search for 'roam' in the lists of executables/installers.
Re: ROAM terrain algorithm implemented!
Will this strictly reduce the GPU load or will it help the CPU somewhat too? And RAM? VRAM? Anything that reduces Spring's CPU torture what I personally am most interested in. In any case, it's good to see the engine making strides to be more efficient.
Re: ROAM terrain algorithm implemented!
Tested it.
Shadowmap projections are hosed (not surprising, that code needs to be rewritten anyhow).
Example 1: ViewRadius 64:
Example 2: ViewRadius 8:
Other than that, it does what it says it does.
Very little FPS improvement, on Unpleasantville (my massive city map for P.U.R.E., with hundreds of World Builder objects, but hey, that was asking for a miracle anyhow, as it's mainly CPU-limited), so I tested again on something with a lower load, and FPS is fairly un-changed, at a ViewRadius of 64.
However, I can lower ViewRadius considerably, with the same perceived quality in OTA POV. I went from 64 to 8, just to test it out, and the final appearance was much the same, although the shadowmap became more and more goofy.
I saw some other things that were troublesome, though. It appears that groundscars / groundplates are using a full-resolution version of the heightmap (you can't see it in wiremap) instead of the ROAM'd version. This probably accounts for a lot of the "no change". I think that we're going to have to change the way they operate, and have them get the ROAM'd triangles they intersect with, for full fidelity and a much lower cost.
And for future uses, it is probably necessary to have Lua callouts that can get a set of triangles from any rectangle, x,y, so that future attempts to build things like animated decals, etc., can run at a much-reduced cost.
Shadowmap projections are hosed (not surprising, that code needs to be rewritten anyhow).
Example 1: ViewRadius 64:
Example 2: ViewRadius 8:
Other than that, it does what it says it does.
Very little FPS improvement, on Unpleasantville (my massive city map for P.U.R.E., with hundreds of World Builder objects, but hey, that was asking for a miracle anyhow, as it's mainly CPU-limited), so I tested again on something with a lower load, and FPS is fairly un-changed, at a ViewRadius of 64.
However, I can lower ViewRadius considerably, with the same perceived quality in OTA POV. I went from 64 to 8, just to test it out, and the final appearance was much the same, although the shadowmap became more and more goofy.
I saw some other things that were troublesome, though. It appears that groundscars / groundplates are using a full-resolution version of the heightmap (you can't see it in wiremap) instead of the ROAM'd version. This probably accounts for a lot of the "no change". I think that we're going to have to change the way they operate, and have them get the ROAM'd triangles they intersect with, for full fidelity and a much lower cost.
And for future uses, it is probably necessary to have Lua callouts that can get a set of triangles from any rectangle, x,y, so that future attempts to build things like animated decals, etc., can run at a much-reduced cost.
Re: ROAM terrain algorithm implemented!
With many thanks to Lupus and BrainDamage, we did quite some work on ROAM.
Currently it renders entire DSD at 700 fps, with higher visual quality than old spring.
We made a tesselation algorithm, that splits each 128*128 heightmap block into 2 triangle strips, in linear time, using 2n+2 vertexes per N tris.
So, we can finally see the light shining at the end of the tunnel...
Currently it renders entire DSD at 700 fps, with higher visual quality than old spring.
We made a tesselation algorithm, that splits each 128*128 heightmap block into 2 triangle strips, in linear time, using 2n+2 vertexes per N tris.
So, we can finally see the light shining at the end of the tunnel...
Re: ROAM terrain algorithm implemented!
i'm far too stupid to understand what you're doing...
...but im smart enough to understand the magnitude! awesome work.
...but im smart enough to understand the magnitude! awesome work.
Re: ROAM terrain algorithm implemented!
sounds awesome man!
Re: ROAM terrain algorithm implemented!
Great, glad to hear it's made progress, can't wait to test the next versions
Re: ROAM terrain algorithm implemented!
Ok, did more optimizations, now I hit 1k fps with whole map rendered, and 2k with DSD front (totally flat) rendered. This is ofc with shadows, reflections and AA off.
One of the optimizations is that if the camera doesnt move, then it only pushes the pre-generated tri strip to gpu and nothing else. If the camera is moving, then it re generates everything, dropping fps by about 30%. I would like to hook the regeneration into slowupdate anyway.
Also, I would like to enlist your help, if anyone is willing. There is a flickering issue. Its semi-deterministic, but I dont know the engine well enough to pinpoint it.
Right now, everything is statically allocated (sue me) So it uses 50mbytes more memory on dsd than vanilla spring.
github link: http://github.com/Beherith/spring/tree/roam
Drop-in test executable: http://beherith.eat-peet.net/stuff/springroam.exe
EDIT: drop in .exe now fixed, no flickering!
One of the optimizations is that if the camera doesnt move, then it only pushes the pre-generated tri strip to gpu and nothing else. If the camera is moving, then it re generates everything, dropping fps by about 30%. I would like to hook the regeneration into slowupdate anyway.
Also, I would like to enlist your help, if anyone is willing. There is a flickering issue. Its semi-deterministic, but I dont know the engine well enough to pinpoint it.
Right now, everything is statically allocated (sue me) So it uses 50mbytes more memory on dsd than vanilla spring.
github link: http://github.com/Beherith/spring/tree/roam
Drop-in test executable: http://beherith.eat-peet.net/stuff/springroam.exe
EDIT: drop in .exe now fixed, no flickering!
Re: ROAM terrain rendering, help us make spring much faster!
Very nice! I tried it and, at least for me, the flickering seems to be a bumpwater issue, the seizure-inducing effect wasn't present on other water modes.It also seems to become less common on lower viewradii.
Keep up the good work!
PS: my personal tests:
CA, Commanders script, Conquest of Paradise, reflective water, ATi 4870, AA 16x.
18-20 whole map, ROAM
12-15 whole map, normal
Keep up the good work!
PS: my personal tests:
CA, Commanders script, Conquest of Paradise, reflective water, ATi 4870, AA 16x.
18-20 whole map, ROAM
12-15 whole map, normal
Re: ROAM terrain rendering, help us make spring much faster!
MidKnight, that is not a really representative test, because shadows and reflections still use the old rendering algo, and 16x AA can be taxing for the gpu.
We still desperately need help on the flickering issue
Edit: Some people seem to have issues with their gpu not obeying glDisable(GL_CULL_FACE)
(it looks like tris missing from the map)
If this error happens for you, please report.
We still desperately need help on the flickering issue
Edit: Some people seem to have issues with their gpu not obeying glDisable(GL_CULL_FACE)
(it looks like tris missing from the map)
If this error happens for you, please report.
Re: ROAM terrain algorithm implemented!
You are drinking Zobrowka with banana juice? Are you crazy?FLOZi wrote:I think I'm falling for you, Behe.
Only way its Apple juice to drink with with Zobrowka!!!
I must tell you now:
[ZXC] Zobrowka Xtra Club
Re: ROAM terrain algorithm implemented!
Have you ever tried to juice a banana? Its not really possible...maxymili wrote:You are drinking Zobrowka with banana juice? Are you crazy?FLOZi wrote:I think I'm falling for you, Behe.
Only way its Apple juice to drink with with Zobrowka!!!
I must tell you now:
[ZXC] Zobrowka Xtra Club
And thats apple cider on the picture, apple juice with pulp.
On topic:
I pushed rudimentary shadow rendering, It draws the shadow map with the same resolution as it draws terrain, resulting in a heavy (almost half) fps drop.
On the flickering bug: Its very strange, I find that the bug doesnt appear when I force retessellation on every frame... You can set that by forcing
framchanged var to true in inline void CBFGroundDrawer::AdvDraw(int bty)
Re: ROAM terrain rendering, help us make spring much faster!
Triangle windings seem to be messed up (they need to be alternated when creating strips), and there are holes in the mesh:
Could you describe your stripping algorithm in high-level terms?
Could you describe your stripping algorithm in high-level terms?