[Solved] How are dungeon texture variations implemented?

[XJDHDR]

I've noticed that sometimes, DF Modelling appears to export a model with the wrong textures assigned. The main examples I've seen appear to be models used in dungeon blocks. To give two examples:


In this first image, the red circle is the model I have replaced (model 56008) and the yellow is a model above it that has the original texture. The model was originally using texture 319, index 4 in this location. DF Modelling exported it using texture 122, index 4. The Runtime Materials climate tickbox then causes this to become texture 322.


In this second image, the yellow arrow is the original door model (model 9004) and the red is a prefab I created from the model I exported. The original model was using texture 374, Index 3 in this area. DF Modelling exported it using texture 074, index 3. I tried ticking the climate tickbox for this texture as well but it had no effect. My prefab used texture 074 either way.

Edit: Changed title

[Interkarma]

Daggerfall Modelling exports the raw model data and the default textures assigned as they're found in the game files. This is actually the original texture.

When Daggerfall Unity loads this same data, it runs each texture index through processors for season, weather, dungeon, region, building type, etc. and switches the textures around at runtime. The same dungeon pieces (e.g. throne room in PH) can appear in different dungeons with alternate texture sets. There's no such thing as a "correct" texture, it's variable based on game logic. And Daggerfall Modelling can only export what is in the game files as it's just a model viewer without game logic.

[XJDHDR]

Thanks for the reply Interkarma.

I'm aware of the whole texture variation based on climate and season aspect. I am using the Runtime Materials script to apply textures to my models and, as far as I'm aware, the "Apply Climate" tickbox is supposed to take care of that aspect. Is this correct or does this only apply to climate variations and I have to manually create season variations?

[Interkarma]

Runtime Materials is climate and season aware but doesn't look to be dungeon aware. This texture swap is done in DungeonTextureTables class and requires a dungeon seed to deterministically transform the texture table. A dungeon's LocationID is used for the seed.

In theory, that logic could be added to Runtime Materials in at least some capacity. I wonder if TheLacus is still interested in expanding this feature?

[XJDHDR]

If Runtime Materials could be extended to support this, that would be perfect.

I noticed that the models documentation I linked above doesn't say anything about these dungeon variations though. In the absence of RM supporting these variations, I'm assuming one would have to create a new prefab for each dungeon texture variation. How would one name and configure these prefabs so that the correctly textured one is selected for a particular dungeon? Or is this not currently supported?

[Interkarma]

There's no support for model replacement system to handle dungeon variation textures at this time. I'm not even sure how that feature would look, it's a messy concept that doesn't translate well into modern workflows. Dungeon textures are kind of like shuffling cards. There are hundreds of possible combination of the dungeon texture table, you don't want to be packing all those variants into a mod for random texture swaps.

And the hell of it all is, those textures are just random. Unlike the exterior world, there's no logic or aesthetic to dungeon textures. They're just a random number table seeded by location ID. One kind of random is just as good as any other. There's nothing particularly special about classic's texture choices.

If someone adds this feature to mod system in some capacity, I believe they're better doing anything but just recreating the same shuffle. For example: models with switchable material atlases and/or shader parameters based exterior climate, dungeon depth, block wetness, and so on. Something like that would at least introduce some internal logic and aesthetics to dungeons.

In the short term, I think adding dungeon logic to Runtime Materials (see DungeonTextureTables class) would be the most sensible approach for pure "classic-style" model replacements.

[XJDHDR]

You certainly won't see any disagreement from me.

[TheLacus]

Hi!

I openend PR #1875 which adds the ability to use textures defined in dungeon texture table. Materials are applied when the GameObject is added to DaggerfallDungeon or any of its children.

[XJDHDR]

Thank you very much for doing this.

[XJDHDR]

@TheLacus, am I doing something wrong here? I cloned your repository and loaded it into the editor to test your PR.
This is what the door I'm testing looks like right now:


When I tick the "Use Dungeon Texture Table" option, the door turns purple:


The same thing happened to this model which previously looked like the first picture in my OP: