toqozz/bevy_debug_lines

A prototype plugin providing a simple line drawing api for bevy.

bevy_debug_lines's Issues

0.4.0 on crates.io

Any chance to get ver 0.4.0 uploaded to crates.io?

Line thickness parameter breaks when lines are on the same x, y plane

This is a little hard to describe and I might be misunderstanding some of it but I've written a little demo to show what I encountered.

Basically this code spawns a cube at (0.0, 0.0, 0.0) and then tries to draw 9 lines... four lines pointing up the Y axis, one line pointing up the X axis and four lines pointing up the Z axis.

This is what I get

with this code

    // vertical lines
    lines.line_colored(Vec3::new(0.0, 0.0, 0.0), Vec3::new(0.0, 5.0, 0.0),  0.01, Color::RED);
    lines.line_colored(Vec3::new(1.0, 0.0, 0.0), Vec3::new(1.0, 5.0, 0.0),  0.01, Color::RED);
    lines.line_colored(Vec3::new(2.0, 0.0, 0.0), Vec3::new(2.0, 5.0, 0.0),  0.01, Color::RED);
    lines.line_colored(Vec3::new(3.0, 0.0, 0.0), Vec3::new(3.0, 5.0, 0.0),  0.01, Color::RED);

    // one line going up the x axis
    lines.line_colored(Vec3::new(0.0, 0.0, 0.0), Vec3::new(5.0, 0.0, 0.0),  0.01, Color::RED);

    // four lines starting from different points on the 
    // x axis going from same x value but toward 5.0 z value
    lines.line_colored(Vec3::new(0.0, 0.0, 0.0), Vec3::new(0.0, 0.0, 5.0),  0.01, Color::GREEN);
    lines.line_colored(Vec3::new(1.0, 0.0, 0.0), Vec3::new(1.0, 0.0, 5.0),  0.01, Color::GREEN);
    lines.line_colored(Vec3::new(2.0, 0.0, 0.0), Vec3::new(2.1, 0.0, 5.0),  0.01, Color::GREEN);
    lines.line_colored(Vec3::new(3.0, 0.0, 0.0), Vec3::new(3.1, 0.0, 5.0),  0.01, Color::GREEN);

Note: the last two lines I could get to work by doing x values of 2.0 -> 2.1 and 3.0 -> 3.1. If I leave the X value the same (like in the first two green lines) then it doesn't show. And, I don't seem to get this issue with the other lines (the vertical lines and the X-axis line render fine despite only having the difference in one axis between start and end points)

If I change that part to this

    lines.line_colored(Vec3::new(0.0, 0.0, 0.0), Vec3::new(0.1, 0.0, 5.0),  0.01, Color::GREEN);
    lines.line_colored(Vec3::new(1.0, 0.0, 0.0), Vec3::new(1.1, 0.0, 5.0),  0.01, Color::GREEN);

then I get all four green lines

Here's the full code

use bevy::prelude::*;
use bevy_prototype_debug_lines::{ DebugLinesPlugin, DebugLines };

fn main() {
    App::build()
        .insert_resource(Msaa { samples: 4 })
        .add_plugins(DefaultPlugins)
        .add_plugin(DebugLinesPlugin)
        .add_startup_system(setup.system())
        .add_system(demo.system())
        .run();
}

fn setup(
    mut commands: Commands,
    mut meshes: ResMut<Assets<Mesh>>,
) {
    let mut transform = Transform::from_translation(Vec3::new(-2.4399414, 3.9506745, 5.9317107));
    transform.rotate(Quat::from_xyzw(-0.26216018, -0.36458296, -0.10775752, 0.88698345)); 

    commands.spawn_bundle(PerspectiveCameraBundle {
        transform,
        ..Default::default()
    });

    commands.spawn_bundle(PbrBundle {
        transform: Transform::from_translation(Vec3::new(0.0, 0.0, 0.0)),
        mesh: meshes.add(Mesh::from(shape::Cube { size: 1.0 })),
        ..Default::default()
    });
}

