What happens to Shader Editor textures when exported?

This is a voronoi texture made with mix shader in mobile render path:

My question is: how the mix shader works in mobile with such limitations? (i don’t even had tested it on mobile yet). Is this texture “baked” or it is just strings in the material data? What about the UV? Is there any benefit on using it over conventional baked textures or it introduces some overhead?

I am curious about it because it works even in 2d/baked render path

Thanks in advance!

1 Like

Build with DebugConsole or post a test project, I will build an APK-file. And we will test it.

I suppose that the shader is simply formed depending on the selected settings in RenderPath, it is unlikely that the textures themselves are baked without settings. It just turns out to be a more or less complex shader.
I see this difference in the example with cubes (d6_roll, which I laid out). There are no textures and everything is formed by materials (shaders) and, depending on the RenderPath, they are different.


Procedural textures are calculated each frame based on parameters (thus the name procedural). Those parameters get hardcoded into the materials shader and it then runs some mathematical procedures that calculates the color of each fragment. I think all (or at least the most) functions for procedural texture generation can be found here: https://github.com/armory3d/armory/blob/master/blender/arm/material/cycles_functions.py. So there is nothing baked unless you bake it

Be aware of bump mapping or any other method that samples texels (texture pixels) around some coordinate: this will recalculate the texture multiple times per pixel which makes everything a bit slower.

About the mix node: This uses the mix() function in glsl that mixes two values depending on a factor, so it first calculates both inputs and then mixes them. Everything else would result in branching (I think) that would massively slow down the performance. What’s still missing is the automatic optimization to not include an input if the mix factor is a constant(!) 0.0 or 1.0 (TODO in the code). This is actually not complicated to implement (as long as the compiler discards unused code which in my tests didn’t happen for webgl for example) but it will probably get more complicated if we implement material animations someday.


@E1e5en , there have a baked version and a mix shader version, you can touch the screen to spawn more suzannes: https://drive.google.com/file/d/11FtSskIrwSIwMteDPnFSHZyKTSB0VzOV/view?usp=sharing / we also can see if the problem related to mali still happening after the updates and also if it happens with this kind of texture.

@timodriaan , maybe the animated materials can be disabled by the user trough a checkbox? In this case it would be good if this can be done for individual materials or objects, but probably will include all the project. Also maybe Armory can detect if the material is animated to ignore the optimization, i don’t know how this works. For textures that does not moves with the object (i.e. using camera coordinates or a second object coordinate), this update is also required (?) – the optimization will make the texture to “freeze” in the object?

Turning the optimization off when the factor value is animated is not that difficult, it’s just an extra step that has to be taken into account (exactly what you’ve said). What makes it more difficult is to check if the connected nodes are animated and because of that it’s better to only optimize when the factor input is unconnected (= is a constant value).

The same problems apply to auto-baking: although this should be technically possible it is very difficult, a lot of work and it probably slows down the export a lot:

  • You’d have to specify a resolution and a UV map for the auto-baked texture and you must decide if those settings apply to all baked textures.
  • You’d have to traverse the entire node tree that could affect the procedural texture in order to check if nothing there is animated. I’m afraid that this would make the material parsing code extremly complicated and slow.
  • An object can have texture coords based on its position for example, this should be taken into account because it could affect the procedural textures (most procedural textures don’t repeat themselves, they are just infinite).

If you need a lot of procedural materials and they slow the game down, you can still bake them manually.

A simple check for 0/1 as a constant should be easy to do, it’s just important to keep in mind that this must be updated when someday animated materials will work. If that particular property is animated, it cannot be optimized. That’s all I wanted to say, sorry if it sounded complicated in the above post^^


APK: https://drive.google.com/drive/folders/1_rijxrhGt2i3hLpGB1pkF7NMpptolOg2?usp=sharing