[MAJOR] Almost all hidden properties are now disallowed, they have been allowed since UEFN released until 34.30.

General Issues and Bug Reporting
, , ,
22

Hello,

I thank you again for taking the time to read and respond to our feedback in this community. I had some quick thoughts on this property validation problem.

The current approach is to block UEFN Maps with any non-whitelisted property.
But I propose, specifically for StaticMesh and PostProcess/Components, that properties which aren’t intended for standard use should still function, but be marked as experimental rather than being blocked entirely from in-game use. Here are a couple of reasons why:

• UE5 to UEFN barrier: Limiting so many settings through a shifting whitelist creates major roadblocks for developers migrating assets from UE5. When properties are outright blocked, developers are often forced to abandon asset migration from FAB and other sources. This increases the divide between what’s possible in Unreal Engine and what’s allowed in UEFN, further highlighting the already significant differences in capabilities.

• Limited by what’s currently deemed the “standard”: The push to restrict features simply because they’re not considered standard is problematic for several reasons:

• It’s not entirely accurate, as Fortnite itself uses many of these disallowed properties in its Frontend and Battle Royale maps features not available to creators.

• It creates friction for new users exploring UEFN, who quickly run into limitations.

• It delays solutions for issues that have already been addressed in native engine features. For example, StaticMesh includes a field to control distance field intensity essential for reducing unwanted dark spots on large meshes. This is supported by the engine, but UEFN currently disallows modification of that field, resulting in unnecessary constraints.

• Experimental designation enables creativity: Allowing access to these properties under an
“experimental” label would empower creators with more creative freedom, while still clearly indicating that the functionality is not officially supported.

In summary, blocking UEFN maps due to disallowed properties creates unnecessary barriers for UE5 asset migration, introduces inconsistent limitations (especially when Fortnite uses those same properties), and hurts creativity. A more balanced solution would be to classify such properties as experimental accessible, but clearly marked with opt-in activation via game feature data.

Thank you for reading my post. I hope this is given consideration. We appreciate your ongoing engagement with the community and efforts to help it grow.

2 Likes
23

We are reviewing these hidden rendering properties to decide whether or not they will be exposed for use.

Starting in v37.00, modifying these hidden properties from their default values will cause validation errors instead of warnings.

We urge creators to migrate off of these properties now, or let us know why that won’t be possible for your island.

bDisallowNanite
bRenderInMainPass
bRenderInDepthPass
bVisibleInReflectionCaptures
bVisibleInRealTimeSkyCaptures
bReceiveMobileCSMShadows
bCastDistanceFieldIndirectShadow
bSelfShadowOnly
ForcedLodModel 
bAllowCullDistanceVolume
bTreatAsBackgroundForOcclusion
bUseAsOccluder
BoundsScale 
CastRaytracedShado
2 Likes
24

We need to keep bDisallowNanite for the following reasons:

  • Many old props (trees, bushes, ..) were updated with Nanite support, but a lot of Creators prefer the original, non-Nanite versions. (including me)
  • Elevation pieces do not function correctly when Nanite is enabled. The Mesh Paint Starts to flicker or doesnt even show at all (inculdes Tilted & Greasy Island)
  • Meshes with World Position Offset (WPO) materials that scale dynamically tend to flicker when the camera moves.
  • Creating proper Nanite-compatible materials is difficult because not all necessary features are exposed. As a result, we’re often forced to use non-Nanite materials - bringing us back to point 3, where those materials don’t behave properly.
12 Likes
25

This wont be possible for multiple of our islands due to mesh paint not properly working with Nanite enabled and the force LOD model being anything other than one which by default its 0. PLEASE PLEASE PLEASE, let us have these properties, they are crucial as we dont have proper mesh paint integration yet :folded_hands:

7 Likes
26

Also some custom meshes have artifacts when using nanite and dont behave properly, but since we have no way to have a mesh appear different on players with nanite vs not like epic can this is a HUGE issue for custom meshes if these are dissallowed.

3 Likes
27

We have already explained to you why we need these, please listen our concerns, my whole message outlines the answer to your WHY. [MAJOR] Almost all hidden properties are now disallowed, they have been allowed since UEFN released until 34.30. - #22 by abdulqaz

5 Likes
28

IMO, it seems like they took what we wanted and instead of allowing them they are now targeting them, it is unfortunate, and I hope you change this course of action. This marks a crossroad for our UEFN capabilities, and make a lot more thing impossible to do, consider your action very careful, this may cascade into something big, leading to people leaving this community.

4 Likes
29

Please keep “bDisallowNanite” enabled because many essential features such as vertex painting don’t function correctly with Nanite. These are not obscure tools they are fundamental to our workflow, and the current limitations are restricting us once again. It’s been two years, and only now are there steps being taken to address these issues. please maintain the current settings as it stands.

6 Likes
30

At least in my experience, bDisallowNanite has been useful for stuff like mesh paint, which is very useful for environmental assets, and for many creators, finding a workaround for this will take a very long time, and in some cases, might not even be possible. Most of these also likely have their own uses and should not be disallowed either. Not sure how this is supposed to be the “future of fortnite” if you guys are trying to eliminate as much functionality as possible.

