#Avian Physics

1 messages · Page 5 of 1

cinder summit
#

At least nintendo tried to copyright the concept of physics rather than the math thonk

vestal minnow
#

what if I rename the symbols, checkmate NVIDIA

cinder summit
#

😂

#

I think there's a theory here that makes a lot of sense tho

#

What if ... They patented it to stop patent trolls? thonk

#

NVIDIA gets hit by patent trolls pretty often, they always win but I'd imagine it's still a net cost to them because it wastes a lot of time

#

Also who the hell are these patent trolls that think it's a good idea to go after multi-billion dollar companies?

vestal minnow
#

the bigger the company, the bigger the potential bank you can make - and the further you can go into debt if it fails, like it probably will

#

also aren't big lawsuits just a USA thing?

cinder summit
#

Not just the USA, I see it happen on korean companies from time to time too

vestal minnow
#

yeah but in the EU you just can't sue someone for 10 million euro randomly

cinder summit
#

They also improved things in the USA, for copyright you now need to have a solid case before starting a case about fair use or you're forced to have to compensate the other side when you lose immediately

#

Those changes haven't happened on patents yet tho I think ... Patent law in the USA is a fucking joke

#

I mean patents generally don't even serve an actual purpose so it's not surprising the law is a joke

vestal minnow
#

I'm going to patent ECS-based game engines made in Rust, surely that'll work 👀

cinder summit
#

You'd probably get the patent granted at least

#

But if you try to sue anyone you'd lose

#

Actually I think "made in Rust" might make it impossible to patent

#

But yea a patent for ECS-based physics is probably possible, even if unity already has it in their engine

vestal minnow
#

"ECS game engine using a novel parallel executor"

cinder summit
#

I mean now we're getting close to something that actually sounds like a new idea 😂

vestal minnow
#

"ECS-based physics integrated into a game engine"

cinder summit
#

ECS-based physics with modular collision detection, written on top of a novel parallel executor

#

Patent a BVH that becomes corrupted when you update it, then sue seb thonk

vestal minnow
#

"ECS-based SDF physics"

cinder summit
#
  1. Sue nvidia
  2. Seize all their assets
  3. Take ownership of the company
  4. Opensource the XPBD patent and anything related to SDFs
  5. Sell the shares back to the original owners
    thonk
#

Hostile sdf physics takeover

vestal minnow
#

shush, they could be watching

#

don't reveal our plans

cinder summit
#

Watch them announce their plans to stop supporting SDF physics tomorrow 😂

#

Sure would be a setback to my plans of making SDFs dominate the world thonk

vestal minnow
#

also how do they distinguish simulation methods? like the patent mentions using a Gauss-Seidel solver, but what if I made a minor tweak and called it a Gauss-Seigal solver

cinder summit
#

I mean they describe XPBD as a "small addition to PBD"

#

And now it's a different simulation method

#

If you change that small addition partially because there's mistakes in the paper you could call it JondolfPBD thonk

vestal minnow
#

JPBD

#

kinda nice tbh

cinder summit
#

Especially in that it still has the PBD part that's easy to mix up

vestal minnow
#

works with my real name too

#

JAPBD lmao

#

JAPBDLMAO, that's the one

cinder summit
#

Meanwhile NVIDIA: "Initials are JA, interesting" takes notes 😂

vestal minnow
#

||It is public on my GitHub, commit history and website though||

cinder summit
#

Why didn't they call it NPBD it they wanted to patent it tho thonk

#

Or PBDWorks thonk

mossy sluice
#

I'm having some weird behaviour with the trimesh colliders. I have four walls which each are a trapezoidal trimesh. It seems the wall on the left and bottom allow my player object to phase through the inner edge on only half of one the triangle edges. Could it just be a CW vs CCW thing?

2023-11-05T203403690256404-0400.png
#

I don't think I had thi issue using rapier

cinder summit
#

I also had some trimesh collider issues before switching to SDF collisions, some change on main might've introduced some issues with 0 thickness colliders

mossy sluice
cinder summit
#

Trimesh colliders have no volume, it's just the outside surface

mossy sluice
vestal minnow
#

It's hard to say, but you could maybe try using trimesh flags for preprocessing them, like this

Collider::trimesh_with_config(Vec<...>, Vec<...>, TriMeshFlags::ALL),
#

I haven't really seen them do much though

#

It definitely could be a CW/CCW thing too, I believe Parry requires CCW for triangles

#

(Parry is the collision detection library used by both Rapier and bevy_xpbd)

mossy sluice
vestal minnow
#

Also what's the scale here? How big are the walls and the player? (roughly)

mossy sluice
#

I set the camera's orthographic projection to baically set a square -1 to 1 scale in the window

#

Which I assume is why the debug renderer is going weird

vestal minnow
#

yeah that's what I was thinking, the debug renderer assumes pixels in 2D currently

mossy sluice
#

logic

mossy sluice
vestal minnow
#

I haven't really tested the engine in this kind of small 2D scale before so I don't know if it could also have numerical issues, the examples just use default cameras and normal pixels (in the future, something like rapier's physics scale will be added though)

#

although generally numerical precision should be better near 1

#

so I don't think it should be an issue in your case

mossy sluice
gentle steppe
#

I'm walking into the middle of a discussion so I'm probably going to say something dumb, but could you rotate it on the y-axis to turn it around? I guess in bevy 2d maybe that's not an option?

#

I've definitely done that in other game engines instead of using a flip

#

But in those, you did 2d as a subset of 3d

vestal minnow
#

yeah you can't really do that in pure 2d

#

since rotation is just an angle in radians

#

you'd have to simulate 2D with bevy_xpbd_3d, which might be possible using LockedAxes, but inconvenient

gentle steppe
#

bevy 3d apparently won't render sprites

#

You'd have to do your own quad + texture solution

#

Sorry, typo there.

vestal minnow
#

you could do collider.shape_scaled().as_trimesh().unwrap().reverse() maybe

mossy sluice
#

reverse() mutates the trimesh in place

vestal minnow
#

hmm, I could've sworn I added a mutable version 🤔 doesn't look like it though

#

you can get a copy of the shape, mutate that, and create a new collider

#

using Collider::from(my_shiny_new_shape)

mossy sluice
#

Ok I'll try that, but do I need to use shape_scaled instead of just shape though? I'm applying the transform via the component not through the shape itself.

vestal minnow
#

yeah just shape

mossy sluice
#

Wait, the SharedShape stores the trimesh with an Arc, so I think you're supposed to downcast to a trimesh Arc then grab mutability from the Arc?

#

I don't know, when I try to clone the trimesh, it's throwing me a different generic type, it's too confusing.

vestal minnow
#

yeah the Arcs and generics in Parry are quite annoying

#

I guess you can just create a new collider from the vertices and indices, but reverse it
Parry's reverse for 2D is just this apparently

self.indices.iter_mut().for_each(|idx| idx.swap(0, 1));
mossy sluice
#

I think you can do the reverse() thing if you had a shape_mut method since you could downcast_mut::<TriMesh> from there

vestal minnow
#

yeah I think I had shape_mut but it's gone for some reason now, I'll add it back soon though

mossy sluice
#

I'm not really sure how to detect if the triangles in my trimesh are CW or CCW because I'm just generating the mesh from the two points the wall is supposed to span across and the inset normal.

royal helm
#

I'm curious on whether kinematic or dynamic body based controllers are faster

#

my intuition says dynamic, but I'm not sure

cinder summit
#

Depends on what you're doing with either. Dynamic bodies are pretty likely to be faster tho, since you can benefit from the physics engine's optimizations for collision response stuff

vestal minnow
#

what optimizations :p

royal helm
#

Yeah that is what I'm thinking, also a fully featured kinematic will probably have to reimplement most responses themselves

mossy sluice
vestal minnow
#

kinematic bodies don't require a velocity solve unless done manually

#

(friction + restitution)

royal helm
#

I suppose my thing with the controllers would be it'd be fully robust in each

cinder summit
royal helm
#

Idk if there is a non shapecast kcc that is robust

#

Unless it's like

#

Dot colliders

#

maybe I'm wrong though

vestal minnow
#

the kcc example in the repo just does naive collision response without shapecasts

#

probably not super robust tho

#

and doesn't handle stairs etc.

cinder summit
#

You can make a fairly robust one with a small number of shapecasts

#

But it's still more shapecasts than a floating dynamic controller for example

#

You can also just replace those shapecasts with sphere casts on SDFs and reduce the worst case cost of it by a lot thonk

cinder summit
royal helm
#

Naw just a curiousity

#

I'm making a moba with xpbd probably and going to do a kinematics one this time

#

mostly for complete control

cinder summit
#

As long as you don't have trimesh colliders you're probably going to be fine

#

And if you do you can always switch to sdf physics later 😂

mossy sluice
#

I was able to fix my trimesh collider issues by ensuring the vertice were CCW

vestal minnow
#

Nice :)
I wonder if rapier does something to fix them automatically if it was working there... last I checked, I don't think it did, but I don't remember

cinder summit
#

Great now I have one more reason to hate trimesh colliders

vestal minnow
#

lmao

cinder summit
#

Right after not being SDFs and having garbage performance thonk

mossy sluice
vestal minnow
#

I should probably sleep now

#

it's 4 AM and I have school tomorrow (today?)

mossy sluice
vestal minnow
#

I did manage to do the economics homework during this conversation btw

#

yay

mossy sluice
#

I believe it's a political science XD

mossy sluice
shell ermine
#

in the US damages are trebled if you knowingly violated the patent

#

which is why most companies discourage you from looking at patents

#

and if the paper/code was MIT then it didn't include any patent grants

#

which is why the rust ecosystem generally does mit+apache2 for foss stuff

#

and it doesn't matter if you're right or wrong, because I'm 99% sure you don't have enough money to fight it in court

mossy sluice
#

Why are you randomly talking about licensing and patents?

cinder summit
#

Was an earlier topic

#

NVIDIA has patents for something they opensourced about 2 years before they patented it, which makes absolutely no sense

mossy sluice
cinder summit
#

That 2 years things makes the patent invalid, and opensourcing things with patent rights is generally a hard to win fight that's mostly just used for patent trolling

shell ermine
#

yeah

#

you're probably fine, but I don't think it could be upstreamed without an explicit approval from nvidia

