This is my first time to actually have a look into collision handling (up to this point I've used physics for this type of thing). I'm having a problem with my model because the collision results are returning 1400ish each update and it seems to be due to my model colliding internally. Can I explicitly tell the system to ignore all collisions except specific nodes?
Also, is the only built-in way to handle collisions by cycling through the results? It would seem useful to have a event type system to deal with this better. Does anyone else agree…or is there already something for this?
In my collisionmanager I wrote a NotCollidable class to hold a set of node names that I didn't want to collide with (e.g. the skybox, etc) it wasn't the best way to do it, but you could do the same with only nodes that you want to collide with (since that'll be a shorter list than 1400+)
I'm not sure about the second part of the question. I didn't find any other way than to cycle through the results, but that doesn't mean much. I would agree that an event type system would be beneficial… here's an example of an issue I had. When I allowed my pool of 150 bullets per gun to fire then return to the pool, when each went out, they each ran through collision detection to see if they hit anything… now alone 300 checks isn't too bad, but 300 X the number of objects in the scene that are potentially collidable presented a bigger problem and a large (and VERY noticeable) slowdown in game speed until the processing was over.
Well, essentially I'm really concerned about the performance ramifications for calculating collisions at all if I have to calcuate EVERY collision. I only want to determine what is colliding with a single object in this case. Do I have to bite off the whole beast for the small chunk of cow I want? :-o
darkfrog said:
Well, essentially I'm really concerned about the performance ramifications for calculating collisions at all if I have to calcuate EVERY collision.
I agree, you've personally seen what happened to the speed on one implementation I did. That's why I worked on other portions of my code before I was going to go back to the collision detection, I just never made it that far.
I would have much rather been able to have pulled out an object and based on it's location (e.g. in octree space) narrowed down it's position to even collide with anything, however, I didn't quite get there in my development.
darkfrog said:
I only want to determine what is colliding with a single object in this case. Do I have to bite off the whole beast for the small chunk of cow I want? :-o
I wouldn't think so, unless you're really hungry :roll:
edit: I was looking at quaternions when I typed quaternion instead of octree
- Look through the code
- Understand it
- Come back
- rephrase your question.
Edit: Perhaps a bit harsh, but remember, you have developer status…
Fair enough, but as I've already stated, I'm just now going through this and trying to understand it. I was simply trying to verify my initial understanding was correct.
Your response would be more appreciated if you'd say, "You're missing something…go back and learn more" instead of "Well, you could be right, but until you know better I'm not going to say". :-p
Perhaps, if this was an isolated case… however, i don't want to get into that.
The first question you need to answer is why do you have 1400 items being registered as collidable. This is the major problem, and quite possibly greater than a collision problem. If your ship is within the bounding of 1400 objects, either your boundings are messed up or the scene is problematic.
Objects are placed in the results object if your object is colliding with the boundings, triangle indices are added to those data entries that also have triangle collisions.
isCollidable has been a switch in Spatial for a very long time now.
mojomonk said:
Perhaps, if this was an isolated case... however, i don't want to get into that.
Well, by making such a statement directly in the forums instead of talking to me directly why don't we go ahead and clear the air publicly? If you have a problem with the way I'm handling myself as a developer I'd appreciate it if you could talk to me about it privately rather than throwing something like this up on the forums or you can take away my developer status if it's a big problem.
mojomonk said:
The first question you need to answer is why do you have 1400 items being registered as collidable. This is the major problem, and quite possibly greater than a collision problem. If your ship is within the bounding of 1400 objects, either your boundings are messed up or the scene is problematic.
Objects are placed in the results object if your object is colliding with the boundings, triangle indices are added to those data entries that also have triangle collisions.
isCollidable has been a switch in Spatial for a very long time now.
I've tried setting the collidable status on the underlying aspects of the Node but it seems to take away all collisions then, not just the top-level one.
Just to be clear, I'm not mad, I'm just disappointed in your back-handed comment.
No, you're right, I apologize.
Now, to your problem… why are you getting 1400 objects colliding with your test? Answer that and we'll figure out where the problem lies. Like I said earlier, if you are colliding with that many objects… every object in your scene? There is a problem with bounds. Or the check might be incorrectly made. How are you calling the collision system?
Thank you.
I've been cycling through the items and I'm pretty sure it has to do with the ship model I'm loading. It looks like components of the ship are colliding with each other and causing this. I've tried model.getChild(0).setIsCollidable(false) but then nothing collides anymore. I'd like the outter Node of my model to have a bounding sphere that collides with other objects and if I do this I get no collisions at all:
model.getChild(0).setIsCollidable(false);
model.setModelBound(new BoundingSphere());
model.updateModelBound();
However, if I comment out the first line I get 1400+ collisions.
I'm calling my collision results like this on update:
collisionHandler.clear();
rootNode.calculateCollisions(rootNode, collisionHandler);
CollisionHandler looks like this:
public class CollisionHandler extends BoundingCollisionResults {
public void processCollisions() {
if (getNumber() > 0) {
System.out.println("Collisions: " + getNumber() + " - " + getCollisionData(0).getSourceMesh() + " - " + getCollisionData(0).getTargetMesh());
}
}
}
What you need to do is organize. Just throwing everything into a polygon soup and expecting good results is not going to work out, especially once you have a real scene.
A few tips:
- checking rootScene collisions with rootScene is not a good idea.
- It's wholly dependant on your game on how you organize, but normally a number of trees are created (you might have one for non-collidable, one for static collidable, one for dynamic collidable, etc).
- Normally, you only want to check collisions for objects that are moving. That is, checking rootNode to rootNode is going to be checking EVERYTHING with itself (highly inefficient). If you have three ships buzzing around, check each ship with rootNode individually.
The collision system is a low level system, it only works as well as the data you give it. You are going to need to write higher level management systems to optimally call collision checks as needed, this system is dependant on your needs for your game.
If you don't care about triangle accurate collisions, then better optimization of your scene should be good enough. If you are using triangle accurate collisions, you should consider using collision meshes for actual collision checks (especially if you are using those 25k poly ships).
- Well, I was initially just checking the ship with the rootNode but when I set isCollidable to false and then no collisions were occurring I swapped out to see if I could get anything to collide.
- Okay, so to minimize collisions instead of having one rootNode for the entire scene split it out into a non-collidable rootNode and a collidable rootNode (as a simplistic example)? That's a good idea.
Yeah, I currently am using that 25k poly ship as a placeholder I would think it should still work just fine apart from LOTS more polys in the scene to potentially collide. Am I doing this right by grabbing an underlying child of the ship and turning off collisions for it and still expecting the outter node to collide or is that not going to work?
Would you be opposed to me adding a collision manager to jmex (after I've spent a lot more time learning how to use this obviously) to simplify collision management a bit for people who want to abstract more away from it?
If you check you ship for collisions against the root node and the root node contains your ship you are going to run into those same problems. Collisions occur at the leaf node, the upper levels are there for processing the scene graph. Therefore, only leaves that collide are placed in the results (i.e. Geometry). Nodes are never placed in the results. Therefore, you can not turn of collisions for children and have the parent have collisions.
This problem is a problem with organizing your game data. And how you organize it is specific to your game. Any manager you write is going to count on that fact. So, no, please don't check anything into jmex, it's really started to become bloated as it is.
That explains a lot actually. So setting a bounding sphere around my ship is not sufficient. If I really want to ignore the ship itself then I need to actually create a Sphere around my ship and set it to cull always and use the bounding sphere on that instead?
mojomonk said:
This problem is a problem with organizing your game data. And how you organize it is specific to your game. Any manager you write is going to count on that fact. So, no, please don't check anything into jmex, it's really started to become bloated as it is.
Oh, I definitely agree and I'll acknowledge that I'm probably more to blame than anyone else for the "bloat". I think after the next release (or before the next release) we should begin an effort to cleanup the codebase. I'd be happy to manage the majority of that since a lot of the extras as of late are because of me. It would also be good to get some feedback as to what people like and are using and what is unnecessary and can be removed.
I think there's a lot of old code in jME that can be deprecated as well in favor of new ways of doing things also. We could start a thread on the forum just to discuss things that are in jME and get the communities feedback on what they like, don't like, and some efficiency increases overall.
Just fyi, mojo, this was a good thread to read so thanks for responding to df's posts. 
I hate having to do it but am using instanceof to filter on mesh collisions.
We initially made the type field to remove the need to use instanceof everywhere, but in the end it did not seem to have an impact on the code and things I've read since then suggest that instanceof is no longer all that big of a deal. If that is true, the field may eventually go away in a future release.