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