Licensing and future of xpbd-based physics in bevy

Hi Jondolf, author of bevy_xpbd-the tutorial series here :) fun to see I inspired something and the project still goes on :)

From time to time, I've been toying with the idea of picking up and finishing my tutorial. My plan was to wrap up the friction chapter, clean up the language, and then making my own bevy_xpbd repo public and release on crates.io... which I guess I no longer have to do since you're way ahead of me :P

I'm still wondering if I should finish the tutorial itself, though, and I'm thinking about looking at your code for inspiration :) ...but I'm wondering: would you mind dual-licensing your code under Apache-2 as well? That way anything you/we make can easily be moved between the various crates in the bevy ecosystem.

Also: what's your plan for nalgebra/parry types in public API, is it going to stay or not?

Hi, thanks for the issue! I'm honored to see you reach out to me. This is also my first time doing open source collaboration, and my first ever issue :)

I think you should definitely continue working on your tutorial. I found it to be really helpful and interesting, and it could inspire others as well. Not sure about using my code for inspiration right now though haha, I'm reworking quite a few things and there are some pretty big bugs (like really unstable collisions) and things that need to be updated. Also, bevy 0.10 👀

For me, this is still primarily an experimental side project, so I can't promise to work on it actively, especially when I'm busy with school. I'll mainly try to keep up with major bevy releases and publish the crate when I've fixed major bugs (like the collisions) and added a couple more features. I'm aiming to probably release the crate during the summer.

Do you still intend to publish your own engine? Since you're its "original author", I could rename this project to something slightly different (e.g. bevy_physics_xpbd, bevy_prototype_xpbd...) if you want. I didn't mean to "steal" the name, so I'm fine changing it if you want.

Would you mind dual-licensing your code under Apache-2 as well?

Thanks for the heads-up! I added the Apache License 2.0 :)

What's your plan for nalgebra/parry types in public API, is it going to stay or not?

I haven't really worked on the public API too much yet, but I'll try to keep nalgebra and parry out of it. I'm pretty sure I don't actually use nalgebra for almost anything anymore, so I think I could remove it entirely.

Parry is currently exposed as a public module, but I will probably hide it. In the public API, parry is pretty much only needed for AABBs and collider shapes, which are already aliased under my own types and components.

I feel like you're being too humble, this project looks really promising, way tidier than my code currently is and also seems more ambitious than what I had in mind. I kind of hoped something like this project to happen eventually, but didn't expect it to happen until after I'd published my initial repo.

My initial plan was to stay razor-focused on 2D, and completely ignore 3D until I had something that had a decent API, performance and stability, then perhaps think about 3D. Also, when reading existing projects, I always feel like generalizing for n-dimension feels like a barrier both to implementation and making the code easy to understand or optimize. However, looking at your code it does look both tidy and neat, so perhaps I was mistaken :)

Besides that, my main interest is 2D games, and I had no ambitions to try to compete with bevy_rapier_3d.

I'm currently trying to put together a game, Cargo Space, not sure if you've followed the devlogs? In any case, I'm using a variant of my xpbd version in it, but with a couple of special-case hacks in it. I think there are probably too many hacks/custom solutions in it that I could realistically switch to a generalized xpbd implementation as it is, but I'd really like to collaborate, share and exchange good solutions when I find them.

One thing I've picked up from this project, is switching out the specific types BoxCollider, CircleCollider etc. and replacing it with just one collider. That was a good call, cleaned up the APIs and implementation quite a bit.

Because I need it in the game I'm working on, I will at least be actively working on some form of XPBD-based physics in the immediate future, but like you, and I guess almost all of us, I can't promise active maintainership either... but yeah, that's how it is for almost all projects ;)

As for where to go next...

First of all, I'm really happy you changed the license :) I'll look through the crate and borrow/steal more things I like for my game's XPBD implementation. When I'm more familiar with what you've done, I'll have a better understanding of how our projects differ.

Right off the bat, one place we differ is the broadphase. I'm using a simple stupid sparse grid, while you're using sweep and prune. I'd be curious to see how they compare performance-wise.

Another area I'm curious about, is determinism. I'm making a rollback-based networked game, so that means I have to take special care everything is deterministic. Not sure if this has been a goal for you? For me this involved things like sorting collision pairs etc.

I don't think it makes sense to have more than one actively worked on bevy_xpbd physics crate. It's very kind of you to offer me to take over the name, however I really think it would be best if we try to co-operate on whatever we release to crates.io or want to share with the bevy community for consumption.

If I revamp my tutorial, perhaps it makes most sense to have a bevy_xpbd_finished_tutorial or somesuch repo, and then just link to the "real-world" finished repo from there (and from the end of the series).

I'm really happy you put me in the inspiration section, though! It's things like this that makes me want to keep writing and updating my tutorials. I guess I'm really soft for recognition and kind words :)

Phew, that was quite a long post. As you can tell, I'm pretty excited about this stuff :P Anyway, if you want to, it'd be very interesting to explore this space together :)

I did take a look at your devlog (nice work btw), especially the latest one with the broad phase improvements. I opted for sweep and prune for now, because AFAIK spatial partitioning algorithms typically require the bodies to be similarly sized, and they have to make assumptions about the environment. Using a dynamic bounding volume tree is probably another alternative, but I haven't tried/understood it yet 😅

I haven't really benchmarked and compared my sweep and prune to other alternatives yet, but I'll do that when I have gotten everything to work and focus more on optimization. Also, my sweep and prune is probably suboptimal, because it only uses the x-axis, and in many cases other axes could be preferrable. I'll work on it later...

Determinism isn't something I have really thought about, and I have absolutely zero experience in networking and rollback stuff, but I'll definitely take a look at it at some point. If I understood correctly, determinism should be quite straightforward with XPBD, so it should be added eventually. You probably have more insight on the topic though :)

I'm certainly interested in working on this project in collaboration as well, so feel free to open more issues or discussions. I've barely used discord so far, but I'm on the bevy server as well if you want to ask or discuss anything :)

Are you fine with me closing this issue?

spatial partitioning algorithms typically require the bodies to be similarly sized, and they have to make assumptions about the environment

Makes sense. I guess one option would be to actually make it configurable in the plugin 🤔 ...if it turns out to be an actual bottleneck that is.

Are you fine with me closing this issue?

Alright, let's continue the discussions in separate issues :)

Jondolf / avian

Licensing and future of xpbd-based physics in bevy #1