Adventures in engine land, part 1
Posted by
Post
quote and reply
I've been tempted to write a blog post about the engine work I'm
doing for Warsow for quite a while but never got to actually doing
it until now. Hopefully this blog post is going to be only the
first part in the series..
One of the major things I implemented for 0.6 was support for static vertex buffer objects (VBO) for world geometry. What do VBO's do? They allow storing geometry and other accompanying useful data to be stored in video card's memory so when things need to be rendered no huge memory transfers need to be done, you just pass the VBO's index to GPU instead. Nice and simple.
Some of the maps benefited from the feature quite noticeably, exhibiting a x2-x3 boost in performance in scenes with small player counts. But some of the maps seemed to be little affected by the feature or weren't affected at all. One such example was the new wdm5. The so-so performance in some of the scenes was then attributed to high polygon counts and portalmaps, although VBO's exist precisely to combat high polygon counts among other things.
The thing slipped into the final version of 0.6 but I kept on returning to it in my mind, it was obvious something was going very wrong there. Finally one day I decided to take a stab at it and started profiling the map. My initial assumption was that VBO's weren't created for the majority of surfaces so huge memory transfers were still occurring, drastically slowing everything down. As it turned out, I was wrong. Almost everything in the map was packed into VBO's just fine, no obvious bugs popped up. I added a few more counters to r_speeds 1 output to see if there were any hints there, one thing I noticed was a high VBO count in the scene you can see in the screenshot above. Each VBO requires a separate call to the driver to be rendered but since it's all static data, in theory it shouldn't hurt the performance. I didn't pay much attention to that odd thing back then and it kinda slipped my mind.
Around the same crizis was working on his criziswdm3 map. He added areaportals to the doors at my suggestion, to improve performance in the YA room. While it did help indeed, the YA room was still suffering from really weird performance drops. The newly introduced r_speeds 1 counters revealed that at performance worsened considerably at higher VBO counts. The counter was fluctuating from the values of 10 to 400, depending on the view position and angle. But hey, that room is really simple, how can anything there need 400 VBO's?! I then started looking for clues and suddenly everything came into place. rgbgen lightingDiffuse. That little sucker had been initially introduced to get more or less realistic lighting and gloss on statically compiled map models like viciious statue and moving bmodels. It had been assumed that models wouldn't be split into smaller parts. But somehow the feature started to be (mis-)used by the designers for smaller details: handrails, ramps, lamps and so on. To make things even worse, all these little bits were split by q3map2 into meshes with lower polygon counts, each part requiring its own VBO.
I then hacked lightingDiffuse surfaces to be batched into vertex buffer objects and that brought performance to the levels expected. The hack broke the gloss lighting on such surfaces quite noticeably, but the performance gains were so huge that I didn't care. I mean most of the players turn the more expensive gfx features off and who really cares about glossy handrails except maybe a few guys? I then "fixed" the gloss by introducing static lighting direction in the GLSL shader.
I was planning to keep the improvement "secret" for Warsow 0.7 but crizis persuaded me into backporting it to 0.6 branch and releasing 0.62, so players wouldn't have to suffer while waiting for the next big installment of the game. And so I did!
One of the major things I implemented for 0.6 was support for static vertex buffer objects (VBO) for world geometry. What do VBO's do? They allow storing geometry and other accompanying useful data to be stored in video card's memory so when things need to be rendered no huge memory transfers need to be done, you just pass the VBO's index to GPU instead. Nice and simple.
Some of the maps benefited from the feature quite noticeably, exhibiting a x2-x3 boost in performance in scenes with small player counts. But some of the maps seemed to be little affected by the feature or weren't affected at all. One such example was the new wdm5. The so-so performance in some of the scenes was then attributed to high polygon counts and portalmaps, although VBO's exist precisely to combat high polygon counts among other things.
The thing slipped into the final version of 0.6 but I kept on returning to it in my mind, it was obvious something was going very wrong there. Finally one day I decided to take a stab at it and started profiling the map. My initial assumption was that VBO's weren't created for the majority of surfaces so huge memory transfers were still occurring, drastically slowing everything down. As it turned out, I was wrong. Almost everything in the map was packed into VBO's just fine, no obvious bugs popped up. I added a few more counters to r_speeds 1 output to see if there were any hints there, one thing I noticed was a high VBO count in the scene you can see in the screenshot above. Each VBO requires a separate call to the driver to be rendered but since it's all static data, in theory it shouldn't hurt the performance. I didn't pay much attention to that odd thing back then and it kinda slipped my mind.
Around the same crizis was working on his criziswdm3 map. He added areaportals to the doors at my suggestion, to improve performance in the YA room. While it did help indeed, the YA room was still suffering from really weird performance drops. The newly introduced r_speeds 1 counters revealed that at performance worsened considerably at higher VBO counts. The counter was fluctuating from the values of 10 to 400, depending on the view position and angle. But hey, that room is really simple, how can anything there need 400 VBO's?! I then started looking for clues and suddenly everything came into place. rgbgen lightingDiffuse. That little sucker had been initially introduced to get more or less realistic lighting and gloss on statically compiled map models like viciious statue and moving bmodels. It had been assumed that models wouldn't be split into smaller parts. But somehow the feature started to be (mis-)used by the designers for smaller details: handrails, ramps, lamps and so on. To make things even worse, all these little bits were split by q3map2 into meshes with lower polygon counts, each part requiring its own VBO.
I then hacked lightingDiffuse surfaces to be batched into vertex buffer objects and that brought performance to the levels expected. The hack broke the gloss lighting on such surfaces quite noticeably, but the performance gains were so huge that I didn't care. I mean most of the players turn the more expensive gfx features off and who really cares about glossy handrails except maybe a few guys? I then "fixed" the gloss by introducing static lighting direction in the GLSL shader.
I was planning to keep the improvement "secret" for Warsow 0.7 but crizis persuaded me into backporting it to 0.6 branch and releasing 0.62, so players wouldn't have to suffer while waiting for the next big installment of the game. And so I did!
hey, nice read. i dont understand half of the technical terms but i
thought readin this, that applying the shader commands not in the
wrong situation would have saved you a lot of work.
first link is borked btw.
first link is borked btw.
Indeed that was interesting even though my little knowledge it was
understandable, you should make more blog posts :>
Reply to topic
