Bevy Plugins

At its most fundamental level, the Foresight Development Kit uses the Bevy Engine as its underlying engine. Instead of papering over Bevy, we lean into its modularity, meaning that every plugin you build is, at its heart, a Bevy Plugin. This architectural decision gives you unrestricted access to the engine’s internals, allowing you to build everything from simple UI tweaks to entirely new rendering pipelines.

Extending the Engine

When you implement a Bevy plugin within the SDK, you are working with the engine’s core building blocks. You can define Systems to handle frame-by-frame logic, manage global Resources, or attach Components to entities in the 3D scene.

This level of access is what allows the Foresight Development Kit to be so extensible. If the high-level SDK primitives don’t quite fit your needs, you can always drop down to Bevy engine code, because application code and engine code are one and the same.

use fdk::libs::prelude::*;

pub struct MyCustomPlugin;

impl Plugin for MyCustomPlugin {
    fn build(&self, app: &mut App) {
        app.insert_resource(MyGlobalConfig::default())
           .add_event::<MyCustomEvent>()
           .add_systems(Update, my_update_system);
    }
}

fn my_update_system(config: Res<MyGlobalConfig>) {
    // This system runs alongside the core SDK systems
}

Deep Engine Customization

Because you are working with native Bevy plugins, the entire engine is your playground:

• Custom Rendering: You can implement specialized rendering logic for domain-specific data types that aren’t covered by the standard point cloud or mesh representations.
• Render Graph Modification: If your application needs custom post-processing, compute shaders, or specialized multi-pass rendering, you can extend Bevy’s render graph directly.
• Execution Timing: By adding systems to core schedules like PreUpdate or PostUpdate, you can ensure your logic runs at the exact moment required relative to the SDK’s own internal systems.

When to use Bevy vs. SDK Primitives

A common question for new developers is when to use a raw Bevy system versus an SDK-specific primitive like a Tool or a Statement.

As a general rule, use Bevy Plugins for engine-level concerns: rendering, input handling, and background processing. Use SDK Primitives for anything that involves the user: workflows, persistent state, and undo/redo.

For example, if you want to add a real-time physics simulation, that should be a Bevy Plugin. But the button the user clicks to start that simulation should be a Tool that executes a Statement.