Kind of Proper Lighting

Back to school tomorrow, already up too late. Ah well. Progress has been made on lighting - apart from shadowing and specular reflection, it's now fully usable. There are a number of speed improvements which still need to be done, but those changes will have no real effect on the image. Rendering speed is still acceptable as-is with the single light I've been using to test, but it can easily be pushed up far faster than it is currently - I'm using the simple but time-consuming approaches for now.

Charlie

Sponza Atrium

Here's a simple first-look at the engine. Currently it's showing the base texture and tangent-space surface normals of Sponza, a model used for tests (mainly lighting). The next step is to shift the normals into viewing space (using the transpose of the inverse of the transformation matrix, for reasons I neither understand nor need to), and use them to light the scene. This now works on GL2 (DX9-level) hardware, with ideas to extend to GL3.X (DX10) or GL4 (DX11) and add new features (re-building a high polygon count from a set of smaller points and a map - geometry shader).

Base texture

Tangent-space normals - the light blue colour represents (0.5,0.5,1) as a colour, which works out to (0,0,1) as a vector - the
"up" direction with respect to the surface. I have since fixed the out-of-place stone texture - a bug in the model, not in my code for once!

Still a fair way off actually lighting it - I need a way of quickly working out the distances between points amongst other things. At my current rate that might be done in a few days. Skeletal animation, a game engine, net code and sound system are a while off.

Come next Sunday, I'll be camping and so may not have internet access. If that is the case I'll have a scheduled post prepared. With any luck it'll feature working lighting.
Fuck wasps.
Charlie

Progress. Kind of.

I do Linux. It's a thing now.

This is going to be another short post, I'm afraid. Current progress towards the game is shown above - I've set it up to do real-time colour toning of scenes. It's currently just set to turn Red and Green down a lot, and Blue down slightly, and then switch the Red and Blue channels around (fixing the odd colouring issue I was having at the time of last week's post).  It's also rendering to an off-screen buffer at the same time - which means that the in-game content could all be treated in the same way, not just a raw image as shown here.

For anyone interested, the fragment shader code itself is shown. It really isn't that bad, actually. The code that goes with it (feeding it the data points, textures, etc) is horrific at first sight though. Finer-grain control over colours will be possible, when I write some code to handle one-dimensional textures (multiplying by 0.9, 0,7 and 0.6 were really just to test the concept).

The switch to Linux is an interesting one - I had previously done so on my laptop whilst "revising" - but now it's on my desktop, and it's permanent. On the whole I love the OS - everything is free, without any hassle - installing programs is as easy as typing its name, and pressing "Install". Programming is far easier than under Windows - the entire O/S feels more geared towards it. Even advanced changes only require a couple of lines of text. I'll only cave in and install Windows 7 when my craving to play Portal 2 gets too great, or when I discover that there's no fix for a bug I have with it. (The choice to use a Portal-related texture as my test image suggests I'm not going to last too long...) The only real barriers against wide adoption is the lack of apps like Photoshop, After Effects, and a large library of decent games, the perceived increase in complexity (no steeper than Windows - just not what people are used to), and maybe the self-imposed "free software" barriers (again, not a problem to me - technically formats like MP3 and DVD are licensed, and drivers without source code available throw up a "non-free" warning). That's how my experience of it as my "Main O/S" has been, anyway.

Linux is the one responsible for destroying the performance - it's not actually that slow.
Charlie

Shaders Aren't Easy

What I've done there is failed. 

I'm afraid there isn't going to be a substantial post today - I'm just going to show what little progress I've actually made on an "engine" (term used loosely) - my code can import a texture and show it on a slightly-mutated ex-square. Colours are a work in progress, and it's also using a complete hack to set the texture coordinates, but I think it shows that I'm not far off doing "useful" things in OpenGL. It's not going to win any awards for pretty code (once I have model importing, basic illumination and muti-texturing sorted, I can start writing pretty, fast and flexible stuff), but it's all practice and experience in the graphics language.

The texture on the right is the original, the two on the left are various attempts (guesses) at the right colour profile.

I've managed to keep the performance, at least...


"Failure is just delayed success". Is what failures say.
Charlie

5000 FPS. Like a boss.

(Yes, the Physics exam is in 10 hours.)

I didn't manage to hit 9001 FPS, and admittedly it's only 2 polygons, but pretty cool anyway...

I'm just going to leave that here as a little teaser of what's to come. That's actually a very basic shader program - which means it's running on my graphics card and not CPU. In non-technical terms, that means that you get much more speed on modern hardware, and a huge amount of flexibility, at the cost of a bit of complexity. Shaders in modern games control pretty much everything you see, in some way or another - from lighting to the position of objects.

This is only the start, but in the relatively near future, this will become a more full-featured game engine - is anyone interested in helping create a "complete" game, beyond who I've already spoken to? You don't have to be technically minded - there's a huge amount of non-technical work involved in actually creating a decent game - the more hands, the merrier. There may well be a Facebook group in the near future. I have some ideas, as do several other people. RTS/FPS/3PP are all possibilities - it depends on what people would like to do. In fact, some might be useful as miniature test projects, as the code/collaboration improves.

I'm clearly not Chuck Norris
Charlie