Cityscape – part 4

May 15th, 2009

Things 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)

Tags: , , , , , , , ,
Posted in Cityscape | Comments Off on Cityscape – part 4

Cityscape – part 3

May 13th, 2009

The march towards photorealism continues ever onwards:

Look, okay, one day I promise it’ll look more like real buildings. Today’s (first? we’ll see) update isn’t such a big one, but it adds a couple of useful bits and bobs.

Firstly, there’s that there framerate counter. To do that, I’ve added a new GameComponent, and in the Update() method simply keep track of the number of frames and the elapsed time (and have a ‘resettable’ counter that resets on 1second intervals, to get an idea of the ‘current’ framerate, as well as the average). This provides a service for the main Game engine to use to get the current framerate (which might be useful later for doing adaptive LOD cleverness). The display of the counter is achieved using a simple SpriteFont – the XNA Content Pipeline handles all the heavy lifting in turning a .TTF into something you can draw in your SpriteBatch, and there’s a handy utility method to draw the text to the screen.

(the reason for adding the counter was that I was running the code on my Samsung NC10 netbook, and whilst it looked like it was coping reasonably well, it was hard to tell exactly how well. Turns out it’s getting about 40fps, which is quite respectable, but with a lot of jitter and tearing. For what it’s worth, the machine I’m doing most of the dev on is a Dell laptop with GeForce 8600M GT, which is where the screenshots are from – it hovers around 60fps; I assume XNA is locking Update()/Draw() calls to vsyncs.

Next, I’ve added procedural texture generation. This is extremely early days for this yet; the texture generator class has a single static member that creates a 1024×1024 texture, grabs the data into an array, overwrites it with a checkerboard pattern and then sets the data back into the texture. Simples.

(actually, whilst doing this, I ended up bashing my head against a brick wall for a while – with texture sizes above a certain size, I was getting entirely black models, and couldn’t figure out why. It turns out that in texture creation, I was specifying the texture should be created with mipmap levels all the way down, but had turned off autogeneration of mipmaps, so only the highest resolution version of the texture had mipmaps. The textures were of sufficiently high resolution that the objects were being rendered using lower mipmap levels of the texture – which were all black! Turning on mipmap autogeneration fixed the problem.)

Oh, and obviously, I’ve added a few more buildings, moved the camera back slightly and added some ambient lighting. The latest revision in the bzr repo is 11, if you’re following along.

Tags: , , , , ,
Posted in Cityscape | Comments Off on Cityscape – part 3

Cityscape – part 2

May 11th, 2009

Okay, I know I said that I was going to make something a bit more building like next and, well, here you go:

Look! It’s got a plinth and everything! Well, okay, it’s not very exciting, and I’ll be honest, there’s very little extra making-it-look-like-a-building code in there – I’ve simply added another box and changed their sizes slightly. But there’s a bit more gone on behind the scenes:

First, in the first pass, each face had the texture coordinates clamped to (0,0) -> (1,1) across the face, which meant that the textures looked oddly squished or stretched on anything other than a perfectly square face. Now, the texture coordinates are calculated according to face size; a 1×1 world-unit square will have the entire texture exactly mapped to it – we’ll worry about changing this scale to more useful units later.

Secondly, in the first pass, I wasn’t doing things in a very XNA-like style: from my Building class, I was reaching inside the Game to grab the camera matrices to set up for rendering. Whilst this is entirely possible, it’s a bit ugly and leads to lots of unpleasant tangled dependencies. XNA provides a concept of “Game Services” – essentially public interfaces to objects that can be queried for from the main Game object. So, instead of reaching inside the Game for the camera matrices, we now have a Camera GameObject, and an ICamera service for it. The Camera is registered as a GameObject and a service, and then later on, the Building can query the Game for an ICamera object, and get the view and projection matrices from that instead. We also use the IGraphicsDeviceService that is provided by default, rather than grabbing that from inside Game, too.

Thirdly, the application can now be quit simply by hitting Escape, as I’ve added some simple keyboard state monitoring.

And lastly, I’ve changed the game from the default fixed update rate to variable update rate; I’m not entirely sure why XNA defaults to a fixed update rate – most games I know of use variable timesteps – and in XNA, it actually causes problems. The Update() (and Draw()) methods of GameComponents can lag behind in certain circumstances – for example, if the window is moved, or if input focus is switched – leading to unpleasant stalls in your game. Simply switching off fixed timesteps fixes this – and hey, it’s not 1993 any more, we can cope with writing our physics/AI solvers to deal with variable framerates.

As before, the code is at http://bzr.parm.net/Cityscape/ – this post refers to trunk revision 8.

Tags: , , , ,
Posted in Cityscape | Comments Off on Cityscape – part 2

Cityscape

May 10th, 2009

So, I read this series of articles on building a simple, programmatically generated city. The techniques being used are surprisingly simple and really quite old-school (everything is being done with what amounts to the state of OpenGL about 10 years ago – no shaders, no bumpmaps, no vertex buffers, nothing) – but the results are really rather effective. Anyway, as long-time readers of this here blog will know, I used to be a games developer way back in the day, and I’ve still got a bit of a hankering after 3D graphics programming, so I thought I’d give a similar project a go myself: I freely admit that I’m totally stealing the original idea here, but hey – imitation is the sincerest form of flattery, and that.

Anyway, I’ve been meaning to give all of Microsoft’s shiny XNA/C# tools a proper go for some time now, so this seems like an ideal project. This means I get to mess about with things like shaders, funky post-processing techniques and other modern trickery without having to muck around with all the pain of resource management in DirectX/C++ – this will probably be at the expense of a bit of speed, but hopefully the ability to make use of hardware vertex/pixel processing should make up for this.

I’ve got vague plans that eventually this should have stuff like cubemapped reflections for windows, dynamic level of detail for speedup, atmospheric effects using rayleigh scattering and lots of other exciting things, if I have time. But, first things first: the very first thing to do is to get something up on the screen. In this instance, it’s a hugely exciting texture-mapped cube:

Actually, there’s quite a lot more to this than it looks: to render that, we build an array of texture-mapped vertices with normals, then render it using a custom XNA effect (which, at the moment, contains a very simple pair of vertex and pixel shaders to do diffuse lighting). The light source is fixed to the camera position, and the camera is rotated around the box at the speed of 1 radian/second.

There’s two classes involved here: the XNA Game class, and the Building class, which is derived from the XNA DrawableGameComponent class. When the Game object is Initialize()d, a Building object is created and added to the Game’s Component list. When the Building object is Initialize()d, it calls the AddBox() method, which populates a list of VertexPositionNormalTextures and UInt16s with vertex and index data for a box of the appropriate dimensions, and then copies that data into static arrays (for speed of rendering). A texture and the render Effect are loaded and bound appropriately.

Then, on Draw(), the Game sets up appropriate render states, positions the camera, and calls Draw() on all the child components; the Building’s Draw() calls then sets up the matrices for its Effect, and loops over the Effect’s passes (in this case, there’s only one) calling DrawIndexedUserPrimitive() to render the box.

It’s quite a lot of code to get up and running, but hopefully this setup should mean that progress from here involves rather less setup and skeleton code. If you want to follow the code for this as well, there’s a Bazaar repository at http://bzr.parm.net/Cityscape/ – it’s read only, although obviously you’re entirely free to create your own local branches and tool around with it as much as you like. We’re up to revision 4 at the moment – and the first couple of revisions are slightly broken.

I make no claims about the quality of the code, or even if it’ll work on your machine – it’s a Visual Studio 2008 project, using XNA 3.0; it ought to build in Visual C# Express with a small amount of poking, but I haven’t tried it. It seems to run reasonably well on my poky little netbook (as well as beefier machine with Real 3D Hardware) at the moment, so with a reasonably recent machine, you should be good to go.

Next step: Make an actual building!

Tags: , , , ,
Posted in Cityscape | Comments Off on Cityscape

The Universe

March 8th, 2009

So, I was out a-wandering yesterday, listening to the Scientific American podcast talking about Einstein and quantum theory and how the Universe may be fundamentally non-local in a way that would upset both Einstein and Niels Bohr, and the presenter said: “The Universe is a strange place”. Which led to me thinking: no, actually. The Universe is not a strange place. It is, almost by definition, the exemplar model of something that is ordinary and normal. There ain’t nothing more ordinary than, well, everything. It’s our models of the Universe that are strange, surely?

Tags: , , ,
Posted in Miscellaneous | 1 Comment »

Not A Twitter

December 7th, 2008

Much like I don’t have a blog, and this isn’t it, I now don’t have a twitter feed either, and it isn’t here. You’ll be able to find all the places I am whilst not twittering, and things I’m doing whilst not twittering. How exciting!

Tags: , ,
Posted in administrivia, Miscellaneous | Comments Off on Not A Twitter

BBC Sound of 2009

December 4th, 2008

I aten’t dead! And to prove it, here are some mini-reviews of the acts that form the long-list for the BBC Sound of 2009

  • The Big Pink: Glasvegas with synthesizers and drum machines. Which ought to be
    alright, but it leaves me a bit cold.
  • Dan Black: 80s electro-pop. There’s going to be a lot of this in 2009,
    apparently.
  • VV Brown: 50s pop. Entertaining and the single Crying Blood is decent, but will
    probably be pretty disposable.
  • Empire of the Sun: Very, very 1980s synthpop. Done well enough and not actually
    that objectionable to listen to, but you have to wonder why they bothered,
    given that the 80s already happened, and that.
  • Florence and the Machine: Wants to be Kate Bush. Probably isn’t, but hard to
    judge from the one song on the BBC’s website.
  • Frankmusik: Like Calvin Harris meets The Killers. Insanely, ridiculously
    catchy, self-conciously fashionable and has the kind of face that would look
    really, really great on the end of a fist. Guaranteed to be huge.
  • Kid Cudi: Hip-hop. I am ill-qualified to pass judgement on this genre, but it
    doesn’t sound like anything new.
  • La Roux: Prince, except with a girl on vocals. Hell, the single even sounds
    like When Doves Cry.
  • Mumford & Sons: Quick! Someone find me another band that sound exactly like
    Noah and the Whale! It seems the public are suckers for half-assed novelty
    folk!
  • Passion Pit: An annoying version of Bent, if they’d been listening to Battles.
  • Master Shortie: British hip-hop. Actually, fairly interesting. Likeable in the
    same sort of way Dizzee Rascal is.
  • Lady GaGa: A “hip New York party princess” who went to the same school as Paris
    Hilton. That’s all you need to know.
  • White Lies: File under Interpol or Editors. Particularly Editors. Catchy.
    Remains to be seen if they’ve got more than a single in them. Worrying
    propensity for swirly synths. If their album sounds like the single, I’d buy
    it.
  • The Temper Trap: Early U2. Uber-delayed guitars, 3-3-2 rhythms, lots of
    tom-rolls on the drums, picked bass. Far from terrible, but not exactly
    revolutionary.

So there you go: Next year’s hottest music, comprehensively dismissed as being a bit “meh” by a man who is rapidly approaching 30 and wants the world to know it.

Tags: , , , ,
Posted in Music | Comments Off on BBC Sound of 2009

Manchester City Council Council Tax Unit are a bunch of useless cretins

September 11th, 2008

I knew it was too good to be true. I told Manchester City Council I was moving, they issued a final bill and closed my account, and then a little while later sent me a cheque for the amount I’d overpaid. Fair enough.

Except today they’ve sent a “final demand” for &ukp;85 for no clear reason and a demand that I pay it by the 16th September (the notice having been issued on the 9th, giving me “7 days” – ahahahahaha, right) to pay it or they get a court summons issued. And their phonelines close at 5pm because they’re lazy fuckers and letting people contact them at sensible times is just too much like a fucking good idea.

GAH. This is fucking ridiculous.

Posted in Uncategorized | 4 Comments »

Just sayin’

September 4th, 2008

Jeremy, former flatmate and world-traveller, came back from tending to monkeys in Africa to post some photos on facebook. He seems… kind of familiar:


Jeremy Brown, international traveller and monkey rancher
Jesus Christ, our Lord and Saviour

Posted in Uncategorized | 1 Comment »

Settled

August 4th, 2008

So, we’ve been in our new house a week. We’ve got most of the important stuff unpacked, have taken delivery of a fridge/freezer, built the bed, got a sofa off my parents, got the phoneline and broadband turned on and most of the books, DVDs and CDs unpacked (no small feat, it must be said). We’re still waiting on some furniture from Ikea (a desk, a couple of chests of drawers and wardrobe – we’re still living out of suitcases at the moment) and I reckon a lot of stuff will probably stay in boxes for a while yet – but basically we’re living like almost normal people. Almost.

Anyway, we’ve got a lovely garden that we’ve barely used because after being ridiculously hot for the three days we were unpacking and lugging boxes around and things, it’s been raining more or less constantly since, and the house is lovely and it’s great to be back in the countryside again.

And there’s a field of ponies on my way to work. Yay! Ponies!

Posted in Uncategorized | 3 Comments »

« Older Entries
Newer Entries »