Thanks! This is good feedback. I will look into this.
1 Like
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.
this should be enough proof i can provide that most definitely shows what effect nanite has
image on the left is with and image on the right is with nanite disabled
4 Likes
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.
1 Like
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.
2 Likes
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
I have reported and shown an example to the Meshes and World Position Offset (WPO) materials that scale dynamically here: World Position Offset Having Rendering And Flickering Issues
This is due to BoundsScale and bDisallowNanite being disallowed
Thatâs not a bug..
Could have just posted a video here.
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:
1 Like
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
Thatâs not a bug, just increase the scale of the mesh and turn collision off.
But i donât want the mesh any bigger ? so then it is a bug right ?
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
it sounds like this is one of the reasons people want that exposed but if they fix this bug then thatâll at least help creators right ?
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.
1 Like
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.
1 Like
We have to adhere to certain limitations to be able to have UEFN work on all platforms. This is out of our hands and not something we can change, so I donât expect Custom HLSL to become available, at least not in its current form.
We are however working on improving the Material Editor a lot, so hopefully you will not need to resort to Custom HLSL code anyway.
Thatâs where itâs up to the creator to solve for platform related issues, there are hundreds of custom nodes in Epic made materials, many many more in engine functions, custom nodes inherently are a very advanced thing, anyone using them would likely know that they need to create solutions for other platforms anyway. There are many other ways materials can break per platform in UEFN and still get past validation and in turn be seen by the end user, I donât feel this is something that should be restricted for that reason.
1 Like
Thanks, this is a good example for us to look at!
Apologies for the confusion. I wasnât speaking of technical limitations. There are simply rules that we have to follow to be able to ship UEFN everywhere.