Using collideWith now throws the following exception… I pretty sure it did not until recently.
Caused by: java.util.ConcurrentModificationException
Was this changed recently? In particular:
[java]Caused by: java.util.ConcurrentModificationException
@pspeed I thought so too but it seems she’s a good monkey and enqueues, no? Anyway I thought of concurrent collision data generation first too but it doesn’t seem to be it… We didn’t change this code lately did we? Some list stuff or so? @t0neg0d Can you make a test case ?
Let me ask a few questions first to see if I made a bad assumption or three in some of the test delegators I’ve been trying out. (These have nothing to do with the paging system… there trying different ideas for randomly placing objects, etc)
You can ray cast into a Node that is not associated with the scene graph being rendered… and this is ok, yes?
If this is the case, then you shouldn’t need to enqueue a ray casting, yes?
@pspeed mentioned the reusing of collisions results object. Is this a problem even if you use .clear(); ?
Oh… to answer the background thread question, I am. However, it is using a node that is a “point 1.” above scenario.
@normen While I’m waiting for the answers… I’ll give a few things a shot. Trying to figure out how to put together a simple test case for this. If I update the pagingTest project in the contributors depot… there would be one there. However, it would not be a “simple” test case.
Pretend I quoted the crap out of all of that. :evilmonkey:
Only if you do it from one thread. Collisions against an unattached node from multiple threads may be bad if the collision data has not been generated or whatever.
Depends. See above.
a) there is really no reason to reuse collision results. b) it may lead to an error of using the same collision results object from two different threads, ie: trying to perform two ray casts at the same time with the same collision results. That’s really the only way that I can see getting a concurrent mod exception with that class. It’s not like it shares state with anything else once the results are collected.
@normen, she’s doing stuff from different threads from the paging system. Even in the above there is at least one other thread hitting stuff.
Actually, so I checked the source and this has nothing to do with your own CollisionResults. The CollisionResults that is being conc-modded is internal to the BIHTree. So, the same node is having multiple collisions run against it from different threads.
Let’s say I want to find the contact points of a thousand spatials along the edge of another spatial, I would greatly make use of another thread to do that while my scene continues to refresh? None of the spatials used in the collision method are attached to the rootNode nor used by OpenGL to draw on the screen, so I must have missed the point of the collideWith, but what’s related between the spatial collision and the geometry drawing on the screen? Why aren’t both possible concurrently?
EDIT: NO WAIT. Actually, I discovered a flaw in my code. It was indeed reusing a node previously attached to the rootNode. My mistake I’ll test some more making absolutely sure it does not use any node attached to the rootNode.
EDIT #2:Confirmed. It works just fine from a thread given that it is NOT attached to the rootNode (my mistake to assume it was not, when smoehow I foresaw it really was) It works as expected now.