So, I haven't blogged for the last few months...

I have, however:

Rewritten most of the game code, improving nearly every bit in some way. It now loads faster, handles materials sensibly, is more flexible in general, handles physics meshes, and has consistent units and standards. Still needs light, improvements to the character controller, AI, load manager, region format, and sound spatialisation.

Almost finished the moped:

It just needs a couple of changes to the loom/code/variator to increase the top speed, a bigger battery set with 12v module, speedo calibration and bodywork replacement.

Printed ABS and PLA (to some standard, anyway - I need to improve X tension, reduce wobble, heat the bed better and improve extruder calibration, but I've had some strong, if ugly and dimensionally-dubious prints. It doesn't really cope with circles yet, but that can all be tuned.

Seen some cool stuff:

I've just entered exam season once again, so this post will likely be a one-off until the summer.

Charlie.

Physics

There are 1002 balls in that picture. Feel free to count, I checked.

Revision was *so* interesting that I took some time out to make that. Still not handling rotation, input or meshes yet (hence spheres, only bouncing vertically).

Next week's post will probably be non-existent, given that I will have 4 exams in as many days.

Charlie

One Year

It's been about a year now since I started blogging every week - I'm not sure yet, but it might be a good time to take a break, at least until exams are over.

In this time, I've:

• Applied to University
• All but finished a 3D printer
• Learned about, written the sframework and renderer for a game engine
• Taken my AS-level exams and the DT A2 exam
• Torn down and bought the parts for an electric moped
• Helped shoot much of Yaseen's film
• Obtained the electronics and most of the physical parts for the quadrotor

So it's been pretty productive. Maybe this year I'll actually finish some more of these projects though!
Charlie

Skeletons loaded!

So, I worked on skeletal animation and audio with varying degrees of success. Below is my second attempt (the intended model is shown somewhere below - it's a Hellknight from Doom):

Not as beefy as the designers intended...?

Which, whilst bad, isn't as awful as my first attempt:

Aforementioned first attempt. Don't laugh...

Whilst it was looking almost humanoid, clearly something wasn't quite right. Since an unfortunate number of points were getting crushed towards the centre, and the head was the worst-affected, I thought it might be due to my rotation code. After disabling that and changing the direction in which the model is "wound" (clockwise vs anti-clockwise winding of points on the faces), I had the following:

Ugly but better...

Finally realising a couple of pathetically silly mistakes (the transformed points being in the order w,x,y,z but instead using w, x,y and throwing away the z component, explaining the x-crushing, and doing the multiplications in reverse order), I was able to get the following:

Success...

The edges of each skeleton are fuzzed because, like nearly everything, my anti-aliasing is now in a buggy, ghostly half-finished state (which is good - bug-hunting is much more fun and satisfying than writing from scratch, and jaggies are worse than the ghosting). The balls in the scenes (around the feet) are some more testing code I couldn't be bothered to switch off - they're sound emitters, moving around the scene emitting sound, as you might expect a sound emitter to do. I'm not going to spend any more time on skeletons until time management is done better, so that it'll know what frame and sub-frame of animation to play.

I've also changed how lighting attenuation functions - now, an artist can define how lights fall off with distance. The next thing on the list is physics - I've had some basic motion working in the engine but it's still very, very broken at the moment.

Progress list: 

Still not started ,or architected terribly and completely broken

• Physics/game logic/scene management/trees
• Shadowing
• Skybox and Water shaders.
• HUD
• Environment mapping

Partially broken or significant work needed:

• Audio, particularly spatial and streaming
• Speed of lighting, especially stencilling ops - avoid them using FragCoord, minimise calculations wherever possible.
• Skeleton interpolation
• Intersection
• Resource/update/download/network management

To improve:

• Antialiasing
• Time manager
• Light equation/materials/BDRF used 
• Input and key binding (ties in with game logic)

To touch up:

• Model Format/Optimisation

Of those, gameplay, physics, skeleton and sound are all that still need work before the game is playable for development purposes. If people are willing to play audio-less with a ball for a character, it's almost playable right now - as soon as I sort the physics problems I've been having, I'll have a controllable ball interacting with the world.

Charlie

Not Skeletal Animation

The set of points from last week were the raw data of the "skeleton" of a Hellknight from Doom 3 - I'd intended to have skeletal animation at least somewhat working by today. No such luck, though I did fix the final issues of native library loading - it can now manage its own native code entirely, after adapting to some updates to JOGL, with a patch to skip over the part that my code already handles.

On the 3D printer, I added the Y-endstops (both home and end), and calibrated and tidied the wiring almost completely. All that remains before actually printing parts now is the X-axis belt and endstop setup (and using a spirit level to re-level the machine). A heated bed might be necessary to get the best-quality prints, though I'll see how it performs without first.

The motor for my moped arrived, too...

Finally, if you haven't already got it, there's possibly still time to pick up a copy of the Humble Indie Bundle (4) - pay what you want for some pretty awesome games (probably most notably, Super Meat Boy and Shank, both of which are gore-intense but brilliant games).

Charlie

Big steps

So, I've made some pretty big leaps forward in the game programming: 

First half of edge detection

For the anti-aliasing, I decided to use a method pretty much exactly as used in STALKER - so far, it's only detecting edges via the surface normals, but soon it'll also use the depth buffer, to ensure that all the edges are "caught" (look at the pot on the left - its edge hasn't been detected because the change in surface direction between the two surfaces isn't great enough. Once all the edges have been detected, it's a simple and quick step to blur them and so cheaply "fix" aliasing.

This step is a post-processing step, as is SSAO. I've also started to implement SSAO, though it needs configuring for the scene, and the blurring step is still not yet complete - it has to take into account depth, or the shadows will "bleed" onto bits they shouldn't. The final steps are exposure and colour correction - colour correction I've already done, but in lower-quality versions, and exposure is still in the works (fixed exposure only works at the moment).

I also wrote most of the intersection tests, which are going to form a fairly important part of the physics system, level layout and rendering optimisations. The overall plan is that every object in the world will be given a "bounding box", and quickly checked against the feature in question (for example, for checking if an object is visible, it's checked against the viewing frustrum, or for physics, a ray representing the motion of an object can be checked against anything it's likely to collide with). This can be optimised by including all objects in a "tree" of bounding boxes, where each bounding box node completely contains all of its children, so if the parent is outside the area in question,all of its children can be quickly eliminated.

The framework for a download and resource manager have been started - allowing files to be queued and made to download or update, and for resources no longer visible to be unloaded completely to save graphics memory.

I also tidied up the controller code somewhat for Windows - it can now get the proper analog values, and detect the type of controller and battery level (and interestingly, also the type of battery in the controller) of Xbox controllers. Almost completely pointless but cool nonetheless.

Finally, a teaser, most likely for next time:

No clues as to what this is for yet, but it should be interesting...

14500+ lines of code now, 333 TODOs listed.
Charlie

XInput

 So, I spent far too long working on getting the Xbox controller working - instead of using their standard input libraries, Microsoft in their infinite wisdom chose to make a separate API for the sole purpose of interfacing with their controllers. As a result, I ended up downloading a C++ IDE, and using Java's native code to work with those APIs. On the plus side, it means that the vibrate and separate polling of the triggers can be done (using the previous method, only Trigger (R-L) can be read not R and L separately) , but under Windows only.

Other than that, I tidied up the native code loading further - it now "cleanly" loads nearly all of the dlls or modules needed to run independent of platform and architecture (I still have to fix nativewindow though). Lights are now configurable in the engine rather than hard-coded into the shader (simple change but an important step), and I've started to write the basic game code/world itself.

Stuff I still need to do:

• Intersection tests/resolver for physics, area scripting for levels
• Scene optimisation
• Decent gameplay code
• Improve the importer (bring lighting, more material properties in)
• Finish lighting optimisation - actually do the stencilling - additionally, light clip volumes
• Antialiasing
• Shadowing
• Audio

Charlie

Small Steps

So, I finally sat down and spent a couple of hours coding the engine. I've started to tidy up my code layout and sort out decent input and gameplay - and in part of that, I bought a USB Xbox gamepad and played around with using it as an input. Unfortunately, the rumble feature is broken in the library I was using but otherwise, the controller works nicely and gives a nicer feel to motion - it's much smoother than a keyboard, and seems a fairly natural way of controlling a platformer-style game. I also added some very basic mechanics - nothing more than the basic laws of motion at the moment, and nothing visual either. 

Still planning to have something "playable" (i.e. vaguely resembling a game or game engine) by the end of the year if all goes well...

Charlie

Super-Secret Project

Another terribly-short-and-limited blog post to follow, so I don't blame you if you skip this one. Work, parents' evening, and the super-secret-project have been taking up most of my time. In no particular order, I have managed to:

• Sort the 3D printer bed out - glass cut and bored successfully (or nearly finished, need to tidy and finish the holes)
• Nearly-finish the lighting optimisations - stencils are now working, and now just need to fiddle around with how the information about lighting is stored (radius, colour, position, shadow-casting)
• Finish most of the programming on the super-secret project for the time being. Hint: it involves multiple virtual servers, a simple database, plenty of permissions, various types of buckets, and voxels. 
• Buy far too many games - RAGE, Amnesia, L4D2, FEAR series, and a couple of indie titles. I might do a mini-review when I get around to playing them.

I leave you with an incredible video - worth watching in HD.

Charlie

Bugfixes

This weekend, I got to see a legitimate Robot Wars battle at the NEC - two flipper-armed robots throwing each other (and themselves) around. I also saw and spoke to a couple of engineers on the Bloodhound SSC project and saw the vehicle itself.

On the game, instead of coding anything new, I went through some of the very worst bits of my code and carefully removed a few of the worst-offending bugs.

• The first one was that resizing the window would not resize the stencil buffer, resulting in some fairly unusual artifacts appearing. It took me a fair while to notice that I was actually allocating the buffer twice, and corrected it. Now I have stencils, which makes culling pixels for lighting very easy now.
• The second one was a silly mistake in how I handled texture path names. I'd been doing it in a silly way (hard-coded slashes, which is death for cross-platform compatibility) - I went through and replaced most of them with the appropriate platform-independent solution. 
• The final one was a complete pain to find and kill - I found that when changing camera angle with bright lights in the scene, the lights would flicker in a fairly irritating manner. I checked and double-checked my entire lighting code several times, as well as the matrix transformation, before realising that everything was (surprisingly) perfect. The actual issue was that my normal buffer was at too low a precision to make the lights adjust properly over a wide range of viewing angles. Unfortunately, a side effect of increasing the precision is that the lights now take longer to process - now, 800MP would seem to take (very approximately) half a second to run, giving me 16MP to use for lights, not 32MP (which is fair, given that I doubled the bits). It remains to be seen whether changing some of the other calculations (inverse of the matrices, reprojection, etc), lowering precision (8-bit floating not 16-bit floating buffers) and/or constraining the areas will be enough - though there's no reason it shouldn't. 

I also managed to fix George's PS3 for the second time and started work on a super-secret project, which is going to be revealed fairly soon (on or before next week).

In Motion

The printer is finally moving of its own accord - I discovered a work-around for the firmware issue. Connecting the Arduino via USB, connecting in RepStrapper, and then finally applying power to the shield allows the board to connect. The thermistor readings work fine and I'm pretty sure the heater MOSFETS do too, but the stepper boards get too warm to work effectively - I should have some thermal epoxy and old aluminium heatsinks spare to sort that out, though I dislike making any permanent changes to hardware (and that glue is just about as permanent as it gets). At the same time I should also be able to heatsink my 1W laser driver too, and get some pretty pictures of the beam at full power, without it cutting out as the thermal limiter kicks in. The only other option is to buy a new and higher-power circuit instead (torches have higher-power boards but with much less tight regulation, which should be OK for a tough laser diode, though it may shorten the life-span somewhat).

I've also played with the lighting shader code, and worked out that changing the data types (the "quick fix" solution to the lighting speed) is simply not enough to bring the time down to reasonable lengths - it saves a about 2 ms for 800 million pixels - not nearly enough. The only reasonable solution now is to apply the lighting calculation to less pixels - using an estimate of 0.75ms/4MP, that means that lighting can "afford" to light about 32MP and still leave enough processing time for pretty effects like depth of field, ambient light, SSAO and another lighting or material pass for skin, particles, and other effects. To restrict 100 lights to 32MP, the average visible light radius can be around 300 on-screen pixels, which is pretty reasonable - in a cluttered scene many of the lit pixels will be occluded anyway, so drawing the light with a depth comparison might save even more processing time. Shadows are also relatively cheap with this method but will still need careful planning. All of these estimates are based on a fast card at high resolution though, so others' mileage may vary.

Charlie

Thermistor Trouble

In the last week, I've added multi-lights, tidied up my current lighting method and planned/written the beginnings of a skeleton-loader - the Doom 3 format is particularly nice for my purposes. Lights are currently too inefficient - 100 simultaneous non-shadowcasting lights run at about 7fps at 2560x1600. Admittedly, I've taken some horrific shortcuts in the pursuit of simplicity (right now, for every pixel on the screen, for every light in view, it generates the inverse of a 4x4 matrix - not exactly a speedy process).. When I fix that particular source of inefficiency, I'll re-time everything, add shadows, and see if it still needs more work. After that is skeletons and game logic itself.

As for the 3D printer, I (badly) drilled the holes through the glass bed - it's still usable, but has some irritating cracks. The firmware is unfortunately proving to be a bit of a pain - I haven't managed to get everything working reliably. I remember having a similar issue previously, which I think ended up tracing back to the thermistor board, of all places. The board currently sends back a "start" signal, but doesn't do anything useful afterwards, and drops the connection. With a bit of luck that issue shouldn't take much more time to trace down and I'll be all but ready to print!

 Charlie

Normal Mapping

I took a bit of time off from working on the 3D printer to get back into the coding for the game. I designed and added a basic model format (one which requires nearly no interpretation before it can be sent to the graphics card, which cut load time in half), and implemented normal mapping:

Left-hand side: No normal mapping. Right-hand side: Normal mapped.
You will need to see the full-size image - note the detail on the lion's face and roughness of stone.

Normal mapping takes a flat face (for example, the pillar on the right) and adds small peturbations to the direction in which the surface is facing, based on a texture. These changes can add virtual roughness or smoothness to a surface without increasing the geometric complexity, which can make the surface lighting look more realistic, at a minimal performance hit.

The TODO list before something playable is ready:

• Skeletal Animation
• Audio
• Streaming System
• Game Logic
• Mechanics
• Shadows/Specular Power/MultiLights/Graphical Tweaks
• Basic AI
• A world/level to experiment with.

I'm aiming to tick on average one of these off per week, and have something completely playable by the end of the year. It's odd to think that I first played around with this code around New Year's time, and have now been working on this, on and (mostly) off, for almost a year!

Charlie

Ready to Print

The printer is now physically all but ready to go - all that remains is to finish the print-bed and belt, wire up everything and sort the electronics. This post will be edited when I finish.

It Extrudes!

After a weekend of heavy tinkering, I finally got the printer to spool a fair amount of plastic through the nozzle. The only bit I have left to finish now is the print bed, endstops, and the final bits of wiring/calibration - and then all of the optional bits, like insulation and taping the motor to reduce slip.

The very first stages of the extruder assembly - the clamp on the right grips the  plastic filament tightly. The grub screws (in theory - not on my first run!) hold the hot end in.

Later stage of the extruder construction - the big cog is driving the bolt, which in turn drags the filament through.

The near-finished extruder, now with motor.

No photos of the rest of it yet, I simply didn't have time - the SAQ isn't exactly the quickest form to fill out...
Charlie

3D Printer

Prusa Mendel so far

So, I spent a fairly long time over the weekend assembling my 3D printer. I'm still waiting for some bearings for the extruder, the print bed. and the final motor but otherwise it's all ready to go. Not much else to say, really, except check back soon to see it printing!

Charlie

I've made little progress with the game - what I have done has been mainly aesthetic, no physics yet. Normal mapping is almost finished - just need to compute the tangents and it'll be ready. On the plus side, I've made decent progress with the moped - it's in a decent condition given that it's been stored for several years with no maintenance. The brakes are even functional, though the front cable had seized. The gearbox (well, belt box) is also functional, but there's still plenty to do on it - for example, the engine has to be removed, lights sorted, legal bits checked, and it has to be weighed and measured fairly carefully, so that I can revise my estimates and get some real-world numbers to work with. I'll also have to buy the replacement bodywork. Motors are to be ordered shortly, it seems pointless to wait for delivery from China. Charlie

Scooter Mechanics

I spent the last few hours working out the mechanics for my electronic moped project - it should turn out to be fairly practical if I've got my estimations right. The range on about £450 worth of batteries is the limiting factor - about 20-35 miles depending on speed and mechanical efficiency. The problem comes in when you factor in hills - even a mere 5% incline is enough to significantly eat into battery life. Combined with a 1 hour charge time, it should be pretty useful as a commuter or student vehicle though. I still need to wait to hear about sponsorship, funding, and the legal status of my "donor" moped, and look into the process and costs of registering the vehicle for on-road use after it's been rebuilt, but it looks like the project is, at least in theory, possible. Even if it isn't entirely road-legal, 6kW (8hp) in something that weighs around 45kg will be pretty fun for off-road use.

The 3D printer project is not entirely forgotten either - expect to see more on that soon...

I'm also just going to leave this here regarding the quadrotor:

Yours textually
Charlie

Personal statement: Complete!

Since the deadline for submitting my UCAS application is tomorrow, so I hope you can excuse a terrible post. Just to say that I haven't yet got shadow mapping done, but it's not too far off now. The quadrotor theoretically now has spinning blades (fun fact: the tip of the blades move at over 80ms-1), which will be tested fully later today.

Charlie

Speculars: Sorted

Specular lighting is now sorted and working perfectly. I'm also now able to re-build shaders virtually instantly, which means no load-up time for minor changes - which should make shadows much easier to create and debug - more on this next time. The next big hurdle is getting some real game logic running. SSAO and anti-aliasing can wait until there's something playable, with good scene management, and at least vaguely optimised.

Charlie