Hi!
I’m writing because I found a bug in the pipeline. When generating the skeleton in CC/iC, the fingers generate with incorrect rotation. When scaling the main controller responsible for bending the fingers, instead of moving straight, it shifts sideways. The controllers themselves are also rotated by 90 degrees, but simply rotating them doesn’t help because the drivers in the mech bone just snap to different axes. The issue doesn’t occur when generating the metarig.
Hi
My experience with direct imports to Blender from CC (via the pipeline tool)
is that the finger bone rotations are often wrong particularly the THUMB.
However when I rig a non CC character mesh with the stand alone Accurig utility then export that with the Blender preset,
and then use the pipeline tool to import it into blender I get perfect finger rotations
after conversion to Rigify.
The obvious down side is the you would lose your facial animation capability with an export from the standalone Accurig
But I am still on Iclone 7 and do not have Iclone 8 with the built in advanced Accurig so I don’t know if it would retain the facial rigging when sent to Blender
Hi…
Our dev team suggest you use local space rotation — that should produce the expected result.
Thanks for the reply!
I actually bought CC fairly recently, and what really sold me was the nicely implemented facial control that works directly in Blender. If I had to give that up, I might as well stop using CC entirely—at least when it comes to using it for character models. So I figured it was worth reporting this obvious bug in the hopes that the devs will fix it quickly.
Thanks for the reply!
Regardless of rotation space, the result will always be “incorrect.” Scaling the main control affects the mechanical bones through drivers, so whether I use global, gimbal, or local space—the outcome will always be the same.
Thanks for explaining more.
I would recommend reporting your findings in the Feedback Tracker and the dev team will investigate it further. The FT is the best way to get issues looked at and resolved so it’s certainly worth reporting it.
This was fixed in 2.3.1.
