Guidance on Automating BulletSkeletalMesh Simulations in Bullet Physics Plugin

[khalidbourr]

Dear,

First of all, thank you for developing the Bullet Physics plugin—it has been an invaluable tool for my Unreal Engine projects, and I truly appreciate the hard work and expertise you've put into creating it.

I'm currently working on a level that includes several BulletSkeletalMesh components. My goal is to simulate all these meshes using Bullet Physics. While I can successfully simulate individual meshes by manually calling LoadBulletActor, I wanted to ask if there’s a way to set up the plugin to automatically detect and simulate all BulletSkeletalMesh components within a level, rather than having to invoke LoadBulletActor for each one manually.

Additionally, I’ve encountered some unexpected behavior during testing. For instance, while a single mesh simulation works, it gets bigger and it doesn't collide with the floor. I suspect this might be because the floor itself also needs to be a Bullet-compatible mesh. Could you confirm if this is indeed the case, and if there are specific requirements for such interactions to work correctly?

Lastly, I’d appreciate any advice on best practices for setting up the plugin to handle level-wide simulations seamlessly. For example:

Should the BulletSubsystem handle all BulletSkeletalMesh components automatically, or is manual initialization via LoadBulletActor always required?
Are there specific configurations or debug settings I should enable to troubleshoot unusual behavior during simulations?
Thank you so much for your time and assistance. Your guidance would be greatly appreciated as I continue to explore the capabilities of this fantastic plugin.

Best regards,

[Yadhu-S]

Hello @khalidbourr

Glad you are finding the plugin useful. :)

I wanted to ask if there’s a way to set up the plugin to automatically detect and simulate all BulletSkeletalMesh components within a level, rather than having to invoke LoadBulletActor for each one manually.

It is possible, yes. It won't be done automatically though, because we don't have a full fledged integration. The code below is one way of doing it . (Tagging your actor in the editor with a string and adding it by iterating through all actors in the subsystem using OnWorldBeginPlay(UWorld& InWorld))

void UBulletSubsystem::OnWorldBeginPlay(UWorld& InWorld)
{

	// Check if World is valid
	if (World==nullptr)
	{
		UE_LOG(LogTemp, Error, TEXT("Invalid World"));
		return;
	}

        // Tag the actor which contains your UBulletSkeletalMeshComponent through your editor
	FName bulletTag = FName("bullet-skeletal");
	// Iterate over all actors in the world
	for (TActorIterator<AActor> actorItr(World); actorItr; ++actorItr)
	{
		AActor* actor = *actorItr;
		if (!actor)
			continue;

		// Check if the actor has a UStaticMeshComponent directly
		if (actor->ActorHasTag(bulletTag))
		{
		       UBulletSkeletalMeshComponent* skeletalMesh = Cast<UBulletSkeletalMeshComponent>(actor->GetRootComponent());
                       if (skeletalMesh)
                       {
			    skeletalMesh->LoadBulletActor(World->GetSubsystem<UBulletSubsystem>());
                       }
		}
	}
}

For instance, while a single mesh simulation works, it gets bigger and it doesn't collide with the floor. I suspect this might be because the floor itself also needs to be a Bullet-compatible mesh

hmm... If bullet recognizes the floor (You can see it in the debug renderer) , I don't think its a compatibility issue of any kind, it just reads the size of the static mesh from UE and creates its own.From the screenshots I suspect it might be a CCD issue. The body tunneling though the floor rigid body when moving too fast. CCD isn't turned on by default. You can check out this link

Should the BulletSubsystem handle all BulletSkeletalMesh components automatically, or is manual initialization via LoadBulletActor always required?

Unfortunately we need to call this ourselves manually. As I said previously, because we don't have a full fledged integration, and because I did not want to modify the AActor class or anything in the engine, this approach was sort of like a compromise (There might be better ways that I am not aware of).

Are there specific configurations or debug settings I should enable to troubleshoot unusual behavior during simulations?

You already have the debug renderer enabled, which by itself is a great debugging tool. Other than that, make use of your normal debugging tools :)

Good luck with your project, and hope this helps. I have long since moved on from this plugin and switched to Jolt Physics solver for my UE project. So, I'm kind of rusty with this one 😅 .

[khalidbourr]

Thank you a lot for you answer. I am still wonder in going in the direction of the Bullet physic engine with UE5 or to switch to Jolt Physics. I am working on robotics, so simulating the mechanics for me is crucial, what would you suggest ? Thank you again, I really appreciate you help.

[Yadhu-S]

I see. Sadly, I don't know enough about robotics to give you a direct answer to that 😅. However, with any core component switch, make sure switching over will give you a significant advantage because porting over is a massive chore! Make a list of the advantages and compare if you have to. For me Jolt was a much better solution because of its multithreading capabilities. Also there were things in jolt specific to my project that were not in bullet without fiddling with its codebase.

Also, I am not sure if there a jolt plugin available for UE yet, I had to implement my own custom plugin like this one ( which is not that different from this if you want to give it a go yourself). I plan to share mine some time in the future (likely after my project nears completion because the plugin is in its very early stages, and even calling it half baked would be a stretch. Its basically just dough at this point 😄 )

Oh, and do read this blog if you decide to do your own jolt implementation. Its what the code in this plugin is based on. There are changes in my implementation, like we are using subsystem instead of an actor but the idea remains the same (even if it's for bullet)