Scene.ThreadManager and Dispose

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
ecosky
Posts: 69
Joined: Fri Nov 04, 2011 7:13 am
Contact:

Scene.ThreadManager and Dispose

Post by ecosky »

Hi Norbo,

I have recently started retaining a ThreadTaskManager that lives through the lifespan of the application. There are multiple Space instances that are created & disposed as the game runs, primarily to ensure there are no unintended leaks between parts of the game that transition between completely different areas (think switching maps in Team Fortress or any other shooter, it's a completely set of entities when it switches). Previously, I created a ThreadTaskManager for each Space but in the interest of using the ThreadTaskManager more widely in my game, I keep one around that I use for tasks outside the scope of physics. Anyway, the Space constructors take an IThreadManager as a parameter, but the Space Dispose will always dispose the provided IThreadManager. Setting Space.ThreadManager to null before Space.Dispose doesn't work either, as the Space.Dispose assumes a valid ThreadManager to dispose.

I made my own local changes to just clear the Space.ThreadManager and check for null in Space.Dispose, but it seems to me that since the Space is provided the ThreadManager as a ctor parameter it shouldn't be taking responsibility for disposing it.

I just wanted to point that out for something for you to consider.

Incidentally, I create & destroy the Space instances mainly because it seems likely a better choice than manually removing every object in the Space and hoping something didn't get missed. Is this perhaps overkill? Should just removing all objects in the Space sufficiently reset it or will there be lingering events or something else I don't know about yet that might cause referenced object leaks? When switching game modes, I pretty much just want to dump the entire scene contents which is why I currently just dispose the whole thing. It would be nice if there was a safe "Reset" method that would reliably reset the Space to an empty state.

Thanks,
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Scene.ThreadManager and Dispose

Post by Norbo »

The latest version now has a Space.OwnsThreadManager property. If it is set to true, the Space will try to dispose the thread manager.

The Space constructor which takes no parameter sets the property to true by default since it creates its own thread manager. The constructor which takes a thread manager sets it to false. There is also now a third constructor which gives the property an arbitrary value. The property is also settable.
Incidentally, I create & destroy the Space instances mainly because it seems likely a better choice than manually removing every object in the Space and hoping something didn't get missed. Is this perhaps overkill? Should just removing all objects in the Space sufficiently reset it or will there be lingering events or something else I don't know about yet that might cause referenced object leaks? When switching game modes, I pretty much just want to dump the entire scene contents which is why I currently just dispose the whole thing. It would be nice if there was a safe "Reset" method that would reliably reset the Space to an empty state.
For now, I recommend recreating the space as opposed to removals. This isn't so much for lingering state as it is for simplicity and speed- doing a removal on every single object is a lot heavier than flushing it down the toilet because each remove needs to result in a valid world state.

A proper 'reset' would be nice to have in these kinds of situations. It would do a better job at keeping resource pools populated for later simulations. The only thing stopping me from adding it is the effort required to properly implement the extra logic on each and every substage of the space relative to the smallish benefit over the 'toilet flush' approach. I might end up doing it eventually, though.
ecosky
Posts: 69
Joined: Fri Nov 04, 2011 7:13 am
Contact:

Re: Scene.ThreadManager and Dispose

Post by ecosky »

Thanks Norbo

I'll try to update code soon. I'm a bit nervous about switching from the original XNA to the dependency free/main branch.. do you expect the dependency free version to generally work with XNA (it is dependency free after all..)? Perhaps with the debug draw stuff missing? Not sure what to expect if I were to try to switch over to the DF version. No need to get into deep details, I'll probably grab it soon and see for myself, just curious what the biggest issues might be.

Thanks again,
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Scene.ThreadManager and Dispose

Post by Norbo »

The only noticeable thing would be dealing with the occasional conversions to native XNA types when dealing with certain bits of the graphics API. These can usually be compartmentalized with some care. The demos, which are still based on XNA, only end up converting when dealing with the BEPUphysicsDrawer. Those could be avoided too if I spent some time propagating the dependency free math more completely. In my own non-Demos projects, the dependency free math is used all the way down to GPU buffer management, so I don't actually perform any conversions at all.

Modifying the BEPUutilities math types to have implicit casts to XNA types could help get the conversions done without many/any code changes to the main project. This might be the most practical solution, though it does involve a tiny bit of overhead from all the additional shuffling at every conversion.
ecosky
Posts: 69
Joined: Fri Nov 04, 2011 7:13 am
Contact:

Re: Scene.ThreadManager and Dispose

Post by ecosky »

Thanks, appreciate the info.
Post Reply