5 Likes
31

Please reconsider removing BoundsScale. Many materials that rely on World Position Offset (WPO) would break without it, as it’s essential for ensuring correct rendering and preventing visual issues. :folded_hands:

7 Likes
32

Bounds scale is also one of the most crucial features for background actors, they are used for WPO for background actors, like for example Impostor LOD’s which fortnite has used since 2018 (Post Page)

With boudsscale override being invalidated this make it IMPOSSIBLE for uefn creators to use these systems for optimizing our projects as WPO starts to not work from far away without bounds scale override.

Secondly boundscscale is needed for any VFX thats in the background that you want to not cull, along with background actors like mountains.

5 Likes
33

These are all crucial properties many creators NEED for things. Removing these will discourage many creators from doing things on this platform, these are base Unreal Engine properties, they are used across the industry, they are used by Epic themselves, as such this will also discourage people from coming from standard Unreal into this ecosystem. I personally will genuinely not continue using this platform if many of these are removed.

I highly recommend the team reconsiders here, these are needed and are not options for many creators.

5 Likes
34

One of the properties that should be exposed (and probably also having it’s default value changed to false), is the bConstrainAspectRatio on cinematic camera actors.

All the maps (including some by Epic itself) have issues with monitors with different aspect ratios due to that option being set automatically to true, and without the possibility of the map creator changing it to not constrain (keeping normal monitor ratio).

This leads to issues such as flickering UI (for example between 21:9 and 16:9), affecting cinematics, map interfaces (both passive/HUD and interactive/menus), and even fortnite social tab itself and settings screen.

On many cases, experienced creators uses the bConstrainAspectRatio=false on purpose to avoid these wrong/glitchy scenarios, or just to not clamp the camera on a running cinematic (to not show black bars/borders)…

This is a very basic feature, absolutely needed for cinematics, works fine without problems, but is not exposed, forcing creators to “hack” the workflow by editing the camera actor on a notepad to change this setting to a desired state (that imo, should even be the inverse by default for better compatibility)…

14 Likes
35

Why?

Also:

No.

36

I second the missing exposure of bConstrainAspectRatio. Additionally the ability to disallow nanite seems very crucial from a totally different perspective. This platform is enforcing Nanite, however it also requires the creators to publish to all sorts of platforms including low end devices / mobile which do not even have Nanite support. This way creators are forced to do an odd dance between dealing with nanite created overhead and also making all custom meshes having proper LOD levels or it will impact performance on low end devices. If disallowing nanite will not stay, then we should have an option to restrict our experiences to nanite only platforms. It‘s extremely inconvenient to be forced to deal with all these platform related nuances while also having our hands tight on the engine level knobs we could turn in order to optimize and balance the final products.

If anything Epic should just hide all these features for the regular creators and set them to proper defaults, but permit an opt-in for advanced creators to unhide and these features.

4 Likes
37

Please reply to our response properly. We have commented on this massively, but it has all been ignored. It feels like the UEFN devs are undermining us and don’t care. Thank you for your contributions anyways, I know you probably have no control of what goes. :[

4 Likes
38

Please no, we lose more and more every week

1 Like
39

Some of these tools are essential for developers who need precise control over performance. Removing these settings limits creators ability to optimize, debug, and manage complex scenes. Even if some of these are ‘niche’ options they can be critical for larger scale projects. Not even sure what’s gained by removing these features?

Taking away from creators already limited scope of control is a massive step backwards and only limits what’s possible to make further. I lean on some of these features quite heavily and will outline the ones that would ruin dozens on my projects if these become disallowed below.

I’m sure other creators lean on the ones i don’t mention as well..


bDisallowNanite # Nanite ruins certain materials using WPO and the only way to get the vertex shader to work properly is to turn nanite off on the mesh | Would ruin dozens of my islands. (Would make most of my work look broken...) / Nanite also arguably gives minimal perf gains (Sometimes longer frame times) unless you design your entire scene around the feature.

bCastDistanceFieldIndirectShadow #This needs to stay because if you're using DFAO certain meshes generated distance fields can be very bad depending on what you're using the mesh for (IE Some oddly shaped barrier mesh) / Don't want meshes with invisible materials on having any influence over the lighting in my scene. 

BoundsScale #Very necessary for doing vertex animations and not having the cpu cull the mesh when default bounds are out of view. This would break dozens of my maps. 

CastRayTracedShadows #This should be allowed for obvious reasons.
1 Like
40

Hope you all reconsider this, removing these properties is going to lead to a lot of headache for all of us.

1 Like
41

Hi everyone! Good to see a lot of passionate UEFN developers engaging with this topic. I’m Kev on from the Rendering team and I’d like to understand more in-depth what use cases and issue you are encountering around these properties.

Note that this is not an excerices to simply remove functionality, it’s really about making sure that we can maintain the functionality we expose long term.

We don’t want you to resort to having to edit hidden properties to build your UEFN experiences of course, so let’s figure out what we can do here to get you the functionality you need without having expose every single little property and complicate the UX for everyone more than necessary.

2 Likes