Thanks! Unfortunately we’ve got 37.00 in lockdown now so I can’t make that change, but I will check in with the team on that one asap.
Just for clarification, even if it would error in v37.00, can it still be enabled in a future version?
In my case I can temporarily revert it, but I would like to enable it later again and disable global illumination.
Yes, exactly. Once 37.00 goes live, you will have errors in your project to resolve for properties that aren’t allowlisted (I’m checking to see if this will happen for already published projects or if it will only error if you try to re-publish in that version, I’ll get back with an answer on that later today).
If we later allowlist those properties, you can start using them again.
I’ll expose the DynamicGlobalIlluminationMethod property on the PPV for 37.10 so you can use it properly.
2 Likes
Ok so already published projects will keep working even if they use a disallowed property - this will only be a concern if you try to republish, then you’ll have to fix all errors before publishing again.
2 Likes
Despite what the post is titled, I’m 99% sure it was JUST StaticMeshComponent related properties that were disallowed like this, if this is now being applied to everything, notably PostProcessVolumes, once 37.00 goes live, I imagine there will be a lot more properties being listed off here by people to be added properly to the UI.
Can we expect to continue receiving responses and such here once that happens? Many creators projects will still likely break and people will want to have properties validated if it applies to things outside of just StaticMeshComponents.
Sounds promising, the Gerstner wave system did frequently give me trouble. In the meantime though GetWaveData would be nice.
One other thing, what’s the status on RuntimeVirtualTexturing in UEFN? Is there a reason it is not fully allowed to be used? It’s something I’ve wondered for a while, and wanted to use in my maps as well. I know many creators have wanted it for a very long time.
1 Like
I’m pretty sure it was a global change when it was enabled last time. Either way, you’re right - we’ll likely get more requests after 37.00. We are constantly working towards exposing more things and with SceneGraph getting built out more, things will come through there as well (my team is picking up PPV for SceneGraph shortly, so we’ll see some movement on that soon). I’ll be keeping an eye on rendering related things here.
RVT is currently not on the roadmap at this time, so not part of the short term plans. What use case would it solve for you?
This will have to land in a later version as we currently don’t have a good way of exposing partial dropdowns. Currently that option contains things like Screen Space GI (Beta) and Plugin entries - this will have to be sanitized before exposing. Can hopefully hit 37.20.
@Kev.EG just checked v37.00. It looks like bDisallowNanite is only a mesh component setting. While great for finally having it, it’s a bit unfortunate as the Nanite mesh is still included and probably cooking for potentially every custom mesh asset.
Can we get the checkbox and it’s functionality exposed inside the mesh asset settings?
Nanite Settings / Enable Nanite Support
I would like to untick this setting for certain low poly meshes as I don’t need any additional Nanite geometry or generally want a target mesh to be non-Nanite. This should hopefully also reduce the final project cook size.
2 Likes
RVT is an incredible tool for blending things together, such as objects with the terrain itself, like grass, rocks, terrain mesh inserts, and so much more. It’s used on every single one of Epic’s official BR type maps to my knowledge.
RVT also serves as a MASSIVE optimization to complicated landscape materials, due to how it effectively stores the result of instructions to be computed once rather than every frame. Even if you aren’t using it for blending things, merely adding it to a landscape material of your own has a good few benefits. The fact it hasn’t been added to UEFN is another one of the main things that puts me off from serious environment tech art design, I really don’t see a good reason its not in or at least planned.
3 Likes
To follow up on my lost post, we got “Bounds Scale” exposed on the mesh component, however the mesh asset setting still does not expose the setting for adjusting the bounds. In order to do that, you have to edit it in regular UE and migrate the asset. This workflow is not very convenient, therefore I propose the exposure of the related mesh asset setting(s).
We can visualize the bounds, but the settings for adjusting it are still hidden.
3 Likes
This is what i need so the thing doesnt vanish when its semi off screen i think ?
Opting out of cooking in the Nanite data is a larger discussion to be had as opposed to what I exposed as a component override. It does make sense, but it means we’d have to include all the Nanite data in the future when we go ‘Nanite everything’ - meaning a lot of projects would suddenly have Nanite data cooked for the first time in one go.
I’ll have to look into this.
Thanks! I’ll bring this feedback back to the team.
1 Like
This is understandable, but on the flip side, imo we should have a migration path in the future for a full nanite only path, but in the meantime permit opting out of nanite. The reality is that we have a very constrained cook size budget already and a nanite only reality is potentially at least 5 years away from now as we will need to phase out many lowend devices Fortnite supports and wait until all GPUs can support nanite. Do we want the creators to wait potentially that long?
Similar story applies to opting out from Lumen, for visual and possibly performance reasons. I‘m not experienced enough to tell if there is an alternative way of disabling it in UE projects unlike with the post processing volume which is scheduled for 37.10. In case there is a better way of disabling Lumen and global illumination, I’d advocate to expose this setting as well. 
Don’t get me wrong, I would love to go out full nanite, but the budgets and constants can be very hard to deal with.
1 Like
Let me look into this and loop back tomorrow.
1 Like
Yes, you should be able to set the Bounds Scale right on the mesh component right now to make sure you have sane bounds in case you are manuipulating the underlying mesh with for example WPO.
1 Like
Thank you kind sir this was an issue for so long 
Ok I’ve exposed the bounds on the mesh asset for 38.00.
2 Likes