Votes Needed, Suboptimal Source Control and Glorious Graphics

So! Still around I see? Good, because as always there's some interesting things going on. To start off I want to ask people to vote for SuperTuxKart in the newly launched 'Linux Game Awards' Project of the Month Award, which seek "to raise awareness for individual free game projects and for the the free gaming community in general". We have been nominated for January, and voting ends on the 24th of December 2013 (this year, if anyone reads this in the future). So please cast your vote at vote.supertuxkart.net and while we of course hope to win there are other really fine projects nominated, so if you feel like voting for someone else we won't take it personally. ;)

What are the plans going forward? We want to do another minor release before the major 0.9 release bringing full network play support. Why the seeming delay in bringing networking to the masses? While this year's Google Summer of Code brought with it two pieces of the network puzzle, we still have a couple others which needs to be in place in order to make it enjoyable. One of those pieces has been in the making for a while, but there are multiple features and factors demanding attention. On a positive note, you may be able to try playing over a local area network (LAN) in 0.8.2 but this is not certain at the moment.

Your next questions is probably going to be when you can expect 0.8.2 to happen. And as usual, we don't know yet either - it depends on those pesky features and factors I previously alluded to. Well "pesky" might be the wrong word; after all features and bug fixes is what a new release is all about. But for those already anxious for the next version, you should not hold your breath because often things take longer than first anticipated.

After that violent jolt back to reality, we continue with the upcoming hopes and dreams. Google Summer of Code 2014 will happen earlier than this year around, which means that we will soon have to prepare for it. Whether we get accepted is not a given, but if I may be so bold to say, I think our chances are probably quite good. This year went very smoothly thanks to our students and volunteering mentors, and we hope that the success will continue next year.

One issue we did get was merging the branches together in our normal development version (called 'trunk'). The two networking related branches were somewhat co-dependent but not fully compatible, so it took a while to clean things up and make everything puzzle together neatly. This spurred a recent effort to move code development from the Subversion source control system to what is known as Git. We are still in the process of moving, but in the end Git will bring some advantages that will make future branches easier to merge together. As a bonus, it's all the rage these days and might be more familiar to prospective STK programmers.

In summary, currently and probably for a few weeks development is going somewhat slower than usual, but after the usual winter break things should be back to normal. Normal still means that development is non-linear and often happens in bursts of activity rather than a slow trickle, but we'll be leaning more to the latter when we have settled nicely into 2014.

But wait! There's more! Our 3D artist samuncle has been waving his magic wand (or maybe hand?) again creating this masterpiece:

A little explanation is in order. The track is new (and still work-in-progress), and shows off his new-found graphical style featuring painted textures sometimes combined with photos, rather than having photographic textures only as the trend were going towards. This ensures a more "cartoony" look while making it look better by using larger texture sizes, and adding various effects on top. Several of those effects were made by our GSoC student cand, while others, like the colour correction demonstrated in this screen capture were added later. Left is before any colour correction, where we can see that it looks a bit dark and bland, while the right side shows colour correction turned quite high. In the end we might settle for something more in-between, but in any case several tracks will look more vivid and less dark than they used to be. This, in combination with other graphics work happening lately, will do wonders for the look and feel of SuperTuxKart. 0.8.2, and especially 0.9 will make the game stand more out in the graphics department and will be a fitting upgrade to round off future features and (wow) factors with.

Excited yet? I'll round off this blog post with a reminder to vote for us, and also say that while the wait might feel long, it will be worth it in the end! :)

SuperTuxKart 0.8.1 released

We are proud to announce the release of SuperTuxKart version 0.8.1.

Full resolution available at supertuxkart.net/posters. Drawing by Mariam Lamrani

This release includes the following features:

