PBR in SuperTuxKart (new material system)

PBR in SuperTuxKart (new material system)

Postby samuncle » 02 Jan 2018, 16:08

Hi everyone :)

After a week of studying rendering algorithm, light simulation equation etc I was able to implement a full PBR (physical based render) in SuperTuxKart. Let's see what changes and what it means for artists.

Here is an example (left is in Substance Painter with unreal engine preset) (right is in SuperTuxKart)
pbr-final.jpg


background
So first of all let me answer a question:
Why do we need to change? Is it really needed

The rendering system of Antarctica (SuperTuxKart's engine) is using a strange combination between traditional rendering and PBR.
It makes the system cumbersome and difficult to understand.
* New artists must learn from ground a material setup that is only used in SuperTuxKart and in no other software/engine
* There is no resources other than our website and easy way to create a material. We need pretty much to adapt all assets by hand + verify the result in stk.
* We can't preview easily in other software like Eevee (blender's new viewport). We don't need to load every time stk to check the materials.
* The previous system only allowed to emulate non metallic surface. Now we can emulate all materials correctly.

Basic concept of the new material system
In order to setup any material you must answer a few very easy questions

The first texture input is what we would call diffuse in the old system. Now it's named albedo or baseColor
* What is the color of the material, without shadows or shades. The pure color of the surface

The second texture is normal map (this doesn't change compared to the previous system)

The third map is what we would call a gloss map in the old system. Now it's named glossiness and it's a combination of three different maps (to save memory)
* The red channel How is the surface of the material: Polished or rough? 0 = unpolished / 1 = polished
* The green channel Is the material a metal (like bronze, steel) or anything else (plastic, wood, etc) 0 = non metalic / 1 = metal (dielectric)
* The blue channel (like before) Is the material emitting light 0 = doesn't emit light / 1 = emit light
By default all values are set to 0

OMG as an artist does it mean I will have to redo everything?

Nope, all assets with the current system look surprisingly good.
I will take some time to convert them however it's not a necessity because most of them don't use a gloss map anyway.
All future assets will be created to fully use the new system.

How can we test it?

Currently it's in a custom branch. It will be soon merged into the main game. I will also create the first map to take full advantage of the new material system.
Here is a quick test made in substance
pbr-quick.jpg

There are slight discrepancy between the result in other engine and stk however it's a bit beyond my knowledge why is it happening.
If anybody has knowledge of rendering equations, please let me know. Any feedback would be appreciated.

Have fun!

Sam
Image
User avatar
samuncle
STK Moderator
 
Posts: 742
Joined: 16 Mar 2010, 21:28

Re: PBR in SuperTuxKart (new material system)

Postby deve » 02 Jan 2018, 21:14

New artists must learn from ground a material setup that is only used in SuperTuxKart and in no other software/engine


I wonder how many real artists contribute to STK. I mean that I have no knowledge about materials (from artist point of view) and I would be able to create a track in reasonable good quality. I can use some models from library, make some simple models myself, find some textures in the web, then check how it looks in STK. If it's not ok, then tweak it and check again. It's simple to use "./supertuxkart --track MyNewTrack -R" to get a preview.

The previous system only allowed to emulate non metallic surface. Now we can emulate all materials correctly.


Tbh. I prefer non-metalic STK much more.

What is more important to me is that current stable STK works again on most hardware. I successfully ran it on intel 965gm on windows with 30fps in Hacienda, Math Class and other simple tracks. It works on Raspberry Pi 3 with GLES2 renderer with similar performance. I'm just affraid that next-gen tracks will be even more heavy than Cocoa Temple and you will need high end graphics card to play it. And we need good performance for Android too.

Actually Cocoa Temple is already unplayable for me on highest settings. I have ~12 fps on 1280x720 resolution on my nvidia 635m. And again I suppose that I'm not the only one in the world with such hardware.

And second thing is that won't this break Android version? I mean that there is 100MB apk size limit on Google Play. I already use some hacks to put as much content as possible in the apk. But does it mean that we will have much more textures that can't be easily converted to jpg format? From my experience gloss map in jpeg format is just ugly, so I suppose that it will be similar for other materials data.
deve
 
Posts: 227
Joined: 23 Jan 2014, 13:45

Re: PBR in SuperTuxKart (new material system)

Postby samuncle » 02 Jan 2018, 22:07

I wonder how many real artists contribute to STK. I mean that I have no knowledge about materials (from artist point of view) and I would be able to create a track in reasonable good quality. I can use some models from library, make some simple models myself, find some textures in the web, then check how it looks in STK. If it's not ok, then tweak it and check again. It's simple to use "./supertuxkart --track MyNewTrack -R" to get a preview.

It's perfectly valid and it's one of the reason we made the library of objects. People should in priority use those. It won't change with PBR, there will be even more pre setup materials ready to be used.

What is more important to me is that current stable STK works again on most hardware. I successfully ran it on intel 965gm on windows with 30fps in Hacienda, Math Class and other simple tracks. It works on Raspberry Pi 3 with GLES2 renderer with similar performance. I'm just affraid that next-gen tracks will be even more heavy than Cocoa Temple and you will need high end graphics card to play it. And we need good performance for Android too.

So PBR in itself isn't much different to what we had in the past. I only tweaked the way the engine interpret the values but the performances should be very similar.
But there is something really good with the new system and some changes partially implemented in the current version
* We can now set objects as detail/low importance and they won't be loaded if the config is too low
* We can as a safe fallback just not include any gloss map/normal map and the game will still look fine and run fine (just like now)
* Concerning size, the great thing with PBR is we need in most of the cases only the roughness map (the red channel of the texture), instead of two (gloss/specular).
For me an acceptable fallback is to simply not include those texture to lower the size of the APK.

Actually Cocoa Temple is already unplayable for me on highest settings. I have ~12 fps on 1280x720 resolution on my nvidia 635m. And again I suppose that I'm not the only one in the world with such hardware.

I don't have this hardware unfortunately to test. However, I think if the game doesn't run on highest settings on all GPU. Probably disabling shadows helps a lot. We could also not load all objects from the library. Could you try to run the game without palm trees for instance?

I just wanted to add something. I never prevented people to do their own maps or even taking my highly detailed maps and making version with lower requirements (removing objects, lower textures etc).
I always welcomed and suggested people to do it. I like to create high quality maps because I like to explore new things and try to make stk look beautiful.
All maps are open source, you have everything to change them and publish your own version in stkaddons
Image
User avatar
samuncle
STK Moderator
 
Posts: 742
Joined: 16 Mar 2010, 21:28

Re: PBR in SuperTuxKart (new material system)

Postby samuncle » 03 Jan 2018, 23:59

Here is a convention for textures prefix for PBR

1) The map representing the color: _Albedo
2) The map representing the normal map: _Normal
3) The map representing pbr data (a combination of polish/rough, metal and emit map): _PbrData
4) The map representing the color mask (for random colors): _ColorMask

