Custom lighting models (and .usf) support in plugins needed. Is Epic planing to improve plugins?

Hello there,

This has been suggested before but I would like to hear what are the current (short term) plans with .usf support in plugins (and plugins in general).
Is there going to be better plugin support in the near feature? meaning 4.13 - 4.14.

Currently it is almost impossible to release a plugin with custom .usf files in the marketplace (unless replacing .usf files in Engine’s directory is considered acceptable, but in my opinion this is really messy).
I think some attention is needed in the shader and plugin side of things as soon as possible, I’m happy that plugins are finally being released in the marketplace (thanks for that Epic!) but custom shader support is unfortunately still not a thing.

Custom lighting models are also not possible via plugins at all since it requires modifying the engine’s source code, which really sucks :frowning: that’s a huge limitation in my opinion.
I’m basically stuck on this and there is no solution other than submit a pull request, but then we are not talking about a plugin anymore but an engine feature.

It’s a wasted opportunity… a lot of cool plugins could be made if there was better shader support.
I’m sure with a few engine changes plugins can be way more powerful and less restrictive.

Empower your plugin creators! this can only lead to awesome things.

Thanks for reading :slight_smile:

+1 for this!

Having an easier way to get custom shaders working would be a huge improvement!

It’s on their radar: Trello

Big haul of work though!

Apart from custom shaders, I wish the already existing shading models would be exposed a little better.
Just recently changed the diffuse model from Lambert to Oren-Nayar.
Only one line had to be commented out and another comment removed in ShaderModels.usf
In my opinion, the visuals have improved by 200% :smiley:

If that would be accessible via a material parameter, it would be awesome :slight_smile:

The only issue with enabling this kind of thing to be set using material parameters is it then makes the shading model twice as expensive, because you’re going to use all the shading models plus a choice between the two diffuse models. It would be nicer if there was a project setting for things like Oren-Nayar, Lambert, Disney, etc including settings for the specular and stuff… But it’s one of those technical features, so I don’t think it should be exposed to people who might not understand what it does. I think at least being able to set it in the USF is something handy to have. Though, I would love for some more shadow filtering settings, shadowmap depth precision settings, and general fixes to how the filtering code works (because right now, the more shadowmap filtering, the worse the depth bias artifacts are, the bias setting should be applied to the filter taps based on the offsets not a global amount :s)

Would kill for shadow filtering like Crysis 1’s, tempted to port it over actually.

As for custom lights, you can do those just fine using bp & material editor.


They use an unlit additive blend mode material which samples the gbuffers (no specular, I want to use these as ambient lights with a custom lighting falloff / calculation like CE has.) Also thinking to add planar area lights as well but obviously those would have specular and fully integrate into the shading pipeline - probably a USF modification and code to support those though. I also want to allow you to add cubemap textures to control their colour (because UE doesn’t support those, optimisations from pre-4.0 I guess, should really be revisited now there’s support for texture arrays…)

Unfortunately it’s in their backlog and no mention of custom shading model support.

Unity seems to have a way more powerful system when it comes to shaders, I have seen marketplace plugins that adds from customs BRDF models all the way to custom GI solution without having to touch the engine’s source code.

Hopefully one day UE4 can be like that as well :stuck_out_tongue:

I just tried that and, boy, did the results not look great.

Well, you have to adjust your shading habbits accordingly :slight_smile:

For example, I had to tone down my normal maps massively.
While some were barely showing in the Lambert model, they are now really carved out and overdone.
I rerendered them with less intensity and it looks really good.
Also, to make the view-dependent-rougness come out good, you need to adjust the specular.
While in the Lambert model, the specular is the ony source for specular,
in the Oren-Nayar model, the specular (effect) comes from a shallow viewing angle.

The ON model is basically was Kojima created in the Fox engine. And there it looks great :stuck_out_tongue:

PS: Just compare the two shading models with the example map from the (free) automotive materials.
Especially on the Alcantara and patterned leather its really visible.

Problem with switching to Oren-Nayar globally is that everything starts to look like plaster/sand (which is what ON basically tries to simulate - a very rough surface). MGS5 Has this exact problem where things can look really flat without a strong reflection/sweat etc.

On the other hand, lambertian can look a bit too “shaded”, but usually works better for slightly stylised/illustrated look.

So yeah, best would be per-material brdf but that would just kill performance.

Yeah. If you want to have a material with a lambertian look within the ON model you have to set the roughness to exact zero (and start using specular again).
The lambertian model becomes basically an edge-case of the ON model.

@KVogler; - Has there been any downside to using Oren-Nayar for diffuse in UE4? I’ve been trying to learn more about BRDF, and I’ve found that almost all renderers either use Cook-Torrance for spec and Half-Lambert for diffuse, or Oren-Nayar for diffuse and Blinn-Phong for spec. As IIRC UE4 uses the former combo by default, does anything break by switching out the diffuse algorithm? Something tells me it might screw with PBR’s energy conservation rules or somesuch, but I’m a complete noob when it comes to this stuff.

The only real “downside” is when you want to have shiny surfaces.
As said above, the you would have to set the roughness all zeero.
So all the ON micro facetts are coplanar and non occluding.
The lambert model would do an equivalent appearance with a fewer instructions and resources.

So, if you have no rough surfaces in your level, go with lambert
If you have mostly rough surfaces, then go for ON.

If its a mix of both, then decide:

Lambert : “cheap”, but does noty a good job on rough materials
ON: More expensive. Renders rough surfaces good. Renders lambertian look with more costs than native lambert.

Personally, I think the additional rendering costs are worth the effort.

It might reduce performance (I don’t really know) but I don’t think that’s necessarily true, there are already multiple shading models (subsurface, clear coat, two sided for foliage and now cloth, hair etc.) the problem is that you can’t actually add something like that yourself without modifying the source code at least a little bit.

That’s what I’m hoping Epic resolves… let us add custom shading models via plugins.

And why don’t set the changes in a custom fork in Github ? As others do.

Divide features of the game engine to sell as DLCs isn’t good…

Not sure what you mean by that :stuck_out_tongue: there is no division(?) of features, it’s addition :stuck_out_tongue:

Reasons why a custom fork simply won’t do:

  1. I would estimate 90% of UE4 developers use the launcher version of the engine (therefore a custom fork would automatically make it less accessible), not everyone is willing to compile the whole engine… a plugin is simply far more ideal and easy to work with.

  2. Maintaining a whole engine branch just for what would essentially be a few lines of added code is super inconvenient (unless you are already using a custom fork ofc).
    To clarify, only a small amount of code is needed to be added to the engine in order to “register” a new shading model which feels unnecessary (it should be possible via plugin), the actual shading model is added in the .usf files.

  3. Not possible to sell in the marketplace, unless Epic adds the option to sell engine forks I guess.

Noone wants to merge 10 different engine forks to get the tools you need. It’d be so much easier using plugins.

Let me bump this.
Is there better plugin support coming in the near future? meaning 4.13 - 4.14.
Can EPIC please give some hints, if this is roadmapped in near future or dropped into the uncertainty basket?

4.13 is already out, don’t expect anything else from it :smiley:

would be nice to know tho