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.
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
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.
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.
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.
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.
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.
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.
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)…
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.
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. :[
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.
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.
Many old props (trees, bushes, ..) were updated with Nanite support, but a lot of Creators prefer the original, non-Nanite versions. (including me)
Could you elaborate here? Nanite shouldn’t change the way your prop looks.
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)
Mesh painting is mentioned a few times in this thread, I’d like to understand how you are using this and what is breaking for you. Here’s the latest documentation from 5.5, this should work with Nanite.
Meshes with World Position Offset (WPO) materials that scale dynamically tend to flicker when the camera moves.
This sounds like a bug, do you have a repro for this which we can investigate?
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.
Nanite should turn off automatically when a feature isn’t supported, for example if you put a Translucent material on a Nanite mesh. Incorrect behavior here is not intended and if you have a repro case, we’d like to take a look.
Nanite will decimate higher poly meshes when it feels like it and there’s seemingly no setting (at least that will be respected at runtime) that will undo the decimation even when the camera might as well be touching the mesh to add the density needed to animate the surface properly.
