search

stilldesign / PhysX.Net

A .NET wrapper for NVIDIA PhysX 4.1.2 written using C++/CLI.
MIT License
206 stars 55 forks source link

Disposing dynamic actors in contact #18

Closed steenhother closed 9 years ago

steenhother commented 9 years ago

I have two dynamic actors that are in contact. I dispose both actors by calling the RemoveActor on the scene and then Dispose on the actor. (that is of caused done synchronized - after calling Simulate() has returned) In the next Simulation Step I get the message "Cannot find managed object with pointer address".

This only happens for none kinematic actors that are in contact with another dynamic actors!

Is there a different way (or more safe way) to dispose an actor in contact with another actor!

actorsincontact

stilldesign commented 9 years ago

Sounds like a bug, sounds like it's not removing it from the main ObjectTable (which keeps track of all the objects)

steenhother commented 9 years ago

Thanks for your quick reply!

Right now I am only removing the actor from the scene but I have a lot of dynamic objects being created and disposed - I can see in a profiler that the shapes remains in the memory which quickly becomes a problem to my application.

Can I do anything to support the bug fixing - it is really a showstopper to me - but properly the last one: I have been working now for 3 weeks: switching from 2.8.1 to 3.3.1 - it has been quite a task

Right now I am using the PhysX.Net-SimulationEventCallback branch.

Thanks a lot for creating this wrapper and for your support!

stilldesign commented 9 years ago

Hey, sry I haven't addressed this in a week, I've been on holiday out of the country :P

I tried to reproduce this by playing with the EventsSample project and adding specific actors to a List when they collide, then calling Dispose on them after Simulate is called. Unfortunately I didn't receive any exception after calling Dispose on the Actors.

My sample/test is in the SimulationEventCallback branch, EventsSample project. If you could run it and see if the falling box actor and the one on the ground get disposed when they collide. Also any additional info on how to reproduce this would be cool

steenhother commented 9 years ago

Thanks for your reply... hope you have had a pleasant holiday. I have been looking into you sample... I have actually discovered that I did some filtering incorrectly: using the PairFlag.NotifyTouchLost on some actors where it was not needed.

BUT: actually I have other kind of actors where I needed to set the PairFlag.NotifyTouchLost. Then when using this flag I get same kind of exception:

To reproduce just put in the in the "PairFlag.NotifyTouchLost" into the FilterShader:

notifytouchlost

stilldesign commented 9 years ago

Hey, yeah that makes it error. I'm not sure why PhysX would be reporting the TouchLost for an actor which has been dispose by the previous Simulate call, I would of thought it would of checked this and not raised the touchlost.

This might need further thought, but a naive fix for now could be to just change the ContactPairHeader class to use TryGetObject instead of GetObject, and have it return null for one or both of the actors it's trying to get.

steenhother commented 9 years ago

I am not sure how the native fix helps: Even if I do the change as you have described I still get the same exception:

exception

steenhother commented 9 years ago

Hey

Do you have some other tricks that I can try... this is really driving me crazy. I really appreciate any help you can provide.

stilldesign commented 9 years ago

Hey, I also changed ContactPair to use TryGetObject and it allows the sample to work with NotifyTouchLost. I've committed this change, give it try and see if it's working. I've tested it on my home machine and it seems to work - the boxes fall and touch and are disposed and the sample continues to run, also hitting spacebar thorws out a sphere and having those spheres collide causes them to be disposed without issue.

steenhother commented 9 years ago

Thanks. That helped... I did the same in the TriggerPair because that is actually the OnTrigger event that I am using. Can you tell if you have some plans to merge the existing branches and will you include the latest fixes from the SimulationEventCallback branch? Not that is important right now - but I could imagine that that it is something you would like to do?

stilldesign commented 9 years ago

Hey, good to hear you've been able to move forward :) I'll add in the change to TriggerPair as well :) Plus I'll add in some tests around disposal of objects.

I do need to merge all the various branches back into master, it shouldn't be too much hassle, just need to make the time to do it. The biggest change will be merging the 3.3.3 upgrade as there's quite a few changes to the API.

Currently there's: 3.3.3 branch System.Numerics.Vectors branch (common Vector3, Matrix etc library) This SimulationEventCallback branch And I need to revisit the detaching shapes problem

steenhother commented 9 years ago

Sounds great!

It would really be great if you were able to solve the "detaching shapes problem": In the past I were using the feature of being able to remove shapes from an actor and replace it with new ones a lot. In the current version of my application I have done a work-around (by just disposing the actor and then recreate the actor again with a new set of shapes). But that is not a nice solution.

But anyway I am really appreciate what you have already been doing.