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.
Hey, thank you for replying. So bDisallowNanite does indeed affect meshes. A simple case is the Athena Large trees and pine trees, at this current moment, the new Nanite meshes are always on Xbox and other platforms and settings no matter what. Using bDisallowNanite we can get the original look of the trees without any additional changes. I can’t give direct examples, but I have personally been super frustrated with Nanite, especially with Vertex Colors, they do not work together and changing the settings in the actual StaticMesh alleviate the issues, it does not fix the issue, Nanite causes a lot of issues for us that use vertex colors, I might be able to pull up photos later. Also SkyDomes with materials mess up badly, vertices clunck up and tear at edges of the screen if Nanite is enabled on meshes, this I can reproduce. I ask sincerely to allow us to disable Nanite on meshes, it will take so long to fix these issues with Nanite in the engine, and a temporary and working solution is to have a option to disable it. Thank you.
Also in general, changing unexposed properties doesn’t hurt. I agree that it isn’t the standard way of doing things, but as developers we all have different needs. Not allowing us to use BASE Unreal Engine features is a limiting factor many of us creators have dealt with, and this is pushing our tolerance.. Thank you.
Also, since your apart of the rendering team, and this post is about validation. Could you share more about direct HLSL code being used in Custom nodes being banned? (disallowed) We’ve never gotten a statement about this, and hearsay says that its because of engine exploitation.
Your statement about bDisallowNanite is false, per official Unreal Engine Documentation:
“Many parts of Unreal Engine need access to the traditional vertex buffer provided by traditionally rendered meshes. When you enable Nanite for a Static Mesh, it generates a coarse representation (called a Fallback Mesh) of the highly detailed mesh. The Fallback Mesh is used when Nanite rendering is not supported. It is also used when it wouldn’t be ideal to use the full-detail mesh, like when a complex collision is needed, using lightmaps for baked lighting is required, and for hardware ray tracing reflections with Lumen.”
Many creators prefer the “fallback” non-nanite meshes to the ones with nanite enabled, and removing functionality for it is quite honestly ridiculous. I also find it quite odd that somebody officially representing Epic Games would very confidently state something that can be proven false with minimal research.
As for the statement “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.” Why not just expose them? The UX being somewhat complicated is usually just a biproduct of a UGC engine that can create more interesting and unique experiences, which is the goal of UEFN, is it not? Most if not all creators would agree that we shouldn’t be constrained by the fear of UX being complicated. As for the place where you mentioned that BoundScale can be “supported”, what exactly is the reason the bDisallowNanite can’t be? It is a basic engine feature and works as intended currently, and has since UEFN’s launch in 2023, I find myself unsure of what “continued support” it would need.
It seems more and more like we keep getting excuses and less and less like our concerns are being heard, which, if your goal is to attract people to the Fortnite ecosystem over other UGC ecosystems, only supporting mechanics for the same 3 copy-paste map styles is neither attractive nor unique.
I strongly urge you guys to allow more complicated features into UEFN, while keeping the in-game Fortnite Creative toolset as a place for new creators to learn without being overwhelmed by a more complicated toolset. Not only do I believe this approach would allow UEFN experiences to be more unique and interesting, I believe it would make the UEFN space much healthier, as creators who are experienced could not only make more complex maps, they could also create more content using the engine (example: tutorials for people graduating from the legacy toolset to UEFN) and this content could draw more people into Fortnite as a whole, seeing that it has these unique features to offer.
I don’t work with scene building/level designer, but just recorded this to test:
Left side is bDisallowNanite=True (force always disabled)
Right side is bDisallowNanite=False (default setting), but also switching the Force Nanite for Masked can compare both visuals (idk if this is persistent and consistent to be used on a project, but maybe is an alternative?)
I just did a quick test for curiosity since I saw your images, I don’t build scenes so I don’t have many examples of it on other props
A good example is the rotating parts on the Abductors. If you look in certain directions and positions, It will be culled. There is a workaround by setting Max World Position Offset Displacement to a really high number like 1,000,000,000
Here is an older video that shows this exact issue:
I’m having this same issue and I’ve never changed anything. When i semi go out of full line of sight view the mesh either disappears or flickers. This is a custom mesh too. I think i need that setting to fix this for sure.
Tried everything to fix this and never found a solution
Increasing bounds scale would likely be a fix to this, but again, not a property you can edit without pasting something into a text editor, editing it there, then back into unreal
No.. the cpu doesn’t know what goes on in the vertex shader, it will cull based on where the actor is in the level / default boundsscale.
You can go around this by making the mesh physically bigger in the scene or increasing the boundsscale of the mesh.
In your case if you’re using the sprite material function if you’ve made the float2 input for size larger than the mesh you need to make the mesh larger in the scene so that it does not get culled. It is not a bug. That is just how unreal works.
If they expose the BoundsScale then it will allow us to edit the mesh bounds without having to do a text editor workaround as AllyJax said. This with bDisallowNanite should fix the issues on the meshes so its all about these settings they are trying to take away which is a prime reason why we should have those two on top of the others as well.
