Ограничители, они же constraints, обладают весьма полезной возможностью обновлять положение объектов в вычислительном потоке. К примеру, у меня есть плагин манипулятора, который управляет набором объектов в сцене. С одной стороны можно было бы просто задавать объектам положение вроде SetVector для каждого объекта. Но во-первых, это будет производиться уже в потоке рисования, а во-вторых, мой плагин выполняет действия во времени.

По идее мне бы создать ограничитель и в нем записывать положения объектов, но… ограничитель не может только отдавать, он должен что-то еще и брать, иначе МоБи посчитает что нет необходимости в его использовании. Другими словами, нужно сделать связь, путь даже для вида. ? вот в SDK встречается весь интересный выход из данной ситуации, цитирую:

// NOTE:
// Usually input animation node should be assigned to constrained object,
// but this plug-in create an animation node which assigned to «Camera Switcher» to solve this constraint
// before other types of constraints such as ‘Path constraint’
// beacuse MotionBuilder dones’t have deformer propagation system.
if ( FBFindModelByName(  «Camera Switcher» ) ){
mDummy_AnimationNode = AnimationNodeInCreate ( 0/*Curve_UserId*/, FBFindModelByName(  «Camera Switcher» ), ANIMATIONNODE_TYPE_TRANSLATION );

// NOTE:

// Usually input animation node should be assigned to constrained object,

// but this plug-in create an animation node which assigned to «Camera Switcher» to solve this constraint

// before other types of constraints such as ‘Path constraint’

// beacuse MotionBuilder dones’t have deformer propagation system.

if ( FBFindModelByName(  «Camera Switcher» ) ){

mDummy_AnimationNode = AnimationNodeInCreate ( 0/*Curve_UserId*/, FBFindModelByName(  «Camera Switcher» ), ANIMATIONNODE_TYPE_TRANSLATION );

Вторая заметка по ограничителям заключается в их видимости.

Вот стандартных код создания ограничителя заданного типа

// Create Relation Constraint

int i, c = gConstraintManager.TypeGetCount();

for( i = 0; i < c; i++ )

{

if( strstr(gConstraintManager.TypeGetName(i), «Parent/Child») )

{

gConstraintPos = gConstraintManager.TypeCreateConstraint(i);

break;

}

}

тонкий момент заключается в том, что данный ограничитель не появится в списках ограничителей сцены. Начиная с последних версий МоБи его туда нужно добавлять в ручную

FBSystem().Scene->Constraints.Add(gConstraintPos);

Эта заметка имеется отношение в большей степени конечно к самодельным ограничителям, потому что общие иногда проскакивают сами на удивление.

Третья заметка касательно обработки действий сцены с ограничителями.

Если вы не добавили ограничитель в список ограничителей сцены, то вы не сможете по нему обработать сообщение на отсоединение kFBSceneChangeDetach. Другими словами, придется в этом случае исхитряться отслеживать когда сцена обновлена или подгружена новая и прочие события касательно жизни ограничителя.

Заметки по ограничителям в ORSDK
Метки:            

2 thoughts on “Заметки по ограничителям в ORSDK

  • Пятница Сентябрь 9, 2011 на 10:37
    Постоянная ссылка

    That’s very interesting info. Thanks.
    Concerning MB 2012, do You know how to get a default Drag and Drop behavior on constraint (I mean dropping a constraint node on an objects constraints an object and adds constraint into object hierarchy). I can’t sort it out.
    Also do you know how to constrain a cameras Field of View, apart from setting it with:

    1
    static_cast<HFBCamera>(model)->FieldOfView = value;

    Thanks,

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *