Don't know what to trust, Unity Documentation or dev discussions

I'm just starting out learning Unity and I was trying to move a 3D GameObject with a BoxCollider without a RigidBody using Translate() as it was done in the tutorial I am following. I had some problems with the Collider not following the GameObject exactly when moving so I tried reading about it.

In the documentation (https://docs.unity3d.com/Manual/CollidersOverview.html), I found that it says:

"The physics engine assumes that static colliders never move or change and can make useful optimizations based on this assumption. Consequently, static colliders should not be disabled/enabled, moved or scaled during gameplay. If you do change a static collider then this will result in extra internal recomputation by the physics engine which causes a major drop in performance. Worse still, the changes can sometimes leave the collider in an undefined state that produces erroneous physics calculations. For example a raycast against an altered Static Collider could fail to detect it, or detect it at a random position in space."

But in this discussion:
https://forum.unity.com/threads/non-static-colliders-without-rigidbody-still-cost-in-unity-5.452177/

They mention that the doc is outdated and not true. Someone linked an official Unity blog post there as proof. So now, I am having a doubts as to what is updated and what is not in the Unity documentation. I can't continue on my test project because I'm not sure if I'm doing something bad or something OK.

 

If you can't tell then it's fine, because even if there is something "wrong" it clearly isn't causing a problem.

Don't try to get everything to be perfect. Get it to work, then re-examine afterwards to see where you can improve things for next time around.

On this specific matter, the last post in the linked thread is from a Unity staffer who confirms that the documentation is out of date. It sounds like moving static colliders at least isn't a performance issue. They're unclear about if it may raise other issues, but I wouldn't let that stop me from developing my stuff. If I run into related issues then I'll just come back and either add/remove Rigidbodies as required.

 

Actually both of them true to some extent. First, the documentation hasn't changed for a long time, so slightly outdated for sure. Unity had made a lot of optimization which now allow us to move static colliders, but they still more efficient if didn't moved. They probably won't fail or wouldn't be in undefined state anymore.
Please keep in mind that Unity has a very broad range of goal, it's can be utilized for very small and very large games. In very small games, these inefficiencies don't matter in a huge game with a lot of colliders and moving parts it may matter.
It's your job to decide what you choose to do. You need to learn how to estimate your project and how to apply Unity's quirks to it. It will come by experience so just keep up and do it.
As @angrypenguin said, don't care about optimization just yet, you will have plenty of time to do that. Your first projects won't be even near perfect, but this is expected, you will learn how to do better, that's the journey of a developer.

 

The only optimisation you should worry about up front and during early development is workflow and workspace optimisation, not performance optimisation.

So instead of worrying about how fast something is, or how much overhead it has, instead worry about making sure you have the best tools and software you need for the tasks your doing, and that your work environment is conducive to getting work done (good layout in unity, good environment at home to work in with ample lighting, comfortable RSI combatting equipment, everything within easy reach etc).

As well as looking at the processes you do and optimising that (trying to turn something that takes 10 clicks and 10 drags into 1 click and 1 drag for instance over time will add up to a lot of development time saved in one area that can be spent on another).

You can worry about performance later, once you have a game worth optimising

 

@angrypenguin, @Lurking-Ninja, @GameDevCouple_I: Thanks for the replies and I agree with you guys. But this is just one instance and happens to be about optimization. The issue now is what other things are wrong in the documentation? Most of it probably still applies, but I can't be sure now, I need to read documentation and then maybe check some other sources as well. Maybe what it says about how Physics works is outdated as well? I don't know, and that's the problem.

 

It's possible that there are other incorrect things in the documentation. However, I still stick to this principle:

Work based on what's in the documentation. If it gets the desired results then move on. If it doesn't investigate whatever problem you have when you have it.

For what it's worth, I also independently found the physics issues and I have not found any other similar issues. I've found a bunch of vague stuff, but nothing that's wrong like the physics thing.

 

You're still overthinking it. Just do it, if you notice something strange, then investigate and maybe ask on the forums. Until you come across a bug you need to deem documentation as the way the software works. Please keep in mind that documentation is a product by itself as well, and every product can contain bugs. Documentation isn't an exception. Though Unity does a fairly good job with it comparing to other software in general. So don't worry, work instead.

 

Unity has even switched physics engine versions since both that doc page and that thread were written, so for all I know none of that info is valid anymore. Best way when getting conflicting information is to just test it yourself to figure out which is correct, or change your design to avoid the ambiguity entirely.

I agree with this to an extent, but when you're new you are more focused on learning how to create something at all vs how to most efficiently create.

I also look at optimizing your game early in development not as something you should just avoid, but looking at the costs vs the reward. For example, if you ignore performance optimization it is possible to be halfway through developing your game but get stuck with an unplayabley poor performing build, halting any testing until resolved. That is a big problem if you've recruited help testing your game. If you take just a little longer developing a feature, you can sometimes drastically improve its performance.

Of course the flip side is also true, where you could triple your dev time on something for negligible gains - wasting a lot of time that could have been better spent. So it is important to pay attention to how much time you are working on something and understand that getting a lot done that is pretty good is a whole lot better than a little done that is perfect.

 

Rule #1 make your domain is maintainable and modular so you can easy refactor later when performance problems do arise. Rule #2 obey Rule #1.

Thats said its good to always think about allocation and complexity o(n) when writing code.

 

I agree with this, what I should have said is when your early in your project, if you have to optimise something prioritise workflow over performance, whereas if your towards the end of it, do the reverse

 

Trust what works. Nobody cares if the docs are right or wrong when your game is playable and fun.

 

I actually really like this quote. Nice simple rule of thumb, kinda specific to games where there does tend to be a hard release point.

 

Yeah, this didn't really stop me from continuing, its just taking more time to learn things as I can't 100% be sure that the behavior specified in the documentation is what's really going to happen.

My frustration in this documentation thing is I come from a background of developing LOB applications and honestly, in my years of software development, this is the first time I used a large product with an official documentation that you can't trust.

This is also the reason why 'Nobody cares if the docs are right or wrong when your game is playable and fun' didn't sit well with me initially. But I think I understand a bit now how it is in game development (I think). Games are more closed environment and as long as it runs and plays as its supposed to, its OK even if its coded poorly because unlike LOB apps, you probably won't have feature changes every month or so (I'm sure there are exceptions like MMOs, etc).

 

Well, there are plenty of games which have regular updates. But yeah, games are often not approached as rigidly as business apps - often to their detriment! A part of the reason for that is that they're simply lower risk. If a game has a bug it's not a big deal, where if a business application screws up there could be significant consequences.

Regarding not caring if the docs are incorrect... well, I for one certainly care, I just mean that it won't stop me.

 

Definitely it matters less with games than anything else. But I'm not saying it's fine for the docs to be wrong, just that most of the time you can sort things out pretty quickly by implementing and testing so there's no point worrying that you might be doing something 'wrong'. Unity's core set of principles is pretty simple and when you run into stuff like performance issues you can usually find a lot of information on forum threads and such.

Incidentally I have never really found any issue with the docs myself (except for some lack of insight) and I've heard pretty bad things about the docs for other engines.