We have to adhere to certain limitations to be able to have UEFN work on all platforms. This is out of our hands and not something we can change, so I don’t expect Custom HLSL to become available, at least not in its current form.
We are however working on improving the Material Editor a lot, so hopefully you will not need to resort to Custom HLSL code anyway.
That’s where it’s up to the creator to solve for platform related issues, there are hundreds of custom nodes in Epic made materials, many many more in engine functions, custom nodes inherently are a very advanced thing, anyone using them would likely know that they need to create solutions for other platforms anyway. There are many other ways materials can break per platform in UEFN and still get past validation and in turn be seen by the end user, I don’t feel this is something that should be restricted for that reason.
Thanks, this is a good example for us to look at!
Apologies for the confusion. I wasn’t speaking of technical limitations. There are simply rules that we have to follow to be able to ship UEFN everywhere.
By “Ship UEFN everywhere” do you mean allowing creators to ship their content to players? Or what exactly do you mean? Very confused there..
Give us a meta verse shading language so we can have loops! lol
Hi! There was probably a misunderstanding. What you are referring to is what I meant, the fallback mesh will be used when used with a material that doesn’t support Nanite. The rendering itself using Nanite shouldn’t bring a difference, but indeed the fallback mesh migh be different due to the simplifier.
Exposing things in UEFN is easy, removing them is however very difficult once they have started being used. Some of the properties are very implementation specific and maybe even old or hacky and we are thinking about removing them or changing them in UE going forward, which is why we don’t expose everything at once - so we don’t have to commit to supporting properties that might be going away or get changed.
In UE we have different version and games built will use the engine they shipped on. Developers can even modify the source and compile their own version. In UEFN that’s not possible and we have to make sure islands created years ago always run. Every property exposed adds a long tail of support. So we try to be careful and think things over before exposing. No excuses here, we’re just looking out for the long term success of UEFN. This is a marathon, not a sprint.
bDisallowNanite not being exposed from the start came from the idea that we are working towards making everything Nanite and didn’t want the user to have to care about the mesh being Nanite or not - it should just work as expected. This is still our goal and the reason why I’m gathering your use cases and repros in this thread. If this doesn’t work out, then we will definitely reconsider but for now I could you your help to poke holes in this reasoning with content examples that we can look at.
Thank you!
We are working on loops support in the material editor!
The problem is, as it stands, the end user DOES have to care about if somethings Nanite or not. Mesh paint does not work with Nanite, numerous of Fortnite’s own assets look completely different and stylistically clash between Nanite and non-Nanite, certain materials may not work as expected on Nanite, the list goes on and on, until the day comes where full Nanite and non-Nanite feature parity is achieved, I do not see a world where this is removed from the engine itself, when the time comes that it is however, I feel its a safe assumption that feature parity would have been achieved, and at that point the removal would not matter for Creators.
On the left, a tree with Nanite disallowed, on the right, the same exact tree actor with Nanite enabled. They are COMPLETELY different, in both texturing, color, general style, and hell, even the shape looks to be largely different, these are both rotated and scaled the exact same.
Regarding mesh paints, whilst they often preview fine in the editor, in game on Nanite, and on next gen consoles, they will appear how they do with no paint at all, this image is from a user on an Xbox Series console on a UEFN map I work on before I figured out bDisallowNanite existed. The paths here are supposed to be concrete, and they are on all non-Nanite platforms and with Nanite disabled. My fix was, quite obviously, to disallow Nanite, and it works perfectly fine.
Nanite does not always work, and there should be a bypass when it doesn’t work. You have seen the examples above. Fallback mesh does not work. Thank you.
This has happened to me too many times. I agree.
Nanite being enforced means that there will be a additional nanite mesh that we have to bake. Take a really simply mesh like a cube. The geometry is so simple, it just can’t be further reduced. Why would it require an additional nanite mesh?
Another interesting fact is that while UEFN seems pro Nanite, you have not enabled nanite for landscapes. Why? Because a single 2x2 landscape mesh will result in 300+mb cooked size. With a 400mb total game budget that is unacceptable so it was decided not to enable that feature.
This is an example where epic decided to turn nanite off for performance reasons. Why are we not permitted to do the same for our meshes? Not every mesh is high poly and not every mesh requires nanite.
Same applies to texture streaming. The editor does not permit the “never stream” toggle to be set. Why is that? Why should all textures at all costs should be always streaming?
I think that has lots of more reasons attached, such as we not having access to built-in props or internal meshes/materials, so we can’t change it’s settings to configure properly visuals or details, enabling/disabling fallback meshes, and even logic attached to blueprint on many props…
Lots of people on projects that I’ve worked on, did not wanted some of these features (such as props randomizing color on each compile, random decoration/positioning offsets, and so on…) There’s no way to change how these things works, some props that are multiple objects are not always available in single/individual objects for alternative, and so on…
There is lots of roadblocks for creators when dealing with built-in props/assets from fortnite that are out of our control.
For example, on first UEFN Tech Demo, was showcased a demo of looking inside fortnite materials, meshes and some other asset types (obviously as read-only, just for learning purposes), but that showcased feature was never released.
These three images are the same prop, but every time that you move, change some option, rotate or even just reload the project/map, it has different visuals due to the blueprint logic randomizing it, also the pillows have a small random rotation. These things can’t be turned off or manually selected, and individual versions of the props are not available too:
And, related to nanite visuals, I did a quick search and these are some example videos comparing same mesh with/without nanite visuals… I did not looked at everything on content browser, but has lots of more props that are affected by these things:
Whilst unrelated to the original post, this reply brings fourth a pretty important problem I’ve had for a while, and that’s why are we NOT allowed to use the basic static mesh versions of assets? In a lot of cases, simply using the static mesh would be preferable over using an actor, especially for things like landscape mesh inserts, or in the case above, meshes that change depending on position.
I second this an actually brought it up at UEfest, its way better for static environments!
having static mesh versions of at least all of the Fortnite provided foliage would be nice.
yes being able to “HISM” them would be great
