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?
I would like to give some background context in that outside of UEFN, I have a lot of experience in standard UE4, so optimization was something I always had in mind when working on things. That being said, most of these are just used for cases where I want micro optimizations for specific things, even if its platform specific, and in very specific cases having some of these enabled can cause super niche issues, though I haven’t necessarily come across any in UEFN yet for those specific properties.
Regarding bSelfShadowOnly more specifically, I was not aware virtual shadows didn’t work with it, the newer rendering methods from UE5 aren’t my strongsuit necessarily, but having the mentioned FPS self shadowing option would probably be a good compromise there.
Just a general suggestion, but I feel a thread similar to the ones for what Weapons and Galleries people want could be made for what properties people want exposed, there are a LOT of properties that the previously mentioned notepad copy paste trick are used for outside of SM’s, I feel getting a lot of those properly exposed by getting feedback from the community would be the move.
Yeahh! Like I said earlier on this topic ([MAJOR] Almost all hidden properties are now disallowed, they have been allowed since UEFN released until 34.30. - #34 by Sprintermax), the constrain aspect ratio is a very weird one and causes lots of bugs, in my opinion it should not only be exposed to let creators have flexibility on cinematics, but also having its default value inverted (from true to false), so creators without the “notepad trick” and/or with less experience with cinematics make things work properly on different monitors by default without needing to deal with settings that they maybe don’t even know about…