Fallback and ways to reduce data (especially for android)

1) The general fallback is: If it's not powerful enough, just use _Albedo map and solid shader (no normal map, no advanced materials, just the color of the object)
2) The texture _PbrData can be resized to half of the size of the _Albedo
3) We can discard the blue channel of the normal map and recompute it in the shader (btw this is valid for computer as well). Not only it saves disk space but also VRAM space)
4) We can also remove and not include normal map at all to save not only space but computation.
5) We can resize/remove the _ColorMask
Image
User avatar
samuncle
STK Moderator
 
Posts: 742
Joined: 16 Mar 2010, 21:28

Re: PBR in SuperTuxKart (new material system)

Postby benau » 04 Jan 2018, 03:13

colorMask in jpg size is insignificant (black / white), and they are now encoded into alpha channel of main texture anyway
Image
benau
 
Posts: 57
Joined: 08 Dec 2015, 17:32

Re: PBR in SuperTuxKart (new material system)

Postby samuncle » 05 Jan 2018, 00:08

I converted to PBR all the gloss in the asset repository with a script.

Currently it will reproduce a similar look to what we have before PBR. If you want to have new material you will have to setup the metal map and adjust the rough/polish map
Image
User avatar
samuncle
STK Moderator
 
Posts: 742
Joined: 16 Mar 2010, 21:28

Re: PBR in SuperTuxKart (new material system)

Postby GeekPenguinBR » 10 Jan 2018, 06:56

