Update docs.

Docs/Reference.dox

@@ -2010,7 +2010,7 @@ Both a RigidBody and at least one CollisionShape component must exist in a scene
 
 CollisionShape provides two APIs for defining the collision geometry. Either setting individual properties such as the \ref CollisionShape::SetShapeType "shape type" or \ref CollisionShape::SetSize "size", or specifying both the shape type and all its properties at once: see for example \ref CollisionShape::SetBox "SetBox()", \ref CollisionShape::SetCapsule "SetCapsule()" or \ref CollisionShape::SetTriangleMesh "SetTriangleMesh()".
 
-RigidBodies can be either static or moving. A body is static if its mass is 0, and moving if the mass is greater than 0. Note that the triangle mesh collision shape is not supported for moving objects; it will not collide properly due to limitations in the Bullet library. In this case the convex hull shape can be used instead.
+RigidBodies can be either static or moving. A body is static if its mass is 0, and moving if the mass is greater than 0. Note that the triangle mesh collision shape is not supported for moving objects; it will not collide properly due to limitations in the Bullet library. In this case the convex hull or GImpact triangle mesh shape can be used instead.
 
 The collision behaviour of a rigid body is controlled by several variables. First, the collision layer and mask define which other objects to collide with: see \ref RigidBody::SetCollisionLayer "SetCollisionLayer()" and \ref RigidBody::SetCollisionMask "SetCollisionMask()". By default a rigid body is on layer 1; the layer will be ANDed with the other body's collision mask to see if the collision should be reported. A rigid body can also be set to \ref RigidBody::SetTrigger "trigger mode" to only report collisions without actually applying collision forces. This can be used to implement trigger areas. Finally, the \ref RigidBody::SetFriction "friction", \ref RigidBody::SetRollingFriction "rolling friction" and \ref RigidBody::SetRestitution "restitution" coefficients (between 0 - 1) control how kinetic energy is transferred in the collisions. Note that rolling friction is by default zero, and if you want for example a sphere rolling on the floor to eventually stop, you need to set a non-zero rolling friction on both the sphere and floor rigid bodies.
 
@@ -3787,6 +3787,12 @@ byte[]     Bytecode, produced by AngelScript serializer
 
 - The macro \c NULL and 0 should not be used for null pointers, \c nullptr is used instead.
 
+- \c override is used wherever possible.
+
+- \c using is used instead of \c typedef in type declarations.
+
+- `enum class` is not used because of legacy reasons.
+
 - Class definitions proceed in the following order:
   - public constructors and the destructor
   - public virtual functions
@@ -3800,30 +3806,24 @@ byte[]     Bytecode, produced by AngelScript serializer
 
 - Inline functions are defined inside the class definitions where possible, without using the inline keyword.
 
-Keep contributions consistent with existing code unless wide scale refactoring is performed.
-Follow this guideline to keep code style consistent among contributions and contributors:
+It's recommended to follow <a href="https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md">C++ Core Guidelines</a> (except items that contradict Urho legacy, e.g. ES.107, Enum.3, Enum.5)
 
-- Use \c override wherever possible.
+Use this brief checklist to keep code style consistent among contributions and contributors:
 
 - Prefer inplace member initialization to initializer lists.
 
-- Prefer \c using to \c typedef type declarations.
-
 - Prefer range-based \c for to old style \c for unless index or iterator is used by itself.
 
-- Avoid \c enum \c class to keep Urho API consistent. TODO: Perform API-breaking migration to \c enum \c class?
+- Avoid \c auto unless it increases code readability. More details <a href="https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html">here</a> and <a href="https://google.github.io/styleguide/cppguide.html#auto">here</a>.
 
-- Avoid \c auto unless it increases code readability.
+  - Use \c auto for verbose, unknown or redundant types. Example:
+    \code
+    auto iter = variables.Find(name); // verbose iterator type: HashMap<String, Variant>::Iterator
+    for (auto& variable : variables) { } // verbose pair type: HashMap<String, Variant>::KeyValue
+    auto model = MakeShared<Model>(context_); // type is already mentioned in the expression: SharedPtr<Model>
+    \endcode
 
-- Use \c auto for verbose, unknown or redundant types. Example:
-  \code
-  auto iter = variables.Find(name); // verbose iterator type: HashMap<String, Variant>::Iterator
-  for (auto& variable : variables) { } // verbose pair type: HashMap<String, Variant>::KeyValue
-  auto model = MakeShared<Model>(context_); // type is already mentioned in the expression: SharedPtr<Model>
-  \endcode
-  See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html and https://google.github.io/styleguide/cppguide.html#auto
-
-- Use \c auto instead of manual type deduction via \c decltype and \c typename.
+  - Use \c auto instead of manual type deduction via \c decltype and \c typename.
 
 \page ContributionChecklist Contribution checklist