How do I create a parallel sub‑app to compute game logic and send data to the render app from it?

[echo prism]

You can basically copy what PipelinedRenderingPlugin does (go look at the source!). TL;DR, in Plugin::cleanup, they move the entire render world into a thread, and that thread then blocks on a channel. In the RenderApp's extract function, they move the main world to the channel, the thread extracts what it needs, and then it returns the main world through another channel back to the extract function, which puts the world back. Since the render world is not off in its own thread, they don't block each other.

All that said seriously consider whether this is what you want. This kinda muddies what frame you're actually rendering. Currently, it looks more like this:

First frame
main_app    [=====]|[========]     |[====]
render_app         |[=============]|[=========]

Namely, the render app runs after the first frame. But that means in your case, your rendering will actually render an unfinished physics state for the first frame.

The other thing to note, is that generally your bottleneck is rendering so it's not clear that pipelining physics will improve things

[tame prairie]

it already works fine, i just want to sepate it, the same logic but extract data not only from main_app

its not about improving performance

[echo prism]

There is no way to extract from multiple apps at once. You can only extract from main. You'd have to copy your data from the physics world into the main world and then copy that data to the render world through its extract function

[tame prairie]

im looking for better solution

[echo prism]

Just so we're not stuck with an XY problem, why do you want to do this?

[tame prairie]

i want to store game world in sub app to controll it from main app, like saving, loading, pausing etc

[echo prism]

I would suggest using a finer grained tool. Like add a component to any entity that should be deleted when loading, etc. Using a separate world to deal with this is a VERY big hammer that is likely to make your life more difficult. But I'll put that aside

There's no reason your physics world needs to be a SubApp. Instead it could be an App that you run in a separate thread

So your main world would send the main world to the physics world to do its "fake extract", then you just manually update the physics app. Then have a system in your RenderApp extract lock a Mutex on the results of that frame

The fundamental problem here though is that in order to render frame n you need the physics data for frame n which in turn needs the main world data for frame n

[tame prairie]

why do i need to send data from main to physics? main should contain only interface, and physycs contain only game world logic and entities (like server)

[echo prism]

If you spawn a new player, they will inhabit a new physics object, so you need to send the information that a new player exists to the physics world.

Or how about, if the user presses the w key to move forward, you need to send that force to the physics system