I’m not sure of the behavior of physicsSpace.add(control), and need some clarification from the pros 
Is there a way to check if physicsSpace contains a control instance? And if not, does the physicsSpace.add(control) function create duplicate controls? If so, how to I prevent duplicate controls from being added (aside from making my own index)?
How do you get into the situation where you are adding them twice in the first place? Seems like your game state may be kind of chaotic.
Anyway, at least in native bullet, adding/removing a control from the physics space isn’t actually keeping anything internally. It’s just setting the physics space onto the control… which itself adds what’s needed to the physics space.
But you should maybe be a little concerned that you got painted into this corner in the first place.
Not all physics controls actually get stored in the PhysicsSpace: some do and some don’t.
RigidBodyControl and GhostControl and other controls that extend PhysicsCollisionObject get stored in the space.
Controls that extend AbstractPhysicsControl are not collision objects and do not get stored in the space. Abstract physics controls create collision objects, which they add to the space if all the conditions are met.
I understand what your saying. As for how my situation came to be, I have an entity system in place, and the way its currently implemented, the store that backs the system is the source of truth, it contains all the entities and their components, and from this store, entities and pulled and placed into, say, the scene graph or the physics space. I have it set like this to disambiguate control from the scene graph and the physics space, so that entities can exist in either, both, or neither and still be available to the rest of the systems. I can see a scenario where an entity might be pulled from the physics space, and later added again. Currently, when an entity gets pushed into the queue that adds entities to the physics space, and then consumed on the next update, the handler has no way of knowing whether the entities physics control has already been added to the physics space (without adding an extra boolean to every entity). So I figured I could just query on the physics space, but I found that’s not possible. So that’s what got me here. It’s mostly just a side effect from the amount of flexibility I put into my entity system
But in my reading of the code, they do it themselves. physicsSpace.add(myControl) will just set the physics space onto the control RigidBodyControl will then add its collision object back to the space.
I admit I only poked at it for a couple minutes.
Are you using Zay-ES or some other entity system.
Because in Zay-ES, the entity set would be the queue and there is no need for extra logic. On the physics thread, add all of the new objects, remove all of the removed objects… done.
@sgold Gotcha. I’ll have to consider that in my system. The system that handles the physics doesn’t enforce a type for the control, and will accept any PhysicsControl. Will it suffice to restrict them to some type? the issue I’m seeing here is the system will call physicsSpace.add(physicsComponent.control) every time the entity is added to physics, including if the entities was previously added then removed. This could lead to multiple calls to add, and I don’t understand the behavior of add enough to know if this would be an issue.
It’s a custom entity system, sorry I should have mentioned that, but I could implement a queue like that. So, if I call remove for every add, I should be good?
I advise against invoking the physicsSpace.add(Object) method.
The usual way to add a control to a PhysicsSpace is to invoke physicsControl.setPhysicsSpace(physicsSpace). The control should then take care of adding/removing its collision objects for you.
Physics spaces act as containers for collision objects. Adding or removing the same collision object twice should result in a diagnostic message.
And by the way, if you’re using jme3-bullet, I recommend you transition to Minie ASAP!
Ahh gotcha, much appreciated. And I didn’t know that, I’ll definitely shift over to Minie while the physics systems are young
Is there a tutorial for moving to Minie on Jmonkey SDK?
Which version of the SDK are you using?
v3.2.4-stable
Ah, SDK v3.2.4-stable-sdk1 is what I’m using, too!
Yes, there’s a tutorial for adding Minie to existing projects:
How to add Minie to an existing project :: The Minie project
If your project is built using Ant, I also recommend switching to Gradle ASAP. I use the excellent “Gradle Support” plugin, which you can download and install using the Plugins dialog in the IDE (Menu bar → “Tools” → “Plugins”).
Thank you! And I believe it is using Ant, I haven’t messed with the build settings much. I’ll check out that plugin, thank you for the help and support, I appreciate it! I’ve dedicated my quarantine time to finally finishing this game, but it’s still a young project and I have a ways to go
How to distinguish Ant-built projects from Gradle-built projects:
If your project has a “build.xml” file in the root folder, the SDK will probably regard it as an ANT project: the Projects window will display a monkey-head icon next to the project name.
If your project doesn’t have a “build.xml” file in the root folder but it has a “build.gradle” file instead, the SDK will probably regard it as a Gradle project: the Projects window will display a green Gradle icon next to the project name.
The SDK appears to cache the project type, so after you delete “build.xml” from a project, you may have to restart the SDK before it will load properly.