Not A Blog has moved!

Please update your bookmark to point to http://blog.parm.net/ - thanks!

Cityscape - Update 12 (particles everywhere)

2009-6-21 12:32:02

Finally got round to adding some lights to the buildings to stop those pesky aeroplanes from crashing into them all the time:

Again, as with so many things, these are not so simple as they appear. Several steps were needed to get these little static lights in place - but hopefully, it should mean later things like streetlights, cars and, hey, maybe fireworks of something, should be much easier to implement.

First of all, we generate another texture - a simple circular fade from white to transparent that can be used as the basis for all lights. At the moment, the fade is linear, and does look a little artificial, but it'll do for now.

Secondly, we need some way of rendering these: I'm using a billboarding technique that's fairly widely used in particle systems in most games. Essentially, you render a quad that always points towards the camera, giving the illusion of a solid 3D object with rotational symmetry. The effect - especially at a distance - is quite convincing. The trouble is, we need to recalculate the position of these quads every frame, to ensure they're always pointed towards the camera - and doing this on the CPU can get expensive. So, the obvious solution is to use a vertex shader: rather than pass in the pre-transformed coordinates, for each vertex in the quad, we pass in the location of the centre of the quad along with an offset to indicate which corner we're talking about (handily, this also corresponds with the texture coordinates, so we can re-purpose the texture component of the vertex data for this). Then, in the vertex shader, we use this information along with the position of the camera to calculate the real quad vertices.

Lastly, we need something to manage all the particles, so I've added a ParticleBatch class, analogous to the BuildingBatch, that looks after all the particles, calculates the vert buffer, renders them and that sort of thing. It provides an IParticleService for other game components to grab and dump their particles into: The naming of some of the interfaces should give a hint as to one of the current restrictions - that is, we only support static particles at the moment. This is handy from a speed perspective, but means that nothing in our scene can move: this is something we'll have to address a bit more when I want to add moving vehicles and things.

We're up to revision 40 in the repository now. Next step - I'm going to have to delve into the murky world of city planning, and hopefully make things look a bit less like a random collection of buildings, and a bit more like a real city...

Cityscape - update 11.1 (Quick screenshot)

2009-6-16 19:48:25

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:

Cityscape - update 11 (tiered buildings with panelled sides, oh my)

2009-6-16 19:43:27

It'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 (Refactoring)

2009-6-07 11:36:48

Again, 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 (drips and drabs)

2009-6-04 09:42:26

Not 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 2 (weather-related)

2009-6-00 14:13:28

So, it's unseasonably sunny and gorgeous in Cambridgeshire at the moment, so I've been taking the opportunity to spend some time in the big blue room with the daystar, and haven't got much work done on Cityscape lately.

I'm intruiged to know who's reading this, though - I know from my webstats that there's a few people have turned up since I started (or the same people, clicking "refresh" a bit more often) - and if anyone's actually tried checking out the source and building it. Is my insistence on using bzr putting people off, or would people prefer a latest-build .exe stuck online somewhere too?

Comments button is just below, let me know!

Cityscape - Update 8 (fading into the distance)

2009-5-27 14:29:48

Unfortunately, today's minimised screenshot doesn't look so hot (I guess it's something to do with Flickr's contrast enhancing algorithm), so if you want to get an idea of the latest developments, you should probably click through to the original image on Flickr to see it properly.

The big news this time is that I've added lighting attentuation and fogging - cities are big, nasty polluted things, and it's rare that you can see more than a couple of blocks anyway - plus, it means that when I add in distance culling in a while, I we hopefully shouldn't see things pop in and out too obviously :)