#

can't use some of their rendering stuff cuz of bad licenses/patents

cinder summit
#

Especially since cart (and thus the bevy organization) isn in the USA and not the EU

cinder summit
shell ermine
#

software patents are generally a lot more tightly scoped

#

in theory

#

and amd has lawyers and money to fight bad patents

cinder summit
#

Yea I'm pretty sure AMD makes sure it won't get them in trouble first

#

NVIDIA never releases good info on the stuff either so AMD has to tank almost the full R&D costs for it too 🤔

vestal minnow
shell ermine
#

amd is big enough they can clean room reverse engineer stuff

#

if they need to

vestal minnow
cinder summit
#

And we haven't invented JPBD by then yet thonk

#

SPBD ... Sdf PBD

vestal minnow
#

I'll have to go in the lab and invent something novel then

shell ermine
#

then get an internship at nvidia and publish it through them, and end up with it patented by nvidia

#

🙃

vestal minnow
#

feel free to banish me from the community if I do that

cinder summit
#

But if jondolf betrays the community, who will make our physics?

#

Where are we gonna find another highschooler than knows physics and rust

vestal minnow
#

I'm not some physics genius, just read a few papers and generally value high quality docs, presentation, modularity etc.

#

I feel like a good readme goes a long way lmao

mossy sluice
cinder summit
#

I mean we have like 3 people in the bevy community that value docs this much 😂

vestal minnow
#

Alice ofc, who's the 3rd one?

cinder summit
#

That's a secret, can't reveal the results of the documentation competition yet 👀

#

Actually I think no one besides you and alice would do the cfg docs thing

vestal minnow
#

Yeah I might be just in the top 20

#

Cfg is love, cfg is life

timid holly
#

I was quite surprised to find out you were a high schooler Jondolf

#

Very impressive

vestal minnow
#

Thanks

#

That's what people say

#

I'm just obsessed over developing it

timid holly
#

I excelled a lot as a teen, that's where most of my passion for it came from

#

I'm 24 now

cinder summit
#

At first I was surprised, but once I started working on the SDF collisions it seemed a lot more normal to me

#

You just start working on something that's an infinite rabbit hole and you never get out

vestal minnow
#

For me the rabbit hole is bevy_physics

#

It's quite a deep one

cinder summit
#

bevy_sdf and bevy_physics will surely be the next two bevy crates thonk

#

We need to at least beat bevy_editor right

vestal minnow
#

bevy_geometry for the shape primitives too

#

Eh, sdfs are good enough for primitives

#

Use them for rendering

cinder summit
#

Would be cool if we could mix SDFs and mesh colliders with primitives

#

Both can interact with primitives, and most of the primitives are the same

#

Tho some primitives might be easier with one over the other

vestal minnow
#

Then have unified spatial queries that work with the same API against meshes, colliders and SDFs

cinder summit
#

I'm plotting to make torus-arbitrary sdf collisions work thonk

#

If all spatial queries are done with primitives it would be fairly doable actually

vestal minnow
#

Just need trimeshes somehow

#

And convex hulls

cinder summit
#

I mean I don't think there's any valid cases for shapecasting those

#

Shapecasts run poor enough without that 😂

vestal minnow
#

Yeah rather I meant objects to cast against

#

Not the shape being cast

cinder summit
#

Ah yea, you could just use regular polygon collisions between primitives and trimeshes and convex hulls

#

And sdf collisions for primitives on sdfs

vestal minnow
#

I'm a beast on summer vacation, and next year it'll be extended since I won't have pretty much any school after March

#

until fall

cinder summit
#

bevy_xpbd 0.28 next year thonk

#

It will have 3 million features we don't have yet now

vestal minnow
#

We'll get to 0.20 before bevy does

#

Power move, go straight to 1.0

cinder summit
#

A 1.0 crate for a 0.x game engine

#

What is this tokio? 🙃

shell ermine
#

can you have a crate depend on a previous version of itself

#

just make each new release of xpbd have only 1 feature

#

and depend on the previous versions for old features

#

for the most nightmarish cargo update experience

mossy sluice
cinder summit
cinder summit
mossy sluice
#

And the negative scale means I have to reverse the orientation to keep the points ccw

cinder summit
#

Ah, yea commands is probably gonna be the easiest there. Or maybe you can do some tricks with a SystemParam

mossy sluice
#

Uh, so I think a new CollisionStarted event is being created when moving an object within a sensor despite the object never leaving the sensor, is that a bug? 😓

cinder summit
#

I think Jondolf mentioned there was a big like that earlier

mossy sluice
#

Well, that kind of sucks, I guess I can hack around it for now

#

Unless it ends up spamming CollisionEnded events too

#

Oh damn, I didn't realise this guy made Yew too, impressive

mossy sluice
mossy sluice
#

I guess just screw sensors then

#

honestly don't even know why that other guy was even die harding this library at this point

cinder summit
#

Can't really have another collision start if it never considered it to have ended right? 🤔

mossy sluice
#

Kind of a weird bug though

cinder summit
#

I always use CollidingEntities so I never ran into this issue, tho I have had some issues with it not getting cleared before, tho it works fine atm

mossy sluice
cinder summit
#

I think it might be related to the substeps, if there's say 12 substeps it might be considered touching for 10 steps then not for 2, and then it would give you both

mossy sluice
cinder summit
#

With sensors that wouldn't happen as much, but with regular collisions the whole goal is to stop them from colliding

mossy sluice
mellow orbit
#

That does sound like a bug.

mossy sluice
#

Huh, apparently my bevy_xpbd version is behind as of 7 hours ago, I guess I could pull the new version just to see if that fixes anything

#

Well, upgrading the package made my application completely unusable

#

It could be related the scale I'm using, so I'll try changing that

mossy sluice
#

pain

cinder summit
#

#1124043933886976171 message
I think it's this issue

#

For now you could just work around it by storing the entities that are colliding with the sensor in a component, then when CollidingEntities changes seeing what got added/remove and doing something on those 🤔

vestal minnow
# mossy sluice Ok so I had an issue with collision events being spammed when dealing with senso...

Yeah my guess for the event spam is that the scale doesn't work nicely. The narrow phase prediction depth assumes you're using unscaled pixels by default, and it acts kinda like a padding around your colliders for making sure it doesn't miss collisions, but in your case that padding was way too big because of the scale.
I would've assumed that multiplying the scale of everything expect the prediction depth by 100 would work, but weird if it doesn't

merry tide
#

I got the server ghost stuff to work. Seems like a simple thing, it was a little finicky doing the JavaScript -> WASM communication. But now you can post your time and decide if you want to race a different player. This is coming along relatively nicely.

#

The ghost replay stuff is super naive and sometimes the ghost is a lot faster. This is not related to the physics engine, this is all on me.

#

Sorry, what I was trying to say is that the update went well. Only thing that doesn't seem to work is the asset server in Bevy 0.12 for web.

mossy sluice
#

It seems it specifically resends the CollisionStart event when the entity starts to move again while contacting the sensor

mossy sluice
vestal minnow
#

Is it sending them constantly, or only when you've been still for a while and then start moving?

mossy sluice
#

Which I guess might be why it's only an issue with sensors, because otherwise the contact forces would ensure movement until the collision is over.

mellow orbit
#

@vestal minnow Could the entity overlap warning print the Name of the entity in addition to the id? That'd make debugging a lot easier!

#

I can probably work on a patch to add that this evening....

mossy sluice
#

This seems weird

// Reset collision states if either of the bodies is active (not static or sleeping)
// Otherwise, the bodies are still in contact.
if active1 || active2 {
  println!("test");
  contacts.during_previous_frame = true;
  contacts.during_current_frame = false;
  contacts.during_current_substep = false;
} else {
  contacts.during_previous_frame = true;
  contacts.during_current_frame = true;
}

start
test
test
test
test
test
test
test
test
test
end

It seems like it's making more than one "contact" for the collision, is this supposed to happen?

#

It seems to increase the number of contacts as I move the entity during the collision

#

When you're collecting the collisions I notice you're doing this

collisions.extend(new_collisions);

I think it may be possible you're just not flushing the contacts properly?

#

This is just what I'm gathering after skimming through things, could be wrong

pulsar bone
#

Depending on the shapes of the colliders you could have multiple contacts, is the event code not handling that properly?

cinder summit
#

Would be easy enough to test by changing the collider I guess 🤔

mossy sluice
pulsar bone
#

Multiple contacts being possible is new since 0.3, right @vestal minnow? Maybe the event code wasn't updated at that time

cinder summit
#

I'm not sure when manifolds got added, but multiple contacts were always possible I think. But that code has been changed a few times, I've seen issues with CollidingEntities not being correct at least twice, and I think that uses similar logic

mossy sluice
#

Ok so, the contacts were reset, got 12 substeps, then the contacts were reset again with no new contacts generated

start
reset
contact generated
contact generated
contact generated
contact generated
contact generated
contact generated
contact generated
contact generated
contact generated
contact generated
contact generated
contact generated
reset
end

Since it sends the end event when the entity stops moving it seems it has to be related to the sleep condition? Perhaps it's going to sleep too late?

vestal minnow
vestal minnow
#

which could maybe cause buggy collision events

#

although I did test it some time ago and it worked... maybe something broke it again

#

you could try with SleepingDisabled component to see if it's sleeping related

vestal minnow
#

I struggled quite a lot to even get it working as well as it does

#

I plan on reworking it though, could at least have a CollisionStatus enum or something instead of the 3 separate bools

mossy sluice
vestal minnow
mossy sluice
#

I think I found the issue! in the broad phase you're setting the AABBs as "inactive" when the position and rotation hasn't changed, then because of that when you're creating the broad collision pairs you're ignoring all of the AABBs that haven't moved. This doesn't involve the sleeping component at all. So when at the narrow phase you're going through the broad collision pairs you're not inserting the new Contact after the reset saying the collision is still hapenning.

start
inactive
inactive
inactive
inactive
inactive
end
#

I hope this is right

vestal minnow
#

Ah, thanks for looking into it! There was some reason it uses the changed status for position and rotation, but I can see why that could cause issues

#

it can probably be changed back to use Sleeping, just need to verify it doesn't break other things

#

do you happen to have a simple repro of the issue? I could use that for testing things

#

if not, I can make one too

mossy sluice
vestal minnow
#

yeah I can make a simple repro and test when I have time

#

thanks

mellow orbit
#

I'm getting a lot less explody behavior with 0.3.x, but still some weirdness. This is in 3D, and I'm finding that if I insert space between my joints (that is, attach the rigid bodies not at their nominal surfaces, but a tiny bit apart), I get pretty good behavior, but if I make the joints actually exactly aligned, I get weirdness.

#

I haven't tested exactly, but it seems like a space of 1/64 keeps the different parts from colliding. With 1/128 or smaller, I still get good behavior -- and I also see collisions (cyan debug is on).

#

If I go to 1/1024, though, I get occasional explosions.

#

Is this floating point precision issues, or something else?

vestal minnow
#

could be

#

I wonder if switching around the constraint order would help though 🤔 handle joints first, then collisions

#

I can test if I can repro

#

which joint is this?

mellow orbit
#

They're all revolute joints

#

one of them was supposed to be a spherical joint but that didn't work right for some reason

#

and actually I couldn't get fixed joints to behave either, but I need to revisit

vestal minnow
#

revolute joints are working with 0 distance between surfaces for me

#

tried different rotations too

mellow orbit
#

They work, but then sometimes all of the sudden there's an explosion (as I'm moving the composite character around)

#

