Render Pipeline as a plugin

General Feedback & Requests
1

The idea is simple but very useful : move all renderer code into plugin, and make it possible to register new renderer plugin in user project (like Unity SRP)

Benifit

1.modify render pipeline without compile and redistribute the engine.
2.redistribute rendering modification on github easily
3.be able to sell renderer plugin on marketplace, or plugin that depends on renderer modification (like Hair grooming plugin)

Pseudo code:

static FSceneRendererFactory* GFactory = nullptr;

// register custom renderer here
void RegisterRendererFactory(FSceneRendererFactory* SceneFactory) {GFactory = SceneFactory;}

FSceneRenderer* FSceneRenderer::CreateSceneRenderer(const FSceneViewFamily* InViewFamily, FHitProxyConsumer* HitProxyConsumer)
{
EShadingPath ShadingPath = InViewFamily->Scene->GetShadingPath();
FSceneRenderer* SceneRenderer = nullptr;

if (ShadingPath == EShadingPath::Deferred)
{
    SceneRenderer = new FDeferredShadingSceneRenderer(InViewFamily, HitProxyConsumer);
}
else if(ShadingPath == EShadingPath::Mobile)
{
    SceneRenderer = new FMobileSceneRenderer(InViewFamily, HitProxyConsumer);
}
else
{
    // create custom renderer
    SceneRenderer GFactory->Create(InViewFamily, HitProxyConsumer);
}

return SceneRenderer;

}

2

lol there’s hardcoded stuff everywhere in there, porting to a plugin would require a massive rewrite.

3

Well, Render Dependency Graph should allow for easier modification of renderer - but probably you’d have to modify the source code.

Unity SRP could be actually a bad example. SRP packages activated for project probably contains only part of the renderer, and still, a lot of changes for new renderer hasn’t been applied in Unity’s closed source code. Out of curiosity, does anybody distribute custom renderer plugins for Unity?

Obviously, every change allowing for easier customizing the renderer would be welcome :slight_smile:

4

As much as everyone would wish for it, it is unlikely to happen soon. Fingers crossed for RDG and more parts of the renderer moving over. RDG is amazing.

5

Because unlike Unity, Unreal, and C++ can use a lot of hardware based features and APIs that C# just doesn’t have the capacity to access. There’s a lot more interoperability and interdependency in the system code that allows it to do many of the things it can at the performance rate that it can. Due to the way the engine is constructed, it’s just not as simple as plugin/plugout. A lot of that code needs to be freed from being used before it can just be switched out, and since there’s so many dependencies in many different parts of the engine, that just doesn’t really happen until the engine shuts down.

6

?!?

Not sure where that’s coming from, Unity’s graphic RHI is written in C++ just like any other engine, it’s not C# code.
They allow for things they do because “industry standards” for them has always meant very little.

7

There’s far too much hardcoded stuff all over UE4. Need UE5 built with the idea of multi-threading, far more organized and non hardcoded depencies, concurrent multi user editor, and etc. But right now that feels unlikely as hell.

8

UE4 is built with multi-threading in mind. Also added so-called Concert for multi-user level editing event that such workflow isn’t too useful in regular game development, but could work nicely for industries using a game engine to mix virtual and real-world or making previs for movies.

But is always better to join the train and complain :wink:

9

Although the engine is multi-threaded, the main game thread is single and if you make any transformations to Actors from outside you crash the game.

The most you can do from outside is request and wait unless you’re dealing with UField property directly.

So it’s multi-threaded, but with a ton of gotchas and forbidden accesses from outside.