Lighting attenuation is just the light falloff as things get further away from the light - I'm not 100% convinced it's worthwhile at the moment, though. Fogging is very similar: a gradual blend towards the fogging colour (in this case, it's the same colour as the sky) as distance from the viewer increases.

Both of them are very simple to implement in our shaders - a couple of parameters to control falloff and fog colour, and a little bit of extra code to calculate the light falloff/fogging amount - basically, 1/(distance * k), where k is a more-or-less arbitrary fudge factor. The actual fog blending has to be done in the pixel shader, as we need to interpolate between the final resultant colour, lighting, texture and all, and the fog colour. This unfortunately utterly kills framerate on Intel integrated graphics chipsets; their poor little pixel pipelines just can't take it. There's actually a better way to do fogging than this on shader model 1.1 chipsets - the shader model actually supports fogging parameters - so I might implement a version for Intel chipsets that uses this mechanism and see if it improves matters.

I've also changed the building generation code: I've factored out an IBuilding interface and a BaseBuilding that can be simply inherited from to create different building types - I've renamed my existing building class UglyModernBuilding, and added a SimpleBuilding (a straightforward single block building). I've also factored out the actual geometry generation methods into another class, BuildingBuilder. I'm beginning to think Building.cs is getting a bit unweildy now, so there might be more changes/tidyups to come.

So, you'll notice the polys/sec is well down: about 8 million polys per second now. I'm not entirely sure what's causing this - turning any one of my individual effects off doesn't seem to recover the framerate so it's probably something more subtle. I'm not that worried about this right now, as 8 million polys per second is still pretty respectable, but I've got plans for more complex buildings pretty soon, which is going to eat into that budget pretty quickly, and necessitate either finding some more polys/sec, or implementing some sort of distance culling or LOD twiddling fairly soon.

Anyway, the latest bzr revision is 23; have a look if you like.

Cityscape - update 7 (We're all individuals - except him)

2009-5-25 14:55:55

So, one of the things the project I'm ripping off did to add variety was to make some buildings slightly yellow, and some buildings slightly blue. Yesterday's update was still looking a bit homogenous, so in the spirit of ripping off everything, I decided to implement the same thing. And it now look like this:

Now, this took a bit of doing. Because we batch up all our rendering, we try to change as little state during rendering as we possibly can - so, for example, we could have added an extra parameter to the shader to add a tint to everything rendered. However, this parameter would only have been changable between batches, which means we'd have to batch like-coloured buildings together - which would be entirely possible, at the moment, but later on I plan to exploit spatial proximity between buildings to produce batches for culling, and having to produce three batches per region would add complexity and potentially reduce performance.

So, the other place we can pass in static data? In the vertices. Each vertex could have a colour attached to it - this way, so far as our batching is concerned, all buildings are still equal. The downside is, there's no space in our current vertex format (VertexPositionNormalTexture) for this information. One possibility is to turn off lighting (the city is at night-time, remember?) but I've got other plans for that, too, so the best option seemed to be to roll my own vertex format - VertexPositionNormalTextureMod - which simply adds another Vector3 to VertexPositionNormalTexture. Then it's just a case of changing all my buffers over to use this format, add the relevant extra data and make the appropriate changes to the shaders to do the actual tinting.

Pleasingly, this didn't seem to affect framerates at all (at least, not on the number of buildings I'm working with at the moment), and the effect is quite lovely - it adds some much needed variety to the scene.

The latest revision is 21 in the repository - there wasn't a trunk revision attached to update 6, but you can check out revision 7.1.13 if you want to have a look at that.

Cityscape - update 6 (making things look better)

2009-5-24 22:23:56

Right, I've made definite progress towards getting things looking a bit better. It turns out that it doesn't really matter than my buildings are ugly as hell, because buildings actually are ugly as hell - at least for the most part.

The first thing I needed to do was make the textures more interesting. And, again, I just went straight ahead and nicked the technique used in TwentySided's blog, althought it took some tweaking. In each window, I've darkened a random selection of pixels in the lower half of the window, and then addded a small colour modulation.

The next thing to do was to make the buildings more interesting. Currently, a building consists of a central main tower, and then on one or more of the building's faces, a smaller sub-tower. This took a ridiculous amount of work to achieve, and several iterations of the maths concerned - and I'm probably still going to throw it away once I think of a nicer way of doing it. But it'll definitely do for now.

The last thing this update adds is a movable camera - the spinny-round camera was handy for testing performance and getting an overview, but it was seriously limiting in terms of making cool screenshots :) It's pretty simple - we have a position, a rotation around the y-axis and a rotation around the x-axis. The WASD keys move the position, and the arrow keys affect the rotation. We generate a look vector by transforming a view straight down the Z-axis by the two rotations.

Oh, and I made the background darker and added a black base, to make things a bit more city-like. If I'm honest, the dark blue sky is the thing that adds most realism out of the entire update :) One last screenshot:

Next, we make things a little less homogenous, and discover that it's not as simple as we might think.

Cityscape - intermission (Taten't dead)

2009-5-21 09:31:06

I'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.