I believe the reason setParam and functions based on it, like setFloat, take a string argument for the name is so that users can add custom parameters (correct me if I’m wrong) and avoid the issue of creating subclasses.
FIrst, I’d like to understand why creating subclasses is a bad thing. Second, for setting specific data, why not keep this separeate in the public API, and keep the core parameters exposed in a IDE-friendly, type-friendly why, e.g., setImportant( myfloat ...) instead of setFloat("Important" ...).
I’m not trying to critisize as I don’t know game engines at all - just trying to learn/understand.
Which of the potentially hundreds and hundreds of shaders should we expose the parameters for?
What benefit would we gain? Some IDE sugar. Personally, I have trouble caring about this at all since I don’t use IDEs. It also gives a totally 100% false sense of what’s available to the users. “Oh, I didn’t know I could set that because you didn’t hard-code it into the API needlessly…”
What would we lose? We’d lose the ability to easily support custom shaders. Every new shader would require a new material def subclass and a new material subclass and all the mess entailed in that.
Generally, if your strategy is “subclass this thing to add parameters” it’s already wrong to begin with, really.
Edit: and note: not a single bit of this gets you away from reading the fine documentation.
Thanks, that helps. Like I said, I’m just trying to understand it.
I would think you would also get compile-time checking of valid parameters, but of course, as you said, you still have to read the docs to make sure you know what you are doing ( and I’ve a long way to go there).