• New track 'STK Enterprise'
• Updated tracks 'Old Mine', 'Around the Lighthouse' and 'Zen Garden'
• New modes 'Soccer' and 'Egg Hunt'
• New karts 'Xue' and 'Sara'
• Updated 'Beastie' kart
• Wiimote support (for most Wiimotes; check supertuxkart.net/wiimote for instructions and compatibility)
• Added tutorial
• Added new 'SuperTux' difficulty
• New bubblegum shield defensive weapon
• New combined speedometer and nitro meter
• Added ability to filter add-ons
• Updated nitro models
• Added ability to save and resume Grand Prix
• Improved skid marks and particle effects

Video available at youtu.be/WutAN4i98_o. Trailer by Thomas Fournet

It has taken us a rather long time for a minor release, but most of the developers have been rather busy with mentoring students for the “Google Summer of Code 2013”. On the other hand, we had many contributions from new developers: Dawid Gan tirelessly fixed bugs, making 0.8.1 the minor release with most bug fixes. Johannesr1 added shield functionality to bubblegum. Xenux added filtering of add-ons, Glenn De Jonghe saving of a Grand Prix (just abort a Grand Prix at the beginning of a race, later then restart the same Grand Prix again). Funto and Mohammad Al-Ghannam added a multi-player soccer mode.

You can get the new release from our download page for Windows Vista and newer, MacOSX 10.6 and newer (Intel architecture), and Linux (32-bit and 64-bit Intel/AMD architectures). Windows XP version will follow soon.

We hope you enjoy the new release, and as always we welcome new artists and programmers to join us, either through our forum or our mailing list. Also, you can follow us at Twitter @supertuxkart.

With SuperTuxKart 0.8.1 you can race roaringly rapid or roam ridiculously 'round, whatever you want!

French translation of this blog post: samuncle.net/?p=247

SuperTuxKart 0.8.1 RC1

We are pleased to finally announce the first release candidate for version 0.8.1. Major changes are:

     * New track "STK Enterprise"
     * Updated tracks "The Old Mines", "Lighthouse", "Zen Garden"
     * New Soccer mode
     * New Egg Hunt mode
     * New karts Xue and Sara
     * Updated Beastie kart
     * Wiimote support
     * Added tutorial
     * Added new "SuperTux" difficulty
     * New bubblegum shield weapon
     * New speedometer and nitro meter
     * Add ability to filter addons
     * Updated nitro models
     * Add ability to save and resume Grand Prix
     * Improved skid marks and nitro effects

Obligatory screenie: Old Mine got more shiny!

You can find binaries for Windows and MacOSX over at SourceForge.net

We will try to get a Linux static binary as soon as possible
We now have a Linux static binary as well, but in case this doesn't work for you, you can compile the source package yourself. Note that we now use CMake instead of autotools, so be sure to follow the instructions on our wiki.

Also worth mentioning is that while we now have Wiimote support for most such devices around, one specific model is not working yet and hopefully we'll be able to fix that sometime later. See details for that and how to connect your Wiimote over at supertuxkart.net/wiimote.

That should be all, please help us test and give feedback especially if you notice any problems. Enjoy!

GSoC and String Freeze for 0.8.1

The "Google Summer of Code" finished about a month ago. First of all a congratulation to the three students - hilnius, unitraxx, and cand for their fantastic work. They survived more than three months of frantic hacking, frustrating bugs, questions, testing, and discussions. As a result, we have three branches filled with new goodies for SuperTuxKart:

• Cand added significant graphical improvements. On one side that made our artist samuncle very happy, on the other hand this will keep him busy, since now he has to improve all tracks to make use of the new features.
  
  

  

• Unitraxx added an online lobby, allowing people to login, declare friends, and even store achievements. All in preparation for a full online experience ... which will keep our team busy.
  
  

  

• Hilnius added networking support, allowing people to connect different computers and play against each other. The first online game was already played between Arthur and Hilnius.

Also a big thanks to our mentors - Stephen, Funto, and Auria, who helped and supported our students. Their guidelines and experience was important to give us the excellent outcome we had. A special mention also to Arthur, who was the go-to person on IRC, tirelessly motivating our students, keeping them entertained with his puns, and acted as a tester.

I am aware that all of you are very keen to see the next improved version of STK, so here a brief overview of the things that will happen next:

• Arthur is already organising the 0.8.1 release. And the important news item here: we can now declare the string freeze. This means, no more changes to any strings in the game, and all translators can start work on their translations!
  The 0.8.1 release will not include any GSoC work yet, but all the improvements and bug fixes that have been done in the months since the 0.8.1 release. Note that the main developers (esp. auria and myself) have not done very much work for that release, but we had important contributions from the community. This is not supposed to be a complete changelog, I just picked the major improvements from our growing community:

• deveee who tirelessly fixed bug after bug, earning himself the title 'Bug Fixer of the Year'.
• Funto's and Yasin's soccer mode.
• Using the bubble gum as shield thanks to Johannesr1.
• Grand Prix saving thanks to unitraxx (contributed before he started working on GSoC).
• Add-Ons filtering by xenux.
•  The next release will merge in cand's graphical improvements. This will require a fair amount of work on tracks to improve them. Samuncle has developed a new style for this, and he has started to create a great looking track following the new guidelines. This takes a huge amount of work (creating new textures, new models, ...), so any support here is appreciated. At this stage I am not entirely sure if this release will be called 0.8.X, or 0.9. The latter would make more sense, since it will visually be a big change, on the other hand 0.9 was according to our milestones the online version (which would then need to be 0.10 or so). Well, numbering is not important - 0.X it will be.
  While samuncle is quite keen on that version, the full graphically improved version of STK might only arrive after 0.X. We will try to release early versions with only some new tracks, so that you can all see where we are heading to. We really want to have more artists working on STK, so showing off a glimpse of what STK can look like will hopefully motivate more artists.
• After that we will start working on the online mode in earnest. Even though thanks to GSoC we have a solid base to build on, there's still a lot to be done. We have to merge the work from hilnius and unitraxx. And while they did a good job, there is still a lot of testing and polishing to do. One important outstanding thing (which was not part of hilnius' task): hiding latency by using rewinding. Without this STK can be played with 'good' network conditions, but not reliably and fluently enough under real world conditions. At this stage we are not sure what 'good' conditions actually mean - LAN with cable only? LAN with wireless connections? WAN? A lot of things to test. True enough, one game between two people in France and Norway was already played without latency hiding. Depending on time we might release some LAN-only networking versions before. Also, depending on features we want to include, we might also need at least one dedicated server for the lobby, and ideally to prevent cheating perhaps also dedicated online servers - though discussing, testing, and evaluating various approaches are the things that will be on our todo list over the next months.

Now, I will not present a timeline here. After all, STK is a hobby project for all of us, and delays do unfortunately happen. But for us it feels we are getting close to the long awaited 1.0 release.

As always, we can use any help to speed things up - bug fixes, coding new features, testing, documenting, 2D / texture artists, 3D modelling, ...  For example, with the upcoming 0.8.1 release we are very interested in a 'PR Manager' - someone who can write regular tweets for us, perhaps maintain a Facebook page, advertise on other web pages, ... No programming knowledge required, but you should have a good grasp of English. You need to be able to build STK yourself, which luckily is not complicated (and we are happy to give you a hand). So, don't hesitate to contact us - either on our forums, or for more immediate answers on IRC (#stk at freenode).

Also Google has announced that there will be a Google Summer of Code 2014 - the 10th one, a nice round number. While I can't guarantee that we will be selected again, our experience with GSoC 2013 was great, so we will try to be part of it again.

Cheers,
   Joerg

Graphics final: statsy

As nothing major will be happening on the graphics front from now on (docs, cleanups), let's print some stats for our loyal followers.

Splashing on some pics to not scare you out outright with numbers. That's one damn cool looking barrel in the shadow if I say so myself.

That glass is wavy. Distortion effects can now be used in underwater/aquarium levels.

Anyway, to the main meat. Any bugfixes and other code that could go directly to trunk has gone there, so these numbers are a bit short for measuring all the work I have done. They are only the graphics parts that couldn't be merged with 0.8.1 not yet out.

