Posts Tagged ‘lights’

Cityscape – Update 12

Sunday, June 21st, 2009

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 8

Wednesday, May 27th, 2009

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.