Understanding materials and the model cache

Pipeline
,
1

If I load a level the first time, all models are white. Once its cached and I load the second time (by restarting the game) everything is correct. I can make this repeatable by deleting the cache. So whats going on here?

2

Oh and i just noticed my cube map stopped functioning after cache clear ha.

3

Hmm… This is just a guess, but perhaps the texture file-paths referenced by your models are incorrect in some way (perhaps they’re absolute paths, rather than relative paths)–thus resulting in their not being loaded, and, I imagine, the white models. Then, when the model is saved to cache, that process is somehow fixing the file-paths, thus resulting in the textures showing up on reload.

4

That sounds plausible. Ill look into the texture paths that get made my maxwell/yabee.

5

But, a fork. This happens with things not textured, just have materials.

6

In that case, it sounds as though the materials are perhaps becoming broken somehow–and again, fixed on being cached…

Could you please export and upload to the forum a simple test-model–perhaps just a cube–that displays this behaviour on your machine? I’d like to take a look on my end.

7

Sure no problem.

1 Like
8

sorry this took so long. Here is a video of the behavior.

I missed a section where i deleted the cache. But behavor still stands. When loading egg file with no cache, materials are missing color. Once its cache, it simply works, blocks are red.

And here is the egg
tutorial_1.egg (424.7 KB)

If you still want, ill add you to the github repo that way you only need to clone.

The way I work around this is simply converting the egg files to bams. Bams dont have this issue.

9

The problem is that you are using an outdated definition of the base color in the material.

Wrong:

<Material> Material.001 {
  <Scalar> baser { 0.800000 }
  <Scalar> baseg { 0.001614 }
  <Scalar> baseb { 0.000000 }
  <Scalar> basea { 1.000000 }
  <Scalar> roughness { 0.500000 }
  <Scalar> metallic { 0.000000 }
  <Scalar> local { 0.000000 }
  <Scalar> diffr { 1.0 }
  <Scalar> diffg { 1.0 }
  <Scalar> diffb { 1.0 }
}

It should be like this.

<Material> Material.001 {
  <Scalar> baser { 0.800000 }
  <Scalar> baseg { 0.001614 }
  <Scalar> baseb { 0.000000 }
  <Scalar> basea { 1.000000 }
  <Scalar> roughness { 0.500000 }
  <Scalar> metallic { 0.000000 }
  <Scalar> local { 0.000000 }
}

This is an outdated tag.

  <Scalar> diffr { 1.0 }
  <Scalar> diffg { 1.0 }
  <Scalar> diffb { 1.0 }
1 Like
10

Thank you, ill submit a pr to the yabee exporter. Cheers @serega-kkz

1 Like
11

@Maxwell175 PR, up. Includes our last discussion as well.

1 Like
12

However, I would like to clarify that this does not actually mean that this tag is not valid.

<Scalar> diffr { 1.0 }
<Scalar> diffg { 1.0 }
<Scalar> diffb { 1.0 }

The point is that this:

<Scalar> baser { 0.800000 }
<Scalar> baseg { 0.001614 }
<Scalar> baseb { 0.000000 }
<Scalar> basea { 1.000000 }
<Scalar> metallic { 0.000000 }

Is an alternative for specifying the base color of an object. The point is that you need to use one thing, however, taking into account that the latter method is the PBR standard and taking into account that the blender switched to this PBR standard. The above method has lost relevance, but this does not mean that it cannot be used. The problem is rather that the EGG interface relies on the diffuse method, and the Bam interface on the base color.

You can see this for yourself by replacing the material parameters with diffuse shading.

<Material> Material.001 {
  <Scalar> diffr { 0.800000 }
  <Scalar> diffg { 0.001614 }
  <Scalar> diffb { 0.000000 }
  <Scalar> roughness { 0.500000 }
}

The problem will also disappear.

1 Like