I agree and I agree with the thread in general. I just want to make a counter-point because the same people who might buy a grossly unoptimized mesh and think it is okay because it says “nanite mesh” might also get easily swayed to the other end and think, “nanite is bad, I should only use “game-ready” stuff instead.”
Personally, I am not going to buy any model if it doesn’t have a marmoset/sketchfab viewer or a ton of screenshots so I can know the technical details involved. I wouldn’t recommend anybody to spend money on 3d art if they don’t know the basics of how to inspect one from a technical standpoint.
Online stores are always at least half full of stuff that will be largely unusable, so buyers should be extremely cautious unless you are prepared to spend the time refactoring or optimizing or w/e else you need to do to make the thing viable for your own project. And if you do chance on something that doesn’t suck, make sure to leave a nice review
I always try and leave a balanced / nice review. But in this case, I just had to leave a gaping void. I can’t really say much positive about it, because the models are so nuts. Good, to be clear, but nuts.
I’m pretty sure Epic hasn’t said to partners, “you don’t need to pay attention to poly counts any more”, which was the message I was getting.
After reading this i did a more in deep dive into nanite.
I tested a few meshes and how this all really works (Spoiler: I still dont understand how this works full).
So to me it looks like if you activate Nanite this will then also use some sort of decimation like in Zbrush too (you can see this also in the pictures).
Beside the size of the model it really seems like it doesn´t matter how many polygons it have.
The big benefit i see in using a lot of polys is not using a normal map. I tested 8k textures they where around 80mb and the normal map for this was around 150mb, ORM was 30mb. A model out of the tests i made was only 31,5mb compressed nanite size.
But i still try to figure out how to use the best out of both.
Maybe it would be a good idea to include a lower model because of the disk size it uses and also a normal map .
So everybody can decide himself what to use. And if you want to edit the Uv´s yourself it can be really hard with high res meshes if you dont have a really high end pc.
I also think it would be hard to build a very low poly model out of a model (with baked normals) that is build with Nanite in mind if you dont think about this from the start. And some things just need extra polys to look almost the same.
Below i added a few pictures from a few tests i made.
Here are a few tombstones both are Nanite. One is 500k and the other 100k without normal.
I guess you cant really tell which one is the one with 100k.
But the disk space used doesn´t really was a difference. 6,4mb full model – and the funny thing 7,7mb the decimated model.
So in this case it seems it would be better ro go with the higher res model.
But the very high model gives a complete different result
Base 1,5 million Verts - 31,5mb disk space : Decimated to 300k Verts - 6,8mb disk space.
In this case it makes a hugh difference and it would make sence to use the lower res model. If there is not something with Nanite i dont understand or see right now.
screenshots aren’t exactly the same as a model in a game under dynamic lighting conditions and camera moving around though.
All the little surface details may be lost if model is decimated beyond a certain limit. Depending on the intent of how model is used, that may be important.
Depends on game and situation of course, but I guess if I was buying “nanite models”, I’d probably want the highest possible resolution and I can reduce it as needed for my needs. Same idea we already have with textures.
You are 100% right. It depends on your needs and you will always lose details if you decimate, even if it is only a tiny amount.
Just tested this with a 1x1 m stone for a floor, i endet up with 2 million polys.
Does it look good? Yes but will you see this tiny details in a game? i guess not.
And how does this add up if you use this for every pice in a level. How long will be loading times?
I mean this single little stone is 15mb compressed size.
But i think this is more for a own topic for a discussion about.
In the end it is really great to have nanite. You can just do insane amount of details.
Yeah I was wondering about that too - I just did some tests which make it look as if the reduced version is saved.
There were 3 projects, 1. without nanite, 2. nanite 100% and 3, nanite 20%:
536,772,608 bytes
536,772,608 bytes
531, 849,216 bytes
So the reduction has reduced the packaged size by 4.7Mb so that’s good to know - it works the same way textures do… No-where near as much savings as keeping things that are never close-up low poly though…
We wanted to clarify how we handle Nanite submissions on the UE Marketplace.
We encourage creators to submit all types of content, but creators are welcome to submit ‘Nanite only’ products as long as they list that information appropriately on the product page. If you feel that you have purchased a product that did not provide enough information for you to make an accurate buying decision, we recommend that you reach out to the seller for support or request a refund. If they are not able to resolve the issue, please submit a support case here and the Marketplace team will be happy to look into the issue.
All assets must meet the minimum content for the category that they are being distributed in.
The assets should contain enough complexity in design and geometry that Nanite is properly utilized. In other words, simplistic unoptimized assets will not be accepted as Nanite assets.
Technical Requirements:
Only Unreal Engine 5.0+ products can support Nanite.
This disclaimer must be included on the product page: “This product supports Nanite for Unreal Engine 5.0+”.
Overall project size (with Saved and Intermediate folders removed) should not exceed 10 GB prior to zipping. If the project does exceed this limit, please contact Marketplace Support to discuss options.
Nanite should be Enabled for all meshes by default.
Supported Platforms should only list platforms where Nanite is officially supported.
Thanks for your answer. Can you please explain to me why it’s important to have all meshes Nanite by default? Is it just so the package is shown to be compatible with Nanite for all meshes - or is there a performance/resource reason as well?
The main reason was because we believe the majority of users that purchase products advertised with Nanite support would expect that Nanite would be enabled by default.
For anyone that purchases a Nanite advertised product and wishes to disable Nanite on all assets; this can be done fairly easily by selecting all assets in the Content Browser > right-click > Asset Actions > Bulk Edit via Property Matrix > and unchecking the Nanite Settings/Enabled box.
