mojira.dev
MCPE-110361

PBR textures do not work when using texture variations

In a texture pack if you define a texture set for a block and that texture set contains a normal and MER file as documented in the RTX guide from NVIDA, the texture set works properly. 

If you define a variation set for a block in the terrain_textures.json as below 

{
 {
   "num_mip_levels" : 0,
   "padding" : 0,
   "resource_pack_name" : "vanilla",
   "texture_data" : {
      "dirt" : {
         "textures" : { "variations" : [
                           {"path" : "textures/blocks/dirt/0"},
                           {"path" : "textures/blocks/dirt/1"},
                           {"path" : "textures/blocks/dirt/2"},
                           {"path" : "textures/blocks/dirt/3"},
                           {"path" : "textures/blocks/dirt/4"},
                           {"path" : "textures/blocks/dirt/5"},
                           {"path" : "textures/blocks/dirt/6"} ]  }
      } 
  },
 "texture_name" : "atlas.terrain"
}

If the numbered files are texture sets, no MER or normal layer will be loaded, however the color layer is properly loaded. 

I would expect that if the color layer is loaded, then the MER and Normal layer would be loaded. 

I cannot find any documentation that states differently, i am happy to be proven wrong...

Attachments

Comments 11

My last issue I’ll comment on before i go inactive, can confirm.

Could you please attach the resource pack you're using to this report?

I have attached a data pack that has dirt randomized. (numbers on the dirt block). and coal_block and coal_ore set to call the exact same texture set file as dirt and drit1 (0 and 1 in the picture) as  you can see the coal_block and coal_ore (closest to the user) have the proper texture set loaded, but dirt0 and dirt1 do not have the texture set loaded, only the color file.

for clarity this is the terrain_texture.json file used in that test (I redid the test with textures I can actually share):

{
  {
   "num_mip_levels" : 0,
   "padding" : 0,
   "resource_pack_name" : "vanilla",
   "texture_data" : {
      "dirt" : {
         "textures" : {
              "variations" : [
                  {"path" : "textures/blocks/dirt/dirt" }, 
                  {"path" : "textures/blocks/dirt/dirt1"}, 
                  {"path" : "textures/blocks/dirt/dirt2"}, 
                  {"path" : "textures/blocks/dirt/dirt3"}, 
                  {"path" : "textures/blocks/dirt/dirt4"} ]  }
              },
     "coal_block" : {
         "textures" : "textures/blocks/dirt/dirt"
     },
    "coal_ore" : {
         "textures" : "textures/blocks/dirt/dirt1"
      }
  },
"texture_name" : "atlas.terrain"
}

you can see the same texture should be called... it is "textures/blocks/dirt/dirt" and "textures/blocks/dirt/dirt" are character for character the same. And the PNG is named 0.png, so no way that it isn't loading the texture set (IE the color files can only be found through the dirt.texture_set.json) but it is not loading all info (IE the MER) from the same file. (as indicated by the shine). 

I am very interested in what I am doing wrong here or if it is a proper bug with rtx

1 more comments

What does this have to do with the way that the resource packs stack? There is only 1 resource pack involved. I would understand if the you staid "works as intended PBR texture do not support texture variation" But this is inside 1 pack and it simply disables PBR or any ray traced texture if the variations are used.

Seems like a bad resolution justification....

Looks like i will just stop development of the RTX packs as texture variation is more important to me then PBR.

Could this be changed in order to have it function? It would be extremely useful to have this feature in custom biomes that have variating ground textures.

I agree with MadHatter. It's very discouraging to see a feasible feature like this unsupported. The short response from Mojang makes me think this issue was prematurely closed.

How would this interfere with a resource pack stack? Wouldn't a resource pack without block variants be able to override one without variations? Example:

Lower texture pack
{
  "texture_data": {
    "dirt": {
      "textures": [
        {
          "path": "abc"
        },
        {
          "path": "xyz"
        }
      ]
    }
  }
}
Higher texture pack
{
  "texture_data": {
    "dirt": {
      "textures": "123"
    }
  }
}

One could then merge this JSON data to get the dirt texture set path equal to "123." Suppose the 123.texture_set.json file didn't have a MER or normal map defined: Minecraft would not show base layer "123" with the MERs and normal maps from the "abc" or "xyz" textures in the lower resource pack.

So what's the problem?

Please reconsider this issue! Texture variations in Minecraft with RTX would be a game-changer for resource pack developers.

I will be creating a new ticket as Mega spuds response makes exactly 0 sense.

It's possible that by "the way the resource pack stacks", they may have meant the order in which certain aspects within the resource pack are rendered - for example, if RTX textures (ie. PBR, luminosity, etc.) are rendered before texture variants, then it could mean texture variants wouldn't match up with the RTX material textures.

With that said, even if this theory was true, it still would be no explanation for why it's an intentional feature. This might mean that it's hard to fix, but by no means would it be justification for it being intentional or by design.

Given that this bug is a big limiting factor in the work I do, I would love to speak with the developer who gave the explanation for why it's intended (or any developer on the RTX team, for that matter), in order to better understand it - as I cannot comprehend how the stacking of resource packs, regardless of which meaning that has, would render texture variation an intentional feature.

ravinmaddhatter

(Unassigned)

Community Consensus

Windows

Windows 10

1.16.200

Retrieved