Andrew n marshall
2010-06-01 02:51:33 UTC
How would I extract the sync points that are connected with a
particular request object?
<sbm:event message="vrAgentSpeech partial 1274204462073-41-1 T27 Why
thank you Get packed This town is ghosting and I ain't going with "
stroke="sp1:T27"/>
In this case, I want to extract "stroke" = "sp1:T27" from the
EventRequest object
<head amount="0.2" priority="5" ready="sp1:T4" relax="sp1:T5"
repeats="0.5" type="NOD"/>
where I want to extract "ready" = "sp1:T4" and "relax="sp1:T5" from
the NodRequest object.
The primary object you want to be focusing on is the BehaviorSyncPointsparticular request object?
<sbm:event message="vrAgentSpeech partial 1274204462073-41-1 T27 Why
thank you Get packed This town is ghosting and I ain't going with "
stroke="sp1:T27"/>
In this case, I want to extract "stroke" = "sp1:T27" from the
EventRequest object
<head amount="0.2" priority="5" ready="sp1:T4" relax="sp1:T5"
repeats="0.5" type="NOD"/>
where I want to extract "ready" = "sp1:T4" and "relax="sp1:T5" from
the NodRequest object.
in each BehaviorRequest (bml_sync_point.*). There is one such instance
in each BehaviorRequest. However, what you will find will depend upon
at what phase during processing you make your query.
BehaviorSyncPoint::name_syncs is a linked list of NamedSyncPointPtr
ordered by the performance. That is, "start" should always be first,
"end" should always be last, with "ready", "stroke-start", "stroke",
"stroke-end" and "relax" somewhere in between and in that order.
Additional sync points, such as those for word breaks in speech
behaviors, can also be added to the BehaviorSyncPoints during behavior
parse/construction/initialization.
BehaviorSyncPoint::name_to_pos is a map by the SyncPoint name to the
iterator in the linked list, for random access.
Many STL collection functions are exposed on the BehaviorSyncPoints
class to facilitate its use. They use the BehaviorSyncPoint::iterator,
which should be a reasonable interface over future code refactoring and
long term operations (the underlying std::list::iterator is valid during
most adds and deletes).
The NamedSyncPointPtr is a simple wrapper of a SyncPointPtr, with a
std::wstring (XML) name. The SyncPoint itself has three primary fields:
* SyncPoint::time is a value for when the event will occur. This is
set during scheduling with the appropriate SBM time value (same
timeline as mcu_p->time). Prior to that, the value should be
BML::TIME_UNSET (bml_types.hpp). Thus, by checking
SyncPoint::is_set(), you can determine if a sync point has been
scheduled yet. Be careful using TIME_UNSET directly, because it
is represented as NaN, and TIME_UNSET==TIME_UNSET is false.
* SyncPoint::parent is a reference to another SyncPoint. This gets
set when one SyncPoint is constrained to another SyncPoint, or
null otherwise.
* SyncPoint::offset is the time offset from parent->time.
Granted, the parent/offset pair is a poor representation of a BML
constraint, only supporting fixed duration offsets. This model does not
support partial ordered constraints such as "before" or "after" (nor
does the current scheduling system).
If the parent is set, the time field should be set by an automated call
to BehaviorSyncPoints::applyParentTimes(..). Thus, BehaviorScheduling
objects only need to check SyncTime::is_set() and time during scheduling.
Extracting only the constrained sync points (those represented in the
XML) is largely a matter of filtering for SyncPoints that have a
non-null parent. This should be true even after the behavior is
scheduled and activated.
During behavior realization, the time values are often translated into
other scheduling systems, such as the Blend and TimeShiftWarp curves in
the MeController system, or the sbm commands in sequences. Thus changes
to SyncPoint::time fields after realization will rarely (if ever)
influence character performance.
--
Anm