Separate GameObjects for physics simulation and rendering

Hello, Unity fellows,
In our game we are seriously looking into separating physics simulation and rendering completely - thus creating 2 (roughly) game objects per each actual object. The reasons are explained below. I couldn't find similar question on the Internet so please excuse me if such discussion already exists.
The approach is similar to other platforms (e.g. Adobe Flash, which I used to use, maybe there are many others), where physics and rendering are completely decoupled.
I do understand the benefits of having rendering and physics coupled in the same GameObject, but it also certainly leads to lots of other problems (some of which quite serious)
I would love if you guys share what you think on the subject and share some knowledge if you have tried out something similar.

Pros:
- In a multiplayer game, in case there is a correction by the server, physics simulation may be updated instantly and reevaluate from there, but rendered game objects may be smoothly transferred to where they need to be (and not teleported)
- Can use layers separately - no more mess due to the layers being used for rendering and physics at the same time - you can have objects visible but not physically represented at the same time and vice versa - occluded but interactible - big winner
- Can apply some fancy "physics" to given object - e.g. the physical representation is a sphere - it rolls and stops due to drag and/or friction. But the rendered game object is a, let's say a bomb. I want the bomb to just take the position of the physical game object, but not rotate like it does (rather look like it is being dragged, or tilt slightly based on velocity, but not roll). Currently to achieve this you still need to create at least 2 GameObjects for that given object and decouple them anyway.
- ...?

Cons:
- double the game objects count - not sure how much of an issue that is, but certainly bit problematic
- in case of the server correction above, it may look like you are interacting with some object, but it may be currently interpolated, therefore you are not actually interacting with the physical representation - not much of an issue, since corrections are rarely made and are not very significant
- rigid bodies need to assign the position/rotation from their physical counterparts - again not much of an issue I think
- ...?

 

I suggest read this topic, which should answer some questions.
Separate Physics and Rendering layers

 

Yes I have already seen this thread but it is about the layers only. What my post is about, explicitly create 2 GameObjects per actual object - one with physical components (Collider and RigidBody) and the other for rendering components (Mesh Renderers, etc.), and have them linked.

In my opinion, this way the layer problem which is also mentioned in the other thread will be avoided and will allow for some more flexibility. What do you think, is it justified?

 

This is something you will need to decide.

In general I think (I deemed this not viable for me so actually I've never built this kind of twin-game-object system, keep this in mind) that going on this way is not a viable solution (so I'm doing it ever) and the reason is: if your game is small enough to the duplication not causing performance problems than you probably can solve the layer issues without it (less layers at the same time) and you can use any collider you need on any objects so having a sphere collider on a character is okay to be able to roll it down on a slope or something, when you have small game you may afford multiple colliders and switch between them as needed.
On bigger projects when you need more layers the duplication probably will kill your performance.

 

As @LurkingNinjaDev mentioned, I also had my previous prototype, trying having twins. It was not only mess, but start affecting overall performance. I run into layers limit fairly quick. And main reason was, because I wanted avoid floating origin implementation, hence I had multiple worlds in same physical position, but on different layers.

Then I was start applying some dirty tricks. Easy to get out of hands.

So as long you don't have many objects, you may be fine.

On other hand:
twins are currently one of the way, marrying physical and rendering objects in ECS. But in terms of rendering layers, you are not bounded to Native Unity layers count limit. So you can use them mainly for physics if needed.

 

here are some raw numbers from the game:

about 5000 tiles (imagine like a Minecraft level)
every tile has 3 LODs so that lowest LOD does have 6 faces per tile, the others have more to get more detail
every tile also has a BoxCollider and no RigidBody.
There are a couple of RigidBodies and those are controlled by the player.

On a low end Android device (some Lenovo tablet for 50 Euro) it runs at 10 FPS.
The main reason seems to be it is heavy on physics calculations.
We are certainly aiming to achieve at least 60 FPS on such devices.

What I am thinking in terms of rendering:

1. Frustum culling is enabled, this is out of the question.
2. Heavy occlusion culling for occluded tiles (e.g. tiles under other tiles and surrounded by tiles)
   
3. LODs I already mentioned, 6 faces per tile on the lowest end Android devices. Achieved by the LOD bias.
4. Texture mipmapping enabled and low-quality textures on low-end devices
5. etc.

In terms of physics simulation:

1. Enabling physics (either via Unity layers or disabling/enabling Physics-only game objects from a pool) - for objects only close to the player and its controlled other objects.
2. As few RigidBodies as possible
3. etc

Thanks for your input !