Character movement round 1 #881

erincatto · 2025-02-04T18:56:33Z

Sensor updates:

support sensor vs sensor
enableSensorEvents returns and is false by default
sensors now ignore shapes on the same body
[fix] body move events are now correctly adjusted for time of impact

…consider small distances as overlap.

…s in SIMD bias for capsule vs capsule to reduce feature flip-flop time of impact fallback now based on minExtent

sensors skip shapes on same body enableSensorEvents is back and defaults to false

jpeletier · 2025-02-19T11:16:04Z

Hello! I am testing this branch, this is really an improvement! Thanks!

I would suggest to rename the new enableSensorEvents flag to detectedBySensors because at first I thought I had to enable this in the sensor itself, but rather it must be enabled in all the other shapes that could be detected by a sensor.

Anyway, thanks!

jpeletier · 2025-02-19T11:17:44Z

include/box2d/types.h

 	bool isSensor;

-	/// Enable contact events for this shape. Only applies to kinematic and dynamic bodies. Ignored for sensors.
+	/// Enable sensor events for this shape. This applies to sensors and non-sensors. False by default, even for sensors.
+	bool enableSensorEvents;


I would suggest to rename the new enableSensorEvents flag to detectedBySensors because at first I thought I had to enable this in the sensor itself, but rather it must be enabled in all the other shapes that could be detected by a sensor.

I got a feature request for sensors themselves to be disabled and for sensors to detect other sensors. Basically every combination.

jpeletier · 2025-02-19T14:13:21Z

Hmm, after further testing, I see that enableSensorEvents must be true for both the sensor itself and the detected shape, otherwise no events are produced.

Shouldn't it work so that enableSensorEvents must be true only for the target shape for a sensor to work? Otherwise the sensor itself could be detected by other sensor, which perhaps is not the usual case.

For now, I am setting enableSensorEvents to true for all sensors inconditionally, otherwise they won't work.

Thanks!

…imum

…tution Also fixed bug where contacts with no restitution were affected by the restitution solver. This affected the determinism test result.

HughPH · 2025-03-02T18:23:24Z

src/world.c

@@ -2488,6 +2577,112 @@ b2TreeStats b2World_CastPolygon( b2WorldId worldId, const b2Polygon* polygon, b2
 	return treeStats;
 }

+static b2AABB b2ComputerShapeBounds( const b2ShapeProxy* shape, b2Transform xf )


Should this be Compute?

HughPH · 2025-03-02T18:33:57Z

include/box2d/types.h

 	bool isSensor;

-	/// Enable contact events for this shape. Only applies to kinematic and dynamic bodies. Ignored for sensors.
+	/// Enable sensor events for this shape. This applies to sensors and non-sensors. False by default, even for sensors.
+	bool enableSensorEvents;


Adding this before enableHitEvents will subtly break bindings generated for 3.0.0 that point to a 3.1.0 shared library, which might be unexpected if people expect Open/Close Principle adherence.

I tend to organize structs to for good packing, not for adding new stuff to the end. Shouldn't a binding generator look at the names?

I also want these two bools to be close together because they are related.

That's fair, I just wanted to point it out.

Binding generators will create bindings at design time, but they are fixed at runtime - and so something compiled against Box2D 3.0.0 will have a layout mismatch if it's later pointed to 3.1.0. Because at the interface it's just a lump of data, there will be no compiletime or runtime errors and fields in the consumer code will just be in the wrong locations. The best thing for developers is to just recreate the bindings programmatically, but where someone's got, for example, a NuGet package that on the surface appears to do it for them, and they expect to be able to just drop in a Box2D 3.1.0 shared library, then they'll run into trouble when they use the 'displaced' fields.

In my case it's put together manually and I'm taking care to observe and absorb changes in 3.1.0. Here's what it looks like for me:

Each bool takes 1 byte but internalValue is aligned to the next 4-byte boundary, so the packing is not affected in this case and it won't break as it would if you were 1 bool over the next boundary.

With all that said, I understand your reasons for putting EnableSensorEvents adjacent to IsSensor

I'm hoping to generate some json like raylib does to assist with binding generators. I wonder if some sort of version number check could be used.

In my case I could call b2GetVersion at first use, but I'm building the shared libs and including them in the NuGet package so everything should be "joined up" anyway. That's something I might do at build time, so that I get the error if the shared lib version doesn't match, and then I can deal with it. A unit test would be a good place for it.

Those using what we could call "prepared bindings" could call b2GetVersion at their leisure, but I don't see a good way of using that to try to solve this problem. Even if you required that people include the version in b2WorldDef, if they get it from b2GetVersion then the value will be correct always. It would be the same for modifying B2_SECRET_COOKIE: because box2d itself is responsible for distributing it, it would always match.

HughPH · 2025-03-02T18:35:37Z

include/box2d/types.h

@@ -1440,9 +1448,15 @@ typedef struct b2DebugDraw
 	/// Option to draw contact normal impulses
 	bool drawContactImpulses;

+	/// Option to draw contact feature ids
+	bool drawContactFeatures;


Adding this before drawFrictionImpulses will subtly break bindings generated for 3.0.0 that point to a 3.1.0 shared library, which might be unexpected if people expect Open/Close Principle adherence.

I cannot anticipate all the assumptions made by binding generators. I'll make a note of this in the 3.1 release notes.

I had made my bindings against the partial 3.1.0 in main, which was an error on my part. I've changed everything so my Github actions build the latest tag instead, and my bindings work against 3.0.0, with a unit test to detect if b2Version returns something other than 3.0.0. When you're ready to release 3.1.0, I'll get a failing build and I'll update my code accordingly. The two I've mentioned in this PR would be the tip of the iceberg if we were to analyse the gap between 3.0.0 and 3.1.0, so if you're going to make a note in the release notes, it should probably either be vague about a number of changes that will require recreation of any bindings, or I can help you an exhaustive list.

I expect any point release to have breaking changes. I feel a physics engine is a bit different than something like SDL where API stability is at a premium. For Box2D features, performance, and robustness are at a premium and there are a lot of features to come.

static shapes now invoke contact creation by default

erincatto added 15 commits January 27, 2025 11:28

controls for TangentSpeed sample

c5c04bb

renames

50954fd

bug test for capnspacehook

082c414

fix body move events for fast bodies and bullets

3419704

testing

f17ff09

removed some temporary solver testing

8b7113d

fix unused variable

2cb6aea

disable sensors on disabled bodies

6a70379

fixed small bug in revolute joint

c902c3c

Improve accuracy of world overlap functions. Also add a tolerance to …

5b9f690

…consider small distances as overlap.

Changes to support mingw

95c85ba

fixed bug where softness was being used for speculative contact point…

e1fe86f

…s in SIMD bias for capsule vs capsule to reduce feature flip-flop time of impact fallback now based on minExtent

sensors now detect other sensors

308faa4

sensors skip shapes on same body enableSensorEvents is back and defaults to false

fix CI

c981c6b

drawing islands

d671b72

jpeletier reviewed Feb 19, 2025

View reviewed changes

erincatto added 5 commits February 21, 2025 23:09

manifold points now store the total normal impulse instead of the max…

febfd55

…imum

testing normal vector from shape distance

577a10d

Small optimization to skip restitution in SIMD if no lanes have resti…

82ee95d

…tution Also fixed bug where contacts with no restitution were affected by the restitution solver. This affected the determinism test result.

simplified restitution masking

8e1c915

dynamic tree supports 64 bit user data

6cadc40

HughPH reviewed Mar 2, 2025

View reviewed changes

erincatto added 4 commits March 4, 2025 10:02

fix compilation

f13cc98

wip

c1954eb

fix for continuous collision on first time step

da21b40

static shapes now invoke contact creation by default

CI fixes

80f33e1

erincatto added 2 commits March 14, 2025 23:13

wip unstable

60342a6

tiny pyramid

4e0a968

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Character movement round 1 #881

Character movement round 1 #881

erincatto commented Feb 4, 2025 •

edited

Loading

jpeletier commented Feb 19, 2025 •

edited

Loading

jpeletier Feb 19, 2025

erincatto Mar 15, 2025

jpeletier commented Feb 19, 2025

HughPH Mar 2, 2025

HughPH Mar 2, 2025

erincatto Mar 2, 2025

HughPH Mar 2, 2025

erincatto Mar 2, 2025

HughPH Mar 2, 2025

HughPH Mar 2, 2025

erincatto Mar 2, 2025

HughPH Mar 3, 2025

erincatto Mar 3, 2025

Character movement round 1 #881

Are you sure you want to change the base?

Character movement round 1 #881

Conversation

erincatto commented Feb 4, 2025 • edited Loading

jpeletier commented Feb 19, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jpeletier commented Feb 19, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erincatto commented Feb 4, 2025 •

edited

Loading

jpeletier commented Feb 19, 2025 •

edited

Loading