I’m sure there’s a simple answer to this. In earlier versions of JME, there was a function called setCollideable(), but this seems to have disappeared. How do I mark a spatial as not collideable to the engine doesn’t waste time checking for collisions against it’s children? I tried Googling but the only answer I could find was to remove the children from the node and then re-add them afterwards, which didn’t seem right.
Thanks in advance,
In a phrase: you can’t
Generally what’s done is to organize your scene into pickable and non-pickable things… and then don’t pick on the scene root. Pick on the pickable things’ root.
It’s kind of a limitation but since I hit it 5 years ago I’ve always found other good reasons to organize my scene that way anyway. So it hasn’t come up again.
Thanks. Strange why such a simple feature should be removed.
I wasn’t removed. It never existed, I guess.
You want to create a individual physics control for each object in your scene. Then you can add/remove them from the physics space as needed.
// add object to physics space
private void addPhysics(Spatial x) {
bulletAppState.getPhysicsSpace().add(x.getControl(PhysicsControl.class));
}
// Remove object from physics space
private void removePhysics(Spatial x) {
bulletAppState.getPhysicsSpace().remove(x);
}
I perform a check to get the objects distance from the player then I remove the object from the physics space if is too far away.
As far as I know doing it this way has little performance impact on the game but there may be a better way to do it. I also use the scene editor in the SDK to add physics controls as it becomes as permanent part of the node when you do it that way.
You want to do it this way to optimize performance. For example you don’t a street sign or garbage can two blocks away from your player in the physics space. Taking the object out of the physics space will save you computation time and boost over all game performance.
He’s talking about Spatial.collideWith()… or at least I assumed so from the rest of the information in his question.
Yep , I know but that code basically does the same thing.
No, not even close, really. One requires you setup physics objects and does full physics collision tests. The other does ray tests again your spatial’s geometry which is already setup.
It existed in JME<3. Adding a simple boolean to Node which is checked in collideWith() would be simple and save a lot of processing time.
Ok, keep in mind that JME3 is not just an incremental improvement over JME2… it’s mostly a rewrite. So something missing that was in JME2 wasn’t necessarily ‘removed’… it just wasn’t added.
A boolean only covers the simplest use-cases that are also easily covered by a scene graph reorganization. The real enhancement should probably use an int of maskable bits so you could have different values for clickable things versus character ray test things versus ???. It’s not just as simple as “hack in a boolean and have to support it forever henceforth”. Because there were usually other good reasons to reorganize the scene anyway… the feature just never bubbled up in my priorities again. (And I guess no one else’s, either.)