Thanks all for great examples where Disallow Nanite helps you out!
I’d like to know more about how Mesh Painting is broken for Nanite - I’ve seens it mentioned a few times but would be good with some more info for us to investigate.
@AllyJax You had an example with your concrete paths not working on Xbox Series - do you recall what FN version that was on? And what paint mode and material did you specifically use?
As for the large differences in the FN assets with/without Nanite - I’m pretty sure that’s due to there being a material and mesh override which is used to essentially set up the assets differently on purpose, it’s not Nanite causing the large difference per-se. I’ll check with the FN team on this.
Vertex paint, and or mesh paint (when copying the actor from UE5 since its not available in uefn)
No matter the material Decides to not work properly.
Sometimes it wont show at all with nanite on, it will flicker, and or it will show incorrectly and “fragmented”, or the worst it will change as the players gets closer making it have weird LOD transitions.
Along with that without FORCELODMODEL = 1 the mesh’s vertex paint/meshpaint will ENTIRELY fade away in uefn if you move more than like 35m from the object
Nanite doesn’t work on mesh instanced vertex colors as the colors are part of the “per-instance data” and not baked into the actual nanite mesh geometry. The only work around other than “bDisallowNanite” would be to bake the vertex data into the meshes, and that would cause us creators having to import THOUSANDS of meshes into our content, which would pretty much cause the project to be terrible on performance and expensive on project size. That is why we need the “bDisallowNanite” property exposed as it allows us to have a stable workflow while also giving us the proper results we want. In addition, Nanite itself is also very expensive and reduces performance alone. Sometimes us creators that have huge projects, need that extra bit of performance so that we can have a smooth ,functioning game.
Due to some issues I was facing, these were reimported static meshes and Fortnite materials, they were not the base content browser versions, as such they have no relation to FN bugs/versions specifically.
If it is absolutely necessary, I’m sure myself or someone here could make a project that demonstrates Nanite not supporting vertex paint, to my knowledge this was a known limitation of Nanite, but if it’s somehow a bug that’d certainly be interesting.
Also, these issues we have in the first place won’t be fixed in a timely matter. It’s a fact of this platform that change takes time, a lot of time, more time then you’d ever expect, and sometimes never any changes.
We use this workarounds because we don’t want to wait 4 months for a supposed fix, and have it still broken. This is what I predict will happen, we will be left waiting, asking, everyday to see if our issues will be fixed, and either it’ll be fixed 4 months later, or ignored. When we already have a temporary solution!!!
These workarounds MAKE UP for the time the developers will take to fix such issues, me and you, know for sure, these issues will take months to address, there’s more important stuff, or you guys can’t handle it.
In conclusion, give us our workarounds, fix your stuff, then we’ll talk, we know you’ll take a while to address these issues, and we are completely fine, IF we have a option to work around the issues.
Hi! Good timing, I was just about to update the thread
I have submitted exposing bDisallowNanite, bRenderInMainPass, bRenderInDepthPass and BoundsScale to the UI for 37.00.
bVisibleInReflectionCaptures, ForcedLodModel and bUseAsOccluder should not be validation blockers even if not exposed in the UI currently, so we’ll focus on the other properties for now.
Hopefully, the newly exposed properties should cover 99% of the concerns here. I’d like to understand a few of the other properties that were called out in this thread:
Those are pretty specific settings for single features that only work on certain platforms/configurations and I’d like to see some examples of the problems these are solving for you.
These are the types of properties that we’d like for users to not have to worry about (even in UE proper) so ideally we don’t commit to them by exposing in UEFN - but if using these solve problems then we’ll take a look of course!
As for bSelfShadowOnly - this doesn’t work with VSM, so that means it will not work the same across platforms. It also relies on Inset Shadows, which adds additional cost. We’re probably not going to expose this as-is.
If this is for making First Person things, then we have an official FPS Rendering system now, which would be the things for us to expose to solve that instead.
Hi! Do you have an example of how you’re using bAllowCullDistanceVolume? As far as I can see, CullDistanceVolumes aren’t exposed to UEFN so it shouldn’t make a difference?
As for bTreatAsBackgroundForOcclusion, this looks like a mobile-specific property to sort a primitive last in the draw list - so it should only be a mobile-specific optimization (heavily dependent on content), or are you solving some visual issues with it?
