Hi guys, not often, but from time to time, I’m randomly getting one of those 2 exceptions, it’s just sometimes, not all the time. Can anybody help me find out possible causes of this and/or how to resolve/debug this issue? I know it’s physics related because it’s always talking aobut bullet and there are a bunch of RigidBodyControl laying around on my scene. I also have TerrainQuad spatials with HeightfieldCollisionShape enabled. Thanks for any kind of input regarding these issues.
That would be weird because it was not happening a month ago and I already had plenty of props that collide with the terrain without any problem. I’m wondering if bullet could not like the fact that it recently has to collide empty nodes with the terrain. Could this be the cause to you?
@.Ben. said:
That would be weird because it was not happening a month ago and I already had plenty of props that collide with the terrain without any problem. I'm wondering if bullet could not like the fact that it recently has to collide empty nodes with the terrain. Could this be the cause to you?
If you write/read or touch physics objects from multiple threads it is not weird, you just got unlucky a month ago and didn’t see it happen. If you are not spawning threads on your own then it probably is something else.
@jmaasing said:
If you write/read or touch physics objects from multiple threads it is not weird, you just got unlucky a month ago and didn't see it happen. If you are not spawning threads on your own then it probably is something else.
The only threads I’m spawning are to create the TerrainQuads but at the moment when any exception occurs, there are no thread creating TerrainQuads. That’s why I find it weird, especially when I resolved a similar in-thread collision exception before. I know what you’re talking about concerning the collision from multiple threads… but to me it’s completely unlikely to happen from my own threads if that’s the case. I’ll have to completely track this new prop RididBodyControl all the way from the start and see just exactly where it is checked against collisions and/or where the mesh is actually implied in any checks (I know it’s not manipulated for modifications 100% sure) and I also have networking enabled, so I’m wondering since the network uses threads too, maybe from a network function call (at this point inside a thread) maybe it is checking for a collision somewhere. I’ll investiguate more, this will take some time, I’ll post back what I found afterwards for next people coming up with these bullet exceptions.
BUT can somebody confirm that colliding with an EMPTY node cannot cause at least one of those 2 exceptions? I’m pretty sure it began around the time I introduced these empty nodes. Maybe what I could do is actually put some geometry inside of those empty nodes, just to see. It’s sure I’ll get those exceptions thrown within 10 minutes at the most. Will post back results here. Thx
Maybe a stupid/noob question but… Is SimpleApplication.onAction() part of a different thread than, let’s say, SimpleApplication.update() ? Could that be the cause? Because I have isolated in the past hour that when it happens (rarely) it always happens when CLICKING, so from what seems to be: SimpleApplication.onAction()
@.Ben. said:
Maybe a stupid/noob question but... Is SimpleApplication.onAction() part of a different thread than, let's say, SimpleApplication.update() ? Could that be the cause? Because I have isolated in the past hour that *when it happens (rarely)* it always happens when CLICKING, so from what seems to be: SimpleApplication.onAction()
There is no SimpleApplication.onAction(). Are you maybe implementing a listener that you are passing to InputManager? Those are all run on the same render thread as update().
Oops yes (DUH) I was talking about the overriden function from ActionListener.onAction()
OK, so this clears one hypothesis I’ve been wondering… that’s pretty weird. It didn’t do it as much today. I had the program run for > 30 minutes like 4 times today and it ran perfectly.