#Avian Physics

1 messages · Page 4 of 1

vestal minnow
#

yeah

#

but in general just striving for unified APIs and nativeness, like in this case using Time instead of completely separate resources just for physics

cinder summit
#

Honestly using Time seems like the right call ... I'm definitely gonna do that refactor once I migrate to 0.12 😂

#

These constants get used everywhere troughout my code, and it's pretty messy

/// The desired time between ticks
pub const TIMESTEP: f32 = 1.0 / 60.0;
/// The time between ticks but in nano seconds
pub const TIMESTEP_NANO: u64 = 1_000_000_000 / 60;
#

Luckily they live in a separate crate so it doesn't create dep cycles

vestal minnow
#

I like the missing_docs warning there

cinder summit
#

Gotta make sure the 4 types in this crate are documented 😂

vestal minnow
#

Also 0.12 uses a fixed timestep of 64 Hz to avoid a refresh rate pitfall and to have a lossless conversion into f32/f64, so idk if physics should also use it

#

I changed the default for bevy_xpbd to match it but I don't know how useful it is in our case

cinder summit
#

TIMESTEP and TIMESTEP_NANO aren't actually the same value, but they're fairly close, but if you convert between them it becomes less close

cinder summit
#

Bevy doesn't have interpolation but I suspect Joy has plans for that, since I've heard a lot of mentions of not wanting workarounds that would merely hide the lack of interpolation

vestal minnow
#

yeah that'd be nice

cinder summit
#

I think it's fixed now but I remember godot defaulting to 50FPS physics

vestal minnow
cinder summit
#

And it gets worse too, because you might need to raycast on those interpolated entities 😂

#

Tho tbf that sounds like a GPU picking problem ...

vestal minnow
#

it's on main yeah, not in 0.2

cinder summit
#

Everything is on main 😂

vestal minnow
#

Ask me anything, main is the answer

cinder summit
#

Tho tbh there's no real reason not to use main, other than docs.rs being useless

cinder summit
vestal minnow
#

Ummm...

cinder summit
#

main in my game's repo 😂

vestal minnow
cinder summit
#

Watch as bevy_xpbd 0.3 releases with my SDF collisions

vestal minnow
#

I could've released for bevy 0.11 but I don't want to do a massive 0.3 and then a tiny 0.4 right after

cinder summit
#

Luckily bevy_xpbd main is still 0.11

vestal minnow
#
  • 0.12 was supposed to be released over a week ago
#

no, that'd be breaking

#

semver

#

mainly the Time thing and maybe updating the character controller examples to handle movement in PhysicsSchedule, and proper release notes and the blog post

#

and maybe a migration guide for once, if I can remember what needs to be migrated

cinder summit
#

And you only have until this weekend 💀

vestal minnow
#

I'm also going to a nuclear power plant for a school trip on thursday

cinder summit
#

Sounds less intimidating that migrating a whole game to sdf collisions before 0.12 tho ... I mean it's not like I need to migrate to 0.12 on day 1 ... But who else is gonna migrate a dead UI library to 0.12 when the 0.11 PR didn't even get merged? ferris_sob

cinder summit
vestal minnow
#

Some explosive contacts

#

An hour ago I thought Bevy 0.12 somehow made the contact stability issues reappear since the cubes example was drifty/jittery again, got some severe ptsd from that

#

but turns out I had changed the cubes example to trigger velocity changes every frame which makes sleeping not work correctly

cinder summit
#

Understandable, I'm already getting PTSD every time I think of how to construct an SDF for my dungeons and realize they would be bound ferris_sob

vestal minnow
#

you had that link ready lmao

cinder summit
#

I have it bookmarked

#

I've only been struggling with this issue a few days, ever since I realized that the reason spheres sometimes float is because my test SDF is wrong

#

But now every time I think of an SDF I realize it's bound

#

Bevy doesn't have anything SDF built in I think

#

My game uses kayak_ui which has msdf fonts, and my sdf collisions ... That's not enough tho ...

#

Sadly I also need to define my own logic for all primitives, even tho they could easily be shared with other things ... primitives shapes when

vestal minnow
#

sdf text with sdf collisions and physics

vestal minnow
cinder summit
#

The button will then do whatever the letters spell out

#

Collisions with letters might actually be somewhat possible if I implement support for arcs and the font is rounded 🤔

#

Or just figure out the math for true SDFs of each character in the font ferris_spooky

vestal minnow
#

Wow, I just noticed that this became the crate-help thread with the most comments today or yesterday

image.png
#

even though half of the questions seem to be in #math-and-physics :p

cinder summit
#

I mean bevy_xpbd is one of the most important bevy plugins

vestal minnow
#

replace #math-and-physics with a bevy_xpbd channel lmao

#

makes sense

cinder summit
#

There is no rapier. Only xpbd

#

Honestly I'm not even sure who's telling all the beginners to use rapier thonk

vestal minnow
#

probably me lmao

#

gizmos might have a one frame delay yeah

cinder summit
#

I looked into it a while ago ... And I'm not sure if the gizmos have a delay ... The main thing you notice it with on xpbd is the aabbs

#

But that's because the aabbs are from before physics runs

vestal minnow
#

idk it seems weirdly big in that video

#

yeah I think colliders should work but AABBs are delayed

cinder summit
#

I mean technically the AABBs are correct they just show you weird data ... Like "Here's the swept aabb for the latest physics update"

vestal minnow
#

I don't want to convert people personally at least 😂 feels kinda weird considering I'm the author (along with Johan, kinda the original creator)

#

and rapier is still better for some people

cinder summit
#

We already have a lot more users than back in the 0.1 days at least 🤔

#

I remember when I switch to xpbd ... So many bugs ... But now almost all issues I have in my game are caused by parry

vestal minnow
#

yeah I feel like 0.3 is the first release where I feel comfortable recommending it to people unless they need specific features that are missing

#

0.1 and 0.2 were too buggy and filled with caveats

#

also I'm really proud of the 0.3 docs for the most part

#

code example coverage is pretty great

#
  • much better crate-level docs
cinder summit
#

Now we just need a BVH-accelerated broadphase so it also performs well ... At least I can start testing my BVH once I migrate my game to SDFs 🤔

#

Performs well with many colliders*

#

Because with a low number of colliders rapier has a ton more overheaad

vestal minnow
#

At some point I might also make a lot more components optional, like a static body doesn't need any mass properties, velocity or forces, so we could just not insert them automatically

#

main caveat is that queries can be a bit more annoying

#

but for an ECS and its composable nature I think it makes sense to not have a bunch of unnecessary components, because at that point it resembles a fixed RigidBody object or something

cinder summit
#

Not adding components you don't need sounds like general good practice

peak marsh
#

I wanna ask: are deltas necessary (for movement, etc.)? I'm looking through the examples, but it looks like some examples use it but some don't. I'm also having a weird bug where the character gets launched at light speed when the startup is a bit laggy (I'm guessing the delta was too high).

cinder summit
#

It depends on what you are using. If you overwrite velocity you don't need to set deltas. If you're applying a force you probably want to multiply it by the fraction of a second it was active for

peak marsh
#

I see, I guess I misassumed that this is not necessary for bevy for some reason thonk . Also, what's the apply_deferred system for? I saw it being used in the kinematic controller, but I'm not sure what it's for.

cinder summit
#

apply_deferred executes anything spawned with Commands, might be necessary when you add components or spawn resources

vestal minnow
#

apply_deferred applies command buffers. In that example it makes the Grounded updates work since they're needed during the same frame

#

I could've made Grounded contain a boolean which wouldn't require commands, but making it a marker component allows nice query filter stuff

peak marsh
#

Ah, that makes sense! Without the buffer, the Grounded status will only be reflected in the next frame right?

vestal minnow
#

yes

cinder summit
#

Rather than next frame, it'll apply after whenever the next one is scheduled, probably whenever the next schedule runs, which is most likely not where the code runs

#

Run the character controller in Last thonk

vestal minnow
#

yeah that's a more accurate description

#

PhysicsSchedule also has some apply_deferreds

vestal minnow
# peak marsh I wanna ask: are deltas necessary (for movement, etc.)? I'm looking through the ...

I'm not an expert on this, but in general, if you're doing a continuous operation in a non-fixed update schedule, you should multiply by delta time, but for instantaneous operations it's not required. Multiplying by delta time can help make things less dependent on frame rate, as e.g. Update has a variable timestep.

Use delta time for these:

// Move continuously over time
position += velocity * delta_time;
// Accelerate continuously
velocity += acceleration * delta_time;

For these, it's not required:

// Apply a single "explosion" once (e.g. jumps)
velocity += impulse;
// Set velocity to a specific value
velocity = target_velocity;

This is also a pretty good answer: https://stackoverflow.com/a/63604204

#

In PhysicsSchedule with a fixed timestep, delta time isn't required for being independent of frame rate, but still recommended so that units might make more sense

#

And with the time unification thing I'm doing, you can have a system use Time and have it work both in Update and PhysicsSchedule (and other schedules)

vestal minnow
#

delta time confusion is very common (for me as well)

cinder summit
peak marsh
#

Thanks for the explanation! I'll start using delta times then.

#

I also have a weird problem with the camera being jittery when following the player. Trying to record it, but screen recording is basically broken on NixOS right now 😭. Is there an appropriate schedule for a camera system like this? Right now I'm just chaining it after the movement code.

vestal minnow
#

It should be

.add_systems(
    PostUpdate,
    camera_follow
        .after(PhysicsSet::Sync)
        .before(TransformSystems::TransformPropagate)
)
#

but for some people that doesn't seem to fix it completely

#

and opt-level = 3 seems to cause camera jitter for some people (like me) for some reason

peak marsh
#

HOLY, that works perfectly for me (so far). The quirk has been haunting me all night yesterday, thanks for the laser-precision fix 😂 .

vestal minnow
#

Cool that it works in your case, it's weird though how I've suddenly had like 6 people ask this in the last few days even though it has always been a thing 😂

peak marsh
#

The weirdest thing about the bug is that it makes it looks like that the object being followed is the thing jittering (relative to the environment). It really drove me crazy and had me questioning things...

vestal minnow
#

yeah it's a very cursed issue

#

it's probably not even that visible in the video

peak marsh
#

Yeah, I'm not seeing the jitter in the video thonk

cinder summit
#

I know people in my game used to have a lot of jitter at >60FPS

#

Which I never test because uh ... I don't think I have good excuses for that tbh 😂

vestal minnow
#

Interestingly enough, the jitter is caused by using 64 Hz 🤔 I get the same behavior with 64 Hz even in Bevy 0.11, but the old default of 60 Hz is fine

cinder summit
#

Is that 60Hz refresh with 64Hz tickrate?

vestal minnow
#

under 60 Hz seems fine, but the range 60 Hz < time < 70 Hz is jittery

#

yes

cinder summit
#

I think it's because it is jittery. Some frames do multiple updates, but the timeframe is long enough that it is still very noticable

