I have an application where I drive through databases and traffic passes me by. When an other vehicle is too far away I remove it with removeNode() or detachNode(). I use multithreading, by including in the pcr file:
threading-model /Draw
When the application is running long enough, the rendering freezes and just hangs, without any error or warning. Sometimes after 5 minutes, sometimes 30 minutes and sometimes longer. When I remove the threading-model /Draw from the pcf file, this never happens.
Also, when I am driving through the world without any other traffic that gets created and removed, the freezing never happens.
This is really very difficult for me to debug, because the freezing happens without any obvious pattern and does not result in any error message. I have the impression that this occurs because in the frame after the nodepath is removed or detached, the rendering system tries to draw it, which results in a freeze because it does not exist anymore. Does this impression make any sense? Does anyone have an idea how I can prevent this freezing?
I am using:
panda3D-SDK-1.10.0pre-a8d24ac-x64 from 2 sept. 2016, before this I used the version of 10-11-2015 and this had the same problem
windows 7 pro, 64 bits
a GeForce GTX770 GPU
Without the multithreading, frame rate drops to around 40 Hz, while it is 60 Hz with threading-model /Draw, so I really would like to use the multithreading.
Hmm, one thing that could give you a clue would be to set “notify-output spam” and log the output to a file so that you can look for the last thing Panda is doing at the time it freezes.
The “proper” way to debug this and know for sure what’s going on would be to grab a debugger (such as Visual Studio 2015) and attach to the process at the moment it freezes, and then break to find out where it’s getting stuck. For this to yield useful information, however, you need .pdb files, which are not shipped with the SDK due to their size. This means you would have to compile Panda3D from source. EDIT: we now offer .zip archives containing .pdb files on the devel build download page!
Do you happen to generate geometry in a child thread? There is a known issue where generating geometry in a child thread can cause a deadlock. You also need to make sure you are not hanging on to any write/read handles to copy-on-write objects for longer than a frame.
I replaced the dynamical creation and removal of nodepaths during the run by creation of a sufficient number of nodepaths at the beginning of the run. Then, when a vehicle gets too far away, I call hide() and place it in a table for later use, and when a new one is needed I look up an existing nodepath from that pool, position it properly in the world and call show(). I ran that for hours and that seemed to solve the freeze problem. So, Its probably a case of generating geometry although I don’t use child threads, apart from the Cull/Draw multithreading.