[Arwill]

>On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea.

I would say its the exact opposite to that. For that genre, its best to roll your own engine, or pick something open-source. The list of problems that i firsthand experienced:

There are lots of features and options in the engines, but they are not all usable at the same time. One feature disables the other. You look at the list of all the nice things the engine can do, but then at some point you figure it can't do (or can't efficiently do) what you absolutely need. All those awesome looking graphics are not practically usable, simply not performant or not compatible to be usable.

There are features that only work in "baked" mode. You "bake" it in the engine editor, and there is no way of changing that at game run time. Unreal is the most limited in this, but Unity is not much better. Some game developers reverse-engineer Unity internal asset formats with a hex-editor, so that they can change feature behavior at runtime. At that point, rolling your own engine makes more sense. One example i saw was a developer reverse engineering the light probe group asset file, so that he could add a new light probe group at runtime.

Engine API's change drastically from version to version. All the code and scripts need refactoring, all the time. You run into a breaking bug, and the only solution is upgrading, but upgrading means breaking your whole codebase.

You need to go trough the engine's abstractions, and bad luck if that can't be done efficiently. An example of this: Unity HDRP applies screen-space ambient occlusion (among other effects). It applies the effect over the whole screen. If there is a third-person view of the character from close or first-person hands/weapons rendered, then even over that. That results in a white halo around the first-person hands/weapon, looks bad. In a custom engine, the solution is simple, apply the full-screen effect before the first-person hands are rendered, then render the hands without the effect. Its a matter of switching the order of a couple of lines of code.

The solution is github and the BSD/MIT/Apache licensed game engines and libraries.

[jayd16]

I think you'd probably want a different render layer with different post effect settings so your weapons can have post-processing as well. I think you can do this in the editor with gui configs instead of changing code.

I'm pretty sure all of SRP is in C# and is "open source" as in source available and editable.

https://github.com/Unity-Technologies/Graphics/tree/master/P...

[Arwill]

The problem with GUI settings is that the result is not apparent, and there might be side effects. I do not find spending half day on trying out setting combinations as productive work.

I have looked into SRP and i do still consider that as an option, and also replacing the shaders. But i have doubts regarding the SRP, for example i have looked at the code that sorts lights in Forward+. The individual light calculations are not much, but its still done trough the job system. I imagine if there are hundreds of lights, then that would make sense, but for 2-5 lights, it seems like a waste. So it might be optimised to scale, but not for my case.

Is the effort of replacing the SRP worth it, and is the performance comparable to putting together/reusing an engine in C++? It is also a bigger commitment, as it needs to be coded on a different level and in a way very specific to the engine. Better than having to reverse asset file formats, but still very specific to the engine.