I will restart my game, and the crash won’t happen at the same place, or at all (even though my game creates the same terrain meshes)… I’m thinking it might be a threading issue…? Hoping someone will have some suggestions
@phr00t said:
Ah, OK. This must be done on the LWJGL rendering thread?
No, just on one thread so that theres no parallel instantiations. Its a jbullet thing, its not so in native. Its another place where jbullets "optimizations" rather add confusion and slowdowns :/
Ahhhhh OK, I gotcha. Yup, I create the terrain’s collision mesh in one thread, and then little collision shapes scattered about in the main LWJGL thread. They must share the same object pool without any synchronization and blam, exceptions Thanks!
Alternativly you can replace the boject pool from bulet witha new instance each time version, then its threadsafe, (at a higher gc cost, but at least with a jdk7 i found theses to be nearly zero)
@EmpirePhoenix said:
Alternativly you can replace the boject pool from bulet witha new instance each time version, then its threadsafe, (at a higher gc cost, but at least with a jdk7 i found theses to be nearly zero)
How would I go about doing this..? Modifying the jME3 / jbullet source directly? That wouldn't make updating very happy.. :/
EDIT: I suppose I could also add some synchronization myself to the physics object creation within my code. This may be the easiest solution.
It’s not just creation you can potentially conflict on but on creation during non-creation iteration.
:?
I still get this error after adding some synchronization during object creation, so something still must be broken:
http://i.imgur.com/grIhl.png
I was hoping to do at least terrain physics creation outside of the rendering thread, since it may cause noticeable lag otherwise. However, this is proving to be quite the headache :(
Also note that I am not adding the physics object to the physics space in these other threads... I just want to built the physics mesh so it doesn't hold up the rendering thread. I wouldn't mind doing object creation all in one thread, but it looks like conflicts are happening in the rendering thread physics update function and creation thread still :(
Thread 2: add new object to list (potentially breaks thread 1’s iteration)
Bad scenario:
Thread 1: starts looping through objects
Thread 2: remove object from list
Thread 1: checked object exists in list, now tries to fetch it, can’t, boom.
In other words synchronizing just on object creation is not enough - you need to synchronize on all access to the list. (If you really know what you are doing you can reduce that but this is the only simple rule that guarantees safety).
I still get this error after adding some synchronization during object creation, so something still must be broken:
http://i.imgur.com/grIhl.png
I was hoping to do at least terrain physics creation outside of the rendering thread, since it may cause noticeable lag otherwise. However, this is proving to be quite the headache :(
Also note that I am not adding the physics object to the physics space in these other threads... I just want to built the physics mesh so it doesn't hold up the rendering thread. I wouldn't mind doing object creation all in one thread, but it looks like conflicts are happening in the rendering thread physics update function and creation thread still :(
I literally mean one thread, sorry if it was unclear. Some stuff is instantiated threadlocal.
@normen said:
I literally mean one thread, sorry if it was unclear. Some stuff is instantiated threadlocal.
OK. So, what I think I need to do is call getPhysicsSpace() in a separate thread (other than the rendering thread). Then, I will need to create all my physical objects in that thread, so it won't hold up rendering and cause lag. However, this also would mean the physicsUpdate() calls would be happening in this new thread... if nodes are controlled by physics objects, could that cause scene node modification problems? Or does nodes get updated by their controllers in the rendering thread so this wouldn't be a problem?
Lemme think… It might be this becomes an issue in the collision callbacks, you might have to check how the BulletAppState gets the reference and pass it from the other thread. But… are you sure you have to do this? Are all threadLocal vars instantiated at the same time? Methinks it should be so that the respective variable is created when its needed, so you’d only have to create the first collision shape on the designated thread.
A) Create the physics space as normal, this will instatiate the collision callback on the right thread
B) Make sure the first time you create a collision shape you do it on the thread that you want to always create them on
C) Make sure you catually do only create the collision shapes on the designated thread.
I think that should work. Else as said, the BulletAppState (along with PhysicsSpace) contains all the code that handles the jme-related localthread stuff.
EDIT: Just a sec, my terrain is still having controls made in the other thread, not the rendering thread… not sure if this is still the problem, but something to try and fix…
But check the actual one 
Thanks!
http://i.imgur.com/grIhl.png
