viblo / pymunk

Pymunk is a easy-to-use pythonic 2d physics library that can be used whenever you need 2d rigid body physics from Python
http://www.pymunk.org
MIT License
922 stars 188 forks source link

Copy only dynamic data #258

Open majklost opened 5 days ago

majklost commented 5 days ago

I am using pymunk for my bachelor thesis, where I plan using RRT algorithm. Problem is, that I store many copies of space in a tree. I benchmarked my solution and found out that making a copy of space is the most expensive operation in whole process (70 % of time). Since all the simulations contain same bodies, constraints, shapes and collision handlers, I would just need to extract and apply only data that changes when stepping the simulation.

I tried to copy all physical aspects of bodies to bodies in second simulator (pos, velocity, angle,...), But simulation result still differs.... I looked how space.copy() is implemented, but it creates new space, so many things differs from my usecase.

Can you give a hint what all should I export and import from one simulation to another to achieve same behaviour when stepping both of them? (I can then contribute this feature to pymunk if it works) Thanks, Michal

viblo commented 4 days ago

This is an interesting question. I have not in any way benchmarked the copy functionality..

It's not easy to export the state fully, since you need to create/set the internal arbiter cache (cached collision data) and internal constraint data that is not really exposed to the python side.

Do you have a more detailed list of what inside the copy that's expensive for your case? I suspect it can depend a bit on what the setup looks like.

/Victor

On Tue, Oct 1, 2024, 21:35 majklost @.***> wrote:

I am using pymunk for my bachelor thesis, where I plan using RRT algorithm. Problem is, that I store many copies of space in a tree. I benchmarked my solution and found out that making a copy of space is the most expensive operation in whole process (70 % of time). Since all the simulations contain same bodies, constraints, shapes and collision handlers, I would just need to extract and apply only data that changes when stepping the simulation.

I tried to copy all physical aspects of bodies to bodies in second simulator (pos, velocity, angle,...), But simulation result still differs.... I looked how space.copy() is implemented, but it creates new space, so many things differs from my usecase.

Can you give a hint what all should I export and import from one simulation to another to achieve same behaviour when stepping both of them? (I can then contribute this feature to pymunk if it works) Thanks, Michal

— Reply to this email directly, view it on GitHub https://github.com/viblo/pymunk/issues/258, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJD2CDWGXVFKUWFUJHTHBLZZL2OTAVCNFSM6AAAAABPGIKVCOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU3DAMBUGA2TSMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

majklost commented 4 days ago

Hello, thank you for response, In my simulation I have a cable: https://github.com/majklost/2Dsim/blob/v2/src/deform_plan/assets/PM/objects/cable.py (Whole project is open source, but at this point it is still under construction and purpose of repo is just saving previous versions of code)

Cable is a group of rectangles connected with springs and rotary springs. The problem with space.copy() is that it is used in every iteration of RRT algortihm (imagine about 5000 or 10000 copies). In this setup all small nuances have drastical impact on final performance (I did not benchmarked internal parts of space.copy() )....

Do you think that extracting and setting things that can change during simulation (e.g. on body - position, angle, velocity) from one simulation to another and copying internal arbiter cache might be sufficient to make these two simulation "synced"? (behave same in next iterations?). Or is there anything else to transfer (I do not know if springs have some internal attributes like stored energy, that would need to be transfered, or is there even a need for making copies of internal C structures?)....

viblo commented 4 days ago

My "worry" is that by replicating everything to sync state between two spaces, the speed will be the same as the current way of copy. For example, AI think allocating a new space should be very fast.. but maybe it's not :)

But it much depend on if the main bottleneck is in allocating python objects, or allocating c structs, or something else.

All in all, without a closer look at a profile of the copy its difficult to say.

On Wed, Oct 2, 2024, 18:00 majklost @.***> wrote:

Hello, thank you for response, In my simulation I have a cable: https://github.com/majklost/2Dsim/blob/v2/src/deform_plan/assets/PM/objects/cable.py (Whole project is open source, but at this point it is still under construction and purpose of repo is just saving previous versions of code)

Cable is a group of rectangles connected with springs and rotary springs. The problem with space.copy() is that it is used in every iteration of RRT algortihm (imagine about 5000 or 10000 copies). In this setup all small nuances have drastical impact on final performance (I did not benchmarked internal parts of space.copy() )....

Do you think that extracting and setting things that can change during simulation (e.g. on body - position, angle, velocity) from one simulation to another and copying internal arbiter cache might be sufficient to make these two simulation "synced"? (behave same in next iterations?). Or is there anything else to transfer (I do not know if springs have some internal attributes like stored energy, that would need to be transfered, or is there even a need for making copies of internal C structures?)....

— Reply to this email directly, view it on GitHub https://github.com/viblo/pymunk/issues/258#issuecomment-2389042539, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJD2CEOHJ2PCRWS3BE36YTZZQKAFAVCNFSM6AAAAABPGIKVCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBZGA2DENJTHE . You are receiving this because you commented.Message ID: @.***>