162 files changed, 8410 insertions(+), 1509 deletions(-)

We're around 10k changed graphics lines.

By file count, 68 out of 162 or 42% are shaders; by line count, shaders account for ~2000 lines, or 20%.

The top-10 files with most changes are:

 src/graphics/render.cpp                            | 787 +++++++++++++++++++++
 src/graphics/callbacks.cpp                         | 744 +++++++++++++++++++
 src/graphics/post_processing.cpp                   | 724 +++++++++++++++----
 src/graphics/callbacks.hpp                         | 683 ++++++++++++++++++
 src/graphics/material.cpp                          | 620 ++--------------
 src/graphics/irr_driver.cpp                        | 353 ++++++---
 src/graphics/lens_flare.cpp                        | 264 +++++++
 src/graphics/shaders.cpp                           | 256 +++++++
 src/utils/helpers.cpp                              | 220 ++++++
 src/graphics/mlaa_areamap.hpp                      | 200 ++++++

To end this, posting the final and only video, one of source code ;)

The music is Ancient tale by Radek, CC-BY.

(in case you wonder why: nobody likes watching jerky fraps-like captures, I don't have a capture card, and STK doesn't support non-realtime capturing (yet).)

Wrapping up, your graphics dude.

Graphics 9-10: 60 shades

Evening, our loyal supporters, and other random passersby who happen to read this blog, if for no other reason that its choice of font is excellent.

While this period's plan was to get wet (insert Snoop Dogg reference here), shadows were deemed more important and pushed water back to next period. Grass, having already been taken care of at a satisfactory level, will drop off the plan, having been replaced by water.

Here you see the importance map with some more functions of importance: distance from the camera, surface normal, and the luminosity of the seen pixel.

Distance is obvious, close shadows need more resolution than far-away ones. The surface normal function boosts the importance if the surface happens to be facing the camera, as shadows on that are more visible than those on a wall at an angle. And finally, darker pixels need less shadow resolution than brighter ones.

Together, we have approximately 16 times better resolution than good-old-shadow maps.

Then, the work progressed towards soft shadows. You might chip your finger on those hard edges if you're not careful, is all.

Having checked the most often used books on your coder's bookshelf, the Necronomicon and the Book of the Law had nothing on soft shadows, which was greatly surprising. Thus we had to dig deeper, finding an antique copy of Gpu Pro 2 buried in a temple close by.

That book details an incantation of screen-space soft shadows, a scalable spell that produces nice-looking soft shadows from any shadow technique. It's far from a uniform blur; shadows are sharper close to the caster as they should be.

Unfortunately we're not immune to a characteristic of warping shadow techniques: the edges swim. What could be done to limit it has been done, but as shadow pixels vary in size and position, fully stable shadows aren't possible with warping techniques.

Luckily, it's not that noticeable with soft shadows and racing at speed. Still, it highlights how this is still an open problem.

The next bit is for artists.

Here we have the screen and shadow views of a fence. There's slight peter panning going on, but otherwise it's looking good. Artists could help the Pan problem by making the fence thicker.

Going forward next to the fence, we see the shadow suddenly disappear. What's that? A fence made of grass decided to rot and disintegrate in place? No, nothing of the sort, sadly. Not even termites.

In the shadow view we see the issue: uneven warping due to huge triangles. Sure enough, checking the wireframe view, the fence tris are rather big. Warping techniques are sensitive to huge triangles: they can cause artifacts like these. Subdividing the appropriate parts gets rid of that.

And finally, water was started on. We have nice glittering summer caustics here, visible at the pool's bottom. Hard to see in a still picture you say? Aye, it be so. Take a sip of your closest bottle of rum, and repeat enough times that the lights in the picture start to move to get a picture of how it looks like.

