I’ve built enough plugins to start to question certain aspects of the UE4 code base as it relates to plugin development. It seems to me that numerous attempts to hide functionality are handcuffing the process in general by requiring direct modification to the UE4 code base just to make a properly integrated plugin. I have two specific issues that I can immediately present…
Although MinimalAPI is designed to reduce link times, it makes integrating plugin classes an enormous pain. Often we are forced to include small/limited functionality directly from source instead of calling derived (but not exported) methods - this results in having to continually update and integrate new UE4 code as it comes in from each new version. Ultimately, the system should be set up so that any module you are dependent upon should be able to make all classes and methods for that module as exported. We simply need to be able to call derived methods without modifying the UE4 code base.
Another handcuff is that a lot of functionality simply isn’t even exported in general. If you want to override some of the material system you would likely need to directly insert code into the material system as opposed to building a plugin. For example, access to MaterialInstanceSupport is simply forbidden. I’m using a 3rd party plugin that integrates directly into the UE4 code base for this reason - and as a client it is awful to have to deal with version updates. But when I tried to create my own material system based plugin (a custom reflection/cubemap system), I ran into the same problem.
Plugins are an enormous help in development, but UE4 is seriously lacking compared to other engines in this respect. As far as I can tell the main culprit is that nearly all plugin development would require direct changes to the UE4 code base. Telling users of your plugin that they will need to modify the UE4 code base will often be a blocker. And if every plugin requires some form of UE4 code base modification, you are looking at a situation where no one is going to want to use those plugins as integration becomes a nightmare.
Yeah, I’ve been looking into aspects of the rendering system and adding functionality through plugins myself. It seems that any new shader file has to be placed directly into the Engine/Shader folder, which isn’t ideal for plugins. I could include a system for automatically placing required shaders in the correct directory but then I would have to include that in every plugin. I feel a much better system would be if the engine could search in Plugin/Shader folders for additional shaders by default.
You could mount a separate folder in as if its content is part of the Engine/Shader folder.
mhddfs-style: https://romanrm.net/mhddfs
It may be a bit like a bullet from behind through the knee into the eye, but should work
Sorry you are running into issues with things you need not being exported We get quite a few Pull Requests on GitHub for exporting additional functions, and usually integrate them quite quickly. That way we know that it’s useful functionality that works in a plugin, rather than just a shot in the dark.
I’m afraid I don’t know enough about the rendering side of things to comment on that.
Thank you for your response. It’s good to hear that you try to be responsive to such pull requests, but I still a see a few issue…
Not backwards compatible with previous versions of Unreal
Requires more effort by plugin developers - the developer would have to make the request and the requests may not be immediately approved (especially a request with numerous changes).
If other plugin developers are not following this procedure then when you require your plugin to update would not work as that would then require integration from the other plugin developers.
Does not promote community and experimentation - a person cannot just post some new tech idea to the forum without also making a pull request for exposing the unreal functions that they are using.
Large plugins can make development easier or even possible. But small plugins improve community and experimentation. Simplifying the process will bring about a flood of reusable tech to the community as a whole. One solution could be to have the system that builds the VS solution files access some other file (that contains a list of modules that will become open/exported) and create module specific build defines that would override the modules default export options.
Not to beat a dead horse, but how is it that UMaterialParameterCollection and UMaterialParameterCollectionInstance are MinimalAPI? It’s closed-off (only available in blueprints) basic classes like these that are kind of maddening. It’s hard to imagine that someone hasn’t mentioned or requested the exporting of these classes’ methods for use in c++ at least in passing. Requiring that developers request the opening of these methods is highly problematic - which leads to another item to add to my previous post’s list…
We pull Unreal’s codebase from GitHub and disperse through perforce so when someone comes across a MinimalAPI gate they simply make the change within the perforce database - then when we next pull from Unreal (based on when 3rdParty middleware has also been updated) we have to go back through and reintegrate all the MinimalAPI related changes. At that point, we are already scrambling to get everything back up and running and have no time to research, separate, and request changes through GitHub.
We get quite a few Pull Requests on GitHub for exporting additional functions, and usually integrate them quite quickly. That way we know that it’s useful functionality that works in a plugin, rather than just a shot in the dark.