Render & Sim World Approach

Hello. I’ve decided to try separating simulation from rendering via multiple worlds. I have an idea on how it might work but wanted to get some feedback.

I imagine that each sim entity I create would of course have no render components, they would have everything they need for the sim plus one component called, say, PresentationLink. PresentationLink would contain an int PrefabID, a reference to a render entity prefab that contains the render components plus some lerping components used to achieve the smooth 60fps look.

As the camera moves, a simulation world system would be responsible for tagging ‘visible’ entities. These would have render world doppelgangers created with Entity references to their simulation world counterparts with some system or two keeping them in sync.

The authoring workflow would typically involve sim world GameObjects and render world GameObjects.

What do you think? Is this a good path? Have any advice or see any pitfalls?

Thanks!

This must be the 5th time I’ve seen this idea come up on the forums and I don’t get why people think they need separate worlds for this?

They already built default groups for this exact purpose.

SimulationSystemGroup
PresentationSystemGroup

That run in separate phases (currently not their intended fixed vs update but should be changed back at some point once issue is resolved).

2 Likes

Same things. Why this guys want this? It’s unnecessary complication.

I didn’t realise unity was doing this already. I just remember seeing a unite talk about this possibility, looked at the entity debugger and figured all systems tick down in a row. Didn’t see it mentioned in the manual either… perhaps I missed it.

Well, that makes thing easier for sure. Cheers.

Performance.

1 Like

Which performance? It’s not give you any performance with comparsion of current groups approach. Especially when they returns sim group to fixed timestamp.

1 Like

The premise of the original post was the separation of simulation and rendering with different tick rates on the assumption that the default world had one single tick rate, as the documentation states:

  • SimulationSystemGroup (updated at the end of the Update phase of the player loop)
  • PresentationSystemGroup (updated at the end of the PreLateUpdate phase of the player loop)

Given this assumption, wanting the decoupling of rending and simulation means fewer simulation ticks can occur, while more render ticks can occur with smoothing. This allows many more entities to be processed in the simulation while still maintaining 60 FPS rendering.

tertle has stated that what I am desiring is (or will be) handled by unity by default.

When they first introduced Simultation/Presentation groups they were implemented as

However, due to issues they changed it in the next version

As far as I’m aware, they still intend to revert this back at some point.

You can read the discussion / reasoning here from the developer in charge of this : https://discussions.unity.com/t/734381/7

1 Like

If you had use forum search in this branch before post this, this topic would not even have arisen :wink:
https://discussions.unity.com/t/734381/7

Ahh beated me :slight_smile:

Thank you for your responses tertle.

I too see benefits in being able to run different system at different tick rates. For example for VR games you might run gameplay logic at 60Hz while rendering runs at 120Hz.

This can be somewhat achieved by running all systems at the highest rates and simply skipping processing some frames (early exit) on lower tickrate systems. I’ve actually done that in the past to save perf, like only ticking some particle systems at half rate.

1 Like

It’s obvious, my point was:
You not take peforance gains with other World (as OP described), in comparsion with different timestep in one World in different groups or with manual timestep manipulation. On the contrary, this is an unnecessary complication to synchronize the data necessary for rendering between worlds.

1 Like

Just out of curiosity, what is the use of separate worlds now? I believe separating the simulation from the presentation was their original purpose.

For example you can create entities in other world with ExclusiveEntityTransaction without main thread block. It’s how sub scenes streaming works in Megacity.

So it’s used primarily now for streaming data in. Like procedurally generated content, right?

Not just procedural. Sub scenes prepared before.

I used it to test both server and client at the same time inside editor

I could see other use cases of multiple worlds. In my case, I need the simulation to be deterministic, serializable and light-weight.

If I could split my presentation in a separate world, it would make my life much simpler.

  1. I don’t risk the presentation (not deterministic) breaking the simulation determinism because it only reads from it.
  2. All the non-serializable stuff like textures, meshes, audio clips don’t get mixed in with simulation entities. That makes serialization much simpler.
  3. The visual-related entities like particles are out of the simulation, keeping it light-weight. (i need my sim to be lightweight for serialization and faster copy)

Are any of you aware if splitting sim/view worlds is a viable option ? Or should I keep 1 world and try to work around my problems some other way ?

2 Likes

Different systems with different tick rates is my one and only dream with dots. @cort_of_unity Any update on when the sim groups are moved back to fixed update?

1 Like