So, the remaining time shall be spent in all kinds of wetplay; hopefully 0.8.1 will be out soon, so we can begin integrating the graphics changes. Many of them need updates to tracks so that they can be fully realized, which would push a release back a century or so, give or take 99.8 years.

Graphics 7-8: gods in motion

Long time no ABC, Pöysti mah man.

What you see above is a sneak peek from the latest work of the Great Sitting Artist, samuncle. He's been getting intimate with the new lighting system, and it shows - can you see how much it blushes? It's adorable really.

Back to our regular scheduled program. The topics for the biweek were motion blur and god rays. Bugs were found, and according to the great principles of persistence hunting (a method used by no other animal than humans), were ran after until they collapsed to death from mere exhaustion.

While that certainly takes the fun out of seeing the bugs writhe in pain, at times you simply can't outrun them and need other measures.

---

The existing motion blur was a radial blur with protection for a certain area of the screen. It looked good enough, but was a bit slow, and the protection area was static.

Given the task here is eye candy, physical correctness be damned; one had to see how it would act when optimized and tweaked first. Before and after, with the protected area visualized in rogue red:

As you can see, the static area didn't cover the kart when speeding, resulting in blur being applied to it when it shouldn't have.

With that fixed, some optimization improved the motion blur's speed by 33%, and as it still looked good, that was that.

---

God rays, light shafts, or a strange sky hybrid of SSAO and radial blur, are this thing you see when your room has not seen a vacuum cleaner in a month and somebody opens the curtains.

Implemented according to the letter and spirit of the long-dead guru GPU Gems 3, may she rest in peace, we draw the sky and sun to a texture, trace the path to the sun, and sample along that path.

Hijacking on the occlusion query for the lens flare, we can determine the visibility of both effects with one stroke, as both are only visible when the sun is.

---

This section will be a bit more technical than usual; please bear with us.

Shadow maps, invented by Sir Williams the Fourth in 1887 or thereabouts, are a method not used by ancient Romans to fake shadows in a two-dimensional quantum display, otherwise known as a picture.

The problem of shadows, unlike that of light, is still unsolved, to the dismay of many. There is no known method to have beautiful shadows that scales well. Therefore we limit ourselves to only casting shadows from the sun; as a directional light, it's merely one render pass more, compared to six for a normal point light.

The above picture is an implementation of a basic shadow map. Far from a next gen darkness system, it produces 50 shades of Minecraft, as one can't simply get enough resolution for the whole visible camera range.

Clearly this is not adequate for us; for we are neither Minecraft nor fans of Twilight fanfiction. As it happens, the current state of the art in shades is rectilinear shadow mapping, made public a year ago by Paul Rosen.

Unlike some other publications of the same era, this technique can be fully implemented in GL 2.1+, without requiring any kind of GPGPU or even float textures, and it also runs faster than the previous state of the art solution, cascading shadow maps.

Rest assured no animals were harmed in the production of this picture; the lines are completely fake leather. What we have here is a packed depth image from above the Jungle level. The area highlighted in white is the back-projection of every visible pixel to this camera, allowing us to find a much smaller area to focus the shadow map on.

The importance map in closer view. In Rosen's algorithm, we determine an importance value for each pixel; in this image, every visible pixel is given an importance of 1, and invisible pixels 0.

What you see on the borders are visualizations of the two 1-dimensional importance maps generated from this image. For each horizontal and vertical line, we take the maximum value to the corresponding 1D importance map. This is done via a per-pixel loop in a fragment shader.

For each importance map, we then generate a warp map of the same dimensions. Red means shift this pixel back, black means stay put, and green is shift this pixel forward.

It's these two 1D warp maps that make the core of this technique. No shadow map area is wasted on pixels not visible (with the exception of those in the same row/column), and the important pixels are bigger than the less important ones. This means that the core area of a shadow might have less resolution than the shadow edges, giving the illusion of a much higher resolution shadow map.

For the exact format, it is a normal RG8 texture, and you can easily use RGBA8 instead with two bytes wasted. The negative range, -1 to 0, is stored in the red channel, and the corresponding positive range in the green channel.

