What precisely is Epic’s golden path for extending assets from a texture and material perspective? What is the vision for the ideal workflow for users who want to extend (re-skin) existing content, without re-inventing the material graph? For example… There are many times when I just want to leverage 60% existing content, with 40% of my own modular architecture. I’ll be texturing my own models, but I’d like a consistent visuals across all walls (existing and new). So it’s imperative that my own materials and custom TextureData are in agreement with a single set of textures.
I suppose the above example, also raises that question of: “Are Fortnite’s existing modular content MEANT to be skinnable, by way of swapping TextureData?”. It feels like that is the case, but it’s not yet exposed.
The various public workflows / interfaces don’t appear to be in complete agreement with each-other and the documentation. Consequently, the golden path isn’t quite clear to me yet. Maybe some of the public touchpoints / base materials just aren’t released yet?
For example…
- The FortniteBase material default settings prefers a specular RGB packing of [specular, roughness, metallic] respectively.
- The documentation however, states a default packing scheme of [Specular, Matallic, Roughness] respectively
- TextureData appears to be similar to the documentation, but no clear path for AO support is mentioned for tiling textures (which would be required by many).
I understand that the FortniteBase material is a simple interface suitable for basic props. I also understand that not all content well support TextureData swaps (runtime tinting logic often appears to invalidate swaps). But ideally, these interfaces would both be more in agreement on their texture packing. I know that I COULD re-import all my textures after changing their packing scheme and change my MI_FortniteBase to reflect legacy conventions, but that would be quite limiting and doesn’t feel scalable.
- Is it the intent of Epic to expand on Texture and Material support for TextureData based workflows for use cases such as this? It seems like it would be ideal for the FortniteBase and TextureData based workflows to be more in agreement for efficient texture sharing while also supporting AO. ATM the various workflows feel like disparate systems.