It occurs to me that the screenshot attached to the last post doesn’t show my classic buildings off terribly well, so here’s a grab of just one of them:
Posts Tagged ‘buildings’
Cityscape – update 11.1
Tuesday, June 16th, 2009Cityscape – update 11
Tuesday, June 16th, 2009It’s been a while. It feels longer, as I turned 30 since my last update, so happy birthday me. It’s all downhill from here. I’ve still been working on this darned city, though, and here’s a screenshot to prove it:
So, what do we have since last time? Well, building on update 10, where I clarified the box-building code by assembling boxes out of 5 panels (I ignore the base, as my intent is to always have the camera high enough that you can’t see the bottom of a box), I’ve actually introduced columned boxes. To see what I mean by this, see the following diagram:
There’s two ways of creating a columned panel; either way, we can specify the width of the windowed panel, and the width of the spacer columns. Then we either specify the desired number of windowed panels (easy to do, harder to use), or the desired width of the whole panel (which is harder to do, as I discovered, and obviously means that some compromise has to be reached if the desired width is not exactly achievable with the panel widths supplied). The algorithm I use essentially ensures the whole panel is symmetrical about the mid-point, and won’t ever have two blank column panels next to each other. The implementation is a bit yucky, but you can check it out in BuildingBuilderPanels.cs in AddColumnedPanel() if you’re interested.
That done, I set about making panelled boxes, with exactly the same sizing options as before, and then from that made a “Classic” tiered building design, as you can see in the screenshot above. This is an extremely customisable building type, and takes a ton of parameters on construction. Basically, each tier is slightly smaller in width and height than the one below it, and is separated by a black spacer block, which can overhang the blocks slightly. All the box sizes are rounded to integer numbers of stories and window-panels, and (for the moment) stretched textures aren’t allowed, although I might bring these back in if I can figure out a clean way of doing it. I’ve also added a simple routine to add some rooftop furniture, but I’m not totally happy with this yet – it doesn’t really stand out enough for me.
If you check out the latest revision, you’ll also see the very, very early phases of some particle code that I’m going to be using for things like streetlights, cars and lights on top of buildings – these will just be simple billboarded particles, not actual light sources (although maybe I’ll change to deferred rendering later and have them as actual light sources… or, maybe not!) and I hope to have them in some time in the next few days.
I’ve also spaced out the buildings a bit more – it means there’s blue gaps in the world now but I think the city looks a bit more natural spaced out like that; my city planning code is still extremely rudimentary, so needs quite some work doing on it, anyway.
The latest revision in the Bazaar repository is 37 now – check it out and see what you think.
Cityscape – update 10
Sunday, June 7th, 2009Again, no pretty pictures this time, because there’s not actually anything to see. I’ve spent a few days refactoring things in Cityscape, and having completely broken and then unbroken pretty much everything, I’m about back to the point I was a week ago, but with (hopefully) a somewhat tidier and more sensible bunch of geometry generation functions. I’m still a bit unhappy about the number of parameters these things take, but it’s a tradeoff between how much the caller needs to figure out for itself and how much flexibility the callee offers.
I’ve essentially ripped out the entire box generation function, and replaced it with a far more sensible (and hopefully) simpler set of routines that builds a box out of a set of panels. The idea is that now I’ve got a function to build panels in a useful way, I can use it to build more interesting looking buildings with blank spaces on their faces; this should hopefully make the city look less uniform.
One thing that keeps biting me in the ass is XNA’s peculiar insistence on using a right-handed coordinate system; I spent a good while trying to get the panels to line up on my boxes because my brain basically just can’t deal with the idea that positive-Z comes out from the screen rather than going into it. I really, really don’t get why MS did that, and if anyone knows the story behind it, I’d love to know.
Anyway, you can pull down revision 27 from the repo if you fancy having a look at the new building generation stuff.
Cityscape – update 9
Thursday, June 4th, 2009Not a terribly coherent entry, this one. And no pretty screenshot for you to look at either, I’m afraid – in fact, it’s not going to be very exciting at all. I’d skip it if I were you.
However, if you’re determined to know what I’ve been up to lately, you’ll find the following bits and bobs in the latest revision.
- Cylindrical buildings – and therefore, also, a new cylindrical primitive type. I tried to get this working in such a way that I could carve off sections to give a more modern, building-ish look, but I had trouble getting the surface normals to behave. The way I’m doing it at the moment, I generate vertices around the central point, with the normal for each vertex pointing outwards, and then generate the polygons by sharing the vertices. The problem comes when you slice a bit off, and the normals become interpolated across the face, thus:
The led to some weird lighting artefacts and the only solution I could see that would eliminate the problem simply would be to stop sharing vertices and rework the whole cylinder geometry generation code. Which is a job for another day, I think. - Manchester “Beetham Tower” style buildings – This is quite an iconic building in Manchester and a simple enough one that I figure it’s worth putting in – it’s basically a simple block skyscraper with an overhang halfway up:
Simple as it may be, though, it took me quite a while to get my textures to line up, and it’s still not right – also, the tower has quite characteristic window patterning that I should perhaps attempt to replicate. Still some work to be done here, I think. - Lastly, I’ve factored out a lot of the building builder classes into separate files – the Building.cs file was getting unwieldy and awkward to navigate, so now it’s much simpler.
I’m still not happy with the buildings: the big problem at the moment is a lack of detail: the buildings are all too uniform and the flat walls-of-windows lack any sort of visual interest. I’ve got a couple of ideas to add more interest – adding black columns to break up the walls of windows, a bit of rooftop furniture and more detailed buildings, that sort of thing – and hopefully I’ll find some time to add that sort of thing soon; it requires quite a bit of reworking of the BuildingBuilder, though, so it might be a while before we see any real results from it…
We’re up to revision 25 in the repo now. I wouldn’t check it out, though, as I seem to have forgotten to add a file to the commit. Bugger. I’ll sort that out when I get home tonight.
Cityscape – intermission
Thursday, May 21st, 2009I’ve not updated recently, but that doesn’t mean the project isn’t ongoing. I’ve been fiddling around trying to draw better buildings, but the problem – not to put too fine a point on it – is that everythign I’ve tried so far looks like total ass. I just can’t get something that looks convincingly building-like out of it. That, combined with the Cambridge Beer Festival sapping all my tuits, means that I’ve got very little to actually show you – there’s been updates to the repo you can look at if you like, but they’re not very exciting, and there’s some really, really ugly maths in there.
I think I need to take a few steps back and try some different approaches, but I promise I’ll have something new to look at soon.
Cityscape – part 4
Friday, May 15th, 2009Things have come on a bit since yesterday. I’ve added a first-pass of the building textures, and a polygon count (for reasons which will become apparent soon enough. Now, it looks like this:
The texture generation is simple enough (and mainly ripped off, like the rest of this project, from TwentySided’s PixelCity) – a 512×512 near-black texture, with 8×8 blocks of either light or dark grey scattered across it. To get the solid-black of the tops of the buildings, I’ve simply set the texture map to a single pixel at the bottom left of the texture.
Also, you’ll notice that I’ve added more buildings – in that screenshot, it’s a 31×31 grid of buildings (with random heights, for a bit of interest), and added a polygon count. Now, the reason I added the polygon count is interesting, and we’re going to learn a bit about how graphics cards work in the process.
So, I increased the number of buildings to 961, and the framerate stayed nice and happily at about 60fps. Excellent. Then, I got greedy, and made the grid 41×41, giving me 1681 buildings – and the framerate plumetted to around 40fps. This seemed odd – I’m not yet hitting really big polygon budgets. Games these days happily push hundreds of thousands, if not millions, of polygons per frame, and whilst XNA is doubtless adding some overhead, this machine manages to pull off things like Demigod and Dawn of War 2 on respectable settings without too much pain. So something, clearly, is up. I added a polygon counter just to check my sanity, and yes, we’ve nearly doubled our polygon budget, but it’s still only about 20k polys:
Hm. So, what do we do in this kind of situation? Well, we investigate! We’ve basically doubled our poly budget by doubling the number of buildings, right? Well, more or less, anyway. How about instead, we drop our number of buildings back to the original number, and increase their complexity? What happens then? So, I added the base back on, which is essentially just another box at the base of every building, and…
Wait, what? We’ve now got more polygons than we had in our 41×41 scenario and we’re still at ~60fps. Something odd is happening here. So what happens if we add more (mini-tower on top) and more (two stage body for the building) complexity? We can do three times as many polys as our original 31×31 city without a framerate drop – it’s only once we get to four times as many – fourty-six thousand, over twice as many polygons as in our 41×41 city – that we start to see any impact at all, and it’s only a couple of fps. What the merry hell is going on here, then?
Well, remember how our buildings are constructed: for each box, we insert the vertices and indices into an array, then convert these to fixed-size vertex buffers for use when rendering. There’s one of these buffers per building. As we’re adding more complexity to our buildings, we’re increasing the amount of stuff in each buffer; however, when we add more buildings, we’re increasing the number of these buffers that need rendering – so it seems that it’s the number of buffers (or, more accurately, the number of draw calls we make) that’s our killer here.
And this is an important point: think of a graphics card as being like a car engine. You get most efficiency out of an engine when you drive smoothly, and a moderately high (but not excessive) speed, without changing speed too much; driving around a city where you’re constantly braking, changing gear, stopping, starting and so forth is absolute murder on your engine’s efficiency – and it’s the same thing for graphics cards. Hand them a big buffer of triangles to go off and render, and they’ll tear through it at high efficiency. Hand them a whole load of small buffers, or change texture or shader regularly, and they really start to struggle.
The reason for this, more-or-less, is that the time for a render call is split into two parts – a fixed setup cost, and a variable rendering cost. If you’re rendering a large number of small batches, your render time is going to be dominated by a very large number of fixed setup costs; however, if you render a single large batch, you only have to do this setup once, and then the rest of the time can be spent on actually drawing the triangles.
So, what can we do about this? Well, that’ll have to wait until next time – but remember, all of our buildings are using the same texture, shader, vertex format, etc – so an obvious solutino should hopefully present itself!
(We’re up to bzr revision 13 now, if you’re following along at home)