@Kev.EG anything new about these two requests?
bConstrainAspectRatio should not only be exposed but also having the default value for it being âfalseâ, currently is default to true and lots of creators (specially innexperient ones) does not fix it for supporting other aspect ratios, causing lots of bugs and even affecting things that should not such as core fortnite UI itself 
1 Like
Iâm not super familiar with the camera actor dependencies, but I donât really see a good reason for that not being exposed, in addition to the Aspect Ratio and FOV. I can dig a little and see if thereâs a good reason or if we simply havenât gotten to it yet.
I can also mention that itâs only the CameraActor that has it enabled by default explicitly, the CameraComponent actually has it disabled by default. The change is 10+ years old so I donât have the context, but can try to find out.
Iâd be curious to hear how youâre using the camera component in your work and what bugs youâre seeing with the constraint aspect ratio enabled.
1 Like
As for Nanite Landscape - I believe the plan is to dedicate resources towards the new terrain system instead of making the current system optimal in UEFN. There will be more info on that system at Unreal Fest in September. I guess that also answers @AllyJax question on RVT - itâs likely that RVT will be introduced through the new terrain system once that makes it to UEFN.
2 Likes
Is there anywhere I can go to get some info regarding this new terrain system? Whatâs different to what weâve had basically forever now?
It used to be on the public roadmap, but I donât see it there anymore - itâs probably being reworked for 5.7. There are a couple of talks at Unreal Fest you can see on the agenda schedule. I donât think there are any technical details out on it yet, but that will come as documentation starts rolling out for 5.7.
Mostly this is a user experience problem. The constrained aspect ratio generates either horizontal or vertical black bars on the players end depending of their screen aspect ratio which is simply not ideal. I would like to animate the camera like a drone flying over my world, or some kind of a game transition. Such experience should not have any black bars at all, but be presented in unconstrained full screen manner.
Iâd love FOV settings to be exposed as well. 
As for FOV, I work on vehicle focused experiences and FOV is commonly used in order to tweak the sense of speed.
The âForward Lookingâ tab has been removed for some reason. I asked Jean-Sebastien about it, but he couldnât provide an answer for the exact reasoning.
It was briefly mentioned during the last UE Fest in Orlando, but nothing specific has been shown except that the goal was to show it with 5.7, which now seems to be the case.
Mesh Terrain has been announced to be presented at Unreal Fest 2025 in Stockholm.
Iâm very keen to see where this is heading. And I hope UEFN gets the support as fast as possible. I really wonder what the cook size will be.
RVT and render targets are very important to me in the long term as well, but I think the main problem is that UEFN has no HLSL support due to some security issues. Hopefully there will be some kind of Verse like wrapper in order to enable custom shader nodes. This is also very important for the PCG plugin as many things are moving towards the GPU which may also require HLSL.
@Kev.EG more requests. 
Why are collision related features hidden? In the past we had some of these exposed in the landscape spline meshes (iirc), but thoese are hidden now. Basically whenever we set the âCollision Presetâ we have no idea what collision responses it will have. And there are a ton of different presets. While we cannot create custom presets yet, itâs still handy to know how the collision responses will be set depending on the existing presets. This reduces the trial and error through pure guessing.
Can we please get custom complex collision mesh exposed in the mesh asset setting?
I was told by some of your colleagues to abuse an extra LOD level as a workaround. It should be explicitly configured so small so the engine will never switch to it, but the LOD mesh would be used a custom collision geometry. I think just using custom collision mesh would be much nicer and more convenient.
Please expose Spline component and Spline Mesh components / Actor. All 3 validate just fine, but cannot be added or placed if needed. One can place a spline using the modeling drawing tools, but the regular actor variant is still missing.
Can we get culling settings on (H)ISM components please? Controlling culling is very important when it comes to optimizations.
How about the LOD related settings on the mesh component?
Can we get Is Editor Only setting on the mesh component? Itâs often very convenient to place some helper meshes for visualization purposes that should be excluded from the final cooked build.
The spline mesh component is missing all those settings. It requires to be configured in UE in order to be placed in UEFN, which is very very tedious. This also makes it impossible to tweak those directly within UEFN.
Equally, the spline component is missing a lot of settings as well. Not all are needed in UEFN (e.g. construction script related toggle).
When it comes to mesh components, I personally rely on many of these settings as I need to migrate them from UE to UEFN as Iâm using PCG to generate them. However Iâm unable to edit many of those settings directly in UEFN afterwards. On top of that, I assume that if the validation process will be very strict about those, it will stop from validating for very simple things like spline (mesh) positions, which will be very very sad.
In my case Iâm building a hybrid project. Static world using SM, (H)ISM, FISM, (soon-ish) PCG ISM, SplineMesh and for dynamic objects where I need to query collision for example I rely on Scene Graph entity based meshes. However I cannot just go with SG only right now or anytime soon. I need the most bits from actor based mesh components.
EDIT:
Dear @Kev.EG after hours and hours trying different UMG layout widgets and settings I figured out that there are two hidden properties on the Size Box. Can you please expose these two asap?
- Min Aspect Ratio
- Max Aspect Ratio
I was trying to replicate the same behavior of the RR car UI, but itâs simply wasnât possible without these two settings because the in-game HUD Scale will otherwise scale the width and my own overlay widget would appear in the wrong place and not mimic the native UI behavior. These settings solved it for me.
EDIT:
This is the example widget placement I cannot achieve without the hidden settings. It works on all platforms, all hud scales and all aspect ratios. Without the settings itâs not possible to replicate that behavior.
1 Like
Okay, Iâve exposed bConstrainAspectRatio on the CinematicCameraActor (CameraComponent) in 37.20. For FOV and AspectRatio, weâll have to loop back to that since some experts are on vacation. Either way, I donât think the FOV would be for the main gameplay camera, as itâs already being animated for certain Fortnite effects if Iâm not mistaken.
For the DynamicGlobalIllumination option on the PPV, we almost managed to implement a new way to expose limited enums in dropdown boxes, but it will need a little more time so Iâm hoping for 37.30. In the meantime weâll remove the validation error on it so you can work around it starting in 37.20.
Fo all the other requests 
I can look into the ISM culling and the spline mesh properties, but for Collision and UMG stuff it will have to go to a separate team - I suggest starting up a new thread to request those with good repro steps and explanations like you did here.
2 Likes
Hey kev, would it be possible to see these features exposed in UEFN? These would be SUPER helpful for projects.
Iâm pretty sure those are not going to be exposed as there is currently a big effort to refactor the Material Layer system which would bring some new asset types - so that would come when itâs done (I donât have an ETA for that).
1 Like
Correction on this - we ran in to some issues excluding this from validation in 37.20, so we will instead focus on exposing it properly, goal for that is 37.30.
1 Like
Bit late but going back on this here, is the only reason custom hlsl shader nodes arenât allowed just because of platform related restrictions? That seems a bit silly given platform switches and such exist, I know they are used by Epic internally a LOT in more complicated materials, and hooked up with platform switches and quality switches to do other, more simple things on other platforms that canât use custom nodes. If the decision here is solely due to platform concerns, I feel that could be looked into further, as anyone who would realistically use a custom node would likely know they need to support other platforms in other ways.
1 Like
Perfect, Thank you!
It goes against the rules of some platforms to allow executing arbitrary user generated shader code for security reasons.
What we would have to do it create a whole new CustomHLSL system where we provide a sandboxed environment where users could code only against a sanitized API that we maintain, so no direct âHLSLâ API calls or constructs. That would be the equivalent to using material nodes, but in text. It would be useful for those wanting to write out their shader logic in code instead of nodes, but it would be restricted in what buffers and functions you could access etc.
This is something being discussed but not on the roadmap for now. What is on the roadmap is to roll out the new HLSL Translator backend that will enable the material editor to become more powerful with strong typing and proper dynamic branching and loops an more. The idea being that users should be able to achieve anything through nodes and rely less on CustomHLSL.
What is it that youâre trying to do with CustomHLSL?
While not directly material related. PCG has scripting nodes with a curated set of APIs that can be called in order to write HLSL based GPU nodes.
This was on the âForward Lookingâ page. I wouldnât mind to have a higher level verse based abstraction to do this for PCG and for materials to be honest. Additionally having script based materials is often much easier to parse in terms of logic execution than gigantic spaghetti looking node based materials. 
1 Like
That reasoning makes sense, wasnât aware of that at all.
Iâve talked about the standard Unreal Engine Water plugin material function âGetWaveDataâ before but thatâs what I was hoping to accomplish here, as it uses Custom nodes to pull info otherwise unavailable through the Material Graph.
Youâve talked about a new water system thatâs in the works before, but I really do just wish GetWaveData could be exposed before then so itâs remotely possible to interact with this system for Water, very frustrating not being able to do so. Currently Water bodies default materials in UEFN have completely broken transitions, this was marked as âWonât Fixâ on a bug report not long ago, not having GetWaveData makes it impossible to make equal quality water materials to address these problems ourselves.
1 Like
Is there a reason we dont have nanite fallback mesh support, in UEFN we can set the fallback triangle % but we cant actually have it a different mesh like fortnite does in BR. this limitation is arbitrary and makes me think its an accident because there is a nanite override material option in material instances but right now its useless since we dont have fallbacks
@Kev.EG I would like to re-iterate one thing from the previous requests. Is there any chance you can expose âIs Editor Onlyâ or is another team in charge of that decision?
In fact, that setting is already partly exposed.
When we create a new prop blueprint thereâs an editor only static mesh component. Copying it reveals two settings:
bIsEditorOnly=True
bIsVisualizationComponent=True
Any chance we can get these exposed? bIsVisualizationComponentseems to be restricted to only appear within a actor blueprint and it causes the component not to leak into the details panel when selected in the outliner.
bIsEditorOnly is theoretically available everywhere.