fn demo(mut lines: ResMut<DebugLines>) {
    // vertical lines
    lines.line_colored(Vec3::new(0.0, 0.0, 0.0), Vec3::new(0.0, 5.0, 0.0),  0.01, Color::RED);
    lines.line_colored(Vec3::new(1.0, 0.0, 0.0), Vec3::new(1.0, 5.0, 0.0),  0.01, Color::RED);
    lines.line_colored(Vec3::new(2.0, 0.0, 0.0), Vec3::new(2.0, 5.0, 0.0),  0.01, Color::RED);
    lines.line_colored(Vec3::new(3.0, 0.0, 0.0), Vec3::new(3.0, 5.0, 0.0),  0.01, Color::RED);

    // one line going up the x axis
    lines.line_colored(Vec3::new(0.0, 0.0, 0.0), Vec3::new(5.0, 0.0, 0.0),  0.01, Color::RED);

    // four lines starting from different points on the 
    // x axis going from same x value but toward 5.0 z value
    lines.line_colored(Vec3::new(0.0, 0.0, 0.0), Vec3::new(0.0, 0.0, 5.0),  0.01, Color::GREEN);
    lines.line_colored(Vec3::new(1.0, 0.0, 0.0), Vec3::new(1.0, 0.0, 5.0),  0.01, Color::GREEN);
    lines.line_colored(Vec3::new(2.0, 0.0, 0.0), Vec3::new(2.1, 0.0, 5.0),  0.01, Color::GREEN);
    lines.line_colored(Vec3::new(3.0, 0.0, 0.0), Vec3::new(3.1, 0.0, 5.0),  0.01, Color::GREEN);
}

webgl2 compatibility

Unfortunately this doesn't work with bevy_webgl2 because of the shaders' version. There is a panic on startup which is a bit difficult to trace to this library.

Feature Request: Retun handles to all spawned lines.

It'd be nice if we could get the ID of the lines spawned in, and if we could mark them with components.

Imagining a similar usage to those already in bevy's conventions:

commands.spawn((
        Line {
          start,
          stop,
          duration,
        },
        SomeMarkerStruct, // So we can use the Lines better in queries.
    )).id(); // so we can insta-get it from the ECS at anytime.
}

Perhaps similar things could be achieved by exposing more of the Components that update uses:
debug_line_meshes: Query<(&dim::MeshHandle, &DebugLinesMesh)> could maybe be cool.