vestal minnow
cinder summit
#

With 64Hz you get 1 refresh with 2 physics updates every 0.25s

#

2 physics updates means everything moves twice as fast for that frame, which would look like jitter ... It also happens on 60 if you get that cursed 0 2 0 2 pattern

vestal minnow
#

yeah that'd match with the visual jitter frequency at least

cinder summit
#

<60 would probably end up looking like it occasionally drops a frame, which is less noticable because we're more used to seeing that

vestal minnow
#

I guess I'll keep 60 Hz as default?

#

idk it seems weird

#

you'd think 64 Hz works since it's the new default in 0.12

cinder summit
#

In many ways 64Hz just makes an issue 60Hz had more obvious

vestal minnow
#

yeah I tested, with 60 Hz it's pretty much always running once a frame, but with 64 Hz there's a second run every 0.25 seconds

cinder summit
#

With 60Hz you need a slightly unstable framerate (which it always is to some extent) and it aligning to the exact right accumulated time, and suddenly it looks like 30FPS (still less noticable than 4 jitters per second tho)

#

The more frequent the jitters are the easier it is to not notice them, and they would also only be 1/70th of a second of motion instead of 1/60th for example

#

I wonder if we have the components necessary to do interpolation in SyncPlugin 🤔

#

Since we just want Transform to be somewhere between the current and last update

royal helm
#

@vestal minnow do you have any apply_deferred in xpbd?

cinder summit
#

There's 4 in just PhysicsSet::Prepare for example

#

I think Prepare should be the main one tho, since that's where missing components get added

pulsar bone
#

There seem to be 4 instances of transform propagation as well 😅

vestal minnow
#

yeah, let's not talk about that...

#

supporting user-made changes to Transform is a pain

cinder summit
#

If only more people used Position/Rotation directly thonk

vestal minnow
#

imo that doesn't feel native so I generally recommend Transform, but it'd be nice to have a better approach

cinder summit
#

4 transform propagations seems excessive tho 🤔

#

the transform propagation can't take up frametime if there are no entities with Transform or GlobalTransform

vestal minnow
# cinder summit 4 transform propagations seems excessive tho 🤔
  1. Run propagation for changes made between end of last frame and start of the schedule physics is run in
  2. Run propagation in PhysicsSet::Prepare to make sure initial positions are correct, but only if new bodies/colliders have been added
    3 and 4. Run propagation for changes made during PhysicsSchedule, before and after applying Position and Rotation to transforms
vestal minnow
cinder summit
#

Isn't 4 unnecessary because PostUpdate already propagates those transforms to global transform?

vestal minnow
#

there's a questionable update_previous_global_transforms system that requires up-to-date transforms... but maybe that could run in Last

cinder summit
#

Could even schedule it right after the propagation in PostUpdate

vestal minnow
#

yeah, that

cinder summit
#

I'm also not sure if I understand 2 ... Aren't they already propagated from 1? 🤔

vestal minnow
#

I put those in the wrong order actually, 1 runs after Prepare but before StepSimulation

cinder summit
#

What does the simulation use Transform/GlobalTransform for? 🤔

vestal minnow
#

just user API for reading/writing to Position/Rotation, and also for child colliders and collider scale

cinder summit
#

Ah for people scheduling stuff inside PhysicsSchedule?

vestal minnow
#

people can use Transform basically anywhere, except in the SubstepSchedule it's not up to date

cinder summit
#

Yea that sounds pretty cursed ... Treating Transform like a rendering component feels so much simpler 😂

#

If there's interpolation Transform would also just be straight up wrong most of the time, so it would make sense to use Position/Rotation as simulation coordinates, and Tranform as a purely graphical thing

vestal minnow
#

yeah but using Position/Rotation in projects just feels wrong to me unless touching engine internals

cinder summit
#

Yea the real issue here is that bevy just gives us Transform ... Which is probably exactly because bevy doesn't have any physics ... Transform isn't designed for physics ... Having Scale in there is especially cursed

vestal minnow
#

like if you use Unity, Unreal or Godot, you'd just change the transform/basis, there is no separate "physics transform" afaik

#

if people change transform and nothing happens, they'd be confused

cinder summit
#

The whole Transform situation in bevy is generally not ideal ... GlobalTransform also sounds like a normal component you should use

#

But that always leads to problems ... And I'm not sure if Scale on Transform behaves as I'd expect (I never use it with hierarchies tho, so idk)

vestal minnow
#

I'm pretty sure it causes shear in nested hierarchies where parents are rotated

#

at least I noticed it with child colliders since the meshes become warped and the colliders no longer match them

#

I could eventually also revisit #16 experimentally to try and see if there's any way to make transforms viable for use in physics directly, but idk if that would just be more cursed than our separate components, and we'd also lose stuff like f64 support (but idk if official bevy_physics would care about that)

#

also Transform2d would be required

cinder summit
vestal minnow
#

allowing shear for colliders is interesting, idk how gjk/epa works with that

cinder summit
vestal minnow
#

The SyncPlugin is just probably the biggest code smell right now imo so it'd be nice to find some way to make it cleaner/redundant

cinder summit
vestal minnow
#

eh, more like 150-200 lines of actual code

cinder summit
#

I mean just the SyncPlugin is probably not that concerning to touch

#

But there's propagations scattered in different places too

vestal minnow
#

the logic and scheduling intricasies required to make it work just break my brain

cinder summit
#

In theory if you just rotate and scale points by a chain of their parent's transforms you'd still end up with valid points ... But the way it's accumulated in GlobalTransform might introduce some issues

pulsar bone
#

iirc if you have a non uniformly scaled parent and a rotated child you get shearing

vestal minnow
#

Yep

#

I can see if I have an image or repro in a bit

lavish laurel
#

@cinder summit What even are the odds of FixedUpdate falling out of sync when it's running at the same rate as the refresh? I kinda need physics to be fixed but I really don't wanna deal with stutter. As of right now I have it fixed at 120hz which looks perfectly fine testing at 30/60/120/240/uncapped, can't really tell if there are any skips. I understand why for pure simulation it makes more sense to have a finite float, but in practice is it a real issue (or more so than having consistent stutter)?

#

Maybe until we get real interpolation I can just add another fixed schedule that's used for noticeable parts of the game like transforms/physics that runs at a multiple of 30

cinder summit
# lavish laurel <@409485472390316033> What even are the odds of `FixedUpdate` falling out of syn...

The higher the tickrate is the harder it is to notice ... If you have 60 tickrate at 60FPS it works fine most of the time, but once it goes wrong it will just keep doing that for quite a long time ... There's some ugly hacks to work around the issue, but a real solution definitely requires interpolation (and possibly making more time for FixedUpdate, tho that seems to be something only Godot has experimented with)

#

The main thing that makes it obvious is actually the event issues with FixedUpdate, telling 30 and 60FPS apart when the camera still moves smoothly and animations play like normal is pretty hard

#

64 is a tickrate that just perfectly highlights the issue non-stop. It happens often enough that it doesn't seem like a small glitch, and the tickrate is low enough that the jumps are still fairly big

#

If you had animations, camera movement, and camera smoothing that play independant of tickrate it wouldn't be as noticable. But most games that use 64tickrate are online games and they always have interpolation (for more reasons than just physics)

lavish laurel
#

@cinder summit Thanks, I see. I do have camera movement/smoothing that's independent so maybe that's part of why I don't notice it, though it sounds like it doesn't correct itself when it goes out of sync... The other day I was curious about that so I let the game run for a few hours and it was still fine when I got back, so beats me haha

#

Maybe I should just bite the bullet and figure out how to make my game work with delta lol

cinder summit
#

If it goes out of sync it will probably eventually drift back

#

Working with delta isn't really a solution either, since then you just get incorrect physics

royal helm
#

well, I'm just going to look at implementing a simple move_shape kind of thing

#

either that or just modify wanderlust to be incredibly aggressive with its stopping/starting

lavish laurel
#

That's ignoring delta but you get what I mean

cinder summit
#

Well the main thing is you want to use delta, but the delta should be the fixed amount of your physics

#

Games like dark souls have the fun issue where the physics are tied to FPS, and I think some things do multiply by delta, but then others just assume it's the capped FPS

#

Which causes it to not quite speed up as intended, but also break in stupid ways

lavish laurel
#

Right, so in that case do they implement things like interpolation for their transforms? Or just by virtue of having both a fixed framerate and logic being executed per-frame, if it goes out of sync it goes out of sync together so it's not really jarring?

cinder summit
#

I think the main reason many console ports have these issues it because their physics don't run on a separate cycle, it avoids needing interpolation, which means slightly less visual latency and no weird alignment issues

#

With that approach if you drop down from 30FPS to 20FPS, the game just moves at 2/3rd the speed

#

Similarly if someone mods the FPS cap from 30 FPS to 120FPS it now moves 4x as fast

lavish laurel
#

Isn't that essentially the same as just using Time and not multiplying by delta?

cinder summit
#

If you make your forces smaller and don't multiply by delta when you should, you get roughly that behavior yea

#

xpbd does internally use the delta for some things, so presumably things would still behave differently if FPS changes

lavish laurel
cinder summit
#

With 0.12's unified Time you pretty much always want to multiply constant changes by Time.delta_seconds(). Since that time will automatically be FixedUpdate's period in FixedUpdate, and there is a PR to have the same with xpbd's loop in the 0.12 migration

#

It's kind of funny how devs rarely notice these issues during development ... If your game runs decently, disabling vsync would result in obvious changes if you didn't use delta correctly, or anything uses the wrong delta

lavish laurel
lavish laurel
vestal minnow
#

I feel like I could also get rid of PhysicsTimescale and PhysicsLoop with Time<Physics> 🤔 Then we would have just a single resource for managing all of the simulation scheduling and timing logic since it's all related anyway

#

You could have the relative speed (time scale) in Physics itself, similarly to Virtual, and same for pausing/resuming

#

or maybe it'd be better to have Virtual control Physics, but then you wouldn't be able to e.g. pause physics independently of Time<Virtual> which might be annoying

#

All in all, Time<Physics> might replace 4 resources while also making things more unified, logical and schedule-agnostic :P
I'm really enjoying the time rework

#

it'll also make scheduling docs more grouped together which is nice

pulsar bone
cinder summit
#

excluded_entities is an alloc type so I don't think so ... Tho tbh that's something that should probably be fixed 🤔

#

I'm also not sure if HashSet really makes sense when it's almost always empty

#

Or well 1 item I guess 🤔

#

Something like a SmallVec might also work up to the defined capacity 🤔

royal helm
#

I don't understand how it could be const, const are methods that are precomputed at compile time essentially, you can't do that with a physics sim that has inputs from a player, etc.

royal helm
#

I think HashSets are fine, sure it's an alloc, but usability of the method is worthwhile here

cinder summit
royal helm
#

HashSet::new doesn't alloc, similar to Vec::new I'm pretty sure

#

so if you don't insert it isn't allocing

cinder summit
#

Doesn't help if you fill it with exactly 1 entity tho, which is pretty common .... Wouldn't want a cast to find a player to find the player that activated it

#

Ideally you'd be able to either reuse a collection you already have or pass in [Entity; 1], not sure if it would be possible to impement the necessary generics here tho 🤔

royal helm
#

I don't know if that matters much, shapecasting isn't cheap

#

this alloc is an order of magnitude lower than everything else

#

you could make it take a impl Iterator<Item = Entity> I guess

#

but that would need to be collected

#

or some form of preprocessing otherwise it can't be reused internally

cinder summit
#

You'd need to take an impl of some trait that gives you .contains(&Entity)

royal helm
#

sure that'd be fine

#

I'd just frame this as a usability thing rather than performance

#

the performance of an alloc isn't going to be noticeable with a shapecast

cinder summit
#

It's definitely a usability thing, since you can get around the performance penalty by reusing the HashSet ... Which would probably make for some very messy code

#

And besides shapecasts there are also cheaper things, raycasating into the void is cheap, shape intersections with no overlapping AABBs is also cheap

#

Both could be cheap when you just have a small number of primitives too, tho parry's dynamic dispatch and potential qbvh bugs might mess with that math a bit

#

My BVH was subtly broken yesterday and that makes it really clear how much of a performance hit that can cause (and incorrect results)

junior flower
merry tide
#

Hey, guys! Thanks so much for the help last time. Is there an example of making more complex shapes, like the ones Lyon tesselates, and have it work with XPBD? I am thinking ideally bezier curves. If it doesn't need tesselation that is also obviously fine.

#

I am trying to make levels, and I don't want to go down the LDTk-route, but perhaps rather import some SVGs.

vestal minnow
#

but you can't have infinite precision like what SVG paths have, it has to be an approximation of the shape (like a polyline)

#

if it's a filled object without concavity (holes etc.) then you could also create a convex hull collider

rare eagle
#

Hi, I've been trying to get xpbd working with LDTK.

use bevy_inspector_egui::quick::WorldInspectorPlugin;
use bevy_xpbd_2d::prelude::*;

const PLAYER_SPEED: f32 = 128.0; // pixels per second

fn main() {
    App::new()
        .add_plugins(
            DefaultPlugins.set(ImagePlugin::default_nearest()), // prevents blurry sprites
        )
        .add_plugins(LdtkPlugin)
        .add_systems(Startup, setup)
        .insert_resource(LevelSelection::Uid(0))
        .add_plugins(WorldInspectorPlugin::new())
        .register_ldtk_int_cell::<WallBundle>(1)
        .register_ldtk_entity::<PlayerBundle>("Player_Start")
        .add_plugins(PhysicsPlugins::default())
        .add_systems(Update, handle_player_movement)
        .run();
}

fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
    commands.spawn(Camera2dBundle {
        transform: Transform::from_xyz(100.0, 100.0, 0.0),
        ..default()
    });

    commands.spawn(LdtkWorldBundle {
        ldtk_handle: asset_server.load("my_project.ldtk"),
        transform: Transform::from_scale(Vec3::splat(3.0)),
        ..Default::default()
    });
}

#[derive(Default, Bundle, LdtkEntity)]
struct ColliderBundle {
    collider: Collider,
    rigid_body: RigidBody,
}

impl From<&EntityInstance> for ColliderBundle {
    fn from(entity: &EntityInstance) -> Self {
        match entity.identifier.as_ref() {
            "Player_Start" => Self {
                collider: Collider::cuboid(8., 8.),
                rigid_body: RigidBody::Static,
            },
            _ => Self::default(),
        }
    }
}

#[derive(Default, Component)]
struct Player;

#[derive(Default, Bundle, LdtkEntity)]
pub struct PlayerBundle {
    #[sprite_sheet_bundle]
    sprite_bundle: SpriteSheetBundle,
    #[from_entity_instance]
    collider_bundle: ColliderBundle,
    #[worldly]
    worldy: Worldly,
    player: Player,
}

fn handle_player_movement(){...}

#[derive(Bundle, LdtkIntCell)]
pub struct WallBundle {
    #[from_int_grid_cell]
    collider_bundle: ColliderBundle,
}

impl From<IntGridCell> for ColliderBundle {
    fn from(int_grid_cell: IntGridCell) -> Self {
        match int_grid_cell.value {
            1 => Self {
                collider: Collider::cuboid(8., 8.),
                rigid_body: RigidBody::Static,
            },
            _ => Self::default(),
        }
    }
}

Whenever I use the physics bundle it keeps moving my player sprite from where I set them up in LDTK to the world origin. I guess the issue is that the position is being set afterwards, but it isn't respecting the transform that the LDTK importer sets. Has anyone had this issue before and found a solution?

vestal minnow
rare eagle
peak marsh
#

I'm having a weird issue where a kinematic character isn't jumping when you linear_velocity.y = jump_impulse.0;. I know that it's applied correctly because I had a debug print right before it. It usually happens when the player is currently moving on the X axis. Anyone know what could be causing this?

peak marsh
#

Yep, I can reproduce this with basic_kinematic_character too. Make the ground bigger like this:

    commands.spawn((
        PbrBundle {
            mesh: meshes.add(Mesh::from(shape::Plane::from_size(80.0))),
            material: materials.add(Color::rgb(0.3, 0.5, 0.3).into()),
            ..default()
        },
        RigidBody::Static,
        Collider::cuboid(80.0, 0.005, 80.0),
    ));

Then, try to run in a straight line for as long as you can before jumping. Sometimes, the character simply won't jump

merry tide
gentle steppe
#

Which version are you using? 0.2 has a lot of bugs similar to this that are fixed in the github version

#

@peak marsh ^

peak marsh
#

Using the latest main.

gentle steppe
#

ah

vestal minnow
#

My guess is that the KCC example is setting the vertical velocity to zero when grounded, and if you're moving in a certain way then it might think you're grounded even when jumping

#

I'm on my phone rn but I can test in about half an hour

vestal minnow
#

but my guess would be this y = 0 in apply_gravity

        // Reset vertical velocity if grounded, otherwise apply gravity
        if is_grounded {
            linear_velocity.y = 0.0;
        } else {
            linear_velocity.0 += gravity.0 * delta_time;
        }
#

it could maybe have a timer where it can't reset the velocity for e.g. 0.1 seconds after jumping

#

or remove Grounded on jump

gentle steppe
#

Yeah, I personally prefer to remove gravity during the ascent part of the jump. I noticed unreal's character controller has a toggle for this behavior. If you keep applying gravity during a jump the feel will be more like having a jetpack, in my experience.

peak marsh
#

Tried removing Grounded on jump but it still won't work.

peak marsh
vestal minnow
#

yes

peak marsh
#

So weird...

#

Is there a way to debug what's going on with velocity values behind the scenes?

vestal minnow
#

okay I managed to repro the issue twice now, the jumps had to be timed with these weird jitters

peak marsh
#

Oh nice!

#

Thought I'm going crazy

vestal minnow
#

this has other issues, but does this work?

        if is_grounded && linear_velocity.y < 0.0 {
            linear_velocity.y = 0.0;
        } else {
            linear_velocity.0 += gravity.0 * delta_time;
        }
peak marsh
#

Interesting, it seems to fixes it!

vestal minnow
#

yep, so it is in fact that y = 0

#

this just makes the ground collision kinda floaty

peak marsh
#

Never mind, sorry. I think I can reproduce it again...

#

It's feels really inconsistent tbh...

#

I feel like it's harder to reproduce it now. This is vague, but I think the jump sometimes fails when there's a lag.

#

Yeah, I pretty much can't reproduce it anymore, so adding it definitely helps. It happens like a couple of times when my CPU gets busy, but I can't see it anymore.

vestal minnow
#

I'll try with a jump timer, should be more robust probably

vestal minnow
#

Actually this might work too, although it's somewhat questionable

fn update_grounded(
    mut commands: Commands,
    mut query: Query<(Entity, &ShapeHits, &CollidingEntities), With<CharacterController>>,
) {
    for (entity, hits, colliding) in &mut query {
        let touching_ground = hits.iter().any(|hit| colliding.contains(&hit.entity));
        if touching_ground {
            commands.entity(entity).insert(Grounded);
        } else {
            commands.entity(entity).remove::<Grounded>();
        }
    }
}
#

this adds Grounded only if the character is actually touching the ground, not just if the shape caster is close enough

#

also seems to make the jitters less frequent for me

peak marsh
#

Nice, it seems to work great! This seems like a more robust approach, though it does feel a bit awkward.

vestal minnow
#

I might make Grounded contain the distance from the ground. This way, things like jumps can work even if the player is close enough but not quite touching the ground, but gravity can require a distance of 0

peak marsh
#

Actually, with just the update_grounded fix, I can still experience the issue. I need to also add the && linear_velocity.y < 0.0 to apply_gravity. Is this expected?

vestal minnow
#

No, that's weird...

peak marsh
#

Yeah, I can reproduce it with basic_kinematic_character too. It looks like the update_grounded fix alone isn't enough...

vestal minnow
#

Okay iteration number 56, you could try this apply_gravity

fn apply_gravity(
    time: Res<Time>,
    mut controllers: Query<(&ControllerGravity, &mut LinearVelocity)>,
) {
    // Precision is adjusted so that the example works with
    // both the `f32` and `f64` features. Otherwise you don't need this.
    let delta_time = time.delta_seconds_f64().adjust_precision();

    for (gravity, mut linear_velocity) in &mut controllers {
        linear_velocity.0 += gravity.0 * delta_time;
    }
}
#

and this kinematic_character_collisions

fn kinematic_controller_collisions(
    collisions: Res<Collisions>,
    mut bodies: Query<(&RigidBody, &mut Position, &Rotation, &mut LinearVelocity)>,
) {
    // Iterate through collisions and move the kinematic body to resolve penetration
    for contacts in collisions.iter() {
        // If the collision didn't happen during this substep, skip the collision
        if !contacts.during_current_substep {
            continue;
        }
        if let Ok(
            [(rb1, mut position1, rotation1, mut linear_velocity1), (rb2, mut position2, _, mut linear_velocity2)],
        ) = bodies.get_many_mut([contacts.entity1, contacts.entity2])
        {
            for manifold in contacts.manifolds.iter() {
                for contact in manifold.contacts.iter() {
                    if contact.penetration <= Scalar::EPSILON {
                        continue;
                    }

                    let normal = contact.global_normal1(rotation1);

                    if rb1.is_kinematic() && !rb2.is_kinematic() {
                        position1.0 -= normal * contact.penetration;

                        // Clamp vertical velocity to prevent gravitational acceleration
                        // when on ground or sliding on slopes.
                        if normal.y > 0.0 {
                            linear_velocity1.y = linear_velocity1.y.max(0.0);
                        }
                    } else if rb2.is_kinematic() && !rb1.is_kinematic() {
                        position2.0 += normal * contact.penetration;

                        // Clamp vertical velocity to prevent gravitational acceleration
                        // when on ground or sliding on slopes.
                        if normal.y > 0.0 {
                            linear_velocity2.y = linear_velocity2.y.max(0.0);
                        }
                    }
                }
            }
        }
    }
}
#

everything else can be reverted to what it was

#

This basically moves the y = 0 into the actual collision response, and it could be modified to allow things like sliding on slopes with some specified steepness

peak marsh
#

It's improving, but I can still reproduce the issue in really rare occasions ferris_sob. The movement also gets a bit weird, like you can stick to walls mid-air by pushing your characters to it, the character sometimes falls too fast from small platforms, etc.

#

Why is this so cursed ferris_sob

vestal minnow
#

I'll make a quick demo scene in Blender with slopes and walls and stuff, it'd be nice to have in the example anyway

merry tide
#

That sounds great. Any chance for a 2d version of something like that also?

peak marsh
#

Tbh, I'd also love to see a 2D example too in the repo.

vestal minnow
#

lmao

#

yeah I'll add one at some point, idk if I have time before 0.3 tho

peak marsh
#

Nice super_bevy

merry tide
#

I am making a game with the hope of mass appeal, I think most people have a hard time with 3D still. Unfortunately, I cannot seem to wrap my head around making a 1D-game, so I am ending up with 2D at this point.

peak marsh
#

Lol, wouldn't a 1D-game just be a straight line...?

merry tide
#

Yeah, but. What's the game, right? 🙂 I am just being silly.

#

But what I am actually saying is that a super stable 2D physics engine is why I left Godot for Bevy and why I left Rapier for XPBD.

peak marsh
#

Yeah XPBD is cool

#

It looks like that in the end, the linear_velocity.y < 0.0 trick produces the most consistent result, so I'll just stick to that now.

mellow orbit
vestal minnow
#

Walls work properly, and the slope sliding angle is configurable

#

child colliders (like the ones required to get that glTF scene working) should also be supported

peak marsh
#

Looks really nice! I'll try to fiddle with it again once the example gets pushed to the repo.

cinder summit
vestal minnow
#

at this rate, this example will soon be a fully featured character controller

#

"no built-in character controller" they said

cinder summit
#

Is xpbd gets a built-in character controller we can say it's better than the rapier kcc tho thonk

vestal minnow
#

I don't like how rapier's kcc requires you to use all of these separate APIs

#

like normal collision filters and CollidingEntities don't work iirc

cinder summit
#

It's also just generally quite buggy, doesn't perform great, etc

#

In terms of usability it was probably about as jank as using xpbd with a different collider type tho ... All the things that require Collider or the times I use the wrong type by accident ...

#

Well I actually fixed that last one because I just import a custom physics::prelude::*; which doesn't have the wrong types ... Now we just need a feature flag in xpbd so I can yeet the parry dep thonk

vestal minnow
#

yeet parry + nalgebra

cinder summit
#

Funny part is I still rebuild a BVH each frame

#

And that BVH takes about 5x as long to build .... But I get 80% less server load thonk

vestal minnow
#

Why is the load so much smaller?

cinder summit
#

Because trimeshes no longer exist

vestal minnow
#

ah yeah

cinder summit
#

I think the SDFs perform about 30x better than trimeshes

#

Oh and I implemented sphere casts, which are just raycasts with a radius ... They are a lot faster than shapecasts, pretty SDF specific tho

vestal minnow
#

Have you compared the overall performance and stability to normal colliders?

#

like let's say you had a stack of cubes, is that stable?

cinder summit
#

I still need to implement the ability for cubes to collide with other cubes 😂

#

There is only points and lines with radii touching other shape atm ...

#

Capsules and spheres seem pretty stable even with mostly empty contact manifolds, but I'd imagine cubes would still explode without them 🤔

vestal minnow
#

yeah things like capsules and spheres should only ever have 1 or 2 contact points in most cases so they're probably quite stable

cinder summit
#

Yea there's only some rare exceptions like dropping a sphere on a torus. That's one case where they can actually explode

#

But I mean ... Who even makes torus colliders in a real game? 😂

vestal minnow
#

some donut factory game

cinder summit
#

No donut factory support for me yet ferris_sob

Torus { ring_radius: _, inner_radius: _ } => {
    todo!();
}
#

I can extrude 2D sdfs tho ... Just uh ... Need a few more 2D sdfs now ...

pub enum Sdf2d {
    Arc {
        radius: f32,
        thickness: f32,
        segment: f32,
    },
}
vestal minnow
#

You know it's serious when you rename basic_kinematic_character to kinematic_character and break up the example into multiple files

image.png
#

I figured it'd be nice to have the character controller be a plugin in a separate file since it's a good idea to do that in projects anyway

#

Although it's looking more and more like I should make it an actual crate...

cinder summit
#

And that's with collisions being an entirely separate crate which has a few common things and then an xpbd module with a narrow phase and spatial query stuff

#

Since I'm starting to implement 2d SDFs I guess I also need to make 2D collision handling thonk

#

Tho in reality I still don't want to start the 2d vs 3d thing until we know what that should look like for bevy crates

vestal minnow
#

now just need to do the dynamic version 🙃

mellow orbit
#

@cinder summit As I understand it, SDF can pretty easily be used to deform objects on collision. That opens up a whole bunch of amazing new physics engine possibilities!

vestal minnow
#

SDFs by themselves aren't deformable in that sense, but they could be used to do cool cloth stuff

cinder summit
#

You can do some pretty fancy stuff with SDFs, but you do want to be careful with them since it's not very hard to end up with wrong exterior distances or gradients

#

They also have some interesting game-specific usecases ... Sampling the distance to surrounding colliders is extremely cheap even if they are complex colliders. Would be rather useful for something like collision avoidance for AI agents

mellow orbit
#

I would love to see all of that encapsulated in the library so I can have the fancy stuff without having to be careful. 🙂

cinder summit
#

Yea that's pretty much what I'm planning. Having only operations that can create valid SDFs, with very clear warnings in the docs for cases where certain inputs can make the SDF bound

#

Merging overlapping or connected SDFs makes the interior distances wrong, which isn't that big of a deal, until you invert the SDF

vestal minnow
cinder summit
#

And besides SDFs having interesting properties, there's also interesting benefits like being able to do cloth simulations that don't glitch out

#

I'll definitely have to set up a way to slap accurate SDFs onto player characters so I can do cloth and hair physics at some point ...

#

Tho for now it's just a capsule which is very easy 😂

mellow orbit
#

This maybe goes into different channel, but: are you creating bevy meshes as the "output", or do you have a shader / material implementation that replaces bevy's?

cinder summit
#

I just take the SDFs and make a mesh out of them, and slap this green color on them ... You can probably see some weird edges and round corners, which is because the mesh library doesn't use gradients which means the meshes are wrong

image.png
#

And the round room is 3 arc sdfs and 2 cylinder sdfs in case anyone was wondering ... The rest is just boring boxes tho 😂

vestal minnow
#

I'll also try to add 2D versions now

vestal minnow
#

It is an example, the plugin is just in a separate file

#

next to the main file which just has setup stuff

#

also a nice way to see how it is to actually use the engine, I mainly just develop it so I don't have that much first-hand experience haha

#

yep

vestal minnow
#

(this is the dynamic one, still need to do kinematic)

#

should probably move everything up a little since the top is so empty

#

nah it took like 15 seconds, I just added 50px to the y values

#

there's already a collision layer example so that's unnecessary imo

vestal minnow
#

but it'd probably be possible to some extent

#

(if we're talking about spatial query filters here)

vestal minnow
#

excluded_entities doesn't get filled except for some specific queries, but those could probably be handled differently as well

#

we could probably remove excluded_entities tbh, it could be done manually in callbacks when needed

#

also 0.12 omg 👀

cinder summit
vestal minnow
#

yep it can be on RayCaster/ShapeCaster but probably not on SpatialQueryFilter

cinder summit
#

It's also more useful on shapecast than raycast

#

Since raycasts are cheap, but with shapecasts filtering first might be useful

#

Also my sdf spatial query stuff has been getting quite cursed ... To the point where I feel like the parry names might not even be that bad thonk

#

And it doesn't even support DFS vs BFS or anything vaguely ordered yet

vestal minnow
#

It's happening 👀

vestal minnow
#

wait just a sec

#

yes, that

#

I'm making a post in #crates rn

#

Here #crates message

#

The GitHub release has a (non-exhaustive) migration guide

GitHub
Release v0.3.0 · Jondolf/bevy_xpbd

0.3 is a huge release with tons of new features, bug fixes, and quality of life improvements, especially for collision detection. Here are some highlights:

Modular narrow phase: Narrow phase colli...

#

The blog post will come later

gentle steppe
#

Congrats!

vestal minnow
#

Comparing release notes for 0.2 and 0.3 side-by-side is pretty insane

image.png image.png
vestal minnow
# gentle steppe Congrats!

Thanks! There were a lot more contributors for 0.3 as well, so I'd want to thank everyone else too ❤️

cinder summit
vestal minnow
#

alongside joint motors, a parallel solver running on the GPU with unified memory, and fully featured perfectly stable soft bodies

cinder summit
#

Ah yes

#

The SDF collisions work better on the GPU too ofc

#

And it's gotta be unified memory otherwise the arete devs won't fall into despair about how much better physics for bevy is thonk

vestal minnow
#

Exactly

#

I can't decide if I should post about the release on reddit now or after the blog post is done, usually I've had the post ready for release already

#

I guess I could just link to the GH release and docs, and say that the post is coming soon™

#

if you mean the debug plugin, you need to add it manually now, but debug-plugin is a default feature

#

I would add that to the migration guide, but there was barely any debug rendering prior to 0.3

#

just .add_plugins(PhysicsDebugPlugin::default())

#

which bug?

timid holly
#

Maybe someone can help me out here, not sure the best approach to the problem I'm having. I have a 2d game, and i spawn in some circles, I have set Restitution(0.0) on all my dynamic rigid bodies, but sometimes when they collide, one still bounces a lot off the other. Maybe a better solution is to change mass or something?

vestal minnow
timid holly
#

close to main, i pulled it a number of days ago

vestal minnow
#

okay yeah nothing should've changed in terms of restitution behavior in the last few days

#

it's expected that they might bounce just a little bit due to the discrete nature of the collisions, but you could try to increase SubstepCount if that helps

#

something like 20 maybe

#

it should make the simulation more accurate, but at the cost of performance

shell ermine
#

do I need to do something if I get a bunch of

2023-11-04T23:07:41.504938Z  WARN physics_xpbd: some agents have an unreachable target, increasing delta to 0.03
2023-11-04T23:07:41.512408Z  WARN physics_xpbd: some agents have an unreachable target, increasing delta to 0.089999996
2023-11-04T23:07:41.520675Z  WARN physics_xpbd: some agents have an unreachable target, increasing delta to 0.26999998
2023-11-04T23:07:41.529132Z  INFO physics_xpbd: resetting delta
#

and then a freeze

#

that might or might not be related

vestal minnow
#

is that from oxidized_navigation?

shell ermine
#

bevy_pathmesh

#

francois' polyanya for bevy

#

wait

#

those errors are from the example

vestal minnow
#

I'm getting index out of bounds after a while

shell ermine
#

yeah same

#

on native it didn't show any errors

#

even with a debugger hooked up

#

actually I got capacity overflow

#

not index out of bounds

#

at least it finally panicked

#

ok, I think it's probably an issue in bevy_pathmesh, not xpbd

vestal minnow
#

yeah, I haven't used bevy_pathmesh so I don't know why it'd freeze

#

I'm also not getting issues now that I'm trying the demo a second time 🙃

#

nvm

#

literally as I sent that

shell ermine
#

uhh

#

I don't remember the interactive branch uses parry3d

vestal minnow
#

oh yeah that error has parry thonk

#

I do love me some parry bugs

shell ermine
#

phew, it's only xpbd that uses parry here

vestal minnow
#

nah

shell ermine
#

rip

#

cargo tree failed me

vestal minnow
#

it just uses parry through bevy_xpbd

edgy light
vestal minnow
#

it's probably one of the intersections_with_plane calls based on the error

vestal minnow
cinder summit
vestal minnow
#

technically yes, but that might be less discoverable

#

yeah I might do that, but it's moving even further in the direction of having built-in character controllers :P if they're just plugins that are used in a bunch of examples

#

you could do that for built-in character controllers too

#

but I think it does make sense to have it in common, I've been planning on adding the grabber plugin I made a while ago there as well

#

bevy_xpbd is designed to be very moddable and extendable with the idea that you can take e.g. the narrow phase and customize it a little

#

like NiseVoid's SDF narrow phase

#

not really

vestal minnow
#

the current demos can become something like platformer_2d and platformer_3d

#

wdym?

#

yeah I think I should at least group them somehow

timid holly
#

My game physics seems to run really fast now, with the new xpbd, is that expected?

vestal minnow
#

really fast in terms of objects moving very fast?

timid holly
#

yeah

#

about 2x as fast as before

vestal minnow
#

that's weird

#

the examples look normal

timid holly
#

i do have a 144hz monitor and a 360hz monitor

#

not sure if that matters

#

it felt like it was 60fps before

#

now feels like it's running a lot faster

#

well, i'm formulating this improperly, not the framerate, but actual physics simulation speed

vestal minnow
#

it's very possible that I messed something up in the unified time PR but I haven't really noticed it in the examples

timid holly
#

i'll try running examples on my machine to see if i can repro it in any of those

#

wow, chain_2d runs like crazy on my machine

vestal minnow
#

I swear I checked that 😭

#

it does freak out

#

probably wrong initial positions tho

#

*hopefully

timid holly
#

pressing up and then letting go mostly

vestal minnow
#

that looks otherwise right but they sometimes fall weirdly fast in your video

timid holly
#

yeah

vestal minnow
#

I'm not getting that myself

cinder summit
#

Gotta get the physics starter pack featuring:

  • SDFs
  • A whole 3 papers on the subject
  • Lots of xpbd features that subtly break because Collider isn't as optional as it should
timid holly
#

sometimes it falls very fast, sometimes normal

cinder summit
#

Yea idk there's not that many papers on SDF collisions

#

There's a lot of robotics simulation stuff that uses it, but they don't publish papers ferris_sob

#

Outside of collisions there's a lot more info

#

Tho not that many info about gradients, which sucks because gradients are quite important for physics

#

Ah and can't forget implementing your own BVH so you can have spatial queries without parry, except that doesn't benefit you that much cause parry isn't an optional dep in xpbd thonk

vestal minnow
#

how do I make my frame rate not locked to 60fps

#

oh I got it

cinder summit
vestal minnow
#

yep the issue is frame rate 😂

timid holly
vestal minnow
#

yes

cinder summit
#

SDFs are used very often for some rendering stuff. As for collisions I found like 3 whole usecases:

  • Robotics simulations
  • Cloth physics
  • Marble marcher
timid holly
cinder summit
#

Honestly if it wasn't for the cloth physics, I doubt I'd even have heard about them ... Since it was just a thing Jondolf mentioned randomly

vestal minnow
cinder summit
#

Yea it's probably roughly like this:

  1. Cloth physics
  2. Marble marcher
  3. My game
  4. ????
  5. Robotics simulation
vestal minnow
cinder summit
#

I mean fwiw it all started when I heard about SDFs for the first time cause kayak_ui has SDF text

vestal minnow
cinder summit
#

Isn't your simulation just running at 60FPS?

vestal minnow
#

the physics timestep is 60fps yeah

cinder summit
#

FPS totally makes sense then

vestal minnow
#

yeah it is accurate, move_marbles with a lot of bodies still goes from > 1000 FPS to 10 FPS real quick lmao

timid holly
#

Yeah I can easily get <10 fps on move_marbles lol

vestal minnow
#

but yeah I know what the issue is, I just need to find a nice fix

cinder summit
vestal minnow
#

probably narrow phase + solver

cinder summit
#

Hmmm yea I guess the narrow phase can get expensive too since it's not all sphere-sphere

vestal minnow
#

move_marbles is 99% sphere-sphere

cinder summit
#

Actually how much room for optimization is there in the narrow phase? Besides replacing parry with something that doesn't dynamic dispatch

vestal minnow
#

we could reuse contact manifolds, but otherwise probably not that much

cinder summit
#

Ah right that vec in vec thing ... With enough contacts that might actually add up fast 🤔

vestal minnow
#

I rather meant that we can use slightly transformed versions of previous contact manifolds if the bodies haven't moved much instead of always running gjk/epa on them

cinder summit
#

Ah ... That wouldn't do much for sphere-sphere tho

#

Tho I guess if it doesn't account for it being sphere-sphere it still has to deal with rotations and some other fairly expensive math

#

I haven't profiled my sdf physics, but I'd imagine the most expensive part of it is transforming the sample points into the local space of the other collider

#

Just like the absolute insanity where the highest cost to building my BVH is calculating the surface area of merged AABBs ferris_sob

vestal minnow
#

I can fix the weird physics speed issue but it kills my fps

#

nvm I have a fix but it's really sketchy

#

I'm pretty sure PhysicsTimestep::Fixed was already broken in earlier releases and just ran 0 or 1 times per frame instead of consuming the entirety of the accumulated time

#

if I use that behavior, the fps and behavior is basically the same as before, but if I accumulate time using Time<Real> and consume that, FPS is way worse since it can death spiral more easily

#

now, do I implement the old incorrect behavior or the intended but much slower behavior 🤔

#

I guess I could have some max_steps property on the fixed timestep to prevent death spirals, where a value of 1 would correspond to the old behavior

#

0.3.1 tomorrow??

#

if y'all happen to encounter other unexpected issues, let me know

timid holly
#

ty!

timid holly
#

Regarding my earlier issue, it’s not just a small bounce, it’s a sort of explosive one

#

It seems inconsistent

#

I can send a video if that would help

#

And I mean not the issue with 0.3

shell ermine
merry tide
#

I just tried to pull and run that example and here it dips into mid 30FPS on main.

merry tide
#

I just updated to Bevy 0.12 and xpbd 0.3. Is it supposed to behave the same given the same code or are there some breaking changes? I can notice some stark differences in how some basic shapes seem to interact. I won't harp on it if it is expected to behave differentely. I didn't see a changelog.

#

I can make a video describing the difference without much hassle. 0.2 seems more correct to me.

#

Again, it is super fair that it is my implementation of despawning of stuff and the order of systems is wrong, etc.

#

But are there known bugs? Should I just kick back and relax and see if it's fixed in 0.3.1? I didn't see anything reported in the repo.

#

I am actually seeing something that is way more basic than that. Let me show you on a video. It is a little puzzling to me. It will take me 30 minutes to make it, tho, I think. I will make it just in case it is an unknown, if it is fixed implicitly with 0.3.1 that is also great. 🙂

#

Great. I will share it here before I start making issues. It might be just a default that has changed, or something.

#

Cool, I'll test that.

#

This could just as easily be a Bevy 0.12-thing. It has to do with what forces are carried on when an object is despawned. It seems like in Bevy 0.11 and XPBD 2.0, the force from colliding with an object resulting in that object being despawned would carry over to the object that isn't despawned. With 0.12/0.3, that doesn't seem to be consistent. It happens sometimes.

#

But it seems to depend on the impact angle of the objects.

merry tide
#

Also, happy to share code if that is helpful. But it naive at this point.

#

You would think that if it had to do with system order and despawning that it would work consistently correctly when falling straight from the top and down.

#

Could this be related to what I am seeing?

merry tide
#

Adding the debug-plugin doesn't really reveal anything to my untrained eye.

#

This is an absolute yes. I think this is probably the culprit.

#

If you send me your github, I can share the code, no problem. Is there an example of how to move from EventReader<Collision> to what is in vogue now?

#

I had a small issue with it previously moving from desktop on Win/Mac to WASM.

#

But still an EventReader?

#

But I do need Collision if I want to despawn what is collided with, right?

#

/giphy tell me more

#

Ah. Nice.

#

I try this on for size. It looks clean.

#

Sure, I am happy to share code with anyone interested. I will make a debug-video, but it really just shows a debug-overlay on the existing shapes that are static and where expected. Let me try this other thing first.

#

Even using CollisionStarted, it falls through. So I will make a short video with the debug-rendering enabled.

#

I am in no real rush with this. I was thinking of making an "Advent" but that's in December. And I can have a different WASM every day.

vestal minnow
#

I woke up

vestal minnow
#

@merry tide thanks, I'll look into that issue and try to repro. Where are you running the despawning system?

#

Shapecasting with ShapeCaster or SpatialQuery? One of the only things I remember changing about ShapeCaster is that it now ignores the self entity by default, but this can be reverted using .with_ignore_self(...)

merry tide
#

It is pretty small.

vestal minnow
merry tide
vestal minnow
#

Gotcha

#

But yeah the repo would be nice so that I don't have to make a repro from scratch

merry tide
#

What is your github ID? Happy to share with anyone interested. The last commit has the PhysicsDebugPlugin and all that on it.

vestal minnow
merry tide
#

I feel I already knew that. 🙂 Sorry. Been up all night.

#

I sent you an invite. The README should be somewhat informative, but it really should just be cargo run.

vestal minnow
#

Thanks, I'll try it in a bit

merry tide
#

No rush. Thanks so much for looking into it.

vestal minnow
#

@merry tide Hmm, I think I found the issue with the inconsistent collisions when despawning, but it might be a somewhat tricky one.

For now, this should fix it in your case:

.insert_resource(NarrowPhaseConfig {
    prediction_distance: 0.0,
})

The prediction distance basically determines the maximum distance between two bodies for a collision to be counted. It's normally a bit over 0.0 to make sure that collisions aren't missed. This is because if bodies move into a colliding state mid-solve, the collision would only be detected during the next frame unless the prediction distance is large enough.

The issue in your case is that the bodies may not have actually touched yet, but it's still sending a collision event if the distance is within the prediction distance. I should be able to fix this by only sending events for actual touches though

#

And the reason it worked in 0.2 is that it didn't have any prediction distance stuff, but it was also a lot more unstable and collision events had other issues

vestal minnow
#

I made an issue for the collision event problem and added it to the 0.3.1 milestone along with the timestep issue

#

I have fixes for both but I need to check if I caused other issues for the collision events since the logic for them is kinda error-prone

#

I'll also check the spatial query thing .⧲. mentioned

vestal minnow
merry tide
merry tide
#

It is just me again! I am testing it on my MacBook and it seems to be running at what I can only describe as "double speed" somehow. Is this also known/easily fixable thing?

vestal minnow
merry tide
#

I sort of understand. Do you recommend using XPBD from source, or wait for an update? Because this isn't something I can remedy in my code, right?

vestal minnow
#

you can use that branch for now but I'm trying to get the 0.3.1 patch ready today or tomorrow

#

you can't easily do anything to the speed issue in your own code

merry tide
vestal minnow
#

It's been a thing pretty much forever I think, but I've only noticed it in this very specific example of having stacks of balls bouncing, so I haven't encountered anyone else experiencing it

vestal minnow
timid holly
vestal minnow
#

thanks

vestal minnow
#

don't ask how that happened

#

0.2 had a lot of contact stability issues but I believe this is a separate issue

#

if it's a really quick test though, then feel free to test

#

it's quite inconsistent in my tests

vestal minnow
#

I hate how expanding the AABBs just a little extra in all directions fixes some collision event issues

// (pixels in this case)
aabb.mins.x -= 1.0;
aabb.mins.y -= 1.0;
aabb.maxs.x += 1.0;
aabb.maxs.y += 1.0;
#

This feels so wrong, but if it works, then why not...

vestal minnow
#

I think it does

#

no, they cast against colliders and not AABBs

#

or I think the Qbvh uses AABBs for optimization, but not for the actual casts

cinder summit
#

You don't use AABBs for optimization, they are the whole thing that make up the structure

#

Doesn't the qbvh get filled with the real aabbs rather than the swept ones?

cinder summit
vestal minnow
cinder summit
#

Ah yes it .... optimizes*

  • as long as you don't do incremental updates
vestal minnow
#

and yeah the Qbvh AABBs aren't the expanded versions

cinder summit
#

Always read the fine print on your spatial acceleration structures 😂

vestal minnow
vestal minnow
#

(0.5 chosen arbitrarily, just tested with 0.1 and it was kinda broken while 1.0 works)

cinder summit
#

Hmmm ... Do you get collisions for things that don't quite touch?

vestal minnow
#

yes, this is what I'm fixing #1124043933886976171 message (and apparently the explosion thing as well)

#

While fixing it, I noticed that CollisionStarted events were also sometimes getting sent every frame when it looks like a body should be continuously colliding, and it turns out it's because of the AABBs

cinder summit
#

I guess expanding AABBs by prediction distance would be a reasonable approach? 🤔

vestal minnow
#

maybe yeah

#

I'll test

cinder summit
#

Meanwhile my SDF collisions still don't use prediction distance

#

Even tho I can kind of just get those values for free 😅

vestal minnow
#

I think it's working correctly, but the values are kinda arbitrary

#

for the broad phase I can use 0.1x the prediction distance without issues

#

but idk if that just means that the prediction distance is unnecessarily high

vestal minnow
cinder summit
#

I mean it's pretty common for you to fix issues the same day it's reported, but usually the ones you fix by accident are the bugs relating to big things, like with contact manifolds

vestal minnow
#

I swear the AABB expansion logic has been the main culprit behind most of the contact stability issues

#

I can recall at least 3 or 4 times where it has caused issues now

merry tide
#

Seems like a good place to spend time making it better, then. I came here for the immediately obvious quality of the engine, but I am staying for the improvements and quick communication.

#

The thing I am making, I would probably shelf it if it wasn't for XPBD.

#

Or worse, do it with Unity. Which seems to have a pretty good built-in 2D physics engine, far outperforming that of Godot. But that is pretty much synonymous with shelving it for me.

#

Sorry, I am yapping today.

cinder summit
#

I mean the performance of godot is probably better than bevy_xpbd ... I do know godot's new physics engine is very unreliable tho 😂

merry tide
#

No... Well, Godot 2D physics cannot reliably resolve a simple circle colliding with two rectangles same iteration. It picks one.

#

And the result is just painful.

#

And it is a known error, not something I am making up.

cinder summit
#

I think I would've had to go back to the drawing board if we only had bevy_rapier and I couldn't find creative solutions (like sdf collisions) to my game's biggest performance drains ... And afaik rapier still doesn't allow you to do determinism correctly

merry tide
#

Which means that if you tesselate a complex object, it is at best totally unpredictable what will happen.

#

Sure. I might be wrong about this. All of it. But this library is by far the closest I have been to manifesting my vision. Rapier let me down day 1.

#

Sorry, I am treating "crate-help" as "lets-just-chat-about-stuff".

cinder summit
#

If only discord allowed threads in topics, we always seem to need them here :')

vestal minnow
#

I personally don't mind random convo in this help thread/topic as long as it relates to physics or xpbd in some way, which this does

merry tide
#

I am yet to make the tesselation for import of Lyon, but I think xpbd will do it better; if it interacts with multiple bodies it will be reasonably translated.

cinder summit
#

worst case you can convert your game to sdfs

merry tide
#

In Godot, just slap a bunch of rectangles next to each other and you will see that it doesn't treat it as an extended plane.

#

I made some videos exhibiting this behavior, but I won't bother you with it.

vestal minnow
#

well that's just a numerical thing to some extent, I'm pretty sure parry also has issues with edges like that

cinder summit
#

Ah, that edges thing ... I think we got some fix for that to some extent in xpbd, but I do remember rapier struggles with it more ... Might also just be specific to a physics approach too 🤔

#

I think in 0.1 things exploded if they touched two edges at once like that 😂

vestal minnow
#

xpbd doesn't have any "internal edge fixer" or anything so I'm a bit skeptical but idk

merry tide
#

So the usecase would be a game of Arkanoid or something like that. Breakout. Where blocks are next to each other.

vestal minnow
#

while rapier does have something like that iirc (or was it parry?)

cinder summit
merry tide
#

Using Godot you cannot expect the out-angle to be the in-angle reversed if you hit two blocks at the same time.

#

You can end up having one of the blocks sending you literally back where you came from instead of just inverting Y.

#

And if it is indeed an issue, how can you interact comfortably with anything complex by tesselating?

#

Honestly, I didn't even check the engine if it does this correctly. I was just depressed over Godot and Rapier. But... Unity does it. Perfectly, it seems.

cinder summit
#

This case should be fixable at least, even if xpbd doesn't currently handle it correctly ... It's just solving penetration constraints with multiple contacts on different objects

#

Even if you get weird edge normals they should even out to having a -Y normal 🤔

vestal minnow
#

Unity uses PhysX (or can use Havok as well I think) which I would expect to be one of the best physics engines probably

cinder summit
#

Or X/-X normal if it hits on the side

#

PhysX is definitely one of the better tested engines yea

#

Godot 4's physics is an absolute trainwreck, everyone has been hating on it ... And rapier has decent performance for broadphase and narrow phase for how relatively small it is, but it's very rare to see it produce convincing physics behavior

merry tide
#

I will make a small test for it. But what I am looking for might already be good for xpbd. Just a bunch of blocks as a "floor" and expect it to not hurl you in the X-direction. Godot hurls you in the X-direction when it is at the edge.

#

Ideally it would null with a larger plane.

gentle steppe
#

there's even a Rust binding to physx but it's weird of a weird slice of the API and so hard to use it for general purpose stuff

#

for instance, the api has ray casting but not shape casting

merry tide
#

Sorry, by "null" I mean it would be the exact same result as a conflated plane.

vestal minnow
cinder summit
vestal minnow
#

or do you mean the Rust API specifically

gentle steppe
#

physx has them, but the rust api doesn't expose them

vestal minnow
#

gotcha

cinder summit
#

There's also a fair bit of overhead on these bindings usually, right?

merry tide
#

If you bind to C I cannot reasonably see that there needs to be an overhead, but there might be. I mean, at the very least you need to massage the data most of the time.

gentle steppe
#

well and you might need to duplicate all your geometry

vestal minnow
#

you'd at least need to interface with the ECS as well in the case of Bevy, like with rapier

merry tide
#

Yeah, sure, but I am already duplicating geometry from physics to rendering. But sure.

gentle steppe
#

the hard part about binding physx is that it's a lot of C++. Not impossible, just not enough man hours on it yet

cinder summit
#

Yea you get that rapier overhead, and some bindings overhead, which also break a bunch of optimizations I think

merry tide
#

C++ is just a horrible language for libraries. It is good for applications and open source stuff. But if you get binaries in C++, it is very hard to predict what is going to happen.

#

I am not making this up, I wrote some libraries for FinTech in C++ and just differences in stack unrolling for exceptions made it almost impossible to reason about.

#

It doesn't only change from compiler to compiler but also versions of the same compiler. Microsoft seems to have almost decided on what it should look like. It is worse on Linux and Solaris.

gentle steppe
#

Nothing against xpbd, it's great, but I've definitely considered using the bevy_mod_physx just because physx seems to be industrial strength. But I think given the state of the API, you'd probably want to write C++ code that exposes a thin C wrapper with a simple entry point. Then call that from rust.

vestal minnow
#

yeah I think the "easiest" way to get super stable and tested physics would be to use PhysX bindings, but it does have downsides and is maybe more annoying to work with

cinder summit
#

There's also the part where if you need serious physics performance, xpbd and rapier just don't perform well enough

merry tide
#

I am happy here. As long as we are moving forward. And the nice thing about compiling Rust to WASM is that I can change it out from day-to-day.

#

If I ever make money from this project, I am happy to fund further development. Hold me to that when I am drinking Pina Coladas benefiting from you all's work.

vestal minnow
gentle steppe
#

and 90% of what I need for physics is actually just colliders with reasonable responses for kinematic controllers. I'm NOT actually doing a proper physics sim anywhere

vestal minnow
cinder summit
#

xpbd funding? Is Jondolf getting the lifetime of physics dev after all? 👀

vestal minnow
#

👀

gentle steppe
#

could the 0.12 instancing be helping here?

merry tide
#

Dudes, I am happy to fund you out of pocket if you help me make my game work. 😄 Courtesy of Amex.

cinder summit
#

I should implement collisions between cubes and any other shapes in my sdf collisions so I can compare the numbers with parry 😂

merry tide
vestal minnow
#

I might accept sponsors after I'm done with high school yeah, for now I don't want that though

cinder summit
#

At least I'm confident I'm gonna win if it's sphere on concave collider 😂

merry tide
vestal minnow
cinder summit
#

Main difference with funding is if you don't need to work a full time job you can keep working on xpbd

merry tide
#

Yeah. I just think that working for something more than 3 hours a day for a long time isn't good. And then, accepting money turns it into a job.

vestal minnow
cinder summit
#

We just need to make sure there's xpbd funding before jondolf considers working as FMSC, because everyone who starts working there stops maintaining their crates 💀

vestal minnow
#

lmao true

#

didn't they rebrand though?

#

Foresight Spatial Labs to sound less bad

cinder summit
#

I just know that if my game ever ends up popular, making sure bevy and bevy_xpbd stay maintained would be the biggest priority after being able to keep working on my game fulltime. I could probably replace or maintain every single other crate I use besides those two

merry tide
#

A million? That is nothing these days. With my bouncing balls, I can give a billion. But don't ask for a trillion, then we have an HR-issue.

vestal minnow
merry tide
#

Isn't the paper open, tho? Unencumbered by patents?

vestal minnow
#

PBD and XPBD are technically patented, but then the authors of the papers have open source implementations with permissive licenses

#

hard to say how enforceable it is

merry tide
#

Hm. Interesting. We'll be fine, is what I am thinking.

cinder summit
#

I wouldn't be surprised if some sdf collision tech is patented too, considering how few papers there are compared to the number of proprietary softwares that use it

merry tide
#

Well, I mean, back in the days XOR was patented with making a blinking cursor.

#

Smoke and mirrors.

vestal minnow
#

sebcrozet also said that one of the reasons Rapier didn't switch to XPBD is because he wants to be sure there aren't patent issues

cinder summit
#

Just gotta make sure you don't implement it on GPUs with AMD support and you'll probably be fine thonk

merry tide
#

I am putting my eggs in this basket. And to the extent I can I will be happy to contribute. I am not a good Rust coder at this point. I do have code in mainline Microsoft products to relieve memory pressure, so I am not a total slouch.

vestal minnow
#

just need to rename 🙃

cinder summit
#

bevy_xpbd is the best basket to put your egg sdfs in

#

Just make sure you don't put in egg trimesh colliders because then parry will screw you over 👀

merry tide
#

God damn it. How hard is it to just test that?

vestal minnow
cinder summit
#

I would join you on that boycott ... Not that I ever get anything nvidia to begin with

vestal minnow
#

they have so much cool tech and a ton of research, but they have an outrageous amount of patents

cinder summit
#

Realistically most of nvidias patents and proprietary tech are hard to enforce, amd almost always copies it and makes it opensource and clearly nvidia isn't winning cases about it otherwise they wouldn't keep doing it

merry tide
#

It seems like if it is described in a paper with an open source implementation, it is made to be hard to enforce.

cinder summit
vestal minnow
#

Matthias Müller is a legend tho, so many amazing papers and a lot of educational resources

#

despite being at NVIDIA

cinder summit
#

Realistically if you're a good researcher, you just end up at whatever company gives you the most to keep doing your research

#

And they'll then patent all of it, probably with no real plans what to do with it, other than maybe erasing unwanted new competitors

vestal minnow
#

the question about the patents was also asked from Müller on the Ten Minute Physics Discord, but no answer from him so far

#

although his latest message there is from over a year ago lmao

#

probably sent to the NVIDIA dungeon for open sourcing PBD code

cinder summit
#

Does physx even use this tech they research?

vestal minnow
#

XPBD is used in Unreal

cinder summit
#

I wonder if Epic licensed it or if they also think "it's opensource so your patents are invalid"

timid holly
#

So every rigidbody here is configured with Restitution(0.0), sometimes the collision response seems accurate and mostly inelastic, and sometimes it seems very elastic. I guess I wouldn't really consider this explosive.

cinder summit
timid holly
vestal minnow
#

I was about to say that haha

#

I like the animations

timid holly
#

So far I enjoy rust a lot more than I ever did cpp, etc. I'm usually devving in scala

cinder summit
timid holly
#

Also wanted to try making a game with ECS, never done any of this stuff before

vestal minnow
#

and SDFs 👍

cinder summit
#

I used to dislike rust, but now I've been using bevy for almost a year and I'm starting to consider rewriting Go things in Rust 😂

cinder summit
timid holly
#

Yep, that's the main issue that affects the gameplay

#

Makes it very non punishing to stack improperly

#

Since eventually the whole thing kinda just explodes when it gets big enough, and things that were stuck before are no longer

vestal minnow
#

I'm soon releasing the fix I found for my issue, we can see if it's the same issue

cinder summit
#

I mean on the flip side, it does feel very satisfying when everything explodes and all the pieces merge 😂

#

These games get very frustrating when the physics makes all spheres at the bottom sleep and they never wake up again, being locked until something directly next to it gets merged

#

Pretty sure the intended behavior in xpbd is that they start waking up in a chain tho 🤔

vestal minnow
#

they should currently wake up when a collision ends or a colliding body moves

#

but an island architecture would probably be good

#

the way sleeping is handled is... questionable in some ways

#

but it works decently so 🤷‍♂️

cinder summit
#

Worst case you could always make them have 0 friction and they'll spin for all eternity, never going to sleep 😂

vestal minnow
#

I don't suppose someone could find me a research article about economics real quick?

#

do my homework so I have more time for making 0.3.1 😂

#

(I'm kidding... unless you do find one)

cinder summit
#

This sphere has been spinning on my server for over 24 hours 😂

vestal minnow
#

although I'm not sure if the English word "economics" is what I'm referring to

#

I mean "taloustiede" which is "economy science" basically

cinder summit
#

I think economics is correct yea

merry tide
cinder summit
#

It's just a meme because economists often consider theirselves scientists, but most scientists don't because they tend to ignore reliable studies in favor of ones that clearly got manipulated by rich companies

merry tide
#

Math isn't science.

#

This triggers people who think science is a pinnacle. Math is better than science.

#

And with this I actually think I will talk to you all tomorrow. Thanks for the chat and the help.

cinder summit
vestal minnow
#

should put that in the README

cinder summit
#

xpbd has been very stable over time after the qbvh thing got worked around

#

Rapier was never this stable, it would eventually crash with some meaningless error because it produces NaNs rarely for normal collision responses, then fails assertions elsewhere

vestal minnow
#

can't wait for soft bodies

mellow orbit
cinder summit
#

Looks like updating a heightmap or voxel grid with SDFs ... You can just value = max(value, -sdf), maybe use smooth max ... Interesting idea tho, using sdf colliders to make things like snow or water physics more accurate

mellow orbit
cinder summit
#

Offloading sdf physics to the GPU is definitely possible, but it makes your physics very inflexible, especially in that you can't run it on a server unless it has a GPU

#

Not sure if solving XPBD constraints can also be offloaded onto the GPU tho ... But I feel like at that point nvidia might actually get annoyed 😂

vestal minnow
#

you can

cinder summit
#

I might actually look into it at some point ...

#

Because I feel like cloth/hair physics belongs on the GPU thonk

vestal minnow
mellow orbit
vestal minnow
#

in about 4-5 months maybe

cinder summit
#

I'm not sure whats worse ... Having a highschooler develop a physics library for free ... Or for $5 a month thonk

#

I would be funding development of libraries too, but I already spend Infinity% more on my game's hosting than I have income 😂

mellow orbit
#

Well, theoretically, it's not just me throwing in a few dollars.

mellow orbit
cinder summit
#

I just run the game on a 2core VPS at hetzner

#

For like 5 euros a month

#

It can handle a few hunderd players now I think

vestal minnow
#

$5 is more than I've ever gotten from working... because I've never had a job

#

(I do get money from the government tho)

cinder summit
#

I also get some money for the government ... To pay health insurance ... They give me more than the health insurance costs so really the government funds my game's hosting 👀

#

If I ever need to upgrade we're gonna be seeing how bevy and bevy_xpbd behave on ARM thonk

vestal minnow
#

surely there's some government official from the Netherlands in this game engine's physics engine's help thread, and they know how to find you

cinder summit
#

The government doesn't give a shit. This whole system is entirely broken, everyone complains about it, and they don't care about fixing it

#

In some cases you can reduce your working hours, and the government will give you so much extra money you get more per month than working more

vestal minnow
#

welfare traps

cinder summit
#

Yea, but in reverse thonk

#

They should just introduce basic income

#

Then I don't need to worry about getting a meaningless job at some IT company and I can continue doing the important work of making SDF collisions for an obscure game engine

vestal minnow
#

exactly

#

yeah for 2D it uses box2d

#

if glam with libm is cross-platform deterministic then maybe we're (close to) beating Unity on that front

#

except I recall reading that their ECS physics is deterministic

cinder summit
vestal minnow
cinder summit
#

Once I release my game and can't predict how many people will show up I'm gonna throw it on a separate VPS, and I'll ofc use the ARM ones because they are more power efficient which means my game's hosting would be less bad for the planet

vestal minnow
vestal minnow
#

@merry tide For 0.3.1, I think I'll leave the collision event thing as it currently is because it's kinda tricky to fix with the current way it's handled, at least without breaking changes. I'll try to rework it at some point though and hopefully fix the issue

#

for now, you can use the prediction_distance: 0.0 thing

#

it should work fine in your case

#

I don't think the shapecasting code has really been touched since 0.2, but you could try inverting the ignore_origin_penetration setting (from false to true or vice versa)

#

what exactly are you trying to do with the shapecast?

timid holly
vestal minnow
timid holly
#

Cool, i'll test it

vestal minnow
#

if it doesn't work, increasing SubstepCount could help

#

(default is 12)

timid holly
#

i did try setting: prediction_distance: 0, and that didn't seem to fix anything

#

in narrowphase

vestal minnow
#

that just makes it worse probably

#

because it can miss collisions easier

vestal minnow
timid holly
#

seems a lot better

#

i haven't seen them bounce high at all yet

#

is there anyway to make these bodies "squish" or emulate that

#

in the game when something below combines, i have it resize the collider over time to not make it explode

#

trying to assist that

vestal minnow
#

there's not a nice way currently

#

I guess you could set SubstepCount to 1

#

but that just makes physics accuracy worse (which includes making things squishier)

#

ideally we'd expose the compliance (inverse of stiffness) of penetration constraints (the things that handle contacts) but that's currently not possible

#

or add a CollisionStiffness component or something...

timid holly
#

yeah i guess that's more of a stop gap before more involved softbody stuff huh?

#

fyi the game feels a lot better now on that branch

vestal minnow
#

the penetration constraint compliance is very different from actual soft bodies, it just controls contact strength/stiffness while soft bodies consist of a bunch of particles that are constrained by volume, distance and bending angles

timid holly
#

ahh okay

#

that makes sense

vestal minnow
timid holly
#

yeah i guess that would be pretty useful

vestal minnow
#

this guy has very good videos on XPBD and soft body simulations with it

#

they're the type of things I'd like to eventually implement in bevy_xpbd, and what I used for an old experimental demo I made months ago

#

(although that was just implementing the first and maybe second episode basically)

#

ah so the issue is that the ball is spawned overlapping the wall and not right next to it which causes it to explode

#

so the shape cast hit data seems to be wrong

#

you could maybe test with debug rendering to see where the shape is at the hit point

#

it's not visible with SpatialQuery but you can render it manually with PhysicsDebugRenderer. For ShapeCaster it's like this

fn debug_render_shapecasts(
    query: Query<(&ShapeCaster, &ShapeHits)>,
    mut debug_renderer: PhysicsDebugRenderer,
    config: Res<PhysicsDebugConfig>,
) {
    for (shape_caster, hits) in &query {
        let ray_color = config
            .shapecast_color
            .unwrap_or(Color::rgba(0.0, 0.0, 0.0, 0.0));
        let shape_color = config
            .shapecast_shape_color
            .unwrap_or(Color::rgba(0.0, 0.0, 0.0, 0.0));
        let point_color = config
            .shapecast_point_color
            .unwrap_or(Color::rgba(0.0, 0.0, 0.0, 0.0));
        let normal_color = config
            .shapecast_normal_color
            .unwrap_or(Color::rgba(0.0, 0.0, 0.0, 0.0));

        debug_renderer.draw_shapecast(
            &shape_caster.shape,
            shape_caster.global_origin(),
            shape_caster.global_shape_rotation(),
            shape_caster.global_direction(),
            shape_caster.max_time_of_impact.min(1_000_000_000_000_000.0),
            hits.as_slice(),
            ray_color,
            shape_color,
            point_color,
            normal_color,
        );
    }
}
#

dumb question but the ball isn't scaled via Transform right?

#

idk it's hard to say

#

especially if the line looks correct

#

nothing has been changed for cast_shape I'm pretty sure

#

or it can overlap other colliders in specific positions but I don't think that can be avoided

#

like this

image.png
#

although that could be the gizmo thickness actually

#

I think I'll just release 0.3.1 now, it has the fixed timestep fix and contact explosion fix + a couple of other smaller fixes

#

the fixed timestep thing is bad enough that I want the fix released ASAP

#

I can always make a 0.3.2 for further patches

vestal minnow
#

I did release 0.3.1 btw #crates message

#

I'll try tomorrow, don't have time today

#

yeah hmm, that's odd

royal helm
#

Related to xpbd patent stuff I think one idea might be to rebrand bevy xpbd

vestal minnow
#

idk how much that matters if it still uses xpbd

#

since the patent is on the simulation method

#

is XPBD trademarked? surely not

#

I don't have any strong objections against renaming it though since the focus has gradually shifted from the "xpbd" part to the native Bevy physics engine part

#

mainly that people know it as bevy_xpbd and there hasn't been a meaningful incentive for a rebrand

#

ofc if it were to be eventually accepted into the Bevy nursery (once that RFC gets merged) and upstreamed, it would definitely be rebranded

#

right now I don't know what it would be called if not bevy_xpbd though since it can't be bevy_physics of course and probably not bevy_mod_physics

mellow orbit
#

As a non-lawyer, I have heard from lawyers more than once: don't speculate about software patents.

vestal minnow
#

In the sense that you should be extra careful or not care?

mellow orbit
#

There is nothing good that can come of having a record of software engineer's opinions in this area.

#

I am choosing my words carefully 🙂

#

Of course, if there is a known patent on some areas, that should be avoided.

vestal minnow
#

well this is the patent / one of the patents, it covers pretty much the entire core of PBD and XPBD in a somewhat ambiguous manner

#

the consensus has generally been that it seems unenforceable, and that the original PBD patent was somewhat questionable considering there was prior art

#

and especially considering that the actual authors have open source MIT code with PBD/XPBD, you would assume it's fine to implement

#

but my legal knowledge is very limited so I can not say whether or not they could enforce the patent and what the impact would be

cinder summit
#

The more ambiguous patents get the less enforcable they become ... It's like nintendo with their physics patent ... No one would enforce that

vestal minnow
#

Like this just seems quite generic

Embodiments of the present invention provide a position-based dynamics approach for simulating objects using a set of points and constraints, applied as equations that restrict the relative motion of bodies. Forces are applied to the points to move them, and the constraints ensure that the points will not move in a way that is inconsistent with rules of the simulation.
But I guess this is a bit more specific to XPBD
The present invention improves upon existing PBD approaches by using regularized constraints that directly correspond to well-defined energy potentials, and which can advantageously be solved independent of time step and iteration count.

#

but still quite ambiguous in my opinion

cinder summit
#

I'm also not sure if there's any precedent for patents being used against individuals or non-profits

mellow orbit
#

This is the kind of speculation that ends up in court documents.

#

And, NiseVoid: individuals, usually not, because the goal is usually a monetary shakedown. But non-profits, definitely.

#

Nvidia is, at a least, a practicing entity -- that is, they do stuff other than just own patents and sue. It's the latter that are really dangerous.

vestal minnow
#

Who would theoretically be sued in this case? I am an individual currently developing it without monetary gain, but someone could use it in a monetized application

cinder summit
#

I think they could have github take the repo down or go after devs

#

If they do the latter they'd be imploding their company however thonk

mellow orbit
#

You, github, users, anyone.

cinder summit
#

NVIDIA would put theirselves in a very dubious situation if they ever go after anyone for these cases however, because they do this exact pattern everywhere:
Release a paper and opensource code, but also patent the concept

severe urchin
#

isn't this a software patent, which aren't valid in the EU?

vestal minnow
#

Oh are they not?

severe urchin
#

that's a USA problem

cinder summit
#

Did they even file the patent in the EU? thonk

mellow orbit
cinder summit
vestal minnow
cinder summit
severe urchin
#

generally you can't do software patents in EU, I wouldn't lose any sleep over it.

mellow orbit
#

I wouldn't count on the EU here. It's more complicated than that. See https://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention

Software patents under the European Patent Convention

The patentability of software, computer programs and computer-implemented inventions under the European Patent Convention (EPC) is the extent to which subject matter in these fields is patentable under the Convention on the Grant of European Patents of October 5, 1973. The subject also includes the question of whether European patents granted by...

vestal minnow
severe urchin
#

literally everything is covered by a vaguely worded patent if you look hard enough

vestal minnow
severe urchin
#

it's not patentable in the EU I think, doesn't mean GitHub won't do something stupid in response to legal enquiries, but seems doubtful

mellow orbit
severe urchin
#

I've been on the receiving end of software patent troll nonsense before, and we just replied "we are in London, UK - go away" and never heard back

severe urchin
mellow orbit
# vestal minnow

The basic scheme is: what's patented is not a program, but rather something like " a machine which uses this process". It's a whole legal shell game.

cinder summit
#

Yea you can't patent a program, since code falls under copyright

#

And to begin with they opensourced that code 😂

#

I feel like "mathmatical methods" might be closer to what the XPBD patent describes

mellow orbit
#

Anyway, you can't patent something that's already public. The whole point of patents in the first place is to encourage publication rather than trade secrets. In return, you get a protected monopoly. (This concept isn't terrible, but the 20-year period is crazy for software.)

cinder summit
#

But algorithms can be patented to some extend, just look at the world's biggest patent troll: Adobe

mellow orbit
#

In the US, there is a 1-year exception for disclosure by the original inventor.

cinder summit
mellow orbit
#

But October 2016 is more than a year earlier than September 2018

#

Unless I am doing my math wrong. 🙂

cinder summit
#

Maybe nvidia offered some conditions to researchers that they wouldn't patent it for X time on the one hand, but the patent department still patents everything anyway

#

Might explain why they never use their patents when AMD literally copies what they just made 🤔

mellow orbit
#

I am not a lawyer and this is not legal advice. But, if you are using public information from more than a year before the patent was filed... that seems low-risk.

cinder summit
#

Opensource software with patents are generally dubious

#

The only thing it can protect against afaik is competing proprietary software, tho you can still get people to go to court which is really annoying and can discourage people from using it. Tho not big companies obviously

mellow orbit
#

The Apache 2.0 license ideal because it contains an explicit patent grant.

cinder summit
#

I'd imagine publishing research then patenting it later is a similar case too

#

You can't just publish a paper and then start going after other researchers for breaking your patent

mellow orbit
#

Indeed, you cannot.

cinder summit
#

Unreal's info about XPBD doesn't mention that it's NVIDIA's tech either, which nvidia would've surely put in the license terms

#

If epic saw a chance to not license it they would've taken it and defended it in court, and there's no info on those cases

#

The real question tho ... Why do patent offices always accept these bullshit patents?

vestal minnow
#

It wouldn't necessarily even be that big of a deal if GitHub was forced to take down the repo for whatever reason since I could make a non-xpbd version relatively quickly, but I'm primarily concerned for people using it (or if they come after me specifically ofc)

#

and it would prevent some cool cloth and soft body stuff I guess

#

also would crates.io have to take down the crates too 🤔

cinder summit
#

I think just the fact that XPBD has been used and covered in various places with clearly no sign of licensing proofs they never tried to enforce it. If they try to enforce it now they'll just get told they can't

vestal minnow
#

I also don't really want to try to reach out to them directly in case that'd just make them aware of it and react... despite there being several XPBD projects already

cinder summit
#

Unless someone suddenly causes financial damages using it ... But I'm not even sure what you'd have to compete with to cause nvidia damages

vestal minnow
#

Unreal

cinder summit
#

Competing with unreal wouldn't cause damages to nvidia, especially when unreal seems to not have licensed it either

#

Maybe if you set up some really obscure situation where everyone wants to get AMD cards instead of nvidia cards because of the use of XPBD

#

But I literally can't think of any way you could do that 😂

#

If anyone does think of a way to push AMD cards I would like to know tho, would be great to push back against this trend of opensource software only supporting CUDA thonk

vestal minnow
cinder summit
#

NVIDIA benefits from all game engines anyway

vestal minnow
#

maybe we should add a cuda feature specifically to please nvidia 🙃

cinder summit
#

I mean you can just run CUDA on AMD GPUs with vulkan 😂

#

Supposedly PhysX is also opensource

#

NVIDIA's presence in the physics world is very inconsistent and confusing thonk

#

They also do SDF stuff ... Which they publish no info 🙃

vestal minnow
#

maybe they will, first they'll just patent it

#

despite them existing for years/decades

cinder summit
#

I mean either way patenting math seems like it's doomed to fail