Andrew,
>>> >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.
I don¹t follow this right now. It seems you are referring to the
overlay/blending of multiple target controllers (i.e. walking + gaze?)
>>
>>> >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.
>>
Yes, we are using the BMLR code from CADIA. They added functionality to the
bonebus protocol (renaming it commapi) to update the position of Pawns from
Panda3D.
>>
>>> >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.
>>
I¹m not sure what you mean by ³distinct of any specific SbmPawn². My naïve
understanding is that multiple characters/controllers should be able to
reference the position of a single specific SbmPawn.
I have not looked into whether McCtRawWriter is being used to update the
position of pawns and consider lag-compensation something to worry about
later.
>>
>>> >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.
>>
Yes, I see where you do this and agree that generalizing such behavior out
of ³Gaze² would be useful for ourselves and others.
It also appears that much of the functionality in MeCtGazeJoint would be of
value to any target/tether controller and therefore should be generalized.
>>
>>> >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).
>>
Not sure what you mean here. In general, the idea of hard-coding gaze,
orientation, and movement targets into the character seems a bit brittle.
And, I don¹t know what you mean by ³dynamically modifying the skeleton².
Obviously, this is what SBM is designed to do, right? If you mean somehow
modifying the organization of the skeleton, then I don¹t follow how this
would be of use.
>>
>>> >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).
>>
Yes, obviously if you are doing lag compensation, you need to do this first.
What are the behavior targets that need to be run? What is their
relationship to SbmCharacters and their controllers?
Sorry, as above, I don¹t follow why we now need multiple pawns in SBM.
Our thinking on ³output² is that characters may ³grasp² objects in the
scene, but we see the simulation of those behaviors happening in the
visualization environment.
For example, we imagine that a character may influence an object in the
presence of physics and other constraints (or even simple re-parenting), but
that the resulting motion of that object (and an associated pawn) is not
under the direct control of the character or SBM. Obviously, as stated
before, the resulting motion of the object/pawn needs to be updated inside
of SBM.
>>
>>> >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.
>>
The code from CADIA does all of this inside Panda3D and it seems like a
prudent way to go.
We like the idea of SBM as merely a character behavior library and not
involved in the control of or rendering of pawns.
>>
>>> >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.
>>
I would agree that the current specification (or lack there of) needs more
information about pawns.
For instance, we would expect that pawns have not only position but
orientation so that pointing or grasping actions can happen relative to the
orientation of the pawn.
We also anticipate the need for some representation of the physical volume
of the pawn (i.e. spherical, cylindrical, cubic, etc.).
We welcome any discussion about how to handle the interplay between SBM
characters and the distinct geometry of pawn objects.
Perhaps a reasonable approach gives the pawn its own joints or location
reference points that the character can target (i.e. target=pawn1:handle1).
>>
>>> >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.
>>
As I¹ve said, I don¹t follow why these steps are necessary. To me it seems
that the most important task is to construct the target controller in a
similar fashion to the gaze controller.
Outside of generalizing aspects of the gaze controller that aid this effort,
I don¹t think we have the manpower to re-architect the code significantly.
Alex
-----------------
Center for Technology and Social Behavior
Northwestern University
>>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Smartbody-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/smartbody-developer