I think this would be cool for multiple reasons, including (some of which aren't even what I want to use it for):

• spawn a line relative to some parent geometry i.e to maybe raycast check lines of sight for AI agents etc in games.
• Be able to control specific debug overlay systems in a way that's related to the game objects to which you want to attach them to.
• Be able to toggle on/off specific lines/groups of lines
• Be able to programmatically/conditionally update line geometry/colour on a more granular basis.

Took a look, it's probably a little beyond my comfort zone to implement myself but would love to collab if anyone who thinks this'd be easy for them wants to.

3d example is not working

subj

Current `main` branch introduces stutter

I'm experiencing stutter on my best hardware with the current main branch at 7859f9b. I was able to resolve the stutter by removing DebugLinesPlugin.

diff --git a/src/game.rs b/src/game.rs
index a910174..2cf7c20 100644
--- a/src/game.rs
+++ b/src/game.rs
@@ -224,7 +224,7 @@ pub fn update_window_dimensions(windows: Res<Windows>, mut engine_state: ResMut<
 #[doc(hidden)]
 pub fn draw_sprite_colliders(
     engine_state: Res<EngineState>,
-    mut lines: ResMut<DebugLines>,
+    //mut lines: ResMut<DebugLines>,
     sprite_query: Query<&Sprite>,
 ) {
     if !engine_state.debug_sprite_colliders {
@@ -239,7 +239,7 @@ pub fn draw_sprite_colliders(
         let mut curr = 0;
         let mut next = 1;
         while curr < length {
-            lines.line(points[curr].extend(0.0), points[next].extend(0.0), 0.0);
+            //lines.line(points[curr].extend(0.0), points[next].extend(0.0), 0.0);
             curr += 1;
             next = (next + 1) % length;
         }
@@ -306,7 +306,7 @@ impl<S: Send + Sync + 'static> Game<S> {
             .add_system(exit_on_esc_system)
             // External Plugins
             .add_plugin(AudioPlugin) // kira_bevy_audio
-            .add_plugin(DebugLinesPlugin::always_in_front()) // bevy_prototype_debug_lines, for displaying sprite colliders
+            //.add_plugin(DebugLinesPlugin::always_in_front()) // bevy_prototype_debug_lines, for displaying sprite colliders
             // Rusty Engine Plugins
             .add_plugin(AudioManagerPlugin)
             .add_plugin(KeyboardPlugin)

The weirdest part was that the stutter is in an example program which isn't using debug lines (it is literally not calling lines.line(...) from the diff above) because I've got code at the top of the function returning early and skipping the debug line drawing entirely (see code below). So I've got stutter...and the plugin ostensibly isn't even doing anything!

   if !engine_state.debug_sprite_colliders {
        return;
    }

The stutter happens randomly with an interval that feels like it's random between about 0.25s - 5s. The stutter seems to last at least a couple frames and sometimes more like a dozen.

Here's the specs for my workstation with the problem:

# I tried Rust 1.57 -- same thing
$ rustc --version
rustc 1.58.0 (02072b482 2022-01-11)

I do NOT see the problem on my laptop, which is really weird:

Steps to Reproduce

$ git clone https://github.com/CleanCut/rusty_engine.git
$ cd rusty_engine
$ git checkout choppy
$ cargo run --release --example road_race

# Use the arrow keys to avoid obstacles - observe periodic stutters on some hardware

$ git checkout smooth
$ cargo run --release --example road_race

# no stutters now - neither of these will draw any debug lines (`engine_state.debug_sprite_colliders`
  is `false` in this example)

Incompatibility with Bevy HDR camera

When attempting to use bevy 0.9 with bevy_prototype_debug_lines 0.9, I encounter the following problem:

2023-01-07T00:18:41.521676Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon Pro 560X", vendor: 0, device: 0, device_type: DiscreteGpu, driver: "", driver_info: "", backend: Metal }
2023-01-07T00:18:42.323338Z  INFO bevy_prototype_debug_lines: Loaded 2d debug lines plugin.
2023-01-07T00:18:43.174426Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default    
thread 'main' panicked at 'wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `<CommandBuffer-(0, 1, Metal)>`
    In a set_pipeline command
      note: render pipeline = `<RenderPipeline-(5, 1, Metal)>`
    Render pipeline targets are incompatible with render pass
    Incompatible color attachment: the renderpass expected [Some(Rgba16Float)] but was given [Some(Rgba8UnormSrgb)]

', /Users/xxxx/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.14.2/src/backend/direct.rs:2403:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
-[_MTLCommandEncoder dealloc]:131: failed assertion `Command encoder released without endEncoding'

I have confirmed that the issue arises from this crate as simply removing the following line alleviates the problem.

.add_plugin(DebugLinesPlugin::default())

Recreation

In order to recreate this issue, create a bevy app where a 2d camera bundle is used, alongside DebugLinesPlugin. E.g:

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugin(DebugLinesPlugin::default())
        .add_startup_system(setup)
}

fn setup() {
    commands.spawn(
        Camera2dBundle {
            camera: Camera {
                hdr: true,
                ..default()
            },
            ..default()
        }
    );
}

Another project seems to have had similar issues, perhaps this will provide direction on a fix? dimforge/bevy_rapier#288

0.5.0 compat

I am using this plugin in a project, and attempting to upgrade that project to bevy 0.5.0. It looks like the definition of a plugin has changed. I am happy to spend the time to submit a fix, if that is welcome :)

Allow choosing the `RenderLayer` which the line is drawn to

It would be beneficial to optionally be ale to set the RenderLayer which the line is drawn to beyond the default layer of 0.

This enables the lines to be part of a "debug" layer of the camera, or only appear on one camera when multiple cameras are being used which read from different layers.

shortcut for basic shape

Could be very useful to have some methods on DebugLines to create basics shape like arrow, square, circle ...

Underflow when the first line expires

Hello again,

it looks like if the first line in the list of lines reaches it's duration limit and expires, then an underflow occurs.

The underflow occurs here:

bevy_debug_lines/src/lib.rs

Line 277 in 8f7d2eb

i -= 1;

Here is a small reproduction:

use bevy::prelude::*;
use bevy_prototype_debug_lines::*;

fn main() {
    App::build()
        .insert_resource(Msaa { samples: 4 })
        .add_plugins(DefaultPlugins)
        .add_plugin(DebugLinesPlugin)
        .add_startup_system(setup.system())
        .add_system(demo.system())
        .run();
}

fn setup(mut commands: Commands) {
    let mut camera = OrthographicCameraBundle::new_2d();
    camera.transform = Transform::from_translation(Vec3::new(0.0, 0.0, 5.0));
    commands.spawn_bundle(camera);
}

#[derive(Default)]
struct Counter {
    count: i32,
}

fn demo(mut counter: Local<Counter>, mut lines: ResMut<DebugLines>) {
    if counter.count == 0 {
        // This line is the first to be added, when it expires it will cause a panic
        lines.line(Vec3::new(-400.0, 200.0, 0.0), Vec3::new(400.0, 200.0, 0.0), 0.0);
    }
    lines.line(Vec3::new(-400.0, -200.0, 0.0), Vec3::new(400.0, -200.0, 0.0), 10.0);
    counter.count += 1;
}

Update to Bevy 0.10

Seeing as Bevy 0.10 is about to be released, I thought it's time to put this in the room 🙂

Draws stale lines

Hello, looks like there is a small issue with drawing 'stale' lines.

If on frame one, three calls are made to DebugLines.lines(), then three lines are correctly drawn. Then frame two, one call is made to DebugLines.lines(), then two lines are drawn but we only expect one to be drawn.

Here's a small demonstration:

use bevy::prelude::*;
use bevy_prototype_debug_lines::*;

fn main() {
    App::build()
        .add_plugins(DefaultPlugins)
        .add_plugin(DebugLinesPlugin)
        .add_startup_system(setup.system())
        .add_system(demo.system())
        .run();
}

fn setup(mut commands: Commands) {
    let mut camera = OrthographicCameraBundle::new_2d();
    camera.transform = Transform::from_translation(Vec3::new(0.0, 0.0, 5.0));
    commands.spawn_bundle(camera);
}

#[derive(Default)]
struct Counter {
    count: i32,
}

fn demo(mut counter: Local<Counter>, mut lines: ResMut<DebugLines>) {
    if counter.count == 0 {
        lines.line(Vec3::new(-400.0, 200.0, 0.0), Vec3::new(400.0, 200.0, 0.0), 10.0);
        lines.line(Vec3::new(-400.0, 0.0, 0.0), Vec3::new(400.0, 0.0, 0.0), 10.0);
    }
    lines.line(Vec3::new(-400.0, -200.0, 0.0), Vec3::new(400.0, -200.0, 0.0), 10.0);
    counter.count += 1;
}

Looking at the shader it looks like the num_lines property of the shader is read, but nothing is being done with it. Is that correct?

https://github.com/Toqozz/bevy_debug_lines/blob/master/src/line.vert#L25

Update to Bevy 0.12

`Circle` and `Sphere` shapes are missing in crate

Allow lines to intersect with meshes

By default debug lines draws on top on everything. Is it possible to change them to intersect other meshes like any model do?

Adding a PointLight crashes the app

When I try to use this plugin with a scene with a point light it crashes.

For example, if I add a point light in the 3d example of this repo I get this error:

2022-02-20T18:57:30.397787Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'main' panicked at 'wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `<CommandBuffer-(0, 2, Vulkan)>`
    In a draw command, indexed:false indirect:false
      note: render pipeline = `shadow_pipeline`
    vertex 6 extends beyond limit 5 imposed by the buffer in slot 0. Did you bind the correct `Vertex` step-rate vertex buffer?

I don't get this error if I don't spawn a point light.

I tried it with bevy 0.6 and the latest bevy main and the bevy-main branch of this repo. This is on windows 10.

Help needed: How to disable debug line display in a simplest way?

New to bevy, I have a question on how to disable this tool. It seems that I cannot just simplify comment out the plugin.

So apart from comment out every lines.line, do I have other choice?

Feature request: Toggle rendering

Thanks for the plugin, really useful!

It would be sweet if there was some way to disable rendering of debug lines, so one could toggle them with a hotkey, e.g.

fn toggle_debug_lines(mut debug_lines_context: ResMut<DebugLinesContext>, input: Res<Input<KeyCode>>) {
  if input.just_pressed(KeyCode.F1) {
    debug_lines_context.enabled = !debug_linex_context.enabled;
  }
}

Lines are always behind sprites in a 2d scene

Given a 2d orthographic camera and some SpriteBundles, debug lines will never appear in front of the sprites no matter what Z value is used for either. I'm not sure if this is intentional but it also happens when with_depth_test is enabled.

bevy v0.7.0
bevy_debug_lines v0.7.1
rustc v1.59.0

Lines are not rendered after upgrade to bevy 0.11

Running simple d2 example renders only empty window. Logs from Ubuntu 22:

cargo run --example 2d --features="example_deps_2d"
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/examples/2d`
2023-07-16T16:31:03.566207Z  INFO bevy_winit::system: Creating new window "Bevy App" (0v0)
2023-07-16T16:31:03.566395Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1    
2023-07-16T16:31:03.660259Z  INFO bevy_prototype_debug_lines: Loaded 2d debug lines plugin.
2023-07-16T16:31:03.757177Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce GTX 1650", vendor: 4318, device: 7946, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "525.125.06", backend: Vulkan }
Cleaning up debug lines plugin.
2023-07-16T16:31:03.908934Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux 22.04 Ubuntu", kernel: "5.19.0-46-generic", cpu: "AMD Ryzen 5 3600 6-Core Processor", core_count: "6", memory: "15.5 GiB" }

Everything works fine after checkout to 3276dff Fix texture format on HDR for 3d (#40)

The same behavior on the same machine under Windows 10.

Consider using additive `2d` and `3d` features

Hi-

I struggled with the same issue when Bevy changed its renderer, to ensure both 2D and 3D could be used for bevy_hanabi. Initially the code had some 2d and 3d features, but they were mutually exclusive, which is equivalent to what you have now in bevy_debug_lines with a feature and its opposite.

For bevy_hanabi this caused a number of issues:

• By default users have to choose, even before they know anything about the crate. This is not nice.
  • If you set a default, like you did here with 3d, then this hinders discoverability; users might miss that feature flag and end up not being able to use the crate in 2D and get confused, and either log an issue or eventually abandon and consider the crate is broken.
• Obviously, with that setup you cannot use both 2D and 3D. This was already a problem for bevy_hanabi with particles, but for bevy_debug_lines that seems like an even harsher limitation, as games/apps commonly have a mix of 2D and 3D, and you don't want to find yourself having to choose which one you can line-debug and which one you cannot.
• Having a mandatory feature doesn't play nice with some tooling like cargo test or code coverage. Being able to use --all-features on the other hand, and covering all codepaths that way, is quite handy.
  • Related, but more minor, is the fact the official Rust guideline for features is to be strictly additive. So in theory having some codepath activated by the absence of the 3d feature is breaking that rule. I know many crates break it anyway, and in particular no_std breaks that idiom, but cargo and other tools are working under that assumption of features being strictly additive, and sometimes things break if that's not the case.

Eventually the solution was to support both 2d and 3d features additively, each plugging into the appropriate renderer (see here for details). I think that's a nicer approach, and it's not that much more complicated to implement.

Thanks!

Provide a Way to Re-Initialize Debug Lines?

I have a use-case where I want to reset my whole world. I do this by deleting all entities other than the Camera. The issue is that it also deletes the debug lines meshes.

I could filter out the debug lines meshes from my query for all entities to delete, but DebugLinesMesh is the only defining component, and it's not public.

Alternatively I could delete all entities and have a way to re-initialize debug lines, but the setup system is private, too.