Some userdata variables are still uint32_t

[SSNTails]

Some mUserData variables, such as the one in CompoundShapeSettings, are still uint32_t, instead of uint64_t. Should these be expanded to be 64-bit variables so they are suitable for storing custom pointers?

[jrouwe]

This is on purpose to keep compound shapes small (we have compounds with 1000s of shapes).

[SSNTails]

OK, makes sense. During contact callbacks, etc., is the SubShapeID one of these such sub-shapes, or does the 'parent' compound shape body ID consist of this? (I admit I have not gotten to the point of testing this yet)

Essentially I want to be sure that if I am handling a contact, or a ray/shape cast, etc, I can find out the mUserPointer of the parent compound shape (the 64-bit mUserData).

[jrouwe]

The sub shape ID points to the leaf shape (which does have a uint64 user data, so if you're not sharing then you can use that), but you can traverse the entire hierarchy of shapes from the body to the leaf shape by writing a recursive function like:

void visit(const Shape *inShape, const SubShapeID &inSubShapeID)
{
	// do something with inShape->GetUserData()
	// ...
	
	switch (inShape->GetType())
	{
	case EShapeType::Decorated:
		// Recurse
		visit(static_cast<const DecoratedShape *>(inShape)->GetInnerShape(), inSubShapeID);
		break;

	case EShapeType::Compound:
	{
		const CompoundShape *compound = static_cast<const CompoundShape *>(inShape);
		
		// Decode sub shape index
		SubShapeID remainder;
		uint32 index = compound->GetSubShapeIndexFromID(inSubShapeID, remainder);
		if (index < compound->GetNumSubShapes())
		{
			// Do something with compound->GetSubShape(index).mUserData
			// ...

			// Recurse
			visit(compound->GetSubShape(index).mShape, remainder);
		}
		break;
	}

	default:
		// No further recursion
		break;
	}
}

[SSNTails]

Hey, that's really useful! I will give it a try soon. Thanks, Jorrit!