Do high poly count worlds hurt fps?

I saw that the world sdk does not have the option to only partially load a map. Does this mean that the whole world’s polygons are being calculated at each step? If so, will a large high poly map destroy fps?

Only the meshes that are considered “visible” at a given moment are contributing to the total “polycount”. You can see how many polygons unity will be rendering at any point by clicking the little “Stats” button in the Game View and moving your “Main Camera” object around the world.

Generally speaking - PCs can handle millions of polygons per every frame. So you can safely have a world that pushes a couple million polygons. (Don’t forget that avatars will also contribute to the total number rendered!). You probably don’t want to have more than 10 million polygons per frame give or take. I usually take the amount of people my world is supposed to fit, multiply it by 70000 (the max before going “very poor”) and then add it to my currently rendered polycount in the stats window to get a somewhat average number.

For quest 1 that number should preferably not go beyond 50k per frame
For quest 2 it can go higher, so you can do like 100-150k polys per frame (just for the environment).

The more important metric overall for world optimisation is the Batch count. The more batches - the more CPU load there will be. With less than 500 batches being ideal.

Hope that helps!

Expanding what orels1 says,

It’s not a simple matter of “If I reduce X then my performance will be better!”
It’s a mixture of various things that impact performance. Polygon count does play a role in overal optimization, after all, a 200m poly object will require quite a bit of math to process.

But things like material sizes, real time vs baked lighting, physics, colliders, occlusion culling, etc, etc will also play a huge role in performance.

Batching likewise is also a double edged sword. Some say to reduce batching, others say to increase it. Batching means unity will group things together to process it in one go. In a LOT of cases it’s something you want to do. What you want to reduce however is draw calls.

See unity’s own documentation for an explanation on the topic: Unity - Manual: Draw call batching

That said, orels1 is on the right track with things in terms of reducing calls and batches. You don’t want to reduce batches for the sake of reducing batches. Cause if I make everything in my scene not static, I’ll have achieved the same goal with worse performance. The whole goal, is to make it so things that should be grouped together are grouped together properly. And that things that shouldn’t be rendered aren’t rendered.

Using things like material/shader instancing, baked lighting, static objects with culling, etc will already help a lot in the department of reducing the pointless drawcalls