4
\$\begingroup\$

Okay I'm new to Unity, and I'm making a space sim pc game. You know, space is huge, light years of distance between stars. Even if I set 1 AU (150,000,000 KM) as 1 unit, 1 light year will be 63,000 units, that's far far away from one another. Let say planet Earth's scale is 1, then the Sun will be 110x times the size of the Earth. This is big, because if the player's scale is 1, then we need to rescale the planets, the stars. I don't know whether or not Unity will handle large objects or far objects nicely, what I mean here is if a planet is, for example 10000 units, will the objects stop being processed by cpu? And does large objects use more cpu performance, if it does, how much it use?


What I want to know

1. Does far far away objects use up more cpu usage?
2. Does gigantic objects use up more cpu usage? I know it sure does, but how much? Is it 2x scale = 2x cpu usage on that object?
3. Do you have a way to minimize the usage of cpu, or more efficient way to do with large and distant objects?

I'm just started Unity last month, and get excited about how much could Unity do, but i always concern about how much cpu usage does this task use up. Any ideas?

\$\endgroup\$
5
  • \$\begingroup\$ CPU usage? No. There will, however, be problems with floating point resolution. Somewhere in this thread there is some details; the original poster is doing something that sounds a lot like what you're doing. \$\endgroup\$
    – Draco18s no longer trusts SE
    Commented Feb 1, 2016 at 15:41
  • \$\begingroup\$ A sense in which it could add CPU/GPU load is if you have a very complex, distant object that is large. Because it is large, it is visible from far away, so you can't cull it from the scene. So you will have all that geometry being rendered all the time. You can use LOD groups to alleviate that: docs.unity3d.com/Manual/class-LODGroup.html where Unity will swap in less complex versions as you get farther away. \$\endgroup\$
    – jackmott
    Commented Feb 1, 2016 at 15:50
  • \$\begingroup\$ As @Draco18s suggests, you'll likely find floating point precision problems more pressing than performance. One light year from the origin, you'll only be able to represent positions within about a 300 000 km error margin, and it just gets worse from there. Usually this is solved with a "floating origin," where the world is periodically moved to keep the player close to zero. \$\endgroup\$
    – DMGregory ♦
    Commented Feb 1, 2016 at 18:56
  • \$\begingroup\$ @DMGregory Looks like recentering the world is good way to go, but the problem is how do I center it through scripting? I'm just a beginner, can't do advanced thing :( \$\endgroup\$
    – WhatWhereWhen
    Commented Feb 1, 2016 at 19:26
  • \$\begingroup\$ That's another question, and I suspect you may be able to find an answer for Unity by searching either here or for tutorials on the web generally. I know for example the Kerbal Space Program development blog talks about some of their experience with this technique, and there are additional links in the answers here. If you don't find what you need, I'd recommend asking a new question detailing what you've done so far and where you need further information. \$\endgroup\$
    – DMGregory ♦
    Commented Feb 2, 2016 at 0:26

1 Answer 1

Reset to default
3
\$\begingroup\$

Aside from my comment (don't have the flexibility to pull back a specific post at the moment) the answer to your question:

No, but...

There is no CPU gain or loss by changing scale. It's not even correlated, except for one case.

And that one case is rendering. When you scale an object (especially non-uniformly) then it cannot be batched with other like-objects. There are two kinds of batching, static and dynamic.

Static batching is super ridiculously fast. But....it only works on objects that don't move, rotate, scale, animate, or in any way change. They are static. This is functionally equivalent to Mesh.CombineChildren though it happens automatically and will have better results.

Dynamic batching is slower, but still faster than not-batching in most cases. Dynamic batching will group objects that have the same material together into a larger mesh, provided that:

  • They have the same material (material instances, even if 100% identical, break batching)
  • The total vertex-attributes is 900 or fewer (if more than 900, they will be grouped in batches of 900).
    • This value may change in the future
  • The objects have the same lightmap
  • Single-pass shaders (multiple passes will break batching)
  • Real time shadows break batching
  • The objects have the same scale
    • Non-uniformly scaled objects can batch, but the exact details aren't listed.

There may be an impact from having a view frustum that is very large (measured in AU) due to the large size/very distant object jackmont mentions. This is less of a concern than his comment makes it out to be except for the amount of geometry involved.

Largely speaking Unity can render a single 100,000 vert mesh faster than it can render ten 10,000 vert meshes (I cannot find the thread where this was posted now) but that test was done with a very simple flat plane. In terms of real impact, simpler geometry renders better at longer distance (also known as LOD = Level of Detail) because it's so small, calculating the UV and lighting details for something that's only a few hundred pixels shouldn't involve more than a few dozen verts: there's simply not enough screen space involved to make the increased detail matter.

Same thing applies to textures and animations: at very long distances where the object shrinks below the size of a dime, you can start using smaller textures and simpler models and disabling animation entirely: the user simply isn't going to notice.

However, all of the constraints involved in rendering these are GPU and RAM/vRAM based, not CPU.

\$\endgroup\$
3
  • \$\begingroup\$ Alright, I'd been reading this since half an hour ago, I'm not fully understood but what I know is LOD saves me. One more question, if you don't mind, is it the further the object, the more CPU / GPU usage being use up? (E.g: Object A at 1,000 units away, and object B at 10,000 units away, both with same size and same LOD.) \$\endgroup\$
    – WhatWhereWhen
    Commented Feb 1, 2016 at 17:28
  • \$\begingroup\$ Distance from the camera has no impact on render time. Same thing with its scale. It's all about the complexity of the model. The only reason to use a lower poly object when something is far away is because the increased geometry won't be noticed and does have a small impact on render times. In your example, they would both take the same amount of GPU time. \$\endgroup\$
    – Draco18s no longer trusts SE
    Commented Feb 1, 2016 at 18:38
  • \$\begingroup\$ While "distance from the camera has no impact on render time" is correct for most purposes, I think there are a couple of details worth mentioning. 1. For a visible object of a given size, the further away it gets the fewer pixels it takes up on the screen, which can ease its fillrate cost on the GPU. 2. For scenes with large distances, we'll often render in multiple groups (see Source engine's 3D skyboxes) to keep depth resolution high close to the camera. This adds extra passes & complexity compared to rendering only near objects, but it doesn't have extra incremental cost per object. \$\endgroup\$
    – DMGregory ♦
    Commented Feb 1, 2016 at 18:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .