- Home /
Why are all forms of the Material constructor hidden in the documentation?
Here is a link to the current documentation for the "Material" class:
http://docs.unity3d.com/ScriptReference/Material.html
At the moment, the constructor functions are not listed on that page. However, searching the documentation for "Material obsolete" includes "Material.Material" among the first few of 192 results:
http://docs.unity3d.com/ScriptReference/Material-ctor.html
That documentation page has the following message at the top of the page:
"Obsolete Creating materials from shader source string will be removed in the future. Use Shader assets instead."
However, the form of the constructor which accepts a string (containing shader source code) is not even listed among the constructors on that page. But, the following constructors are listed:
public Material(Shader shader);
public Material(Material source);
Note that the first constructor accepts a Shader as a parameter, and the second constructor accepts another Material as a parameter. Neither of these constructors accepts string as a parameter.
What I am concerned about is whether "Material( Shader shader )" is also planned to be made obsolete. Because the constructor is not listed at all in the main documentation page for the "Material" class, I am concerned about the future of these other forms of the constructor.
Can someone at Unity comment on this issue?
I am hoping this is merely some kind of documentation issue -- where any documentation page with the "Obsolete" message at the top (e.g., "Material.Material" or "Material-ctor") is wrongly de-listed from the "parent"/"referring" page ("Material"). In other words, if a subordinate page contains even a single "obsolete" function, the whole documentation page is excluded from being linked to from other pages. But, is this correct, or does Unity plan to do away with the "Material" constructor altogether?
I really dislike the idea of having to create asset files to create corresponding entities in the engine, especially for temporary or transient entities. But, let's say the plan really is to phase out the Material constructor. What would be the most expedient way to achieve the same result (i.e., generate an entirely new Material at run-time)? (Aside: It's sad that the state-of-the-art workaround for the deprecation of constructing Shader/Material from a string is to generate an actual text file and import it as an asset.)
My current guess is that one workaround might be to clone an existing texture somehow, and then set its "shader" property. However, I would want to be sure the clone is truly independent of the original, and I'd want to suppress the creation of a corresponding asset file.
I don't work at Unity but this just seems like it's just an issue with the documentation, the entire constructor seems to have been marked obsolete while the message is about one.
The material constructor used to have 3 constructors: $$anonymous$$aterial(string), $$anonymous$$aterial(Shader), and $$anonymous$$aterial($$anonymous$$aterial). $$anonymous$$aterial(string) was made obsolete because in order to use it programs would have to ship with the ability to compile any .shader file.
$$anonymous$$aterial(Shader) and $$anonymous$$aterial($$anonymous$$aterial) use compiled shader files and this issue does not apply to them. Since Unity needs a constructor to make materials and every material uses one shader, they won't remove the ability to make materials from shaders unless materials are redefined.
That's what I was thinking/hoping. It seems like removing the ability to construct $$anonymous$$aterial instances from Shader or other $$anonymous$$aterial instances would cause major problems for a lot of script code out there. But, if this is really just a case of a documentation glitch (e.g., not linking to any page which contains any obsolete function, even if the other functions aren't obsolete), then that's a rather severe problem in itself.
I realize that you aren't speaking on behalf of Unity, but I appreciate your feedback, and find your perspective on this topic reassuring. Thanks!