Decoupling app/logic loop from rendering

[dafteran4]

Hi, I'm new Bevy. I am trying to control my loop via ScheduleRunnerPlugin by setting RunMode::Loop. Which works fine. But as soon as I load RenderPlugin, this doesn't work anymore when RunMode wait is lower than vsync time. This suggests that both rendering and logic are updated in the same loop and app update is waiting for rendering to be ready for the next frame. Is there any way to decouple app loop (input, physics, logic) from rendering? It seems to me these two should be mostly independent processes - rendering running on its own pace and only interacting with app loop as necessary when ready to pick up the last state, but otherwise not blocking the app updates. Any ideas on how to go about this appreciated. Thanks.

[alice-i-cecile]

This is "pipelined rendering" :) It's a complex matter, and something that the Bevy dev team is actively pursuing. Not exactly feasible as an end user, but fingers crossed we'll have this enabled by default in the next release.

Follow the work here: #6503

[balintbarna]

I think it’s a good idea but I don’t know why it breaks the program to add a resource to a sub app. Is that normal?

[alice-i-cecile]

No, that's quite unusual. Not sure what's going on there TBH. There's a few more suggestions from Discord: a custom executor, running the simulation in an async task, making sure your rendering is fully on a separate thread.

[thebluefish]

I would wager that you're blocking the thread by trying to iter an empty channel. iter and recv both block the thread until a message is received, you probably want try_recv instead.

[balintbarna]

Right! Maybe try_iter
I’ll try it later today
I guess it doesn’t cause an issue if I don’t add the resource because the channel just gets closed

[balintbarna]

It's working:

use std::sync::{
    mpsc::{channel, Receiver, Sender},
    Arc, Mutex,
};

use bevy::{
    app::{App, Plugin, PostUpdate},
    ecs::schedule::{ExecutorKind, ScheduleLabel},
    prelude::{IntoSystemConfigs, Res, Resource, Schedule, World},
    render::{Render, RenderApp, RenderSet},
};

#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
pub struct RealTimeControl;

pub struct RealTimeSimulation;

impl Plugin for RealTimeSimulation {
    fn build(&self, app: &mut App) {
        let mut sched: Schedule = Schedule::new(RealTimeControl);
        sched.set_executor_kind(ExecutorKind::MultiThreaded);
        let (tx, rx) = channel();
        tx.send(()).unwrap();
        app.add_schedule(sched)
            .insert_resource(RenderFinishedReceiver(Arc::new(Mutex::new(rx))))
            .add_systems(PostUpdate, run_physics_while_rendering);
        app.sub_app_mut(RenderApp)
            .insert_resource(RenderFinishedSender(tx))
            .add_systems(Render, signal_render_finished.in_set(RenderSet::Cleanup));
    }
}

#[derive(Resource)]
struct RenderFinishedReceiver(Arc<Mutex<Receiver<()>>>);

fn run_physics_while_rendering(world: &mut World) {
    while world
        .resource::<RenderFinishedReceiver>()
        .0
        .lock()
        .unwrap()
        .try_iter()
        .last()
        .is_none()
    {
        world.run_schedule(RealTimeControl);
    }
}

#[derive(Resource)]
struct RenderFinishedSender(Sender<()>);

fn signal_render_finished(finished: Res<RenderFinishedSender>) {
    if finished.0.send(()).is_err() {
        log::error!("Could not send signal after render finished!")
    }
}

Thank you all for your help!

Now the problem is only that Avian - the physics engine running on the new schedule - seems to be moving extremely fast. The cube falls down instantly instead of the regular pace. I will try to figure out why that is :)