Title: Procedural Controllers

Alex Hill wrote:
I see that a target controller is in the middle range plans for SmartBody.
We would like to make a first pass at this.
Can I get any general advice about any gotchas I would likely encounter?
I’m thinking with regards to controller scheduling/execution.

Great.  Our goal for the target controller is to drive the location of "target" joints, replacing the use of the MeCtRawWriter to assign the position and rotation, but in a more dynamic manner.  Then other controllers, like gaze, can use the position and rotation of these joint to drive their behavior-specific motion.

One of the unique things about the target controller is that is may take in data from outside the SBM process.  We'd like to handle this via the WSP (World State Protocol).  We have some early implementations of this, but we haven't scrutinized the code.

Its possible we want to break up the target tracking into multiple controllers.  First, external data should be assigned to an internal SbmPawn representation of the remote object.  Multiple behaviors (or even multiple characters) may reference this remote object representation, and so should be distinct of any specific SbmPawn.
Additionally, data may not be every frame, which might justify the use of a lag-compensation controller for position updates.  Short term, we can continue to use the MeCtRawWriter.

Secondly, a behavior specific target relation (e.g., relative direction and/or proximity) might be necessary. 
We do some of this inside the MeCtGaze controller, but the goal here is to generalize and expose it for other behaviors.

Being behavior specific, one approach is to include the target joint as part of the SbmCharacter (as new "gaze_target", "orientation_target", "movement_target").  However, our support for dynamically modifying the skeleton is incomplete (proper transition between behaviors like gazing would require one target joint per behavior controllers).

The quicker alternative is to use a second, temporary SbmPawn with a relative position update controller (the "real" target controller).  If we do this, we need to start categorizing our pawns to ensure proper dataflow within a frame.  First, the remote object pawns would run their controllers, with their lag compensation.  Second, the behavior targets would run. Then the actual SbmCharacters.  And finally any "output" controllers (possibly using the relative location controller to update the position of any remotely affected objects, like somethign grasped).


Being a first time SmartBody developer, here's a good plan of attack:
1.) Add a graphical representation of the pawn to the display.  This will probably involve a new subcommand inside mcu_pawn_func(..) and registering some geometry with the pawn's SkScene.  I don't know if this needs to occur at pawn creation time (prior to adding the mcu's root_group) or if it can be added later.
2.) Add a simple mathematical behavior to SbmPawns, like moving in a line or a circle.  This is a pretty basic extension of setting the pawn's position, but instead of using a MeCtRawWriter to assign values to the world_offset position, it would assign the calculated values.  I suggest copying MeCtRawWriter as a very basic starter controller.  (I'll work with you in more detail later.)  Not only is this a simple place to start, but such pawn behaviors can be very useful when testing target-tracking controllers.
3.) Hopefully, by this time, I'll find a moment to categorizing the pawns into some evaluation order.  If not, this is the next step.
4.) Simultaneous to a lot of this work, we can be fleshing out the requirements of the target controller.  We should look at the use of target in the various working groups of the current BML spec and propose a new <target> element that can be shared by all of them.  This will also give us design requirements for what our target controller should be able to do.
5.) Finally, with some basic controller experience under your belt, and a controller evaluation ordering fixed, we can start creating the relative target controller.  You should be able to get this working in the same way you got the circle controller (or similar) working.  Marcus and I will need to help integrate it into the existing behaviors, eventually replace the current gaze tracking code.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Smartbody-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/smartbody-developer

Reply via email to