Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Interconnecting actor woes #2974

Open
ohlidalp opened this issue Nov 24, 2022 · 1 comment
Open

Interconnecting actor woes #2974

ohlidalp opened this issue Nov 24, 2022 · 1 comment

Comments

@ohlidalp
Copy link
Member

ohlidalp commented Nov 24, 2022

#2973 opens up the nasty topic of connecting actors together at all.

Interconnecting beams

Under the hood, every actor has it's own pool of nodes and beams, and the beam which interconnects actors always belongs to one of them. Until 2014-2015 this was handled by a lot of if()-s in calcBeams() which somehow worked but broke with multithreading. Ulteq invested a lot of energy to find a solution and finally added calcBeamsInterActor() (modified copypaste of calcBeams()) which processes just the interconnecting beams, and a good deal of code to determine and track which beams are interconnecting. But there are still edge cases IIRC.

Transferring forces

In a physics simulation, position of nodes is calculated (integrated) based on forces and time. Setting the forces directly is prone to break numeric stability. We have multiple means of interconnecting actors (ropes, ties, locks...) and IIRC each works slightly differently and I've definitely seen position being copied from one node to another. This is a hazzard which we must eliminate. The only acceptable way of applying any external force to a node (be it from other actor, or user interface, or script, or anything else) is... well, to apply force.

Multithreading

Presently we do simulation in 2 phases: 1. each actor n/b and intra-collisions are simulated on it's own thread (using thread pool) 2. interconnecting beams and inter-actor collisions are simulated on shared physics thread. This means that if you have just 1 local actor (the common case!), you're using just single CPU core.

I have a solution in mind

Under the hood, merge all actors into one huge, permanently active n/b pool, and keep one extra dummy pool permanently sleeping. Keep the existing N/B logic around for spawning and repair/reset, just do simulation on this common pool. To sleep or wake up, swap the N/B between those. This would ellegantly solve the interconnecting problem as any beam would be technically on the same actor. This would also allow us to replace the threadpool by "symmetric multiprocessing" where the workload is equally split in all available CPU cores.

@ohlidalp
Copy link
Member Author

ohlidalp commented Jul 1, 2023

Related: #3057 - adding MSG_SIM_ACTOR_LINKING_REQUESTED fixes a threading hazard, but the performance concerns still apply

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant