Hybrid compound shape

[mihe]

I've been noodling over this idea for a while now, and figured I would sit down at some point to actually explore it properly, but haven't really found the time. So instead I thought I would just go ahead and ask you about it, to see if it's even worth exploring.

In short, would it be possible to somehow have a sort of hybrid/deferred StaticCompoundShape that behaves as a MutableCompoundShape until you explicitly invoke some Optimize() method on it, which then builds/rebuilds all the spatial partitioning and whatnot?

I feel like something along those lines would provide the best of both worlds for the most part. Instead of having to rebuild the whole StaticCompoundShape on any sub-shape mutation/transformation, or going the alternative route of deferring the rebuild of it to some later point, which would presumably necessitate rebuilding all of them on any physics query, you would instead just defer the optimization of the compound shape to some later point, with a performance hit on any physics query performed on it until that optimization happens.

I understand that would come with the same caveats as MutableCompoundShape with regards to race conditions, and needing to invoke BodyInterface::NotifyShapeChanged and whatever else, but those seem like small concessions.

Anyway, I'm not asking for this to be added to Jolt necessarily, since it could almost certainly be done user-side, but I figured I would pick your brain about it anyway.

[jrouwe]

I think it is certainly possible to implement this. You could probably implement this using a new DecoratedShape type and then make sure that all queries do OptimizeIfNeeded() before calling the StatiCompoundShape query function.

The biggest issue with it that I see (which you already mention) is in multi threaded scenarios. If there are 2 threads doing a query on the same shape at the same time, you'll need a mutex lock to ensure that only 1 thread does the rebuild. For godot physics this is probably not an issue since everything is serialized through a physics thread anyway (which I don't think you support for godot-jolt yet).

As for the question if this should be included in Jolt or not: It could be, but it does go a little bit against the philosophy of being able to collect lots of TransformedShapes and then iterating over them without locking. You're the first to ask for this, so I'm not sure if there is a general need. MutableCompoundShape may be sufficiently performant in most cases.

[mihe]

You could probably implement this using a new DecoratedShape type and then make sure that all queries do OptimizeIfNeeded() before calling the StaticCompoundShape query function.

I'm not sure I follow. Are you saying StaticCompoundShape would get this new OptimizeIfNeeded() method? I don't quite see how I would do this using a DecoratedShape and the existing compound shapes (as-is).

My thinking was to just have a specific point in the code (likely before stepping) where I just run through all the bodies that have had their set of sub-shapes modified and optimize them. If any query gets invoked before that point, then it'll just be slower, which is fine. It's only for any queries that happen within that same physics tick. I mainly just want to avoid having to pay the price of optimizing the same compound shape multiple times within the same physics tick.

I believe Godot Physics does something similar to this as well (although their compound shapes are more akin to your MutableCompoundShape) where they queue up bodies that need to invoke their equivalent of your BodyInterface::NotifyShapeChanged, which they then flush right before stepping the simulation.

For godot physics this is probably not an issue since everything is serialized through a physics thread anyway (which I don't think you support for godot-jolt yet).

I've never seen this actually spelled out in any documentation, but Godot does allow for concurrent physics queries, as queries are done through the PhysicsDirectSpaceState3D object, which bypasses the physics server (and its giant queue in the case of run_on_separate_thread). I believe it's however invalid/undefined/whatever to access that object while the physics server is synchronizing with the rest of the engine, which is also where the simulation is stepped.

But yes, I don't support any of that currently. There are other things that need to be refactored to support concurrent queries. That's a later problem. So far everything is still quite serial.

As for the question if this should be included in Jolt or not: It could be, but it does go a little bit against the philosophy of being able to collect lots of TransformedShapes and then iterating over them without locking.

How would something like this differ from MutableCompoundShape in this regard?

You're the first to ask for this, so I'm not sure if there is a general need. MutableCompoundShape may be sufficiently performant in most cases.

It's certainly possible that this is misguided to begin with. I mostly just felt (when first implementing compound shapes in Godot Jolt) that more people would suffer from the downsides of MutableCompoundShape than would from the downsides of StaticCompoundShape. I've already seen one example of someone building out their entire level as a single StaticBody3D with thousands of convex shapes in it.

The place where my usage of StaticCompoundShape does very poorly at the moment is when people build their level programmatically by first adding the body to the scene tree (thus creating the underlying Jolt body) and then start tacking on dozens/hundreds of shapes onto it. In such a case I don't really need the compound shape to be mutable forever, just for it to defer its optimization until a later point, which I figured something like this hybrid compound shape could help with, without me having to sacrifice correctness.

[jrouwe]

I'm not sure I follow. Are you saying StaticCompoundShape would get this new OptimizeIfNeeded() method?

Yes I was very handwavy. I basically meant something like this:

class LazyCompoundShape : public DecoratedShape
{
public:
    // Example of how to add a new subshape
    void AddSubShape(...)
    {
        std::lock_guard lock(mMutex);
        mCompoundSettings.mSubShapes.push_back(...);
        mChanged = true;
    }

    // Example collision function
    void CastRay(...)
    {
        // Take a reference on the shape for the duration of this call
        // (this prevents another call to GetCompoundShape() from freeing our data)
        RefConst<Shape> shape = GetCompoundShape();
        
        // Forward to inner shape
        shape->CastRay(...);
    }
   
    // Make sure to override all virtuals so that everything uses GetCompoundShape()

private:
    RefConst<Shape> GetCompoundShape()
    {
        std::lock_guard lock(mMutex);
        
        if (mChanged)
        {
            // If something changed we need to build a new shape 
            // (this will release the reference to the old shape, 
            // any query in progress should still have the reference 
            // for the duration of the query so should continue to work)
            mCompoundSettings.ClearCachedResult();
            mInnerShape = mCompoundSettings.Create().Get();
            mChanged = false;
        }

        return mInnerShape;
    }

    StaticCompoundShapeSettings mCompoundSettings;    
    Mutex mMutex;
    bool mChanged = false;
}

How would something like this differ from MutableCompoundShape in this regard?

MutableCompoundShape has similar problems indeed. The proper way to use it in a multi threaded environment is explained in the header:

Note: If you're using MutableCompoundShape and are querying data while modifying the shape you'll have a race condition.
In this case it is best to create a new MutableCompoundShape using the Clone function. You replace the shape on a body using BodyInterface::SetShape.
If a query is still working on the old shape, it will have taken a reference and keep the old shape alive until the query finishes.

This is the only way that I can think of to make it possible to modify and query at the same time.

(edit: Simplified code a bit)

[mihe]

Yes I was very handwavy. I basically meant something like this:

Ah, I see what you mean now. Keeping the StaticCompoundShapeSettings around like that is pretty clean actually.

I'll play around with that later and see where that gets me. Thank you!

This is the only way that I can think of to make it possible to modify and query at the same time.

That makes sense. I can see why you'd be apprehensive about introducing more sharp edges like that.

[jrouwe]

B.t.w. I was thinking that it is probably best to not derive from DecoratedShape but instead use a plain Shape. This avoids accidental access to mInnerShape without going through the GetCompoundShape() function.

[mihe]

I've spent some time exploring this idea now, and unfortunately it didn't really turn out as well as I had initially hoped.

The stuff that tripped me up was:

1. Actually setting this new compound shape on the Body meant that Body::SetShapeInternal would call GetCenterOfMass and GetWorldSpaceBounds on the shape. This meant I had to not build the underlying StaticCompoundShape for these methods and instead provide temporary (zero?) values for them, in order to not defeat the purpose of this lazy compound shape.
2. Since I now provided a temporary/zero value for GetCenterOfMass, you would end up getting this temporary value when requesting it through a user script right after messing with the set of shapes, meaning I likely needed to special-case the context where BodyInterface::SetShape was called in order to only ignore those specific calls to GetCenterOfMass, GetWorldSpaceBounds, etc.
3. Since I now provided a temporary/zero value for GetWorldSpaceBounds (and I guess GetLocalBounds/GetInnerRadius) I assume that has some sort of implication on the broadphase update in BodyInterface::SetShape? Could you actually, within something like NarrowPhaseQuery::CollideShape, hit a body whose root shape has empty bounds? If not, that would likely defeat the purpose of the lazy compound shape.
4. Since methods like Body::AddImpulse don't actually involve the shape in any way, there's nothing prompting the lazy compound shape to build itself, meaning I'm forced to manually do that (along with something like BodyInterface::NotifyShapeChanged) before invoking such things, which meant making assumptions about the inner workings of Jolt.
5. BodyInterface::NotifyShapeChanged requires the previous COM, and while we happen to keep track of any previous Shape already, it's not necessarily the most previous Shape at the callsite, which required slightly more involved bookkeeping.

There were probably more concerns that I've forgotten already, but assuming I haven't completely misunderstood something here, then I'm not sure that this was a great fit for how I chose to incorporate compound shapes into Godot.

If any of this sounds off, or if you have some ideas for how to work around these concerns, I'd love to hear it.

I came up with a compromise in the meantime, which at least makes a slight dent in the problem here: godotengine/godot#101189

[mihe]

When adding a new sub shape you can do this incrementally so the cost can be quite low.

I had sort of hoped to avoid mutating a retained instance of this new shape type, and instead just recreate it from scratch every time, much like what we do already, but I assume that would (when coupled with properly calculating the COM/bounds) inherently result in performance that isn't much different from just creating a MutableCompoundShape.

I'll try and refactor the code to instead mutate a retained instance at some later point, but I fear it (along with the Body::AddImpulse issue) will complicate the code to an unfortunate degree. I can't really see any other solution to this problem though.

[jrouwe]

I had sort of hoped to avoid mutating a retained instance of this new shape type, and instead just recreate it from scratch every time

I am suggesting to recreate it from scratch every time. The only thing you do incrementally is calculating bounds and COM. Maybe you can send me what you have so far? I'll try to add some code to illustrate what I mean.

[mihe]

I am suggesting to recreate it from scratch every time. The only thing you do incrementally is calculating bounds and COM.

I must be misunderstanding something then.

By "every time" I mean with any mutation to the overall shape tree. There is no AddShape method on the built compound shape, within which to do anything incrementally. Every sub-shape that will go into that particular compound shape instance (which may or may not be the final set of sub-shapes) is known at the time of creating it, and any further addition/removal will cause a full rebuild of the compound shape with (at least currently) nothing passed on from the compound shape being discarded.

Maybe you can send me what you have so far? I'll try to add some code to illustrate what I mean.

Sure, give me a couple of hours though.

[jrouwe]

I'll show you what I mean when you send the code (I only need the custom shape b.t.w.).

[mihe]

I only need the custom shape b.t.w.

Here's a cleaned up version (without some of the error-handling) of the naive approach, where it's just prompting the inner shape to build on every single virtual method, including COM/bounds. It's not too different from your example above, except there's no AddShape, and it inherits from JPH::Shape, as talked about earlier here:

#include "Jolt/Core/Mutex.h"
#include "Jolt/Physics/Collision/Shape/StaticCompoundShape.h"
#include "Jolt/Physics/Collision/TransformedShape.h"

class JoltCustomLazyCompoundShapeSettings final : public JPH::ShapeSettings {
public:
    JoltCustomLazyCompoundShapeSettings() = default;

    explicit JoltCustomLazyCompoundShapeSettings(const JPH::StaticCompoundShapeSettings *inInnerShape) :
            mInnerShape(inInnerShape) {}

    virtual JPH::Shape::ShapeResult Create() const override;

    JPH::RefConst<JPH::StaticCompoundShapeSettings> mInnerShape;
};

class JoltCustomLazyCompoundShape final : public JPH::Shape {
public:
    explicit JoltCustomLazyCompoundShape() :
            JPH::Shape(JPH::EShapeType::Compound, JPH::EShapeSubType::User3) {}

    JoltCustomLazyCompoundShape(const JoltCustomLazyCompoundShapeSettings &inSettings, JPH::ShapeSettings::ShapeResult &outResult) :
            JPH::Shape(JPH::EShapeType::Compound, JPH::EShapeSubType::User3, inSettings, outResult),
            mInnerShapeSettings(inSettings.mInnerShape) {
        if (!outResult.HasError()) {
            outResult.Set(this);
        }
    }

    JPH::StaticCompoundShape *GetInnerShape() const {
        std::lock_guard lock(mMutex);

        if (mInnerShape == nullptr) {
            JPH::ShapeSettings::ShapeResult shape_result = mInnerShapeSettings->Create();
            mInnerShape = static_cast<JPH::StaticCompoundShape *>(shape_result.Get().GetPtr());
            mInnerShapeSettings = nullptr;
        }

        return mInnerShape;
    }

    virtual bool MustBeStatic() const { return GetInnerShape()->MustBeStatic(); }

    virtual JPH::Vec3 GetCenterOfMass() const { return GetInnerShape()->GetCenterOfMass(); }

    virtual JPH::AABox GetLocalBounds() const { return GetInnerShape()->GetLocalBounds(); }

    virtual JPH::uint GetSubShapeIDBitsRecursive() const { return GetInnerShape()->GetSubShapeIDBitsRecursive(); }

    virtual JPH::AABox GetWorldSpaceBounds(JPH::Mat44Arg inCenterOfMassTransform, JPH::Vec3Arg inScale) const { return GetInnerShape()->GetWorldSpaceBounds(inCenterOfMassTransform, inScale); }

    virtual float GetInnerRadius() const { return GetInnerShape()->GetInnerRadius(); }

    virtual JPH::MassProperties GetMassProperties() const { return GetInnerShape()->GetMassProperties(); }

    virtual const JPH::Shape *GetLeafShape(const JPH::SubShapeID &inSubShapeID, JPH::SubShapeID &outRemainder) const { return GetInnerShape()->GetLeafShape(inSubShapeID, outRemainder); }

    virtual const JPH::PhysicsMaterial *GetMaterial(const JPH::SubShapeID &inSubShapeID) const { return GetInnerShape()->GetMaterial(inSubShapeID); }

    virtual JPH::Vec3 GetSurfaceNormal(const JPH::SubShapeID &inSubShapeID, JPH::Vec3Arg inLocalSurfacePosition) const { return GetInnerShape()->GetSurfaceNormal(inSubShapeID, inLocalSurfacePosition); }

    virtual void GetSupportingFace(const JPH::SubShapeID &inSubShapeID, JPH::Vec3Arg inDirection, JPH::Vec3Arg inScale, JPH::Mat44Arg inCenterOfMassTransform, JPH::Shape::SupportingFace &outVertices) const { GetInnerShape()->GetSupportingFace(inSubShapeID, inDirection, inScale, inCenterOfMassTransform, outVertices); }

    virtual JPH::uint64 GetSubShapeUserData(const JPH::SubShapeID &inSubShapeID) const { return GetInnerShape()->GetSubShapeUserData(inSubShapeID); }

    virtual JPH::TransformedShape GetSubShapeTransformedShape(const JPH::SubShapeID &inSubShapeID, JPH::Vec3Arg inPositionCOM, JPH::QuatArg inRotation, JPH::Vec3Arg inScale, JPH::SubShapeID &outRemainder) const { return GetInnerShape()->GetSubShapeTransformedShape(inSubShapeID, inPositionCOM, inRotation, inScale, outRemainder); }

    virtual void GetSubmergedVolume(JPH::Mat44Arg inCenterOfMassTransform, JPH::Vec3Arg inScale, const JPH::Plane &inSurface, float &outTotalVolume, float &outSubmergedVolume, JPH::Vec3 &outCenterOfBuoyancy JPH_IF_DEBUG_RENDERER(, JPH::RVec3Arg inBaseOffset)) const { GetInnerShape()->GetSubmergedVolume(inCenterOfMassTransform, inScale, inSurface, outTotalVolume, outSubmergedVolume, outCenterOfBuoyancy JPH_IF_DEBUG_RENDERER(, inBaseOffset)); }

    virtual void Draw(JPH::DebugRenderer *inRenderer, JPH::RMat44Arg inCenterOfMassTransform, JPH::Vec3Arg inScale, JPH::ColorArg inColor, bool inUseMaterialColors, bool inDrawWireframe) const { GetInnerShape()->Draw(inRenderer, inCenterOfMassTransform, inScale, inColor, inUseMaterialColors, inDrawWireframe); }

    virtual void DrawGetSupportFunction(JPH::DebugRenderer *inRenderer, JPH::RMat44Arg inCenterOfMassTransform, JPH::Vec3Arg inScale, JPH::ColorArg inColor, bool inDrawSupportDirection) const { GetInnerShape()->DrawGetSupportFunction(inRenderer, inCenterOfMassTransform, inScale, inColor, inDrawSupportDirection); }

    virtual void DrawGetSupportingFace(JPH::DebugRenderer *inRenderer, JPH::RMat44Arg inCenterOfMassTransform, JPH::Vec3Arg inScale) const { GetInnerShape()->DrawGetSupportingFace(inRenderer, inCenterOfMassTransform, inScale); }

    virtual bool CastRay(const JPH::RayCast &inRay, const JPH::SubShapeIDCreator &inSubShapeIDCreator, JPH::RayCastResult &ioHit) const { return GetInnerShape()->CastRay(inRay, inSubShapeIDCreator, ioHit); }

    virtual void CastRay(const JPH::RayCast &inRay, const JPH::RayCastSettings &inRayCastSettings, const JPH::SubShapeIDCreator &inSubShapeIDCreator, JPH::CastRayCollector &ioCollector, const JPH::ShapeFilter &inShapeFilter = {}) const { GetInnerShape()->CastRay(inRay, inRayCastSettings, inSubShapeIDCreator, ioCollector, inShapeFilter); }

    virtual void CollidePoint(JPH::Vec3Arg inPoint, const JPH::SubShapeIDCreator &inSubShapeIDCreator, JPH::CollidePointCollector &ioCollector, const JPH::ShapeFilter &inShapeFilter = {}) const { GetInnerShape()->CollidePoint(inPoint, inSubShapeIDCreator, ioCollector, inShapeFilter); }

    virtual void CollideSoftBodyVertices(JPH::Mat44Arg inCenterOfMassTransform, JPH::Vec3Arg inScale, const JPH::CollideSoftBodyVertexIterator &inVertices, JPH::uint inNumVertices, int inCollidingShapeIndex) const { GetInnerShape()->CollideSoftBodyVertices(inCenterOfMassTransform, inScale, inVertices, inNumVertices, inCollidingShapeIndex); }

    virtual void CollectTransformedShapes(const JPH::AABox &inBox, JPH::Vec3Arg inPositionCOM, JPH::QuatArg inRotation, JPH::Vec3Arg inScale, const JPH::SubShapeIDCreator &inSubShapeIDCreator, JPH::TransformedShapeCollector &ioCollector, const JPH::ShapeFilter &inShapeFilter) const { GetInnerShape()->CollectTransformedShapes(inBox, inPositionCOM, inRotation, inScale, inSubShapeIDCreator, ioCollector, inShapeFilter); }

    virtual void TransformShape(JPH::Mat44Arg inCenterOfMassTransform, JPH::TransformedShapeCollector &ioCollector) const { GetInnerShape()->TransformShape(inCenterOfMassTransform, ioCollector); }

    virtual void GetTrianglesStart(JPH::Shape::GetTrianglesContext &ioContext, const JPH::AABox &inBox, JPH::Vec3Arg inPositionCOM, JPH::QuatArg inRotation, JPH::Vec3Arg inScale) const { GetInnerShape()->GetTrianglesStart(ioContext, inBox, inPositionCOM, inRotation, inScale); }

    virtual int GetTrianglesNext(JPH::Shape::GetTrianglesContext &ioContext, int inMaxTrianglesRequested, JPH::Float3 *outTriangleVertices, const JPH::PhysicsMaterial **outMaterials = nullptr) const { return GetInnerShape()->GetTrianglesNext(ioContext, inMaxTrianglesRequested, outTriangleVertices, outMaterials); }

    virtual void SaveMaterialState(JPH::PhysicsMaterialList &outMaterials) const { GetInnerShape()->SaveMaterialState(outMaterials); }

    virtual void RestoreMaterialState(const JPH::PhysicsMaterialRefC *inMaterials, JPH::uint inNumMaterials) { GetInnerShape()->RestoreMaterialState(inMaterials, inNumMaterials); }

    virtual void SaveSubShapeState(JPH::ShapeList &outSubShapes) const { GetInnerShape()->SaveSubShapeState(outSubShapes); }

    virtual void RestoreSubShapeState(const JPH::ShapeRefC *inSubShapes, JPH::uint inNumShapes) { GetInnerShape()->RestoreSubShapeState(inSubShapes, inNumShapes); }

    virtual JPH::Shape::Stats GetStats() const { return GetInnerShape()->GetStats(); }

    virtual JPH::Shape::Stats GetStatsRecursive(JPH::Shape::VisitedShapes &ioVisitedShapes) const { return GetInnerShape()->GetStatsRecursive(ioVisitedShapes); }

    virtual float GetVolume() const { return GetInnerShape()->GetVolume(); }

    virtual bool IsValidScale(JPH::Vec3Arg inScale) const { return GetInnerShape()->IsValidScale(inScale); }

    virtual JPH::Vec3 MakeScaleValid(JPH::Vec3Arg inScale) const { return GetInnerShape()->MakeScaleValid(inScale); }

private:
    mutable JPH::Ref<JPH::StaticCompoundShape> mInnerShape;
    mutable JPH::RefConst<JPH::StaticCompoundShapeSettings> mInnerShapeSettings;
    mutable JPH::Mutex mMutex;
};

[jrouwe]

I've integrated the shape in the MutableCompoundShapeTest to illustrate how to implement GetCenterOfMass and GetLocalBounds/GetWorldSpaceBounds:

MutableCompoundShapeTest.zip

I see that a call to GetMassProperties is made that potentially still prematurely creates the shape, but it's easy to calculate that in the same way too (let me know if you need it).

I'm wondering now if this implementation has enough use cases to make this into an officially supported shape.

[mihe]

I suspect there may have been some misunderstanding in the discussion above after all, given what the code here looks like.

Just to illustrate what I mean, here's how this custom shape would behave in a chain of events where someone programmatically adds a bunch of shapes to a body through a script, assuming we don't refactor how we build shapes, besides switching to this new compound shape:

• my_body = RigidBody3D.new().
  • This sets up the initial JPH::BodyCreationSettings.
• add_child(my_body).
  • This adds the body to the parent node and (let's assume) the scene tree as well. This causes the JPH::BodyCreationSettings to go through JPH::BodyInterface::CreateAndAddBody, which requires a valid shape. However, no shape has been added yet, so we fall back on JPH::EmptyShape.
• my_first_shape = BoxShape3D.new().
  • This does nothing Jolt-related.
• my_body.add_child(my_first_shape).
  • This will cause a full rebuild of the body's entire shape, completely from scratch.
  • We build the JPH::BoxShape.
  • No compound shape is required, so we just assign the one shape to the body, and in the process dereferencing (thus destroying) the old JPH::EmptyShape.
• my_second_shape = BoxShape3D.new().
  • Again, this does nothing Jolt-related.
• my_body.add_child(my_second_shape)
  • This will cause another full rebuild of the body's entire shape, completely from scratch.
  • We don't need to build the first JPH::BoxShape, since nothing about it has changed, so we reuse it.
  • We do build the second JPH::BoxShape.
  • A compound shape is required this time, so we create a JoltCustomLazyCompoundShape.
  • We add the first body to it, incorporating its COM and bounds.
  • We add the second body to it, incorporating its COM and bounds.
  • We assign the compound shape to the body, and in the process dereference the old JPH::BoxShape.
• my_third_shape = BoxShape3D.new().
  • Again, this does nothing Jolt-related.
• my_body.add_child(my_third_shape)
  • This will cause another full rebuild of the body's entire shape, completely from scratch.
  • We don't need to build the first JPH::BoxShape, since nothing about it has changed, so we reuse it.
  • We don't need to build the second JPH::BoxShape, since nothing about it has changed, so we reuse it.
  • We do build the third JPH::BoxShape.
  • A compound shape is required, so we create a brand new JoltCustomLazyCompoundShape.
  • We add the first body to it, incorporating its COM and bounds.
  • We add the second body to it, incorporating its COM and bounds.
  • We add the third body to it, incorporating its COM and bounds.
  • We assign the compound shape to the body, and in the process dereference (thus destroying) the old JoltCustomLazyCompoundShape.

Forgive the overly verbose breakdown, but I just want to make sure we're on the same page.

(I should probably also mention that all of the rebuilding in the breakdown above goes away if you just move add_child(my_body) to the bottom instead, since we have no reason to build anything before the JPH::Body exists. This will be the vast majority of the casual use-cases, as this is what happens implicitly when instantiating a scene, but when doing things programmatically you can easily shoot yourself in the foot like this.)

Assuming I haven't misunderstood this lazy compound shape in some big way, just using it in place of something like MutableCompoundShape should rightfully make very little difference here, since we're truly starting from scratch with every shape mutation. We're still calculating the COM/bounds just as many times with either one, and given that we set the compound shape on the body we'll end up paying the cost of any broadphase update/dirtying immediately as well.

The obvious question to all this is of course "Why don't you just reuse the compound shape?", which essentially boils down to me originally not wanting to have to reconcile the state between the two worlds. It's essentially the "immediate mode" vs "retained mode" debate when talking about GUI stuff. Granted, the tree here is fairly simple, so I don't think the "retained mode" option would be that much more complicated, but it does invite a class of desync bugs that you'll never have with the "immediate mode" approach.

(There was also the matter of me wanting to use JPH::StaticCompoundShape, which obviously doesn't allow for reusing it, but I'd say the motivation was 50/50 between this and the simpler reconciliation.)

Either way, it seems to me that things have to be refactored in some way, outside of just switching out the compound shape and adding some NotifyShapeChanged. Perhaps this refactoring isn't as bad as I imagine it to be. I'll have to try it out regardless, since I don't think I can justify keeping things as-is with the amount of overhead in the scenario shown above, even if the workaround is often simple.

[jrouwe]

Ok, my (incorrect) assumption was that you would continue to reuse the LazyCompoundShape for subsequent add_child calls, calling LazyCompoundShape::AddShape/RemoveShape as children are added/removed to the godot nodes. It does indeed mean keeping 2 systems in sync. Given that it could improve performance a lot, I personally think it's worth a try. I guess the difficulty comes from being able to infinitely nest shapes in shapes in godot and passing that as a flat list to Jolt? (haven't looked at the actual building code to confirm)

Actually, you could even create a LazyCompoundShape for the first shape since StaticCompoundShapeSettings::Create is clever enough to not actually create a StaticCompoundShape when there's only 1 shape. The downside to always using a LazyCompoundShape is that there is additional memory overhead and overhead of locking a mutex in querying scenarios (which is probably undesirable).

[mihe]

I guess the difficulty comes from being able to infinitely nest shapes in shapes in godot and passing that as a flat list to Jolt? (haven't looked at the actual building code to confirm)

Thankfully that is not a thing in Godot. It's not currently possible to assign a CollisionShape3D as anything but the direct child of a PhysicsBody3D and have it actually apply. There is however a pending PR to allow for this, but it still just behaves as a flat list (in depth-first order I assume) as far as the physics server is concerned, so there's no notion of compound shapes within compound shapes.

The only real complexity as far as the shape tree is concerned stems from the various JPH::DecoratorShape that are applied, but it should be easy enough to strip those away when looking for the actual shape I guess.

Actually, you could even create a LazyCompoundShape for the first shape since StaticCompoundShapeSettings::Create is clever enough to not actually create a StaticCompoundShape when there's only 1 shape. The downside to always using a LazyCompoundShape is that there is additional memory overhead and overhead of locking a mutex in querying scenarios (which is probably undesirable).

Yeah, the mutex seems unfortunate. I'd prefer to not add much more to the single-shape case, since it's likely the majority of bodies being created out there. With that said, I am currently wrapping every single shape reference in a custom decorator shape to allow me to have different userdata for the same shape, so it's not exactly as lean as I made it out to be in the breakdown above, but still.

[jrouwe]

Ah, I see where my confusion comes from, I tried adding shapes to shapes and it seemed to work in the UI:

But I notice the big yellow sign now that says that it is not supported :)

[jrouwe]

Oh, I just spotted: the shape type should not be JPH::EShapeType::Compound but UserX to prevent someone from casting the shape to CompoundShape.