deve {l Wrote}:
New artists must learn from ground a material setup that is only used in SuperTuxKart and in no other software/engine


I wonder how many real artists contribute to STK.


I don't know what exactly do you mean by real artists, but, besides myself and my brother, I can remember of other persons making tracks, karts and textures (art) for STK: Anon, CinusMinus, ctdabomb, Jymis, rubberduck, Sven Andreas Belting, XGhost, etc.

Well, the current library of textures is very limited. Not always we find on the repository a texture that represents what we had on mind for a certain tree, plant, mountain, clapboard, metal, rust, etc. So, we need to expend time to create exactly what we want. However, if the source of textures can be enlarged by addition of dozens or thousand materials ready to use in the game, this means an important step for STK which represents an improvement for the workflow of any person who wants to contribute to the game.

Speaking for myself, I can state that any form to save time, reduce the work of artists who (at least tries to) contribute to STK, is totally valid. The time saved in not making specific textures for generic objects like stones, wood, metal surfaces, etc. can be used to make specific textures for houses/buildings or any other special object. You can imagine how many hours I have spent to make each one of these:
01.jpg


Now, you can try to imagine the amount of job (days) if the artists need to paint their own texture of wood or stone (because those available on the repository looks like more of the same) or to fake brushed metal, chrome, etc. (instead using one already available) as well to export the game every time they need to check if a certain material works in game as planned. So, the possibility to use PBR is very welcome.
"Making cool harmless games makes the world a better place".
User avatar
GeekPenguinBR
 
Posts: 362
Joined: 22 Mar 2014, 00:41
Location: Rio de Janeiro

Re: PBR in SuperTuxKart (new material system)

Postby Anon » 26 Mar 2018, 10:17

rubberduck had some good tracks. 0zone0ne contributed some pretty neat songs and concept art too.

Image
There are slight discrepancy between the result in other engine and stk however it's a bit beyond my knowledge why is it happening.
If anybody has knowledge of rendering equations, please let me know. Any feedback would be appreciated.


As you'll recall I've actually tried doing something like this before too. Well, I tried doing the opposite anyway, taking STK's unique old rendering algorithms and trying to replicate their effects in Blender. I branched that off of another project and which Blender's node-based system for implementing those equations, but the algorithms are the same.

I get the sense that the a big part of the discrepancies between Substance Painter and STK look like differences in the lighting setups rather than rendering algorithms. Generally speaking, the lighting on the screenshot from Substance is a lot more soft and smoothed out. The red Suzanne on the left seems to be lit by a much brighter point (or sun/ray) source from behind the camera, causing shadows to form in different areas, making its colour brighter, and creating harsh specular highlights right on the areas facing the camera. The brightest lamp in Substance Painter on the right, on the other hand, seems to be an overall dimmer area light situated to the right of the screen, which consequently produces different shadowed areas, less harsh shadows, less harsh specular highlights (including those on the metallic portions), dimmer colours, and less contrast between lit and shadowed areas.

Background image/environment is another thing as well. As I recall, Supertuxkart uses the skybox to compute reflections on metallic pixels (and also diffuse lighting on non-metallic parts). It looks like the skybox used in rendering here is coloured differently and possibly less detailed on the STK side than on the Substance Painter side, making the metallic parts blue and a bit flatter on the STK side. The skybox visually rendered behind the STK monkey is a lot brighter too, which, combined with the relatively brighter main light source on the diffuse areas, might give the illusion of the reflective metal bits being darker than they really are (or maybe that's just my red light filter).

Other than that, the CGX and Beckmann models for specular highlights (...or microfacet distributions) do produce slightly different results at certain roughness levels IIRC. I'm not sure which one you or Substance Painter are using. I don't remember what kinds of post-processing exactly STK did (or what it does now), but that'd also be one of the first things I'd check. The diffuse areas on the left look a bit "naked" as well; have you accounted for fresnel effects? Specularly bounced light beams don't have a chance for their colours/spectral distributions to be selectively absorbed/multiplied/coloured by transmission through the solid medium, so forking some of the light from the diffuse rendering equations to the specular ones based off fresnel effects might help with the oversaturation.
Anon
 
Posts: 204
Joined: 03 Jul 2014, 16:30

Who is online

Users browsing this forum: No registered users and 1 guest

cron