Prawda jest taka, że też na początku myślałem, że to jest kwestia tych dwóch parametrów. Sęk w tym, że nawet po ustawieniu ich na maksymalne możliwe wartości problem wciąż występuje.
Wypalać też próbowałem, ale opóźnienie i tak zostawało.
Bardzo prawdopodobne jest, że opóźnienie wynika z hierarchii obiektów i zdaje sobie z tego sprawę. Sęk w tym, że nie bardzo jest to jak obejść. Docelowo kolczyk będzie musiał być sparentowany do kości, nie do mesha. Pojedyncza kość nie może mieć fizyki
Rigid Body, nie może też być wybrana jako cel dla
Rigid Body Constraint (jedynie cały szkielet). Stąd konieczność podpięcia najpierw jednego obiektu, na którym będzie "zawieszony" kolczyk, a potem drugiego, który będzie sobie dyndał. No i się tworzy łańcuch obiektów, który nie bardzo jest jak skrócić.
Warto zaznaczyć, że constraintsy zawsze są trochę gumowate, co ujawnia się szczególnie przy gwałtownych ruchach.
Szczerze mówiąc trochę kicha w takim razie.
Tak czy siak, jeśli chodzi o kolczyk, udało mi się jako-tako rozwiązać problem. Działa to mniej więcej tak: cała hierarchia podpiętych obiektów zostaje jak była. Czyli mamy jeden obiekt robiący za cel dla Rigid Body Constraint (w tym wypadku Torus.001), i drugi - dyndający sobie i symulujący właściwą fizykę (Torus.002). Oprócz tego dochodzi dodatkowa kość, do której podpięty jest docelowy mesh kolczyka. Kość ma modyfikator IK, a jako cel ustawiony obiekt Torus.002. Symulacja dalej działa z opóźnieniem, ale wizualnie wszystko wygląda tak, jak powinno. Nawet jeśli przy szybkim ruchu głową obiekt
Rigid Body wyleci poza swój zakres ruchu, to kość wizualnie sterująca kolczykiem wciąż będzie na swoim miejscu, jedynie obracając się w kierunku docelowego obiektu. Mam nadzieję, że w miarę wiadomo o co mi chodzi.
To jednak tyczy się tylko symulacji
Rigid Body, w której obiekt jedynie się obraca. Potrzebuję jeszcze jakiegoś rozwiązania dla obiektu, który ma też pewną swobodę w przesuwaniu się. Zobaczymy, może uda mi się coś wykombinować i w tym przypadku.