I want to extend the functionality of the built in material class in C++. There are a few things that are stopping me doing this, particularly - none of the methods are virtual, especially _update_shader
I want to make a terrain material that takes extra textures so being able to override set/get texture would be helpful if these were also virtual.
If this is something that the godot team are interested in I might do a fork and make some engine changes and commit them back.
Isn't that a very specific use case? You don't you create your own shader in order to input more textures and use them in a custom way?
yes and no, in that is is a more specific use case but it might still be used in a variety of ways for a variety of reasons.
Inheriting the engine material would allow me to have flexibility where i need it but to be able to add/replace/modify the base material functionality.
While I get where tagcup is coming from I'd rather have a flexible tool-set for building my own custom terrain system/engine than have the kind of inflexible terrain system that say unity for an example has. Then again unity isn't necessarily the best example anyways - their terrain system is very old(~2006).
This is a false dichotomy: there is nothing that would stop you from rolling your own custom terrain system, because editor plugins, modules and GDNative will still be there.
Sure, but I'd have to start from scratch, no? I'm saying I want to have my easy bake cake and eat it too. ;)
the important/ontopic point here seems to be however that we both like Supagu's idea.
You want a terrain system, but you also want "have a tool-set for building your own custom terrain system/engine". I really don't know how that's going to work. Do you have any concrete plans how that can be realized?
In any case, all I was saying is that it would be nice if Godot shipped with a terrain engine, because that's a pretty common need and all other top engine come with some sort solution. I don't remember saying "let's make a clone of Unity's terrain engine" at any point.
Also, no, I don't think you'll have to start from scratch. If Godot ever comes with a terrain engine, it's going to be an editor plugin, which you can extend/fork.
Just leaving that here re: the terrain discussion: https://github.com/Zylann/godot_terrain_plugin
sorry. I missed this! I don't think doing this is the right way to go. For terrain, you also probably don't need to override this either, but create materials on the fly. you simply can't just mix and match materials in a terrain
Most helpful comment
Virtually all 3D games have terrains, so I don't agree this is a specific use case in that sense.
Both Unity and Unreal come with extensive terrain engines. What I'd argue is that, Godot should also come with a terrain engine.