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: 741
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: 205
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: 741
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: 741
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: 51
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: 741
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: 321
Joined: 22 Mar 2014, 00:41
Location: Rio de Janeiro

Who is online

Users browsing this forum: No registered users and 0 guests