Parameter File (XML) of a 2D texture should be stored as the dependency of the texture.
Currently, if we change the parameter file, the texture will not be reloaded applying the changes of its paramaters. E.g. when we change the filter mode in the
test_texture.png won’t be reloaded with the new filter mode.
Currently, 3D/Cube/2DArray textures have this feature, but 2D texture does not.
I have tested adding the following code to
Texture2D, it seems working correctly. I remember Parameter file ability was added by @Eugene, so I think it’s better to ask you first.
auto* cache = GetSubsystem<ResourceCache>();
String xmlName = ReplaceExtension(GetName(), ".xml");
I also find an issue with
void Texture::SetParameters(const XMLElement& element) -
The logic in this function is that if some key/value is configured in the XML, this property of the texture will be set to the new value, if the property is not configured, it will not be toughed. i.e. default value is used.
if (name == "border") // if this property is configured
SetBorderColor(paramElem.GetColor("color")); // new value is set
A simple case to show this issue is that we delete a property from the XML file, the texture’s property value (sampler state) will remain the same and the old value is applied later rather than the default one.
I feel that the present behavior is correct. If you set the parameters and don’t include a particular parameter, it should leave the texture with whatever parameter it had, which you had already set before in code or with a different XMLElement.
Though if you think it should default to resetting to defaults I don’t think that’s unreasonable, it’s possible it’s the more intuitive behavior. I like the approach I proposed as it seems more flexible, but I personally won’t be using it, so if you think it should be the other way I wouldn’t object.
The issue with current
SetParameters happens when reloading of the XML files. If the new version of the XML removed certain property, the property will NOT be reset to default, instead, the value in the XML file of last revision will be kept.
Edit: just think about use this in an editor, when we change the property of the texture, it won’t always appear correctly, which is problematic.
I guess I misunderstood the original code. In Texture2DArray/TextureCude/Texture3D, the resources configured in an XML parameter file are added as dependencies, not the XML parameter file itself. I think we should not use the parameter files for reloading. We still need more work to if we want to edit textures in tools.
In all other textures the XML file itself is a “texture resource”. Whereas actual textures are dependencies.
In Texture2D situation is opposite. However, why do you think we shouldn’t use parameters for reloading?
As I mentioned in previous lines, we need extra method to handle the reloading of the parameter file to apply all the properties of texture changes.
In tools, if we are editing a Texture2D, we know when it is dirty, we can just apply all the properties and save them in parameter files if any property is different from its default value(though get default values are hacky).
Additionally, the fact is that none of the texture types have made the parameter file as their dependency. If we can solve all issues, we need to add the parameter file in their dependency for them all.
None of other texture types have parameter file. Of course they don’t make it “dependency”. Texture2DArray, Texture3D and TextureCube are XML files, they don’t depend on it. Resource doesn’t depend on itself.
Oh, yes you are right. The XML file for other texture types are resource itself. So we only need to solve problem for Texture2D.
Problem with partial parameter update may still persist in other texture types tho. It may be necessary to reset optional parameters somewhere if they aren’t set in file
I don’t have a clear answer yet how to achieve this in a clean way.
- notify resource if it is just loading or reloading?
- intercept reloading from editor and call extra interface?
- Do we need a
Reset function for resources?
I didn’t check how it works in practice, but the place that loads parameters is responsible for resetting parameters that aren’t set. I mean, I expect it to be responsible.
What if we set a parameter which is supported by the parameter file but not configured to its default value? I don’t see any overload of this. Typically, the GPU resources of the texture will always be recreated afterwards, no matter if a certain parameter is dirty or not.
if “border” is find in parameter_file:
The issue I see with it is that we did not define default values explicitly, maybe we should.