[Closed] My First Controller Plug-in… Questions:

(a) Is it possible to customize the controller gizmo apparatus?

yes you would override theControl::Display function and Control::HitTest function

the trouble is you’re flying a bit blind, there’s no sample controller that show’s how it should be done (or if there is I’ve not found it) and not a lot in the reference to help either. One of the many frustrating things of dealing with the sdk.

Continuing my search for bread crumbs… I found some classes in “objmode.h” pertaining to the control apparatus:

class MoveCtrlApparatus
class RotateCtrlApparatus
class ScaleCtrlApparatus
class SelectCtrlApparatus
class TransformCtrlApparatus

All of these take a pointer to a Control as a formal parameter… so it seems these classes are what are responsible for updating user interactions (Move, Rotate, Scale, Select) with a controller’s transform gizmo???

I don’t like to experiment “in-the-blind” but I guess I will just have to try and implement a “LookAt vector” (similar to the X,Y, Z arrows) to append to the move gizmo for the legacy LookAt Matrix3 controller… then figure out how to HitTest it. :shrug:

Edit: I suppose a simpler solution would be to just use the designated “LookAt” axis (either X, Y, or Z axis) and then just lock the other two axes to prohibit their movement… but this would depend on the chosen coordinate reference system.

Ok… most of the discussion above is now overcome by events. In writing my first controller plugin (using the other controller plugin .cpp files as reference) I finally got it to compile (after taking care of all of the abstract class methods) …but I still need to write the dialog process and some of the class methods.

What I’m trying to wrap my ahead around now is how Parameter Blocks are handled for a Controller’s parameters.

In looking at the link_cnstrnt.cpp file (lines 61, 87 and 101):

line 61: Control tmControl; // ref 0
line 87: IParamBlock2 pblock;
line 101: Animatable* SubAnim(int i) {return tmControl;}

…and comparing that to the lookat_cnstrnt.cpp file (lines 73, and 148):

line 73: IParamBlock2* pblock;
line 148: Animatable* SubAnim(int i) {return pblock;}

Question, (forgive me if it’s an ignorant question) why wouldn’t the link constraint use the pblock in line 101 and simply have the tmControl inside the parameter block?

Also, any ideas why they commented out the LinkConstValidatorClass ?

Thanks. :hmm:

Ok… I think the reason that the Link Constraint has a Control* pointer is because it retains the underlying transform controller when it (the Link Constraint) is assigned to a node– so I don’t need that. :curious:

Anyone that has a solid grasp of controller plugins and their parameter blocks– PLEASE send me a PM to clear up a couple of questions I have. :banghead:

So my parameter block node tab list is not being initialized to size zero but rather some really large int value…

I could really use some expert help! Please somebody send me a PM that’s willing to help me.

So somebody threw me a bone… my problem was that I had my pblock ref the same as the controller ref (i.e., 0). Once I changed the pblock to 1 (or other integer) it successfully loaded my controller onto the node and displayed my Controller’s UI. I still have much to do– the dialog process is not finished and lots of methods still to write.

This controller project is my take on an “Animatable Pivot” Matrix3 Transform Controller.

Ok… so I have my [Animatable Pivot] matrix3 transform controller loading now when it is assigned to a node from the “Assign Controller” rollout on the Motion Panel. The controller’s UI is mostly functional– at least when it comes to adding/deleting target nodes to the listbox (as done in the LookAt, Position, and Orientation Constraints).

I’ve also added the “PRS Key Info” Dialog and “Inheritance Link Info” Dialog (taken from the PRS controller’s code)… I’ve gotten these additional dialogs showing up as additional rollouts (on their respective panels) thanks to @Klvnk.

What I don’t like, and would like to ask you guys how to change, is how when I add a node to the listbox it appends its respective weight controller as a sub-anim directly to the main transform controller, like so (assuming 3 nodes have been added to the target listbox):

(-) Transform: myController
└– myController Weight 0
└– myController Weight 1
└– myController Weight 2
└(+) Position: Position XYZ
└(+) Rotation: Euler XYZ
└– Scale: Bezier Scale

All of the constraint controllers behave this way (that is to say– adding the individual weight controllers directly underneath the owning controller)… and since my transform controller is based mostly on the LookAt and Link Constraint controllers, it behaves this same way.

…whereas, I would rather all these weight controllers, associated with their respective nodes in the listbox, to appear under a “Weights:” hierarchy like this:

(-) Transform: myController
├(-) Weights:
│ └– myController Weight 0
│ └– myController Weight 1
│ └– myController Weight 2
└(+) Position: Position XYZ
└(+) Rotation: Euler XYZ
└– Scale: Bezier Scale

Does that make sense? So if you look at either LookAt, Position, Orientation constraint code then the solution would equally apply to my own controller.

So how would I re-structure the Parameter Block to rollup the weight controllers like that, rather than have them all individually listed directly under the main transform controller?