By “Ship UEFN everywhere” do you mean allowing creators to ship their content to players? Or what exactly do you mean? Very confused there..
1 Like
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!
2 Likes
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.
1 Like
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.
3 Likes
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?
2 Likes
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:
On this video, you can see the rotation randomly changing on each blueprint compile:
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:
1 Like
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.
1 Like
I second this an actually brought it up at UEfest, its way better for static environments!
1 Like
having static mesh versions of at least all of the Fortnite provided foliage would be nice.
1 Like
yes being able to “HISM” them would be great
1 Like
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.
2 Likes
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.