Andrew- We should meet next week to help clarify these ideas for Alex, since I have some difficulty following this. What is lag-compensation? I hope you don't mean extrapolation (dead-reckoning). I'll look into the various relative geometric relations (offsets) that will be useful requirements early next week. I suspect that the gaze-aversion target offset is best handled by the gaze controller itself, since that would be awkward to specify in a general target controller, but I'm not sure. It's practically trivial in its current state, but maybe you think it would be a useful option for future development.
-Marcus On Thu, 26 Jun 2008, Andrew n marshall wrote: > > 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