This gives us 16 bits of precision for the warp map, which ought to be plenty.

Here's a warped image of the same Jungle level. As this image only uses the visibility importance, it is not that warped yet; only invisible pixels are removed from the shadow map.

Applying other forms of importance, we can decide that shadow edges need more resolution, or that pixels close to the viewer need more. This is a quite powerful technique using little power or VRAM; 1x512 RGBA textures take 2kb each.

This implementation is not yet complete, there are some remaining artifacts, and optimization & tuning has yet to be done. So expect more shadow work in the coming weeks.

Finishing this investigative report, we have a picture of an old classic game Slicks'n'slide. It's a top-down racing game with weapons, a favorite of mine.

Signing out,

Want to play online ?

Hi you,

After my last post which was very technical about the network, I wanted here to show you at what point is currently the online racing in your favorite open-source game ! So I've decided to make a short video for you to see that you can starting from now play online with other players, as long as you don't have high pings (<100ms).
I didn't know where was the server when I recorded the video but now I can tell, the server is in Paris, France, and my ping to the server is under 50ms. This is important because there is no lag compensation yet, but don't worry hiker is working on it :).
For instance, i played with Arthur who has a ping (from Norway) of 75ms to that server. Turned out that we felt the lag while playing essentially concerning picking powerups.

I won't make you wait, here's the video.

Do not hesitate to send your comments here or on youtube !
Cheers,
Robin 'hilnius' Nicollet

Random ramblings among riveting revisions

Greetings, SuperTuxKart-lovers (and occasional passers-by)! Your benevolent blabbering brat is back, to give some additional updates between all the honest, hard-working heroes writing here nowadays.

Zero point eight point one pontifications
I guess the first thing people are wondering is where did 0.8.1 go. The simple answer is that it's still not quite ready, for various reasons. One being that we didn't anticipate GSoC and all that would entail when giving our first tentative guesstimates, and the other being personal commitments taking up most of the rest of time the developers had. So where is it at right now?

Wiimote support is almost ready. However, the newer Wiimotes with built-in Motion Plus does not work so far, mostly due to lack of developer time. Bringing full support for Wiimotes might be pushed back so as to not stall the release even longer.
Soccer mode has been worked on by Yasin, who was one of the students we would have really liked to have but didn't have room for. Mad props to him for staying with us nonetheless and helping out even though he has various other things to deal with. Right now soccer mode has team support, with markers showing which karts are on which team, and will just need a few additions to be in a usable state. How fun it will be in the first release is left to see, but that will surely be refined later.
The tutorial and Easter egg mode are both pretty much finished, though for the latter there's an acute lack of tracks with eggs defined. 0.8.1 might just become a preview release for this feature, just like soccer mode.

STKSoC(sic)
Then there's the GSoC stuff. Yeah, that's not really exciting, so I guess you don't want to read about it.
Just kidding! Cease fire, please! We just had our mid-term evaluations, which means we evaluate whether the students have done what they've promised, and if not what can be done to repair it to get a passing grade. But due to the hard work of our three students there was no question at all that they would all pass with a spotless record. But don't take my word for it; just read the excellent blog posts they've written! Cand with his fancy-pants graphics (making an old-school grump like me wonder whether I should drool or say 'meh'. I kind of do both at the same time, though I'd never want to go back), hilnius with his back-packet trips back and forth the interconnections, and unitraxx with his... wait, where are his blog posts? Oh, there they are! Be sure to read his musings on being a Google Summer of Code student and how he's solved his tasks with dialogs and obligatory screenings. Congratulations to all of you, and keep up the good work!

Blondes on snowmobiles

What's this? Could it be... yes, it is indeed a new kart and a new character! She's Sara, incidentally also a princess and the mascot of OpenGameArt.org. Our resident 3D artist samuncle's first kart, it also features a unique jump animation, which will also be created for the other karts with time. See it in action here:

That's all the weather for now folks, and if I've forgotten something please remind me.

