Can we get any updates regarding bDisallowNanite? As 37.00 creeps closer and closer, it’d be great to know what’s going to happen here.
1 Like
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.
4 Likes
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:
bReceiveMobileCSMShadows
bCastRaytracedShadows
bCastDistanceFieldIndirectShadow
bVisibleInRealTimeSkyCaptures
bSelfShadowOnly
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.
thank you!
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.
Anything you can say about exposure of bConstrainAspectRatio (camera component), bEnableNanite (on landscape) + related settings?
1 Like
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.
1 Like
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.
Is there any importance to this particular release version? Can’t further settings be still exposed at a later point by any chance?
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:
1 Like
Unfortunately I can’t speak for those as they aren’t rendering related, but I’ll raise them internally!
1 Like
Any chance we can get the Z (now Up) killzone value exposed from world settings? It seems to be overall restrictive to permit only up to -500 vertical units and not allow creators to override this value manually.
I’d recommend requesting that in a new issue thread so it gets picked up properly by our internal tracking so the right team can assess that request!
Regarding something rendering related then, is there any chance the Water plugin Material Function “GetWaveData” can be exposed as well? This is a stock Unreal material function responsible for getting the Gersner wave data from a water body, without this function interacting with said system inside materials is not possible to my understanding, either this function or Custom material expressions would do the trick.
@Kev.EG sorry for being late, but I think this setting might not have been mentioned upthread and I always kept forgetting about it. I personally and other rely on it to achieve certain visual clarity or equality across different platforms. Additionally this setting allows to potentially boost FPS performance in certain situations.
On the post processing volume there’s a way to disable ‘Lumen’.
bOverride_DynamicGlobalIlluminationMethodDynamicGlobalIlluminationMethod=None
External reference:
It would be great if these settings were also exposed.
We have a new wave displacement atlas system in the works that brings a lot of improvements over the current wave system so I’d have to check if it makes sense to expose that Mat Function at this stage or if we’re better off just holding out for the new thing.
1 Like