search

QodotPlugin / qodot-plugin

(LEGACY) Quake .map support for Godot 3.x
MIT License
960 stars 70 forks source link

More configurable material override texture application #101

Open Shfty opened 4 years ago

Shfty commented 4 years ago

Need to be able to specify which SpatialMaterial / ShaderMaterial parameter is used when applying textures.

This is already partially implemented in the form of auto PBR and material overrides, but a more general approach would make the system more flexible.

The existing auto PBR setup should be extended to cover all 15 of the SpatialMaterial texture parameters using suffices configurable via ProjectSettings, as well as support for generalized ShaderMaterial suffices that map directly to a shader parameter by name.

Shfty commented 4 years ago

Need to consider whether storing material overrides inside the texture folder is a good idea - may be better from a encapsulation standpoint for the default workflow to store them in a separate directory with the same base/group/texture substructure.

Shfty commented 4 years ago

Also need to consider workflows that don't use the base texture as albedo - i.e. a SpatialMaterial that uses it for emissive instead, or a ShaderMaterial. Using a suffix on the base texture's filename isn't an option as it needs to share the map-side name for editing purposes.

Replacing material overrides with a resource-driven setup is probably the best approach - use a new 'TextureMetadata' resource type to store which SpatialMaterial or ShaderMaterial parameter the base texture should be applied to, as well as an optional material to override the default with. This has the added benefit of allowing a single material to be used with multiple textures without excess duplication.

How should TextureMetadata be stored in relation to QodotMap? Adding a resource property akin to the FGD is an option, but it's probably better to follow the texture structure and scan directories based on a search path.