-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix rapier debug render #224
Conversation
It's a little annoying to have to show the debug window and then click the checkbox, so this makes it easier.
Implements custom debug renderer for Rapier using Egui. This is to avoid an issue we have using Rapier's built-in debug renderer, which requires entities to be kept alive that we can't filter based on components. Fixes fishfolk#132
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to work really nicely, way easier to see as well.
Also figured out that the flashing boxes are the enemies' hitboxes, we might wanna check that.
If I'm not mistaken the flop attack staying in place is due to the refractor before right, if so seems ready to go.
Yeah we should probably create an issue for it.
Yep! Bors r+ |
224: Fix rapier debug render r=zicklag a=zicklag Fixes #132. Found out that #132 was caused by the fact that the debug lines plugin that rapier uses to manage debug rendering requires that 4 entities be kept alive to contain the debug lines. The issue is when we try to reset the world by deleting all entities other than the camera, those entities get deleted, too. And we can't filter those entities out because their distinguishing component is private. Also, there isn't a way to re-create those entities after adding the plugin. This works around the issue by implementing a custom debug lines renderer for Rapier that uses Egui to draw the lines instead. It's simple and mostly copied from rapier's plugin. Co-authored-by: Zicklag <zicklag@katharostech.com>
The last time I've tested the state PR before it was merged, the problem was the opposite - enemies were always jumping when attacking. Seems to be kind of the opposite, now 😁 |
bors cancel Oh, wait, I didn't know what you guys meant, that's weird. |
Canceled. |
I think it might be from #221 but I've got to double-check that happens on master right now. |
OK yeah, that's happening on master, so it's not from this PR. :) Bors r+ |
Don't worry it's intended (for now) |
Also re: flashing box, if I understand what you mean I'm pretty sure it's because when we spawn attacks/collision entities they don't have a Collider shape at first, till they are activated in activate hotbox system which adds the required component. Not 100% certain but it started happening when I changed it to work that way. |
Interesting. It's possible for us to filter out certain shapes that rapier gives us to debug render now that we have the custom implementation, so we could potentially filter those out if they aren't actually there. We can also add a custom debug collor to different colliders with the Another possible cause could be hierarchy flushing issues, maybe? But I think Bevy 0.8 fixed those. |
Fixes #132.
Found out that #132 was caused by the fact that the debug lines plugin that rapier uses to manage debug rendering requires that 4 entities be kept alive to contain the debug lines.
The issue is when we try to reset the world by deleting all entities other than the camera, those entities get deleted, too. And we can't filter those entities out because their distinguishing component is private. Also, there isn't a way to re-create those entities after adding the plugin.
This works around the issue by implementing a custom debug lines renderer for Rapier that uses Egui to draw the lines instead.
It's simple and mostly copied from rapier's plugin.