Graphics 5-6: Anti-this, pro-that

Good evening our loyal supporters. Welcome back to the same spiderchannel, at the same spidertime.

This biweek's plan was MLAA and SSAO. In addition, some remaining issues with lighting were squashed, and some unplanned effects were added, business as usual.

---

Selective bloom, requested by artists, was added. Now you can mark objects as causing bloom, even if their native brightness is not enough to catch them in the normal siphoning.

The test object in this picture is not the best one; you will likely see this effect used in the green crystals of the mine, and the windows of the mansion. The aforementioned windows may get something else too, but that's a secret, so don't tell anyone.

This is done by keeping a list of all such marked objects, and rendering that list with color and depth writes off, only writing the stencil. This results in 4x-8x drawing speed, as most graphics cards have that path optimized for uses such as Z-prepass.

This stencil is then used to copy the affected pixels from the picture to the bloom texture.

The bloom threshold was made configurable per-track. As you can see in the picture, the left version is clearly not bloom over-use.

The right is the default threshold, left was altered a bit to show how glorious a bit of bloom looks like.

---

Lightmaps were enabled in the new system. Before, after, the map.

This is a splash of older tech, and quite laborous for the artists too. However four tracks currently have it, so it should be used there.

---

MLAA, or Morphological Anti-Aliasing, is a shader-based AA technique. This means it can run in situations where traditional MSAA cannot, or catch edges such as those inside transparent textures better. It can usually reach better quality at the same speed; the quoted numbers for this particular technique are MSAA 8x quality at MSAA 2x speed, but the exact specifics obviously depend on the scene.

While no longer the state of the art, Jimenez's MLAA was used due to the author's familiarity with the technique, and the very decent results it still achieves. The most common competitor, FXAA, is a bit faster, but results in inferior quality - it blurs textures noticeably, which should not happen.

A short overview of the technique follows. First, any jagged edges are detected and marked for processing using the stencil. This greatly improves the performance of the technique, since the heavy shader for the following pass is only run on the needed pixels.

In the second pass, each edge is classified according to a pre-generated map of edges. This map tells the following pass where to fetch information from - essentially, which pixels to combine and the weights for them.

The final pass simply overlays the combined pixels on the picture. Before - after:

---

Dear reader, meet JJ.

Have no fear though, the glistering brightness that fills you with awe is a bit toned-up in this picture; sadly, the version to make it in the game will be more subtle. This comes as a disappointment to fans everywhere, and there have already been mass protests of over a thousand people outside my residence.

---

Levels can now choose to have cloud shadows. This completely fake system only fits some levels with a bright, daytime sky with clouds, but there are a few of such levels, and it improves them quite a bit.

It's a fairly subtle effect, and so hard to catch from a still picture, but when moving in the wind it's quite nice.

Itching to hear more I bet? This very fake effect is done inside the sun light, as that's the only thing that should be affected by it. A straight planar top-down mapping is created based on the pixel's world-space position; it's offset by the wind, and then used for a look-up in a specially made texture.

The effect is quite cheap. It does come with the downside that as currently there is no shadow mapping, the cloud shadows (just like sunlight) are visible inside buildings, caves and such. This may limit the levels where this can be used a bit for now, but with the overworld and hacienda, those areas are few and having it there is not distracting.

---

Finally, SSAO, or Screen-Space Ambient Occlusion.

"Mama, I want contact shadows and dark creases" "Sure thing, hon"

Another fake effect with no real-world equivalent, SSAO usually enhances scenes quite a bit. It approximates global light bouncing by making approximate ray traces around a pixel, checking if those points can possibly occlude some light from reaching this pixel.

Like you can probably imagine, it is expensive. Several tradeoffs were made in order to get it to run on the majority of the user base; it should still look acceptable, while the FPS hit is much less than the usual implementation.

Low - high:

The high variant merely runs at full resolution, and no tuning has been done for that one, as the majority will run on low or off.

