No GetShapes function

[opera-aberglund]

Desired Behavior:

There is GetBodies, GetJoints, GetContacts... but there should also be a GetShapes, probably defined like this:

inline const ShapeIDs& GetShapes(const AabbTreeWorld& world) noexcept
{
    return world.m_shapes;
}

Actual Behavior:

It doesn't exist. I can't access all the shapes I've created, because I can't access the m_shapeBuffer directly without knowing the ShapeID, and the only way to get the ShapeID is either if I stored it somewhere when I created the shape, or by accessing the shapes assigned to a body.

[louis-langholtz]

Thank you for filing this issue (and the others)!

I recall going back and forth in my thoughts on whether to have a matching GetShapes like function. There were some reasons I had against it at the time. Wasn't sure whether this lacking interface would be noticeably inconsistent. Sounds like it was however.

[opera-aberglund]

Thank you for filing this issue (and the others)!

I recall going back and forth in my thoughts on whether to have a matching GetShapes like function. There were some reasons I had against it at the time. Wasn't sure whether this lacking interface would be noticeably inconsistent. Sounds like it was however.

No problem! A lot of these things I discovered quite naturally while trying to serialize/deserialize everything. Any inconsistencies left in the code will often be exposed.

[louis-langholtz]

A lot of these things I discovered quite naturally while trying to serialize/deserialize everything. Any inconsistencies left in the code will often be exposed.

100% I was of the same perspective on this! I'm glad you were too.

As for having a GetShapes function, as I'd mentioned elsewhere, there's a GetShapeRange function. If no shapes have been destroyed, then ShapeID(0) up to but not including ShapeID(GetShapeRange(world)) gives us all the valid shape IDs (without GetShapes). If any shapes have been destroyed, then calling IsDestroyed first on the shape ID tells if that's still valid or not.

So maybe if nothing else, this is a work around for you for now.

[louis-langholtz]

A question for me now about this, is: do I want to try and remove the other ID collection getting functions in favor of always going in linear order?

While this current inconsistency bothers me, I'm not sure removing these others won't break something that can't be broken. It also removes functionality that users may have used before and will need to update from.

I've made a new issue (issue #568) with a slightly different title that emphasizes my issue of this being an inconsistency so I can close this issue in the meantime and focus on the inconsistency.