Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
I suppose that a different, vary vague way to describe the differences would be that inverse-kinematics are about the "destination", while forward-kinematics are about the "journey", and sometimes one is more important than the other.
As one is better in some situations while the other is better in other situations, neither of them are strictly better or worse than the other; Depending on what you're trying to do, the best option may be to use a bit of both.
https://steamcommunity.com/sharedfiles/filedetails/?id=661850284
Rig scripts do often hide control categories, but they can be accessed by showing hidden controls in the Animation Set Editor's "gear" menu, and then (if you so choose) unhidden by the category's right click menu.
(However, generally, most controls are hidden because they're either now overridden by the IK rig and therefore would just be frustratingly unresponsive, or in some cases, because they would crash the program - two bones pointed at each other with aim constraints is sometimes useful for things like pistons, but will crash SFM if selected - so be careful what you poke).
It's inadvisable to keep adding and removing an IK rig if avoidable (it will cause the loss of keyframes, amongst some other possible issues).
Personally, I program all of my IK rigs in a similar way to episoder's, with nodes at the hip/shoulder that can be used to provide some FK capability.
(Although I have the parenting the other way around - my rigs default to normal IK parenting, and have to be locked to the FK nodes, rather than vice versa).