or also (not investigated yet) it seems like angular force gets compounded (force without persistence -- haven't switched to impulse) and the thing starts spinning like a top and then eventually vanishes. but this only happens when they're touching or close

vestal minnow
mellow orbit
#

I'll have to double-check that I haven't got some logic error, but it also seems that I have to start the rigidbodies with a separation of at least 0.01 to avoid having them considered overlapping

#

I've gotta go get lunch but I'll poke at it more and send examples later this evening or this week

#

I have to fix my camera, too -- I never got that ported from rapier properly 😉

vestal minnow
#

and yes they are dynamic, I just disabled gravity

vestal minnow
#

there was no overlap warning prior to 0.3

#

but I assume it's visible otherwise

#

yeah

mellow orbit
#

Here's what I'm seeing. My "robot" is connected by revolute joints, with the "foot" sphere aligned to the X axis and with .with_angle_limits(-PI / 32., PI / 32.) -- I had used a fixed joint here and that was totally not working for some reason I've forgotten. The head is attached to the body aligned to the X axis, so it can turn (with limits at ± pi/2). If the D key is pressed on any frame, it sets torque to -- well, I think it's pi, for some reason, but whatever, "some smallish number". When the D key is released, it sets force to 0.

#

With a space of 1/256 added between the joints, I get what I expect (and roughly what I had with rapier). (This is me just holding down the D key for 20 seconds or so)

vestal minnow
mellow orbit
vestal minnow
#

if raycaster has max_hits = 1, then yes they should be

mellow orbit
#

(Oh also note that in all of my examples I am starting with everything pushed away by .0101 so they aren't immediately overlapping. Physics is off at the beginning, and when I enable it, the joints pull everything together

cinder summit
#

Also whats with people getting explosions with things overlapping? I spawn enemies in my walls and they just stay there 😂

vestal minnow
#

max_hits = 1 uses best-first search and finds closest hit, others use depth-first search and can be unordered yeah

#

and cast_ray is basically max_hits = 1

cinder summit
#

Ah ... gotta love them edge cases

#

My SdfSpatialQuery just has ray_hits, it's never ordered, so if you want 1 thing you just store the best result 😂

#

It's honestly not even that annoying, since very often you need to do some extra checks because the collision layer is a bit too broad for the logic (like a combat layer instead of a Player and Enemy layer)

#

Distinguishing between those would be bad practice anyway, cause there's also PvP thonk

vestal minnow
#

I also noticed that the overlap warnings are also wrong since they rely on the prediction distance too

#

so it's triggered unnecessarily

#

I can fix that very easily tho

#

yeah probably, but it fixes the overlap warnings for me at least so it's still worth doing

#

can also verify that it is in fact an overlap collision in your case and not something else weird

#

(although it probably is a collision)

mellow orbit
vestal minnow
#

the spawn overlap warning should be fixed on main now

#

(also merged the log PRs @mellow orbit)

vestal minnow
#

they're not vanishing for me, but it does give the overlap warning yeah

#

the debug rendering shows they're there, they just don't have a mesh

#

or texture

#

Update

#

I changed the radius to 10.0 but same with the original 1.0

#

(but does print overlap warnings for some reason)

#

oh I think I've been misunderstanding your issue lmao, I thought the issue was that they "disappear" because the overlap causes NaN values or something, but by disappear you mean that you're specifically trying to despawn them, but not because of the wall that they're ricocheting off of

#

yeah well the CollisionStarted issue is this again #1124043933886976171 message

#

you can get slightly better behavior with NarrowPhaseConfig prediction_distance = 0.0 but that'll probably cause collision stability issues

#

but yeah you could also just spawn the ball about 1.0 px (or a bit more) before the toi

#

or rather move 1px in the direction of the normal I think

#

yeah

#

technically you can have a negative prediction distance 🙃 then every collision will just be detected a bit late

cinder summit
#

If you do a shapecast and then spawn a same size collider at that point they should be colliding at least 🤔

vestal minnow
cinder summit
#

It just needs to be a small amount away from the toi there

#

the toi is the point where it hits, so you'd be relying on floating point errors to have it not consider it colliding at that exact point, or you'd need to make the rules for what is colliding different

#

Like "it's only colliding if it's penetrating enough or moving against the other collider"

vestal minnow
#

*toi is time of impact when a point is moving along a ray with some specified velocity

cinder summit
#

Yea, you need origin + direction * toi to get the point

#

At which point you already have some floating point error probably but whatever 😂

vestal minnow
#

if direction is normalized

#

because it matters in parry apparently

cinder summit
#

I remember it behaving the same if direction isn't normalized

#

Despite the docs saying it normalizes it either way

vestal minnow
#

parry docs don't say it's normalized I'm pretty sure

cinder summit
#

Yea I think it's rapier saying that

vestal minnow
#

and anyway seb verified #math-and-physics message

#

I don't like how it's called dir in parry

#

but shapecasts use vel

cinder summit
#

But yea what seb says there confirms my formula works

vestal minnow
#

yeah it does

cinder summit
#

You just shouldn't put in unnormalized vectors because it'll make your brain melt 😂

#

My BVH and SdfSpatialQuery have the same behavior, but I plan to put in the docs that you should pass in a normalized vector. People can ignore that if they want tbut then it's their fault at least

#

My BVH also misbehaves if direction is very small, because the workaround for costs more cycles per aabb check

vestal minnow
#

yeah in 0.4 I'll probably normalize it automatically and then have distance instead of time_of_impact

#

which is what most engines have afaik

#

with bevy_geometry we could also use Ray2d and Ray3d which are automatically normalized

cinder summit
#

You do want to be careful with it, putting in extra normalizes on things that are normalized already can add up to a lot of extra calculations

vestal minnow
cinder summit
#

Yea there's various solutions, just something to keep in mind

#

"Future possibilities"
"SDF rendering"
It was in the plans all along? thonk

vestal minnow
#

not SDF physics 😢

cinder summit
#

It says collisions

#

SDF collisions are surely the only glam collisions out there right? thonk

vestal minnow
#

I think it actually would be if it was public

#

I can't find any

cinder summit
#

Yea my SDF collisions are only accessible to like 5 people 😂

vestal minnow
#

I still haven't even checked them out, I probably should

cinder summit
#

Just beware of really big enums and impl blocks

#

I should probably rewrite it using traits and use enum-dispatch or something for the main type 🤔

vestal minnow
#

lmao there's actually an sdf_peck module

cinder summit
#

It's a crate even ... The repo has a lot of crates that need to be split out 😂

vestal minnow
#

It looks really nice honestly

mellow orbit
#

Is there an example of DIstanceJoint anywhere? I seem to have discovered a fun new way to yeet things into infinity 🙂

vestal minnow
cinder summit
#

I don't even have that many tests 😂

vestal minnow
mellow orbit
vestal minnow
#

probably wrong anchor positions

#

I should do the auto config anchors like physx

mellow orbit
#

yeah, you can see that they're right in the middle

#

but why does that matter?

vestal minnow
#

are they at the same point in world-space?

#

and what's the rest length

mellow orbit
#

let leash = DistanceJoint::new(target_id, globe_id).with_limits(0.01, 1000.0);

#

although I tried it .with_rest_length of various values too

#

without the "leash" the ball just drops to the ground and bounces, of course

vestal minnow
#

you could try just DistanceJoint::new(target_id, globe_id).with_rest_length(target_pos.distance_to(globe_pos))

#

or whatever you want the leash length to be

#

but it should be the same as the distance between the anchor points

mellow orbit
#

I'll try that, but ... does with_limits not do what I'd hoped?

#

I'd like this to act like a rope, not a stick...

vestal minnow
#

I'm pretty sure it should work as long as the rest length is within the specified limits

#

but it's 0.0 by default iirc

mellow orbit
#

testing that...

#

nope set it to 2.0 and zoooooom 🙂

#

but let me use the exact right value...

vestal minnow
mellow orbit
#

okay if I set the rest length close to whatever is correct at first, that seems better

vestal minnow
#

I have zero issues with just this

commands.spawn(
    DistanceJoint::new(static_cube, dynamic_cube)
        .with_rest_length(2.5)
        .with_limits(0.75, 3.5),
);
#

(static_cube can also be dynamic, no difference)

mellow orbit
#

I've got ```
let leash = DistanceJoint::new(target_id, globe_id)
.with_rest_length(target_transform.translation.distance(Vec3::new(2.0, 3.0, -2.0)))
.with_limits(0.5, 500.0);

#

(I'm moving the robot -- both dynamic)

#

ah, hmmm. setting "compliance" reaallly low might help

vestal minnow
#

*high

#

inverse of stiffness

mellow orbit
#

oh yeah 🙂

vestal minnow
#

probably 0.01 should work already

#

or even 0.0001

mellow orbit
#

hmmm still very rigid at 0.01.

0.1 works

cinder summit
#

Cause I may want to refactor my SDF logic to use bevy shapes where possible 😂

mellow orbit
#

10.0 is even better for what I'm looking for 🙂

vestal minnow
#

...

#

soon™

#

after I begin

cinder summit
#

Ah so it's like a bring your own bevy_primitives and then get it merged in bevy before you start kind of thing? thonk

vestal minnow
#

yes

#

but yeah idk what I should be prioritizing honestly

cinder summit
#

I feel like I already have a bunch of things in this RFC

vestal minnow
#

joint motors and other joint things? constraint optimization? spatial query API improvements? bevy_geometry?

cinder summit
#

Raycasting on bounding volumes? I already implemented that ... I also have a bunch of primitives 😂

vestal minnow
#

takes notes

#

bevy_geometry tomorrow :)

cinder summit
#

If you're looking for raycasting stuff you can find it in the bvh crate 😂

vestal minnow
#

wtf is morton_encode

cinder summit
#

It's a uh ...

vestal minnow
#

maps coords into bit form somehow

cinder summit
#

space filling curve

vestal minnow
#

oh

cinder summit
#

What does that mean? Idk I just followed the blog Griffin linked 😂

vestal minnow
cinder summit
vestal minnow
#

ah yeah this tutorial series thingy

#

it looked nice but haven't read it properly

#

yet

cinder summit
#

It seems pretty decent, but it starts out very complex, there's actually a later post that is a simpler introduction

#

And it's hard to translate to Rust because the C++ code is just really cursed

vestal minnow
# 
// TODO: dim4?

👀

cinder summit
#

I mean if I make my BVH have 2D support, why not 4D support too 😂

#

Keeps the door open for 4D SDFs thonk

vestal minnow
#

4D cloth and soft bodies in the horizon

cinder summit
#

RiiS 4D gold thonk

#

(Reimplement it in SDFs)

vestal minnow
#

oh god, delauney pentachoronization for 4D meshes

#

triangulation and tetrahedralization are already bad

#

(and no, I didn't know what a pentachoron was prior to this)

mossy sluice
#

I got my topology thing kind of working, don't have rotation or scaling implemented yet though, and there seems to be some issue with how I'm deleting the projections when the player stops intersecting an edge because I'm getting warns about double despawns.

2023-11-06T182715213286842-0400.png
#

But as it is now, torus physics should work perfectly fine in theory

#

doughnut ferris_spooky

#

I'm wondering how I am going to work out how to "clip" the rendering of the meshes and the colliders though.

cinder summit
mossy sluice
cinder summit
#

Oh hey the SDF for a torus is really simple ... I should implement it
Just look at this simplicity:

  vec2 q = vec2(length(p.xz)-t.x,p.y);
  return length(q)-t.y;
mellow orbit
cinder summit
mellow orbit
#

The first part is just moving the character around. In the second half, moving the camera.

mossy sluice
mellow orbit
#

The camera is Dominance -127, and there's a system to slerp it to look at the character

#

and the input is enabling ExternalForce.

#

Placeholder ground needs to be fixed, obviously

#

And I need motors to keep the head looking forward 🙂

cinder summit
mellow orbit
#

Or something like rest_limit for revolute joints.

vestal minnow
mossy sluice
vestal minnow
mellow orbit
#

maybe it is an electromagnet

cinder summit
#

Maybe it's a donut and you can hook it onto things

vestal minnow
#

SDF donut that can be molded into different shapes smoothly

cinder summit
#

Not sure if we can do collisions while modling between different shapes ... I can't imagine that wouldn't make it bound thonk

mossy sluice
#

Oooo yeah if the shape is defined by a function you can just change the coeffecient for shape blending

vestal minnow
#

yeah probably not, but it'd be really cool

#

marble marcher tho

cinder summit
#

Yea the terrain can probably morph just fine

#

As long as the exterior gradients don't distort it should be fine

vestal minnow
#

what do gradients mean in this case? the same as in math, i.e. the direction in which the function icreases the most?

cinder summit
#

Yea, the direction in which distance increases

#

It's how you get the normals for collisions

#

The distances tend to also get distorted when you break the gradients, but you can sort of work around distances being subtly incorrect

vestal minnow
#

I seriously need to write more tests though, you already have like 10x our tests if we discard doc tests which mostly check that things compile

#

I'm pretty sure there are 0 spatial query tests 😂

cinder summit
#

Write CollisionStarted/Ended/CollidingEntities tests

vestal minnow
#

yeah that'd be very useful

cinder summit
#

Tho in a way you could say my game is a test for spherecasts and shape intersections too thonk

vestal minnow
#

it's good for dogfooding bevy_xpbd

#

except sdfs ig they showed that the narrow phase should be more modular actually

cinder summit
#

Me using sdf collisions definitely does result in me finding less bugs, mostly just some architectural issues to the modularity stuff

#

But realistically parry bugs don't get fixed anyway 👀

vestal minnow
#

still no docs or real examples 😭

mellow orbit
vestal minnow
#

optionally specify the axis using with_aligned_axis

mellow orbit
#

The angle limits are like the min,max limits on the DistanceJoint, right? And the aligned axis needs to be Y, so the head can turn...

vestal minnow
#

yeah it's just min and max angles in radians

#

and aligned axis of Y would mean that it can e.g. look left and right

#

I think

mellow orbit
#

Yes.... let neck_joint = RevoluteJoint::new(body_id, head_id) .with_aligned_axis(Vec3::Y) .with_local_anchor_1(Vec3::new(0.0, TORSO_HEIGHT + JOINT_SPACING, 0.0)) .with_local_anchor_2(Vec3::new(0.0, HEAD_HEIGHT / 2.0, 0.0)) .with_angle_limits(-PI / 2., PI / 2.);

#

but it's the z axis (in local space) that I want to set as the "rest limit", while still having this other limits. It seems to me to be almost exactly the rotational version of what the distance-joint is linearly (if the distance joint were fixed in place and along a line).

vestal minnow
#

so do you want limits along two axes? like looking up/down and left/right

#

or just one

mellow orbit
#

For now I'd be happy with just one.

#

Limits exactly like I have above, except a springiness returning to the center.

vestal minnow
#

ah so min and max angles, but it should still try to return to the rest position (looking forward)

#

unless I'm misunderstanding

mellow orbit
#

yes, exactly

vestal minnow
#

a hacky workaround would be to have two revolute joints for the same entity pair; one would be a hard constraint with the angle limits, and the other would be a very soft constraint with [0.0, 0.0] as the limits

mellow orbit
#

eventually I might want some more sophisticated version allowing looking up and down and tilting to the side (like, human neck is a pivotal joint technically but close enough to a spherical joint.

#

Oooh, I'll try that!!!

vestal minnow
#

the soft constraint would just have a very high compliance to make it softly push the head to the center

mellow orbit
#

or a low compliance if I want to really make it stay there, yeah?

vestal minnow
#

yep

mellow orbit
#

actually, that works great. is there any downside?

vestal minnow
#

not really, I guess it's a bit more expensive to have two separate joints, but it shouldn't matter since it should be able to handle even hundreds (or thousands?) just fine

#

probably thousands

#

I should make an example/benchmark that simulates thousands of slightly offset pendula with different colors to display the butterfly effect in action as well as testing joint performance

#

bloom could make it look pretty with the rainbow colors

mellow orbit
#

Experimentally, Compliance of around 10.0 gives me a nice soft effect which tends towards the intended direction. I'm thinking I'll leave it like that normally, but then adjust it to be somewhat lower when I want to have the robot actually look at something of interest or whatever.

vestal minnow
#

That looks pretty good :P

mossy sluice
#

Got a cube to loop forever, unfortunately I couldn't take a video because wayland is being sassy

2023-11-06T221832543685527-0400.png
#

And the program crashed, pain

mossy sluice
#

Anyway, soccer on a torus is fun

mellow orbit
#

I also notice that (space or not) the arms don't seem to ever sleep. That's odd.

#

Hmmm no, still happening but more rarely. sigh.

royal helm
#

also the unfortunate thing right now is that negative scaling doesnt work with all colliders nor could it very easily

#

I was thinking maybe a translation or rotation might be able to mirror some of the scaling easily

#

but im unsure atm

vestal minnow
#

I would imagine that it'd be possible to flip X/Y/Z for all shapes somehow

royal helm
#

it is, it just requires a lot of internal digging

#

inside parry

vestal minnow
#

Yep

royal helm
#

cones for example would need to be reworked a lot

arctic fulcrum
#

I have a relatively basic scene as a demo (character controller + static boxes) - the game seems to freeze for a few seconds after starting with some frames taking (by eye) 100ms or more - but after playing for maybe 5 seconds, it usually "recovers" and runs smooth (60fps?). I'm on a 2017 Macbook in case that's relevant, running Bevy 0.12.0. At least once, though, I've seen it get slower and slower until it freezes completely and apparently never recover.

I'm wondering if there's some kind of "death spiral" from attempting to be fixed-timestep, and it just happens to usually recover?

I haven't completely ruled out any other causes, but there's not much in the demo besides bevy_xpbd

arctic fulcrum
winter pebble
#

Does enhanced-determinism feature enables full cross-platform determinism?

#

And is it compatible with parallel or simd?

vestal minnow
winter pebble
#

I'm interested in win/Linux/android

vestal minnow
#

Compatible with parallel for now at least, but not compatible with simd

winter pebble
#

I see

#

If I want max performance, should I ignore determinism and enable parallel+ simd?

vestal minnow
#

Because I believe simd depends on architecture implementation details

vestal minnow
#

But the difference probably isn't huge

winter pebble
#

If I want just 2d physics with some rigid bodies and a lot of non-rb colliders (mostly circles), how much worse performance should I expect compared to Rapier?

vestal minnow
#

If you don't have thousands of dynamic bodies constantly colliding with each other, performance should be just fine

winter pebble
#

It's a bullet hell

#

RBs are mostly ships

#

And a lot of bullets that collide with ships but not each other

#

Most of bullets are not RB but manually controlled

vestal minnow
#

#1124043933886976171 message

#

Should be fine even if they collided with each other, and if they don't, then it definitely should be fine

winter pebble
#

Wow

#

Yeah, will try it first then

#

Will need to think of some way of automatically generating collision shapes for ships based on their sprites tho

#

People expect shape-accurate collisions since ships can often be pretty large

#

Not a touhou situation where I can have just a small dot as a collider

vestal minnow
# winter pebble Will need to think of some way of automatically generating collision shapes for ...

Haven't tried it, but Rapier has this: https://github.com/shnewto/bevy_rapier_collider_gen
It's small enough that it should be straightforward to adapt for bevy_xpbd, especially because they both use parry

GitHub
GitHub - shnewto/bevy_rapier_collider_gen: a library for generating...

a library for generating bevy_rapier2d colliders, for bevy apps, from images with transparency - GitHub - shnewto/bevy_rapier_collider_gen: a library for generating bevy_rapier2d colliders, for bev...

winter pebble
#

Works for 16x16 Sprites, but we operate on up to 1024x

#

But well, nothing some collider optimisations can't solve

mellow orbit
#

Replaced the arm connectors with DistanceJoint. I'm still getting occasional yeets into the ether that I don't understand. 😦

#

here, arms and head, but occasionally other things light too...

mellow orbit
cinder summit
#

2023-11-08T01:44:24.855462Z WARN bevy_xpbd_3d::plugins::solver: 192v0 and 194v0 are overlapping at spawn, which can result in explosive behavior.
Huh, I guess I just never pulled that change before

timid holly
#

Is there any way to change that behavior? I know it's more of a side effect, rather than intended behavior, but is there a good way to prevent explosive behavior like in particular

cinder summit
#

In my case I don't even get explosive behavior ... Just a warning

#

The collisions I initially get might also be wrong, because I'm getting static-static collisions too ... Gonna have to see what causes that

mellow orbit
mellow orbit
#

BUT there are still explosions that can happen even without overlapping start items. That's just one of the most surprising

#

I'm not sure it's easy to determine what a more-real-feeling failure state would be for some of these possibilities.

#

But I'm really, really sure that "two slowly moving medium-weight objects bump in just the wrong way and then react with the force of a million atomic bombs" is not it

cinder summit
#

I think there is only really one case where you can't produce a reasonable collision response

#

Which would be when the collision point ends up being at the perfect center of another collider, which can't produce valid normals

mellow orbit
#

I think the first step might be to put in checks (maybe as an optional feature) for Surprisingly High Delta-V in the physics steps, and

  1. log them with warnings and
  2. clamp them to some limit, or even lower them to 0.
#

maybe also a "trace" level log at that point with enough information to figure out what went wrong. not sure how hard that would be.

cinder summit
#

In my case enemies just spawn right against the wall, which isn't really a problem, but the warning is annoying 😂

timid holly
#

Yeah, my particular case I run into this is when my fruit combine, creating a bigger one, and now it's intersecting with other ones. I handle it by lerping the radius of the collider, but I kind of feel like it's a work around

#

It does 😂

mellow orbit
#

yeah, "on spawn it's already colliding" is the first type of situation. as I understand it, it's not just that it's colliding but that it's REALLY out of compliance so the force used to "correct" is over the top.

#

we talked about a "handle overlaps with a gentle push to the outside" option a couple of days ago

#

ah is that where it's just touching but a lot of surface, maybe? dunno. definitely a bug though!

#

This might also be where I'm getting my periodic random explosions. I have a rag-doll-like figure and sometimes it's just going along and then OH NO.

#

I'll try that tomorrow. I have found that adding "thickness" to my joints so the anchors are not touching but rather have a gap bigger than the prediction distance solves 99% of the cases.

#

I guess my other 1% are

but it can cause contact stability issues in cases where moving bodies bump into each other.

#

I should try to simply what I have down to a test case.

#

but for now... off for the night

cinder summit
#

@vestal minnow Why is it called fixed_(once_)hz when it takes a timestep duration as input? thonk

lavish laurel
#

I'm assuming it's just a typo and it's meant to be like the bevy one e.g. Time::<Fixed>::from_hz(60.0) vs Time::new_with(Physics::fixed_hz(1.0 / 60.0))

vestal minnow
#

Well, 1 / 60 s = 60 Hz 🙃
But yeah I somehow thought that was how Bevy's from_hz worked, but it's not obviously

#

(it's not 60 Hz)

cinder summit
#

It's .0166...Hz :')

#

When I saw that line of code suddenly this data made sense to me:

 We had: Position(Vec3(-2.2298813, -938642.2, 7.834011))
 Server: Position(Vec3(12.785339, 72134.08, 10.852114))
vestal minnow
#

Can't really make a patch for that tho since it would break semver pretty badly I guess

lavish laurel
cinder summit
#

Ah yes, for me it was a bit less obvious

#

I just got a gray screen after a frame or two

#

Which doesn't explain a lot when your terminal is also full of deprication warnings from naga_oil thonk

#

It was only when I noticed those numbers that I started suspecting that maybe it wasn't just the shaders

sinful spindle
#

Does this physics engine have good cross-platform determinism?

#

I want to make a rollback networking game using it and was wondering

junior flower
#

Everywhere I look I see @sleek thicket promoting xpbd 😍

#

It's so hard not to: XPBD was so much more natural to me

#

XPBD had something that I couldn't figure out in Rapier: The contact position when doing a shapecast. That's what brought me over. It's spiralled into me sending in pull requests lol

#

Is there actually something broken with Rapier, though?

#

(I didn't use it long enough to find out)

#

Ah the child colliders lagging behind their parent thing?

#

I think I saw that earlier today

#

Now that you mention it, I think I may have been seeing that before I switched to xpbd as well

#

Oh wow it's proper getting left behind

#

Hopefully xpbd can eventually catch up on the perf front too

pulsar bone
#

To be fair xpbd has that same issue, well not the gizmos lagging one frame behind. That was fixed on bevy_rapier main 3 months ago but there hasn't been a new release :V

#

I don't know MadgeCry

#

I'll probably switch over to xpbd when some more of the issues with stability have been fixed, because Jondolf is a lot more responsive

#

Heh, I know nothing about physics sims

#

haha

junior flower
#

I don't know anything about physics sims either but that's what I did

#

12 ish years of unity and I've never really had to care much about physics past OnTriggerEnter

#

In XPBD I use the CollisionStarted events

# 
use bevy::{ecs::query::ReadOnlyWorldQuery, prelude::*};
use bevy_xpbd_2d::prelude::*;

pub trait FilteredCollisionEvent: Event {
    type Query1: ReadOnlyWorldQuery;
    type Filter1: ReadOnlyWorldQuery;

    type Query2: ReadOnlyWorldQuery;
    type Filter2: ReadOnlyWorldQuery;

    fn should_keep(
        entity1: Entity,
        query1: &Query<Self::Query1, Self::Filter1>,
        entity2: Entity,
        query2: &Query<Self::Query2, Self::Filter2>,
    ) -> bool;

    fn new(a: Entity, b: Entity) -> Self;
}

pub fn republish_collision_events<T: FilteredCollisionEvent>(
    mut unfiltered_events: EventReader<CollisionStarted>,
    query1: Query<T::Query1, T::Filter1>,
    query2: Query<T::Query2, T::Filter2>,
    mut filtered_events: EventWriter<T>,
) {
    for CollisionStarted(a, b) in unfiltered_events.read() {
        for (a, b) in [(*a, *b), (*b, *a)] {
            if T::should_keep(a, &query1, b, &query2) {
                filtered_events.send(T::new(a, b));
            }
        }
    }
}

^ This, in fact

junior flower
#

Oh like concrete ones?

#

This is my "Attacker damages Defender" stuff:

#[derive(Event)]
struct AttackCollision {
    attacker: Entity,
    defender: Entity,
}

impl FilteredCollisionEvent for AttackCollision {
    type Query1 = &'static Team<CombatTeam>;
    type Filter1 = With<AttackCollider>;
    type Query2 = &'static Team<CombatTeam>;
    type Filter2 = With<DefenseCollider>;

    fn should_keep(
        entity1: Entity,
        query1: &Query<Self::Query1, Self::Filter1>,
        entity2: Entity,
        query2: &Query<Self::Query2, Self::Filter2>,
    ) -> bool {
        match query1.get(entity1) {
            Ok(attacker_team) => match query2.get(entity2) {
                Ok(defender_team) => attacker_team.can_damage(defender_team),
                _ => false,
            },
            _ => false,
        }
    }

    fn new(a: Entity, b: Entity) -> Self {
        Self {
            attacker: a,
            defender: b,
        }
    }
}

Registered with this:

.add_systems((
    // ...
    republish_collision_events::<AttackCollision>,
    // ...
))
#

And then acted upon with this:

fn process_combat_collisions<T: TeamDifferentiator>(
    mut attack_collision_events: EventReader<AttackCollision>,
    mut attacker_query: Query<&mut AttackCollider>,
    defender_query: Query<&DefenseCollider>,
    mut hitpoints_query: Query<&mut Hitpoints>,
) {
    for AttackCollision { attacker, defender } in attack_collision_events.read() {
        if let Ok(ref mut attack_collider) = attacker_query.get_mut(*attacker) {
            if attack_collider.remaining_hits.unwrap_or(1) == 0 {
                continue;
            }

            if let Ok(defense_collider) = defender_query.get(*defender) {
                if !defense_collider.exposed {
                    continue;
                }

                if let Ok(ref mut defender_hitpoints) =
                    hitpoints_query.get_mut(defense_collider.hitpoints)
                {
                    if defender_hitpoints.is_dead() {
                        continue;
                    }

                    defender_hitpoints.current -= attack_collider.damage;
                    attack_collider.remaining_hits = attack_collider.remaining_hits.map(|v| v - 1);
                }
            }
        }
    }
}
#

This little ditty is what I've been using to avoid having to copy-paste the same function twice to cover entity1 and entity2 being "backwards" in the event:

for (a, b) in [(*a, *b), (*b, *a)] {
#

Looking at it, that layers check is wrong... I should have been looking at the teams, not the layers 🤦‍♂️
* Updated the code above to fix this

finite blaze
#

folks, what is the correct way to add mass to an instance that has a mesh and collider from a scene?
I'm doing:

    commands.spawn((
        Aircraft,
        Mass(100.0),
        SceneBundle {
            scene: asset_server.load("piper_cub/piper_pa18.glb#Scene0"),
            ..default()
        },
        RigidBody::Dynamic,
        AsyncSceneCollider::new(Some(ComputedCollider::TriMesh)),
    ));

yet I get:
WARN bevy_xpbd_3d::plugins::prepare: Dynamic rigid body 2v0 has no mass or inertia. This can cause NaN values. Consider adding a MassPropertiesBundleor aCollider with mass.

#

also, I noticed that with 0.3, using the cubes example on f64 they dance and sometimes explode without any change to their velocities 😬

junior flower
#

Stepped out so I’m on my mobile atm so code is hard to read with such a small width. Poke me a bit later on and I’ll take a proper look. I’ve not got to pickups yet but I’ll probably republish the collision event as a PickupCollected event and then have a per-type system. Enum sounds ok at first but I made the decision a while back that that feels too much like OOP for ECS (for me)
I guess we’ll see in a few months whether or not I regret that decision 😄

vestal minnow
pulsar bone
#

I've got my own version of the CollidingEntities component that also keeps track of which entities started or stopped colliding this frame.
This way you can just have separate systems handle things.
(It's for bevy_rapier but it should be trivial to port)

📎 colliding_entities.rs
vestal minnow
finite blaze
#

WRT to the Mass with AsyncSceneCollider, no it doesn't work normally

vestal minnow
#

the async_collider example does work though, albeit it does give the warning

#

are you spawning it in Startup?

finite blaze
#

yep, I am

vestal minnow
#

so does the body just vanish when touching things?

#

because if not, then it should have some mass

finite blaze
#

I have gravity, and with the AsyncSceneCollider, it doesn't fall down. Neither by adding a Mass component

vestal minnow
#

even this should fall down

commands.spawn((RigidBody::Dynamic, Mass(1.0)));
finite blaze
#

yes, that falls down. If I set a cuboid collider for this instance, with the SceneBundle, and I give it Mass, it does fall down

vestal minnow
#

do you have a minimal repro for the issue that I could try?

finite blaze
#

let me try and create a reproducer from the example (which I didn't realize existed..)

finite blaze
#

it has to do with the model I'm using, but still haven't discovered why

vestal minnow
#

does it matter if it's a trimesh collider or a convex hull/decomposition?

#

and is it rendered correctly with the PhysicsDebugPlugin

finite blaze
#

with PhysicsDebugPlugin and DisableSleeping, I can see the collider when using TriMesh, but not when using ConvexDecomposition. Neither work.
Also, just realized that the game window freezes, and doesn't process closing button clicks (I used to kill it with Ctrl-C on the terminal process)

#

tried again, and now I don't see the collider with TriMesh.. I suppose I'm hitting the race sometimes

vestal minnow
#

convex decomp is very slow for complex meshes

#

can even take minutes for large environments

finite blaze
#

the window freeze also happens for TriMesh

#

anyways, thanks for being willing to debug this with me :). I suppose I can workaround it for now, I wanted to tackle a complete different thing

vestal minnow
#

and you're running in release mode?

finite blaze
#

nope.. let me try for speed

vestal minnow
#

debug is ridiculously slow in Rust without optimizations

#

release can be over 100x speed

cinder summit
#

Yea you gotta set 3rd party crates to opt-level 3 or crates like bevy_ecs, parry and xpbd won't run very nicely

#

This is how I configured them, re-enabling debug-assertions (opt-level > 0 disables it) because otherwise bevy will make certian errors hard to debug

[profile.dev]
opt-level = 1
debug-assertions = true

[profile.dev.package."*"]
opt-level = 3
debug-assertions = true
finite blaze
#

I do have that set

cinder summit
#

Hmmm ... Shouldn't make a huge difference in debug vs release then

royal helm
#

:/

#

@sleek thicket The main reason it annoys me is because this makes it a competitive atmosphere, rather than collaborative

#

It also directly makes me unmotivated to do what you just said: fix rapier

#

because some of these issues are fixed

vestal minnow
# sinful spindle Does this physics engine have good cross-platform determinism?

It's not fully tested yet, so it most likely isn't 100% cross-platform deterministic, but we do have a simple test that creates identical snapshots across Windows, Linux and MacOS, so for simple cases it should work.

Johan has a rollback networking demo called bevy_gaff to test and demonstrate the determinism (and networking). It does have occasional desyncs in some cases though, which we'll try to investigate more and hopefully fix

vestal minnow
#

Improvements and fixes to rapier also benefit xpbd and vice versa, since they can get inspiration from each other. A large chunk of the API of bevy_xpbd is pretty heavily inspired by bevy_rapier (and heron, which originally inspired bevy_rapier's modern API) even though I do change things and experiment with different APIs

royal helm
#

Because negativity tends to not help, good will does

#

A lot of issues are open despite being fixed and yeah people are having issues because of no release. I can't fix that because I don't have control over closing or releases.

#

I've also been on vacation from working on OSS stuff these past few weeks, just coming back more now

sinful spindle
vestal minnow
#

unless that's new

cinder summit
vestal minnow
#

Rapier itself definitely had them though because the spatial queries in xpbd are mostly based on rapier's spatial query pipeline

cinder summit
vestal minnow
#

Also, the new version of bevy_rapier did get released now, but it required a nudge from @royal helm (and work done by @DevilIra)

vestal minnow
cinder summit
vestal minnow
#

yeah they've done a lot of them

cinder summit
#

But hey on the flip side ... rapier probably didn't release with a fail quite as epic as from_hz working the wrong way 😂

#

Better to have your release late than have your delta times be 3600x higher and tickrate be 1/3600th of what you wanted right? thonk

vestal minnow
#

this time for bevy_xpbd I had a 0.12 branch "mostly working" like two weeks before it released

#

so that people could migrate early if they wanted

#

still the wrong way 😭

#

idk how my brain messed that up, I just saw Bevy's from_hz and the current PhysicsTimestep::Fixed(1.0 / 60.0) and smashed them together

#

somehow I logicked the input as "A timestep of 1.0 / 60.0 s becomes the desired frequency for 60 Hz, so it must be correct" thonk

cinder summit
#

Or you mixed up the methods

#

There's more than just from_hz on Time<Fixed>

mellow orbit
vestal minnow
#

the x is unstable yes, but y shouldn't have breaking changes

#

since it's just the patch number

#

it should really only fix very clear bugs or issues in docs

#

but changing how the timestep value is interpreted is very breaking (although a minor change)

#

not sure what the convention is for fixing things like this though, since it is a clearly wrong unit but also breaking

#

depends on how many people are already on 0.3

#

although I guess most people won't even touch the timestep

mellow orbit
#

there's lots of numbers. make a 0.4.0 🙂

vestal minnow
#

that's like if Bevy released 0.13 tomorrow, it feels weird

#

(although not quite the same scale ofc)

#

Best approach: Get all the features and improvements for 0.4 done ASAP and do a normal release 🙃

mellow orbit
#

Your call, of course!

vestal minnow
#

yeah I guess I can do 0.3.2 tomorrow

#

it is a clear oversight that doesn't make sense, so it's probably fine to do as a patch

royal helm
#

@vestal minnow any possibility of adding an exclude_sensors and its ilk to SpatialQueryFilter?

#

is there a sensor layer by default?

#

well that isn't really same

#

I need any Collider that is also a Sensor

#

or well the opposite, I need to exclude any collider that is a sensor

#

I'm not the end user though

#

itd be relatively hacky if I just said 1 << 31 is Sensor colliders

cinder summit
cinder summit
royal helm
#

yes, I'd need it for wanderlust to be ported

cinder summit
#

I feel like those should just be skipped in the construction of the bvh, I don't think sensors should be observable 🤔

#

I don't think I've ever seen raycasts on Sensors be working as intended behavior

#

What would the water be sensing for?

#

Not sure if I'd want that behavior to be on the water entity but yea I guess that is a possible approach

#

If you're ray/shapecasting you can get hits on colliders with neither Sensor not RigidBody I think. The systems handling character control or projectiles would then probably be the one detecting the water and responding to it

#

But yea since it's possible to model it both ways excluding all sensors by defualt could also be a footgun ... But having Sensors be included by default is definitely the more common one 🤔

mellow orbit
#

I just set it spinning a little bit, and then ... well, watch!

cinder summit
#

I think the auto adding of stuff is based on having Collider for some components and RigidBody for the rest

#

Can't say for sure tho, most of that auto adding stuff is broken for me because xpbd doesn't acknowledge the existance of SdfColliders 🥲

#

They can only collide with other SdfColliders if that's what you're asking, but other than that it works fine as long as I generate the swept aabbs and handle narrow phase hits for them

mellow orbit
#

The neck is two revolutejoints, one with compliance 0.0 and one with compliance 10.0 to fake a motor. The shoulders are distance joints with compliance 0.001, and the wrists are distance joints with compliance 0.1. In this configuration I have them with rest_length of 0.0.

vestal minnow
#

sry was gone for a bit, had to finish a physics assignment for school

mellow orbit
cinder summit
mellow orbit
#

Any idea what is causing the exploding robot behavior? The torso collider shouldn't grow like that, should it???

cinder summit
#

Yea ideally there'd be some middleground, where colliders are mostly defined as simple primitives, and all primitives can interact with either sdfs or trimeshes and convex hulls

vestal minnow
#

I sent it 1 minute before it was due, but noticed a pretty bad error so I modified it 1 minute after... so technically I did send it in time :)

cinder summit
#

I do feel like even if xpbd had support for both there would need to be feature flags for them tho, wouldn't want to use the wrong thing by accident. Trimeshes would destroy my games's performance so I'd rather not touch them at all 😂

cinder summit
#

Yea that would be great, I think it might be one of the big reasons @vestal minnow seems pretty obsessed with bevy_geometry/bevy_primitives/whatever

mellow orbit
#

The instant before doom -- the body has become the size of the world

image.png
vestal minnow
#

I'm pretty sure this kind of scaling is because of invalid rotations

cinder summit
finite blaze
#

Like, applying one quaternion but not the inverse?

vestal minnow
#

since rotation is probably approaching NaN pretty quick

#

or smth

cinder summit
#

Wouldn't it just be non-normalized rotations?

vestal minnow
#

yeah that probably

cinder summit
#

As the errors add up I'd imagine the errors accelerate and it explodes in size when you multiply it by the rotation

mellow orbit
#

ah, that makes sense.

#

The torso collider is a convex hull -- all of the others are basic shapes.

vestal minnow
#

you can have a collider without a rigid body, and it will detect collisions, but it currently won't trigger collision response because it's not really a physical object in that sense

#

I think Unity might treat them as static bodies tho

mellow orbit
cinder summit
vestal minnow
#

it's a collider

#

acts like a sensor without a rigid body currently

mellow orbit
#

I thought that leaving it circular might help, and it seems to slightly....

vestal minnow
mellow orbit
cinder summit
#

I mean it might do that, but if it does that should probably change, cause Sensor exists with a reason

vestal minnow
#

Sensor makes a rigid body pass-through, doesn't necessarily say anything about bodyless colliders

#

but yeah I'm unsure what the expected behavior is

#

that it does nothing?

#

it might be weird to see a collider in debug rendering and not have it do anything at all

mellow orbit
#

@vestal minnow should I file a bug for this?

#

also, I really need to fix my ground texture

vestal minnow
vestal minnow
#

and does having more help

vestal minnow
cinder summit
#

Maybe a feature that specifically ignores that collider for collisions, and make some bundles to make it harder to miss anything ... Idk

mellow orbit
vestal minnow
#

these explosions typically happen because of conflicting constraints and/or incorrect joint anchor configurations which leave things in an unrecoverable state

vestal minnow
mellow orbit
#

It definitely gets into an unrecoverable state.

mellow orbit
mellow orbit
#

LOL I tried completely detaching the head and wrists, but my camera follows the head, and that falls off, and with substep 1, goes through the ground

#

Increasing spacing helps, but with just the torso and arms, it can still get into explosive states

#

Do you think the growing collider is a symptom of the constraints being in conflict, or the cause?

#

Hmm, also, it seems like it might be sleep related?

#

There, I waited for the torso to sleep and then just moved forward slightly.

vestal minnow
#

yeah it could be related, I've noticed sleeping randomly causing jitters and stuff as well

mellow orbit
#

Definitely reproducible that way. But that isn't the only case.

#

Also, I should be able to tie the arm closely to the torso, right?

royal helm
#

I think renaming CollisionLayers's fields to membership and interactions would be useful

#

also maybe removing External* from Force/Torque stuff

vestal minnow
#

The layers are named like Godot iirc but I think I agree

royal helm
#

rapier had them as membership and filter but that also implied the opposite of what it does for filter

vestal minnow
#

And yeah I want to remove External, but one counter argument was that Force may imply that it also gives access to the total force including gravity and constraint forces... I think we could also give access to those though

#

Constraints compute the forces anyway, and gravity of course is known, so we could probably add them to something like total_force in Force

#

I did begin to implement this at some point but I think I got sidetracked and left it

royal helm
#

Would be interesting if you could tag forces and other things could nullify them or somethin

#

or just read it

#

Maybe overengineering it though

vestal minnow
#

The constraint forces are just computed based on the Lagrange multipliers, they don't actually do anything

#

So you probably can't easily nullify them based on the force

mellow orbit
#

Are there situations where a collider is expected to expand?

junior flower
mellow orbit
#

To be clear, I am doing nothing to rescale the collider. (Well, I do initially to make the elliptical cylinder — but the same problem happens with a basic cylinder.)

#

I'm not doing any transforms or anything after — all I'm doing is applying external force to the sphere that serves as the "foot".

#

It's some sort of interaction with the arms, which are attached with a distance joint

#

With a distance joint each, of course.

#

I made a version with the head and hands detached and that still happens.

#

The sleep is one way to trigger it, but it also happens with spinning

#

I changed the collider to a cylinder, and the arms are boxes.

#

Hmmm, though — maybe it is sleep-related. Look at the color in #1124043933886976171 message

#

It seems to be asleep even as it spins and grows.

mellow orbit
#

Yeah I'll stick SleepingDisabled on there and see what happens.

#

It's also very weird that the collider grows but the mesh doesn't.

royal helm
#

Does xpbd support scaling of colliders?

cinder summit
#

You can scale colliders (i think that's a parry feature) and there's ColliderTransform for child colliders, but idk if there's anything more than that

royal helm
#

Does it match the Transform hierarchy in that sense though?

mellow orbit
# royal helm Does xpbd support scaling of colliders?

If you change the transform-scale of the rigid body to which a collider is attached, the collider will also scale. Presumably also if you change the transform of a collider on its own. But I'm still mystified by the collider growing because it's unhappy about joints.

#

Like, if you bend my arm back into a painful position, I don't respond my growing my torso until it is bigger than a house.

royal helm
#

hmm does xpbd ever use GlobalTransform?

#

Because rotation and scale are combined in the matrix

vestal minnow
#

Collider transforms do match the Transform hierarchy, but they don't support shear, and they don't use GlobalTransform. The visual scaling you're seeing is because the joints cause things to go into a weird state where rotations most likely aren't normalized, but this doesn't affect the actual collider scale, only Transform.scale does.

#

Or I don't know if parry also handles unnormalized rotations weirdly, but it doesn't affect the computed scale at least

mellow orbit
#

Why does the weird state manifest as the collider debug visual inflating?

#

And... this is a bug, right? The joints are in what is a valid state to begin, and nothing is moved or scaled by anything outside xpbd after that.

merry tide
#

So, I decided to test if the issue I had with Godot also happens with XPBD, and unfortunately it does. But it is not as pronounced. Is this an issue worth reporting or simple to fix? Sorry if this is not the ideal format for this kind of query, short video, 41 seconds.

#

The tl;dr is that when the circle collider hits between two cuboids, the aligned cuboids do not appear to act as a seamless surface.

merry tide
#

It seems (to me) that this would be a base requirement when taking a level from LDTk or anything like that and having it work consistently. But I also understand that I might be oversimplifying the issue because it seems common.

lime hatch
#

is it intended behavior that CollidingEntities is non-empty before bodies actually starting pushing each other? Seems to start happening whenever they are within 0.5 units or so of each other...

lime hatch
merry tide
lime hatch
#

you basically create a bunch of one-way colliders instead of a bunch of boxes

#

but the way I handled it I wrote it specifically for bevy_ecs_tilemaps

merry tide
#

Ah, OK. Yeah, that makes sense. Seems like a bit of an annoying thing to have to do for someone who almost reached for Google to make a for-loop. 🙂

lime hatch
#

hah, yeah. I spent a lot of time trying to get it right (and wrong), and it still blows up in some rare cases

#

alternatively it might be able to skip contacts if they happened on a tile that has a neighbor in the direction the contact normal is pointing

#

some engines allow you to hook in and ignore specific collisions based on your own criteria, I'm a bit out of the loop on jondolfs version, though

#

it looks very modular, though 🙂

merry tide
#

I have another level where the ball crashes with two surfaces that are rotated -45 and 45 degrees and it seems to be 100% stable, but they intersect, like a cross.

#

And it feels like it has to do something very similar for that to happen, where it gets the collision data from each of the colliders and decides based on data from both of them to just bounce straight back up.

#

Is the problem that the circle collider sees the hard corner?

lime hatch
#

not sure I understand the case

merry tide
#

I think you understand better than me the failure case I have in the video where aligned surfaces are not treated as a uniform thing. And I don't really understand how tessellating a shape from, say, SVG using Lyon would work doing that. I think this issue would just be worse when it intersects with 5-10 triangle colliders at the same time.

#

But it does this perfectly, where the ball bounces down into the center of the X and right back up again.

image.png
lime hatch
#

the way contacts is normally resolved with xpbd is that it treats one object at a time, so it probably bounces with both and the combination makes it bounce back up?

#

I'd guess your issue with the boxes would probably be less visible if you increased the timestep.. but that's not really a satisfying way to "solve" it

merry tide
#

Yes, that makes sense. But why doesn't it make sense in the flat-plane case? If you have two cubes with a seam, intuitively (and I know I cannot really trust my intuition on this, because it is often wrong) would be that the bounce angle from the left cube and the right cube would cancel each other out, making it seem like a flat surface.

lime hatch
#

I think the ball hits it at an angle, so it moves both up and to the right, so it misses the other box (because the ball is too far up)

#

when a circle hits the corner of a box, it should probably resolve from the corner along the normal of the circle

merry tide
#

Hm. It behaves perfectly when just moving left and right on the surface. And I think it needs to intersect with two cubes to have an exit angle produced. Perhaps there is a setting for it and it defaults to just lokoing at one.

lime hatch
#

I'd think it is because the vertical velocity increases it moves further down into the box during one frame and the normal changes from straight up to somewhat diagonal

merry tide
#

Yes, but would it not do this...? Sorry, I am a noob so please bear with me. And also, xpbd does this a lot better than Godot.

#

(2 seconds, I need to MS Paint for two seconds.)

lime hatch
#

the easiest way is probably to just change the timestep if you can afford it

#

or make the circle bigger relative to its velocity

merry tide
#

This is good enough to be graphics for my new alien invasion game.

lime hatch
#

haha 😁

#

how I implemented it (not sure if jondolf changed it) it hits the left one first, then it's moved up and to the right, and then it checks if it overlaps with the right one, and it probably doesn't in your case

merry tide
#

Yeah, that is what I am saying. I would want it to do an intersection with both and blend the output. Perhaps that is a tall order.

lime hatch
#

i think so

#

you could probably do it

#

but iirc it has some caveats

merry tide
#

It seems to already have things where output is blended on restitution, etc, so I don't know. It feels so odd to discuss a ball and two cubes in a world where at the same time you have a demo with 1000 3D cubes running at 9000 FPS.

lime hatch
#

I think it's discussed in one of the xpbd papers

merry tide
#

But I would argue this is broken. Like, as a 2D physics engine, it just doesn't really work. There is nothing physical about the behavior. Is this better in 3D? I could make the game with a 3D physics engine and render in 2D.

#

I mean, you could not reasonably even make a Breakout/Arkanoid-clone with this.

lime hatch
#

I think a lot of engines work that way

merry tide
#

Yeah. Well... It seems Unity does it correctly. But I only have a Threadripper, I don't have time to recompile that much. 🙂

#

I don't want to use Unity.

lime hatch
#

unity uses a fork of box2d iirc

merry tide
#

I have made the same mechanics three times. I fled from Unity because I really disliked the experience, mostly how heavy it was. This is years ago. Then I ran into this behavior in Godot, and it seems to be on Godots list of known issues.

lime hatch
#

I remember that what I do in my game is treat tilemaps as their own collision shape, and they always just spit out one normal, and it actually looks at adjacent tiles before it spits out the final normal. So in your case the normal would always be up

merry tide
#

Yeah, but this is just a test level. My Godot-level for testing looks like this. So I would love to be able to do arbitrary shapes.

image.png
lime hatch
#

i get it 🙂

merry tide
#

"I just want everything. :)" 🙂

lime hatch
#

😛

#

i think xpbd is quite performant compared to traditional engines. so low timestep might not actually be so bad

merry tide
#

God damn, perhaps Unity is whipped enough to be a good alternative at this point. In Unity the landscapes typically look like this.

image.png
#

How do I test that super quickly?

#

Sorry, I tried looking it up. Is it a resource in the config?

lime hatch
#

found it. And I also found the answer to my issue

#

the default overlapping distance is set to 1 in 2D... and I was treating the units as meters when it's probably intended to be pixels

#

it defaults to 0.01 on 3d, so it's kind of surprising

merry tide
#

Is this related to substeps? I don't really understand it. If I could have perfect deterministic physics, I would obviously love that. Even if that means locking it to fixed time.

lime hatch
#

sorry, I think maybe I linked you the wrong thing. will have a quick look

merry tide
#

I think you might have linked to the right thing. I tried adding this: .insert_resource(Time::new_with(Physics::fixed_hz(1.0 / 144.0))).

#

And I am having a hard time making it fail.

#

Ah, I made it fail. Agh.

lime hatch
#

you could also increase substep count, but as the docs say, you may have to enable f64 if you make it too high

#

because the substep interval will be too small for f32 to work properly

merry tide
#

Yeah, OK, that is interesting.

#

Even setting it as .insert_resource(Time::new_with(Physics::fixed_hz(1.0 / (144.0 * 2.0)))) makes it fail every once in a while. I hope one day I can understand why it doesn't enumerate the colliders in one step and applies the force in the next, but then again, I never make physics engines and probably never will. 🙂

vestal minnow
#

ooh, a lot of things to respond to

vestal minnow
# mellow orbit Why does the weird state manifest as the collider debug visual inflating?

Probably because of what NiseVoid said: #1124043933886976171 message
I would suspect that the rotation quaternion isn't normalized (have a length of 1) because of the invalid state, so when the rotation is applied to the gizmo rendering, it acts like a scaling factor, and the collider looks bigger. Could be wrong about this though.

If they are in a valid state initially, then yeah, it could be a bug. If they have collisions against each other, it could also be this existing issue which you already also encountered: https://github.com/Jondolf/bevy_xpbd/issues/229

vestal minnow
vestal minnow
# merry tide Yeah, that is what I am saying. I would want it to do an intersection with both ...

This is very doable, but it has caveats.

The current solver uses the "Gauss-Seidel method", which in the context of collisions would essentially mean "Compute overlap for collision A and solve it, then compute overlap for collision B and solve it". This means that in your case, it would first bounce off of the corner of one box, but in it's new position, it's no longer colliding with the other box, so that contact isn't handled.

The main alternative is the "Jacobi method" which first adds up all corrections and only then applies them all at once. So it basically does "Compute overlaps for collisions A and B, and then solve them both". In this case, the bounces against opposite corners should cancel out, because they're combined into a single correction vector instead of being applied separately.

The main caveat is that the Jacobi method has worse "convergence", meaning that it typically takes more solver iterations/substeps to reach the desired state. This would mainly affect cases with several ongoing interactions though (like joint chains or tall cube stacks), so in your case it should have the same convergence as Gauss-Seidel

#

I believe we could quite easily make the solver method easily changeable though, since we could have each constraint's solve method just return the corrections instead of applying them directly, and have the solver decide how to apply them (Gauss-Seidel or Jacobi)

vestal minnow
# merry tide So, I decided to test if the issue I had with Godot also happens with XPBD, and ...

This in general is just a tricky issue. Bodies are moved discretely (in small steps), and at least without Continuous Collision Detection, they will move slightly inside other colliders before the contacts can be resolved. In your video's case, this means that the ball can hit the side of another box when it hits the intersection of two boxes, because it's not hitting just the top surface of the boxes, but going slightly into the ground and hitting the corner or edge. It's hard to know when these collisions should be ignored, so it's an issue in a lot of engines.

#

unless it's floating

#

you can also force the character controller to maintain some very small fixed offset from the ground, and I don't see why that wouldn't be possible for dynamic bodies

#

yeah I more-so meant for traditional capsule-like characters, not this specific case

#

(not strictly related to what we're discussing tho)

#

that looks like a polyline maybe

#

it has a spline detail configuration

#

so it's not actually making perfectly detailed spline colliders, AFAIK that isn't possible

#

(except with SDFs? thonk)

#

parry makes collider updates a bit cumbersome, you generally need to create a new shape from scratch I believe

#

might depend on the shape though, haven't tested

edgy light
vestal minnow
#

somehow I assumed we only had convex decomp in 3D, even though I created these methods...

#

(using parry)

#

creating colliders from meshes is 3D-only for now tho like in rapier

#

maybe we could instead have a built-in way to create colliders from images with transparency since that'll be more common in 2D

vestal minnow
#

I think I will just release 0.3.2 with this since it is a clear oversight and footgun, even though it technically is breaking for the people who configure the timestep

paper jasper
#

Hey y'all. I am looking for someone to support me in building a little 2d example using xpbd. I talked to @vestal minnow and he mentioned this helpful group of people here ❤️
Another perk: i am fine if the example will be open source for others to benefit off. its more like a "how would one build this".
It will be funded! Want to write some rust for money - feel free to ping me 🙂

vestal minnow
#

Yeah I was about to suggest that

#

That's a good place to hopefully find people interested in collaborating, but if you have specific issues regarding how to do things or if you face issues, this help thread is a good place to ask

peak timber
#

Hey, I'm going to try to get bevy_xpbd 3d physics working with big_space, since I don't want to write my own floating origin and physics engine if I don't have to. Was curious if you had any thoughts on this?

#

I see there's a custom Position component but it's pretty much the same as Vec3

#

In this case, the computed GlobalTransform would be too imprecise at far away coordinates from the origin, and preferably physics could be done relative to the GridCell position(s)

#

The edge case being that an entity may be centered on a particular GridCell, but actually overlaps with another or multiple

#

Preferrably there would be a generic solution where physics "just works" at large distances and/or scales. But if that's not something I can do, I can always just center physics around the player's position (since the render/simulation distance isn't particularly large), and replace the SyncPlugin?

#

If that were the case, I don't know if modifying the position like that every frame would be a good idea for both performance and physics itself (like could it cause things to clip into each other)?

#

(If I can figure this out I'll turn it into a crate)

cinder summit
#

It might actually be easiest to implement your own custom SyncPlugin, and just use f64 positions, then convert those to a Vec3 Transform + grid cell 🤔

peak timber
#

xpbd seems to only support f32 though?

cinder summit
#

Ideally bevy would upstream some solution to extend the usable space, and then other crates could easily integrate with it, without these kinds of issues on the edges of grid cells

cinder summit
peak timber
#

maybe I should implement true floating origin? where everything is repositioned every frame around the player

#

that way there's no cells

#

then I could just use that relative Vec3 position for xpbd

cinder summit
#

I'm not sure how well xpbd reponds to those changes in positions atm, tho that would definitely work as long as it is intended behavior that only things near you get simulated (accurately)

peak timber
#

I don't necessarily need infinite distance. 20,000 from origin is just simply not sufficient

#

thanks @cinder summit

vestal minnow
#

So if timesteps are broken again for those who configured it with seconds, replace it with Hertz 🙃

peak timber
#

Is CCD planned for the near future or still far off?

vestal minnow
#

Probably not the near future since I'm prioritizing other things for the time being (like joints now, and then maybe experimenting with making a parry alternative)

#

I haven't looked into what CCD requires in depth yet, so it's hard to say

#
  • substepping has generally been enough so far
mellow orbit
lavish laurel
mellow orbit
#

@vestal minnow I can confirm that adding normalize() to the rotations in position_constraints.rs fixes my exploding problem.

#

Doesn't seem to be necessarily in angular_constraints, but I think that's because it happens that the constraints are applied with positional_constraints second, so it's covered

vestal minnow
#

Like this?

if body1.rb.is_dynamic() && body1.dominance() <= body2.dominance() {
    body1.accumulated_translation.0 += p * inv_mass1;
    *body1.rotation += Self::get_delta_rot(rot1, inv_inertia1, r1, p);
    *body1.rotation = body1.rotation.normalize();
}
if body2.rb.is_dynamic() && body2.dominance() <= body1.dominance() {
    body2.accumulated_translation.0 -= p * inv_mass2;
    *body2.rotation -= Self::get_delta_rot(rot2, inv_inertia2, r2, p);
    *body2.rotation = body2.rotation.normalize();
}
#

(except 2D needs to be handled separately ofc)

mellow orbit
#

yes except there was some fighting witht he compiler over 2d... yes exactly

#

in 3d it is *body1.rotation.0 = *body1.rotation.0.normalize();

vestal minnow
#

ya

mellow orbit
#

unless you want to implement normalize() for Rotation

vestal minnow
#

A PR would be nice if it works 😄

mellow orbit
#

Yeah, I'll do that -- I just am not sure what to do with the 2D. (Can that get un-normalized?)

vestal minnow
#

Well it can't be normalized since it's not a vector or quaternion (unless you think of it as a Z rotation axis, but then the rotation would always be 1)

#

but I guess we could wrap the rotation so that it's always in the [0, 2pi] range?

mellow orbit
vestal minnow
#

that's probably not relevant to this specific issue or PR tho

#

yep

vestal minnow
mellow orbit
#

yeah

#

should I do #[cfg(feature = "3d")] { *body1.rotation.0 = *body1.rotation.0.normalize(); }

#

hmmm or no wait I have a better idea -- get_delta_rot could be changed to something that returns (or sets?) the new rotation and normalizes there. Then normalize only needs to be done in the 3d version, and it only needs to be done in one place.

vestal minnow
#

yeah it could be e.g. compute_new_rotation

#

for the first body the delta is added and for the second it's subtracted, but for the second one I think you can also give a negative impulse -p

#

so you can use the same method for adding and subtracting the delta