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…
Hey! @Velocity_Zero Could you elaborate on the bEnableNanite and related settings on Landscape?
@Sprintermax As for the ConstrainAspectRatio - I can take a look at that, but the doors for 37.00 are closing quickly but I’ll try to get to it in time.
Right now the setting is hidden but it’s possible to still create nanite landscape. There’s not really much to tell here at this point. Epic Games is pro Nanite and I like the general goal of it, especially what has been recently presented with Nanite foliage and voxelation. In UEFN it’s a bit hard to find the right balance because we can and sometimes are forced use nanite in our experiences, while we are required to support platforms that have no nanite support, so almost every mesh needs LOD based fallbacks. That said, Nanite for landscape would be trivially enabled IF the mesh that it would generate wasn’t so costly. I forced it once just to run an experiment and the result wasn’t promising. While the landscape would run both the regular landscape + nanite landscape on supported platforms, the nanite landscape took 300+ MB of cooked size. Without a thin client and a much larger cook size cup this feature isn’t really useful yet. I’m also a bit afraid that the future 3d landscape system might not land in UEFN for a while for similar reasons, as it will just cost too much cooked size + it could create challenges with platforms that do not support nanite.
I don’t remember from the top of my head but landscape actor also had some different hidden settings when it came to fine grained control of HLOD generation. I don’t have the latest UE installed to compare. It would be great if any HLOD related settings were exposed. Especially if anything lets you configure how camera FOV affects landscape HLOD levels to swap. Right now at very large FOV values the landscape behaves as if the landmass was far away and it starts warping between lower HLOD levels, which is a real deal breaker if you use fast vehicles that tend to increase FOV for the sense of speed.
Additionally there’s also a setting that is somewhat hidden in UEFN, but is already enabled. However this setting can be accessed more conveniently in UE than in UEFN.
Under Build / Landscape there should be a setting for building landscape splines in UEFN. That functionality is already accessible via World Partition / Build / Build Landscape Spline Meshes.
Thanks for the writeup on the landscape stuff. As we work towards an improved landscape system, Nanite certainly has a central role there and UEFN will have to get a solution for all of this, that means tackling the cook size challenge as well. I don’t know when that would be exactly, but work is being done in that space.
I mention 37.00 because we plan on making those unexposed property validation warnings into errors again - the thing that prompted this thread in the first place (but hopefully should not be an issue now that we’ve identified the key properties from this thread and actually exposed them).
Well, in that spirit I hope we’ll get some good news for this as well:
While I understand that you might not officially provide a comment on this particular request. I’m sure there are some islands already published with that setting being used and even I need it for better transform accuracy in order to fight the following problem:
