Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

WIP: Revive order of grabbed #1450

Open
wants to merge 13 commits into
base: production
Choose a base branch
from
Open

WIP: Revive order of grabbed #1450

wants to merge 13 commits into from

Conversation

snozawa
Copy link
Collaborator

@snozawa snozawa commented Oct 19, 2024

Summary

Issue

Resolution

  • Since unodered_map is introduced for the performance improvement, it's not good idea to revive other STL containers for the representation.
  • Instead, while keeping the unordered_map, maintain the order by adding the unique id into Grabbed class. Such unique id is (mostly) monotonically increasing and represents the order when grabbed.
  • In addition, Grabbed::ComputeListNonCollidingLinks will consider the order when grabbed via the unique id. If other grabbed body has larger unique id, it means it's grabbed later and don't need to compute the listNonCollidingLinks.
  • Overall, this PR tries to make the result of lazy-computation equivalent as the result of non-lazy-computation.

Shunichi Nozawa added 2 commits October 19, 2024 14:33
- Issue
  - Previously, KinBody remembers the order when the grabbed bodies are grabbed.
  - However, it's broken since we introduced unordered_map. Especially, listNonCollidingLinksWhenGrabbed computation becomes less deterministic along with its lazy computatoin.
- Resolution
  - Since unordered_map is introduced to improve the performance, not good idea to revive std::vector as its representation.
  - Instead, introduce the unique id to remember the order when grabbed.
… it means pOtherGrabbed is grabbed later than 'this'. Thus, pOtherGrabbed did not exist when 'this' was grabbed.

The results of lazy computation should be same as the result of non-lazy computation. Therefore, we should not compute the inter-grabbed collision checking with pOtherGrabbed.
This resolves Issue4 in #1436.
@snozawa snozawa requested a review from Puttichai November 7, 2024 09:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant