Work
Managed to delegate some more, reduce my inbox count and get an internal version out the door for more testing and veg video production, but the main headline story is the sequence of inexplicable crashes I have had to wade through. You all know the frustration as developers of not getting to the task you want to start because of a handful of totally mysterious bugs that need fixing first. Well that was my day. Even after 30 years of coding I can still be tripped up by a crash who's cause is the random corruption of some data at some point in time, and the crash event sheds no light on either.
Add a new flag in the meantime called "dividetexturesize=X" which scales down the textures loaded into the engine. I will have it default to 2 so that lower end machines are not choking their GPU video memory with 2048x2048 textures, and those with higher end cards can simply adjust this value to 1 for the highest resolution textures. In the future I might introduce some modes which do not reduce very small textures as they have much less impact on overall video memory usage.
I've just had a bath, and waiting for a Eureka moment on the crash issues, but none came. I have thus decided to approach the problem methodically. I will totally analyse the area of memory that the crash occurs on, and record as much as possible the before, during and after states, and setup monitors of the data around the memory block in case something else changes it. It's long-winded, but it eliminates the need for intuitive guesswork, and if I can finish off today (by 3AM) with a fix of this most illusive bug, I will be a happy chappy.
My plan (for Wednesday now), is to skip the LOAD OBJECT memory work (which would only yield a small saving overall) and go for the huge performance gain of making all distant objects QUAD buffers, and then extend it to shadows, reflection and light ray cameras. It will reduce draw calls by MORE than half for the same visual, so it's well worth it and early tests show a marked improvement in FPS, even at lower levels. My run-to-the-river currently runs at 10fps with everything on and 15fps with some conservative reductions. The game plays well at 30-35fps so that will be my initial aim on the GeForce 9600 GT card I am currently using. I also plan to recruit one of my coders to help me with some terrain work which should vastly reduce the memory and performance footprint too.
Thứ Ba, 4 tháng 3, 2014
Thứ Hai, 3 tháng 3, 2014
Monday Already
Work
Having crunched code over the weekend, it feels odd that Monday is my first day back. Despite the strange feeling, I set to work obliterating my backlog of emails, sorting out the work for the next two weeks and getting some key issues resolved in the engine. I have sent code off to Simon to add shadows to the Construction Kit and a new version to Rick so he can make some nice videos about the new Vegetation Pack.
Still the best news is the massive memory savings I made by loading the HUGE textures used by the engine into GPU Video Memory. The consequence is that I can make seriously large levels now and the system memory creeps up very slowly compared to the old version. I have ideas to make even more savings too, but as much as I want to chase that particular tiger down, the elephant in the room (performance) remains the highest on my personal snag list. I will be running a demo of Reloaded on an Ultrabook in exactly two weeks time in the biggest developer conference on the planet, and I don't want egg on my face. Yes I will be saving face, but you will be getting some serious performance boon as a result so I think we both win.
I also got an email asking for clarity on the license terms of media provided in Reloaded, and the legality of releasing it as part of the standalone build. The official TGC EULA for this product allows you to distribute the assets (encrypted or otherwise) providing it remains part of the standalone demo you built. If anyone remembers the culture of sharing FPSC Classic games, same deal. We do specifically exclude the extraction of those assets for use elsewhere, either as part of a library or other game creator, but within the context of using the assets to show off your Reloaded creations you are quite safe. It's also great to see the maturity of the community to ask such a question as it demonstrates your respect for copyright material and the terms of use applied to digital media.
Having crunched code over the weekend, it feels odd that Monday is my first day back. Despite the strange feeling, I set to work obliterating my backlog of emails, sorting out the work for the next two weeks and getting some key issues resolved in the engine. I have sent code off to Simon to add shadows to the Construction Kit and a new version to Rick so he can make some nice videos about the new Vegetation Pack.
Still the best news is the massive memory savings I made by loading the HUGE textures used by the engine into GPU Video Memory. The consequence is that I can make seriously large levels now and the system memory creeps up very slowly compared to the old version. I have ideas to make even more savings too, but as much as I want to chase that particular tiger down, the elephant in the room (performance) remains the highest on my personal snag list. I will be running a demo of Reloaded on an Ultrabook in exactly two weeks time in the biggest developer conference on the planet, and I don't want egg on my face. Yes I will be saving face, but you will be getting some serious performance boon as a result so I think we both win.
I also got an email asking for clarity on the license terms of media provided in Reloaded, and the legality of releasing it as part of the standalone build. The official TGC EULA for this product allows you to distribute the assets (encrypted or otherwise) providing it remains part of the standalone demo you built. If anyone remembers the culture of sharing FPSC Classic games, same deal. We do specifically exclude the extraction of those assets for use elsewhere, either as part of a library or other game creator, but within the context of using the assets to show off your Reloaded creations you are quite safe. It's also great to see the maturity of the community to ask such a question as it demonstrates your respect for copyright material and the terms of use applied to digital media.
Thứ Bảy, 1 tháng 3, 2014
A Change Is As Good As A Rest
Work
It seems my buss-mans holiday paid off this time. Within two hours of hitting the code again, I discovered that although the LOAD OBJECT command was gobbling a little more memory than it should, the real villain of the piece was LOAD IMAGE which had been placing MOST of the texture content in system memory as a managed backup. My building ate 23MB in the old Image DLL, but with some extra code to ensure certain commands could still lock a video memory texture, my new Image DLL loaded the same building in at 9MB. Multiply this effect by an entire level and you will start to appreciate how this single tweak has improved your lives in Reloaded land :)
My investigations also saw the LOAD OBJECT memory usage double when the LOAD EFFECT applied it's magic to it, so there is something very suspicious happening there too. Going to stop my weekend work for how, and celebrate my code win with some good, and Sunday/Monday I will chase down the reason for the shader taking my 3MB model up to 6MB (and then find out why my model was 3MB in the first place given that the vertex data cannot be more than 1MB).
Play
In order to think laterally, you need to approach a problem for an entirely new direction. Leaving your code for a week, then returning to it is one way to do that, and leaving it to talk geek for a week is probably the best way to prepare your brain for the comeback.
It seems my buss-mans holiday paid off this time. Within two hours of hitting the code again, I discovered that although the LOAD OBJECT command was gobbling a little more memory than it should, the real villain of the piece was LOAD IMAGE which had been placing MOST of the texture content in system memory as a managed backup. My building ate 23MB in the old Image DLL, but with some extra code to ensure certain commands could still lock a video memory texture, my new Image DLL loaded the same building in at 9MB. Multiply this effect by an entire level and you will start to appreciate how this single tweak has improved your lives in Reloaded land :)
My investigations also saw the LOAD OBJECT memory usage double when the LOAD EFFECT applied it's magic to it, so there is something very suspicious happening there too. Going to stop my weekend work for how, and celebrate my code win with some good, and Sunday/Monday I will chase down the reason for the shader taking my 3MB model up to 6MB (and then find out why my model was 3MB in the first place given that the vertex data cannot be more than 1MB).
Play
In order to think laterally, you need to approach a problem for an entirely new direction. Leaving your code for a week, then returning to it is one way to do that, and leaving it to talk geek for a week is probably the best way to prepare your brain for the comeback.
Thứ Sáu, 28 tháng 2, 2014
Back From MWC 2014 - Phew!
Play
As the trip was not strictly Reloaded work, I had to book this one as a holiday so I am listing it as a 'Play' report :) Did some networking and showing AGK to all and sundry, plus met a lot of very cool dudes and dudettes. Saw some great tech and had some very techie conversations. Also managed to get up on stage a few times and talk my spiel. My warmest thanks to Intel for inviting me there and making me feel at home, and it was great to meet my friends from across the waters again, both old and new.
Also visited my countryman at the Wales stand at MWC too, which was great to see! Got a free glass of wine for my trouble ;) I also really enjoyed the hotel, despite it's distance from Barcelona. If you want a place that gives you REALLY big measures, this is the place!
In those quiet moments on the plane, or in the airport, or in the 40 minute taxi ride to the MWC event every day, I had time to reflect on WHY OH WHY do I only get a handful of content in the level before it bombs. It did not take long to realize a 5000 polygon building with three LOD levels should not cost 15MB of system memory. The most the vertices should cost is 800K and the textures 'should' be in video memory, so what on earth could eat SO MUCH system memory when it is clearly not required? This was the burning question I came back with, and I will be writing a very mean prototype this weekend to trace a series of LOAD OBJECT processes with some of the offenders from the FPSC Reloaded Asset Library such as the character and the large buildings.
I now have two solid weeks of Reloaded coding ahead of me, and my mission to reduce memory and increase performance is approaching make or break time. After that, I am off to GDC for a few days to present it to 'die hard FPS players and top game developers' and I am presenting on an Ultrabook (mobile PC) so the challenge is definitely on. To that end, I have given my mid-range graphics card to Simon so he can work on higher quality visuals in the Construction Kit and I have installed a GeForce 9600 GT:
http://www.videocardbenchmark.net/gpu.php?gpu=GeForce+9600+GT
Essentially the card is 5 times slower than the one I have been using, which will give me some first-hand experience of the problem. It also simulates the speed of a mobile PC too so I can craft the best GDC demo in the time available. I plan to put out a few versions to our internal testers during this process and if the results are good, we will look to release something to the Alpha cadence guys to get a taste of the improvements. If the version is bad, our internal testers will protect you from it :)
Anyway, a LONG day almost done. Now my emails and blogging duties are complete, I think I will sneak off to bed and get a head start on the weekend. I am pleased to see the roof still on, so hopefully we've seen the last of the UK storms for the time being.
As the trip was not strictly Reloaded work, I had to book this one as a holiday so I am listing it as a 'Play' report :) Did some networking and showing AGK to all and sundry, plus met a lot of very cool dudes and dudettes. Saw some great tech and had some very techie conversations. Also managed to get up on stage a few times and talk my spiel. My warmest thanks to Intel for inviting me there and making me feel at home, and it was great to meet my friends from across the waters again, both old and new.
Also visited my countryman at the Wales stand at MWC too, which was great to see! Got a free glass of wine for my trouble ;) I also really enjoyed the hotel, despite it's distance from Barcelona. If you want a place that gives you REALLY big measures, this is the place!
In those quiet moments on the plane, or in the airport, or in the 40 minute taxi ride to the MWC event every day, I had time to reflect on WHY OH WHY do I only get a handful of content in the level before it bombs. It did not take long to realize a 5000 polygon building with three LOD levels should not cost 15MB of system memory. The most the vertices should cost is 800K and the textures 'should' be in video memory, so what on earth could eat SO MUCH system memory when it is clearly not required? This was the burning question I came back with, and I will be writing a very mean prototype this weekend to trace a series of LOAD OBJECT processes with some of the offenders from the FPSC Reloaded Asset Library such as the character and the large buildings.
I now have two solid weeks of Reloaded coding ahead of me, and my mission to reduce memory and increase performance is approaching make or break time. After that, I am off to GDC for a few days to present it to 'die hard FPS players and top game developers' and I am presenting on an Ultrabook (mobile PC) so the challenge is definitely on. To that end, I have given my mid-range graphics card to Simon so he can work on higher quality visuals in the Construction Kit and I have installed a GeForce 9600 GT:
http://www.videocardbenchmark.net/gpu.php?gpu=GeForce+9600+GT
Essentially the card is 5 times slower than the one I have been using, which will give me some first-hand experience of the problem. It also simulates the speed of a mobile PC too so I can craft the best GDC demo in the time available. I plan to put out a few versions to our internal testers during this process and if the results are good, we will look to release something to the Alpha cadence guys to get a taste of the improvements. If the version is bad, our internal testers will protect you from it :)
Anyway, a LONG day almost done. Now my emails and blogging duties are complete, I think I will sneak off to bed and get a head start on the weekend. I am pleased to see the roof still on, so hopefully we've seen the last of the UK storms for the time being.
Thứ Năm, 27 tháng 2, 2014
Wandering in the footsteps of the polar bear with Google Maps
This guest post is from Krista Wright, the executive director of Polar Bears International. We’ve partnered with PBI to share a fascinating look at polar bears in the wild using Google Maps. -Ed.
In Inuit poetry, the polar bear is known as Pihoqahiak, the ever-wandering one. Some of the most majestic and elusive creatures in the world, polar bears travel hundreds of miles every year, wandering the tundra and Arctic sea ice in search of food and mates. Today, with the help of Street View, we’re celebrating International Polar Bear Day by sharing an intimate look at polar bears in their natural habitat.
We’ve joined forces with Google Maps to collect Street View imagery from a remote corner of Canada’s tundra: Churchill, Manitoba, home to one of the largest polar bear populations on the planet. With the help of outfitters Frontiers North, the Google Maps team mounted the Street View Trekker onto a specially designed “Tundra Buggy,” allowing us to travel across this fragile landscape without interfering with the polar bears or other native species. Through October and November we collected Street View imagery from the shores of Hudson’s Bay as the polar bears waited for the sea ice to freeze over.
Modern cartography and polar bear conservation
There’s more to this effort than images of cuddly bears, though. PBI has been working in this region for more than 20 years, and we’ve witnessed firsthand the profound impact of warmer temperatures and melting sea ice on the polar bear’s environment. Understanding global warming, and its impact on polar bear populations, requires both global and regional benchmarks. Bringing Street View to Canada's tundra establishes a baseline record of imagery associated with specific geospatial data—information that’s critical if we’re to understand and communicate the impact of climate change on their sensitive ecosystem. As we work to safeguard their habitat, PBI can add Street View imagery to the essential tools we use to assess and respond to the biggest threat facing polar bears today.
We also use the Google Maps API to support our Bear Tracker, which illustrates the frozen odyssey these bears embark on every year. As winter approaches and the sea ice freezes over, polar bears head out onto Hudson Bay to hunt for seals. Bear Tracker uses of satellite monitors and an interactive Google Map to display their migration for a global audience.
Mapping the communities of Canada’s Arctic
Google’s trip north builds on work they’ve done in the Arctic communities of Cambridge Bay and Iqaluit. In the town of Churchill, the Google Maps team conducted a community MapUp, which let participants use Map Maker to edit and add to the Google Map. From the Town Centre Complex, which includes the local school, rink and movie theatre, to the bear holding facility used to keep polar bears who have wandered into town until their release can be planned, the citizens of the Churchill made sure Google Maps reflects the community that they know.
But building an accurate and comprehensive map of Canada’s north also means heading out of town to explore this country’s expansive tundra. And thanks to this collaboration with Google Maps, people around the world now have the opportunity to virtually experience Canada’s spectacular landscape—and maybe take a few moments to wander in the footsteps of the polar bear.
In Inuit poetry, the polar bear is known as Pihoqahiak, the ever-wandering one. Some of the most majestic and elusive creatures in the world, polar bears travel hundreds of miles every year, wandering the tundra and Arctic sea ice in search of food and mates. Today, with the help of Street View, we’re celebrating International Polar Bear Day by sharing an intimate look at polar bears in their natural habitat.
The Street View Trekker, mounted on a Tundra Buggy, captures images of Churchill’s polar bears
We’ve joined forces with Google Maps to collect Street View imagery from a remote corner of Canada’s tundra: Churchill, Manitoba, home to one of the largest polar bear populations on the planet. With the help of outfitters Frontiers North, the Google Maps team mounted the Street View Trekker onto a specially designed “Tundra Buggy,” allowing us to travel across this fragile landscape without interfering with the polar bears or other native species. Through October and November we collected Street View imagery from the shores of Hudson’s Bay as the polar bears waited for the sea ice to freeze over.
One of Churchill, Manitoba’s Polar Bears on Street View
Modern cartography and polar bear conservation
There’s more to this effort than images of cuddly bears, though. PBI has been working in this region for more than 20 years, and we’ve witnessed firsthand the profound impact of warmer temperatures and melting sea ice on the polar bear’s environment. Understanding global warming, and its impact on polar bear populations, requires both global and regional benchmarks. Bringing Street View to Canada's tundra establishes a baseline record of imagery associated with specific geospatial data—information that’s critical if we’re to understand and communicate the impact of climate change on their sensitive ecosystem. As we work to safeguard their habitat, PBI can add Street View imagery to the essential tools we use to assess and respond to the biggest threat facing polar bears today.
Polar Bear International’s Bear Tracker
We also use the Google Maps API to support our Bear Tracker, which illustrates the frozen odyssey these bears embark on every year. As winter approaches and the sea ice freezes over, polar bears head out onto Hudson Bay to hunt for seals. Bear Tracker uses of satellite monitors and an interactive Google Map to display their migration for a global audience.
Mapping the communities of Canada’s Arctic
Google’s trip north builds on work they’ve done in the Arctic communities of Cambridge Bay and Iqaluit. In the town of Churchill, the Google Maps team conducted a community MapUp, which let participants use Map Maker to edit and add to the Google Map. From the Town Centre Complex, which includes the local school, rink and movie theatre, to the bear holding facility used to keep polar bears who have wandered into town until their release can be planned, the citizens of the Churchill made sure Google Maps reflects the community that they know.
But building an accurate and comprehensive map of Canada’s north also means heading out of town to explore this country’s expansive tundra. And thanks to this collaboration with Google Maps, people around the world now have the opportunity to virtually experience Canada’s spectacular landscape—and maybe take a few moments to wander in the footsteps of the polar bear.
Thứ Sáu, 21 tháng 2, 2014
Internal Tweaks Day
Work
I have spent most of Friday running around finding little jobs to make my mental desk a little cleaner before the weekend. I found time to add some nice things to Reloaded such as character fading when they die, switching them to instance objects when they are far away to save performance, fixing reflections which disappeared when the new occlusion system went in, adjusted the metrics readout so that polygon and draw calls don't instantly fill up the bar to appear more representative of a 'maximum' state, tweaked collision properties for some trees and generally bashed the engine with a variety of performance tests to locate the worst offenders.
I have isolated two performance jobs which move to the top of my plate, and both of them hooks into the new occlusion system very nicely.
The first is to replace distant objects with quads. I did this before for the instance stamp system but it proved to be a huge memory hog and hurt performance when a large group of high polygon objects entered the rendering zone. The great news is that I can re-use the quad system I created from the instance stamp mechanism but drop the 'dynamic VB filler part' which was the troublesome bit. I will be using the feedback from the occlusion system to work out whether quads should be rendered (as they are in a single draw call so need vertex shader magic to hide/show them individually). By passing in a quad distance value to the bound sphere submissions of the occluder I can control quad visibility entirely on the GPU :) Naturally, I can get the CPU to skip draw calls on the higher polygon objects by simply hiding them when they enter the assigned quad range (which will be a value in the FPE so you can change it per entity).
The second boost work will be to move the vegetation generator which currently kicks in hard when you run really fast through lots of grass (and can take good 60 fps levels down to 42 fps). I will move it from the DBP code which creates and destroys meshes on mass into a space between the start and end of the HZB query calls (that's right, exactly where the stall is located). My hope is that the vegetation generation becomes completely free as the CPU would be sitting around waiting for the GPU to come back with my juicy visibility values for the occlusion.
Put these two optimizations together and you should get a reduction of draw calls amounting to half the scene, and a substantial drop in polygons too. I've run measurements with other speed-up ideas, and these two will help increase frame rates significantly AND ensure the rate does not drop when you run quickly through dense foliage.
Play
If you've been wandering why I've been pulling 12-14 hour days for the last five days it's because I am off on a short busmans holiday from Sunday. I will be changing my overworked programmer hat for my CEO and Marketing hat as I represent TGC at this years MWC. Specifically I will be presiding over the huge hackathon there and helping fellow developers as they attempt to code a game in just three days. It's a chance to chill, unwind a little and talk shop with 3000 developers, and trade horror stories to find out if there are any crazy cool optimization tricks that I have missed. If you're heading there yourself, I will be tweeting my location throughout the event in case you want to say hello and swap travelling tales.
Alas I have left myself just one day to prepare all my demos and test my equipment, but I have one more day of Reloaded performance work during Saturday, and hopefully the internal build I am preparing will be received well by our internal team testers. I made a video showing the new occlusion in action, but I have been warned repeatedly about showing 'not great' videos so you will have imagine what it looked like;
"Picture it....I start far from a set of 15 buildings standing on a super flat terrain, each building has 3 barrels placed outside, the draw call count is 62. I run into the nearest building and make sure I can see through no open windows, and the draw call drops to just 12. Apart from the floor, sky and a few other quads the only thing being rendered is the building I am in. Frame rate on my machine stayed well above 60 fps, the target I aim for during my tests. Once I add in quads for singular objects, I expect the initial draw call of 62 to drop to more like 32. All to play for in Reloaded land!"
I have spent most of Friday running around finding little jobs to make my mental desk a little cleaner before the weekend. I found time to add some nice things to Reloaded such as character fading when they die, switching them to instance objects when they are far away to save performance, fixing reflections which disappeared when the new occlusion system went in, adjusted the metrics readout so that polygon and draw calls don't instantly fill up the bar to appear more representative of a 'maximum' state, tweaked collision properties for some trees and generally bashed the engine with a variety of performance tests to locate the worst offenders.
I have isolated two performance jobs which move to the top of my plate, and both of them hooks into the new occlusion system very nicely.
The first is to replace distant objects with quads. I did this before for the instance stamp system but it proved to be a huge memory hog and hurt performance when a large group of high polygon objects entered the rendering zone. The great news is that I can re-use the quad system I created from the instance stamp mechanism but drop the 'dynamic VB filler part' which was the troublesome bit. I will be using the feedback from the occlusion system to work out whether quads should be rendered (as they are in a single draw call so need vertex shader magic to hide/show them individually). By passing in a quad distance value to the bound sphere submissions of the occluder I can control quad visibility entirely on the GPU :) Naturally, I can get the CPU to skip draw calls on the higher polygon objects by simply hiding them when they enter the assigned quad range (which will be a value in the FPE so you can change it per entity).
The second boost work will be to move the vegetation generator which currently kicks in hard when you run really fast through lots of grass (and can take good 60 fps levels down to 42 fps). I will move it from the DBP code which creates and destroys meshes on mass into a space between the start and end of the HZB query calls (that's right, exactly where the stall is located). My hope is that the vegetation generation becomes completely free as the CPU would be sitting around waiting for the GPU to come back with my juicy visibility values for the occlusion.
Put these two optimizations together and you should get a reduction of draw calls amounting to half the scene, and a substantial drop in polygons too. I've run measurements with other speed-up ideas, and these two will help increase frame rates significantly AND ensure the rate does not drop when you run quickly through dense foliage.
Play
If you've been wandering why I've been pulling 12-14 hour days for the last five days it's because I am off on a short busmans holiday from Sunday. I will be changing my overworked programmer hat for my CEO and Marketing hat as I represent TGC at this years MWC. Specifically I will be presiding over the huge hackathon there and helping fellow developers as they attempt to code a game in just three days. It's a chance to chill, unwind a little and talk shop with 3000 developers, and trade horror stories to find out if there are any crazy cool optimization tricks that I have missed. If you're heading there yourself, I will be tweeting my location throughout the event in case you want to say hello and swap travelling tales.
Alas I have left myself just one day to prepare all my demos and test my equipment, but I have one more day of Reloaded performance work during Saturday, and hopefully the internal build I am preparing will be received well by our internal team testers. I made a video showing the new occlusion in action, but I have been warned repeatedly about showing 'not great' videos so you will have imagine what it looked like;
"Picture it....I start far from a set of 15 buildings standing on a super flat terrain, each building has 3 barrels placed outside, the draw call count is 62. I run into the nearest building and make sure I can see through no open windows, and the draw call drops to just 12. Apart from the floor, sky and a few other quads the only thing being rendered is the building I am in. Frame rate on my machine stayed well above 60 fps, the target I aim for during my tests. Once I add in quads for singular objects, I expect the initial draw call of 62 to drop to more like 32. All to play for in Reloaded land!"
Thứ Năm, 20 tháng 2, 2014
Brain Approaching Burn Out
Work
Another crammed day, ending past 4AM. I had planned some other small tasks around the office, emails and tasks, but I spent pretty much the whole time continuing the saga of performance improvements. I seem to be addicted to saving frames!
I'll give you the highlights (as I am wiped out). I've replaced the terrain physics system from a height map to a trimesh, extracted from the actual visual terrain geometry at LOD1. What this means is that your dynamic objects will not sink into the floor or float above it in strange ways. My initial code was to use LOD0, but that dragged me from 170 fps to 110 fps, so by using LOD1 there was no speed loss and I could continue. No extra speed but much more accurate floor collisions, and the back-end meshes I needed for the next achievement.
Terrain occlusion for objects was possible thanks to the LOD1 meshes I generated as part of the physics creation. Converting them down to just flat vertices and passing them to the occlusion system means that hills and high ridges now occlude any objects that sit behind them. A BIG occlusion win. I have not run extensive tests on the performance gain (too busy on related wins) but it did not cause any slow down which we can thank to the GPU stall which extolls a single one-off cost for the occlusion so extra submissions to the system was free.
I also improved the occlusion system to use a dynamic vertex buffer instead of a fixed static one. This means I can calculate and render the best 60K polygons worth of occluders instead of rendering over 2 million vertices (the entire scene) through a static draw call. It is still one draw call, but it only renders the polygons immediately surrounding the player. There is also room for further optimizations here which is a boon as this one DID show a performance boost from 101 fps to 166 fps :)
The final task which I did not quite finish due to running out of brain juice was to work out which terrain sectors (small patchwork blobs of terrain) are hidden by the occluder depth render. I hacked into the BlitzTerrain module and had it skip the sector render if the associated object had been hidden by the occlusion system (if you recall, the object I used to make the new terrain physics floor is the one I left to pick-up the occlusion info for this technique). The problem is that there are many LOD levels, and a relational scatter of sectors per LOD level, and I am only associating DBP objects with LOD Level One. My early tests show it working, but it needs to work A LOT BETTER before it's ready for the public (as only a small part of the hidden terrain is actually skipping a render). Alas when I did an aggressive test and did some hack guesswork on neighboring sectors, wiping out most of the distant terrain, the frame rate did not get much past 180 fps. I have left in a conservative implementation which just acts on LOD1 which will ensure you don't get 'missing terrain squares' when playing your levels.
Notice the empty terrain sector? I set terrain to wire frame and put a hill between me and the distant plane. I am not saving huge amounts here, but the theory is sound and with more work we should be able to throw out a LOT of polygons when such occluded sectors are well hidden. I have emailed the author of BlitzTerrain in the hopes of gaining more insight and inspiration into the relationship between LOD levels and Sector Objects.
The fact I don't get much higher than 180 fps even when I obliterate the terrain rendering suggests that the bottleneck I must chase next is the GPU stall, and as described in a previous blog post I have a fiendish plan to solve it. Alas I probably will not get to that until the pile of little issues that my plate is starting to collect have been vanquished. All in all though, some nice progress and the occlusion system continues to pay dividends!
Another crammed day, ending past 4AM. I had planned some other small tasks around the office, emails and tasks, but I spent pretty much the whole time continuing the saga of performance improvements. I seem to be addicted to saving frames!
I'll give you the highlights (as I am wiped out). I've replaced the terrain physics system from a height map to a trimesh, extracted from the actual visual terrain geometry at LOD1. What this means is that your dynamic objects will not sink into the floor or float above it in strange ways. My initial code was to use LOD0, but that dragged me from 170 fps to 110 fps, so by using LOD1 there was no speed loss and I could continue. No extra speed but much more accurate floor collisions, and the back-end meshes I needed for the next achievement.
Terrain occlusion for objects was possible thanks to the LOD1 meshes I generated as part of the physics creation. Converting them down to just flat vertices and passing them to the occlusion system means that hills and high ridges now occlude any objects that sit behind them. A BIG occlusion win. I have not run extensive tests on the performance gain (too busy on related wins) but it did not cause any slow down which we can thank to the GPU stall which extolls a single one-off cost for the occlusion so extra submissions to the system was free.
I also improved the occlusion system to use a dynamic vertex buffer instead of a fixed static one. This means I can calculate and render the best 60K polygons worth of occluders instead of rendering over 2 million vertices (the entire scene) through a static draw call. It is still one draw call, but it only renders the polygons immediately surrounding the player. There is also room for further optimizations here which is a boon as this one DID show a performance boost from 101 fps to 166 fps :)
The final task which I did not quite finish due to running out of brain juice was to work out which terrain sectors (small patchwork blobs of terrain) are hidden by the occluder depth render. I hacked into the BlitzTerrain module and had it skip the sector render if the associated object had been hidden by the occlusion system (if you recall, the object I used to make the new terrain physics floor is the one I left to pick-up the occlusion info for this technique). The problem is that there are many LOD levels, and a relational scatter of sectors per LOD level, and I am only associating DBP objects with LOD Level One. My early tests show it working, but it needs to work A LOT BETTER before it's ready for the public (as only a small part of the hidden terrain is actually skipping a render). Alas when I did an aggressive test and did some hack guesswork on neighboring sectors, wiping out most of the distant terrain, the frame rate did not get much past 180 fps. I have left in a conservative implementation which just acts on LOD1 which will ensure you don't get 'missing terrain squares' when playing your levels.
Notice the empty terrain sector? I set terrain to wire frame and put a hill between me and the distant plane. I am not saving huge amounts here, but the theory is sound and with more work we should be able to throw out a LOT of polygons when such occluded sectors are well hidden. I have emailed the author of BlitzTerrain in the hopes of gaining more insight and inspiration into the relationship between LOD levels and Sector Objects.
The fact I don't get much higher than 180 fps even when I obliterate the terrain rendering suggests that the bottleneck I must chase next is the GPU stall, and as described in a previous blog post I have a fiendish plan to solve it. Alas I probably will not get to that until the pile of little issues that my plate is starting to collect have been vanquished. All in all though, some nice progress and the occlusion system continues to pay dividends!
Đăng ký:
Bài đăng (Atom)