Monday And The Week Ahead

At The Beginning

I have decided to do another of my rolling blogs, which time stamps my day to give you fledgling and ageing developers alike an idea of the pace of life in front of a coders keyboard.

My day started about 12:30, around noon, and greeted me with a small mountain of emails and paper correspondence which was quickly opened and discarded. Same too in most part to the emails which now split into Social and Promotional categories thanks to Google.  Much easier to mass delete both sections and increase the working week I found. With the handful of 'relevant' emails remaining I fired off suitably brief replies all round and began my day.

1:20PM : Character Tweaks

An email containing feedback on my quick character proto required a few tweaks to speed up the character animations and modify the animation set selection so that diagonal forward and backward walking uses traditional forward and backward animations rather than sidestep animations.  The result was a marked improvement and sent back to source for further study.

2:00PM : Emails' Gone

I finally obliterated the final email from my inbox, and it's now terrain time. The last thing I did was a quick and dirty terrain painter with solid colours. It really needs a texture there, and it also needs to fade into other textures on the terrain also.  This will be my next task, and I feel a shader coming on!

5:43PM : Texture Splatter

After some scrolling through the source code of Blitzwerks Terrain, it became apparent that although it does support shaders internally, I could not find the commands to apply a shader externally, nor did I feel confident to modify the source sufficiently to allow full shader support in the time available to me.  

I had to think out of the box 'again' and created a strange yet working system which creates a camera and points it at a large textured plane containing the current version of the terrain 'paint map'.  I then splat some quads on the plane as I draw, and then the final camera image is sent to the terrain system as the terrain texture. I then combine the quad blobs into the main terrain texture source image by creating a bitmap and transferring the resulting camera image to a texture which in turn textures the original large textured plane. In effect, this cyclic process allows me to draw quickly to the terrain using texture splatters, then combine in real-time the results of those drawings to the original terrain texture image.

This technique also allows me to float a highlighter over the terrain for more accurate terrain editing, and I can save out the final terrain texture at any time (ideally when the level is saved).  Here is the current terrain map after all my experiments up to this point:

The downside is that the step which combines the texture splats to the new final terrain texture image takes about 1 second, so the editing sequence will need to account for this, perhaps as a 'commit' button. The advantage of a commit button is that any editing during that sequence can be reversed or entirely discarded without penalty which might prove a good feature.

It's also apparent to me that I need shadows here. Raising terrain (currently combined with the painter) offers little clue as height until you scroll across said terrain.  Alas without the ability to override the terrain renderer with a shader, I cannot add the shadow mapping extras needed to pull from a cascade shadow map source.  I am left once again to think out of the box.

6:00PM : Small Shadows

I tried a few height maps to get a better canvas to continue my painting experiments and realised (rather belatedly) that the terrain employs the use of normals in the geometry which are aligned when the height map is first created, which in plain speak means I DO have a method of creating basic shadows (of a kind) on the terrain. Enough of a kind to indicate to the level designer exactly where the lumps and bumps are located as they edit.

Alas there does not seem to be a command to generate the new normals once the height data has been changed, nor low level commands to edit the data myself. I have thus decided to 'enhance' the raise terrain command and modify the normal data as the position vertices are changed. This will add some performance hit to the overall procedure, but it will be well worth it I suspect.

8:25PM : Stubborn Normals

I have tried four ways now to update the normals associated with the edited vertices.  The terrain module is divided between two DLL blocks which means access to ALL functions and members of the feature are not readily available. It is also clear that normal generation was only meant to be done during the build step so extricating the required code from the QuadMap structure is proving to be less than straight forward. Couple this with the fact I've coded non-stop and am now very hungry makes for a frustrating time all round. 

My latest attempt involves re-using the normal calculation performed when the terrain is generated, but this brings the FPS down to 11 though 'seems' to generate correct normals of the original height data, just not my edited data. I suspect I am acting on the wrong height/vertex data here and some more investigation could see correct normals from height edits a reality. The extremely slow update is a concern, but once I have it running I can look at ways to localise the update to speed things up.

I think the smart move now is to eat, and return later with a fresh head on my shoulders in the hopes of cracking this before the day is done.

12:22PM : Darn It

Many hours later, I can conclude the current method in the module for generating normals is so intertwined with the origination of the terrain from a height map texture, to add the normal commands would equate to writing substantial new chunks of code. Such work requires a very good understanding of the entire system, not just a small window into it.

The bitter conclusion for this evening is that I cannot affect the normals based on height changes. The height modification is only being made at the very end, the vertex data stage, and does not carry back in any way to the origination data.  Therefore using the existing normal generation system is out of the question unless I can affect the core height data, which of course leads me deeper into the rabbit hole!

Signing Off

And there you go, sometimes you get good days and others, bad days. Some days are both, and at least I managed to add texture painting and highlighting the terrain cursor on this day. I only hope Tuesday brings good fortune and some new ideas. I am now going to take me and my massive headache to bed in the hopes of slumber born inspiration!

Perceptual Computing Gets An Extra Perspective

Just a small note to say that an interview I gave for Intel has transformed into an in-depth case study on the trials and triumphs of Perceptual Computing development, and for those with more reading time available, you can discover this freshly released article here:

http://software.intel.com/en-us/articles/perceptucam-case-study