The low option runs on a quarter resolution, taking only a single sample per step, without randomness, or an edge-aware blur.

Each of the listed parts lessen its quality somewhat, while increasing speed. First of all, the lower resolution prevents small creases from being detected, limiting the effect only to contact shadows. The upside is that it's 16 times less area, directly resulting in a 16x speedup over the high version.

Second, being able to only take a single sample per step, the information we have to work with is the normal plus a linearized, 8-bit depth. This results in some false occlusions in case the occluder is outside the hemisphere; the alternative however, making positions available, would double the cost of this effect.

The randomness in SSAO is usually implemented via a small normal texture. Its cost (beyond flicker that always results from randomness) is that it changes the step's texture read to a dependent one - named using great wit since the coordinates depend on another texture read.

A dependent texture read is a costly operation, since it prevents caches from pre-fetching the actual read. The exact cost cannot be calculated in a highly parallel pipelined system, but assuming it delays each read by 300 instructions (a typical cache miss), a core clock of 400MHz, and 16 steps, each pixel is delayed by about 12 microseconds. The delay is highly variable due to inter-dependencies, so take that cost estimation with a pinch of salt.

The first couple programmable desktop GPUs could only prefetch textures based on coordinates from a varying (that is, export from the vertex shader) or a hardcoded value. This is still the case for many mobile GPUs, but any desktop GPU from about 2004 onwards supports a set of math operations, such as additions and multiplication, making our set of vectors completely pre-fetchable. Should the target be a mobile GPU, this limitation could be circumvented by making the calculation of those vectors in the vertex shader and passing them as varyings.

As for using a normal gaussian blur over an edge-aware one, it results in some of the occlusions bleeding over a bit, but is about 4x the speed of the alternative. A 2x component comes from the fact that the edge-aware blur cannot take advantage of the bilinear hardware, requiring it to do twice as many samples, and the other 2x from requiring a branch for each sample.


With this, we end today's infotainment. Tune back next time!

Graphics 3-4: light me up

Evening, our loyal followers. This bulletin comes a few days early, as no new tech is expected for the rest of the week, just testing and tuning.

These weeks were about lighting, and now we have a running light prepass system. It could be described as more of a hybrid, read on to find out the butler did it.

---

So what is light prepass?

In traditional forward lighting, you draw every mesh, and each mesh runs a loop over all lights to see if they happen to touch it. As you can imagine, this is inefficient the moment you have more than one light.

The first good solution to this, deferred rendering, draws the mesh data to a set of temp buffers containing the position, normal, and other values. Lights are additively blended to the main image based on the values in the temp buffers.

It works, but it's inflexible in the amount of material variation it can do. Light prepass was designed to be both scalable and flexible.

In light prepass, less mesh data is saved: normal and depth only. The lights are additively blended to a light buffer, then the meshes are drawn, and they decide what to do with the gathered amount of light.

---

Our new system is light prepass, but by default it avoids the double draw of each mesh, blending the lights with a standard screen quad.

The moment the flexibility is needed, a mesh can draw itself and interpret the light data as it sees fit; but by default, there is only one draw call, as most meshes use the light data in a standard way.

---

Here we have the first step, ambient light, working. Yours truly has a fascination with the color red; he thinks nothing more of it, perhaps he should.

It's a normal world. This is a new debug view, showing what a normal world looks like, on a normal day. It has already revealed issues with two karts, which would have made them react badly to light (think badgers and mushrooms).

The next frontier after ambient light, point lights. The picture is from a new old map, red light district, with kindly visualized lights.

---

The other topic for this biweekly session was rim lighting for the karts.

First, one needed to identify the karts, and paint them in this spring's fashionable colors. It may look like red to the untrained eye, but in reality it's a mix of Indian red, crimson, and salmon, with just a hint of blueberry and salvia.

Rim lighting in the graphical world is a trick with normals. You compare the surface's normal with the direction to the camera, and visualize the difference with suitable colors, giving each kart a bit of shiny edges.


That's it folks, a short post this time.