[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[x3d-public] Re: [www-vrml] Walking Kamala

Len, hope this finds you. I'm getting bounces from your email service.

Allow me to describe how a game, such as Unreal, structures such things, and some of how things Tony and I are working on deal. Then I'll comment on your mail below.

In a game, you may have several types of creatures ('pawns' in Unreal parlance). One is a 'player' which is analogous to our 'avatar' idea. It is 'you' from your camera's perspective. The other is a 'bot', which is an autonomous (AI) pawn critter. These have scripts which control what they do.

Each pawn may have 'anims' associated with them. These are actual mesh animations, and/or movietextures, etc., which can be 'triggered' (timesensor for animation started).

Pawn scripts know about (among many other global things) 'events', 'instigators', and their 'anims'. An 'instigator' tells the pawn who or what triggered the event they are receiving. The event might be something like 'encroached upon', 'fired upon', 'hit', 'killed', 'offered', etc. The script then plays the anim which corresponds to what's going on. If nothing much is happening, an 'idle' looping animation plays (figeting, butt-scratching, blinking, breathing, you know).

There may be a great long list of possible actions that any pawn may support. These might be: walk (or walk1, walk2, walk3, etc), run(s), die(s), jump(s), side-step(s), waves, taunts, fire(s), slash(es), etc etc etc. It's up to the author to provide these. Since the list is pre-defined and comprehensive, any pawn just 'drops in' to a scene, and the infrastructure knows what to fire (start timer for that anim). If an animation is unsupported by a pawn, fall-backs can be tried (walk if no jump, idle if no walk, etc).

Something games support that X3D does not (currently) is 'object proximity' (we have 'user' or 'avatar' proximity only). As you might imagine, object proximity will fire events as the pawn approaches objects of interest, or other objects (including pawns like other bots and avatars) approach them. Programming an interactive scene without these types of proximity sensors is very very tricky and messy, not impossible, but you have to 'listen' to a LOT of things and have SAI run the event model instead of simply using ROUTES. Performance is a real issue.

So I'll try not to breach any contracts or NDA's and speak generally about some things we do with X3D.

At MM, we call them 'smart objects' and they are (currently) ExternProtos, with 'standard' interfaces, and they contain handy bits in them like touch sensors and 'brain scripts' and so forth, which are exposed via the proto interface. We can track their position and orientation (if a creature, where it's 'looking'), where it prefers keeping it's 'feet', and all sorts of things like that. A list of possible actions (anims) could also be fired thusly. (Don't forget to turn off the previous anim first!). These things should be as autonomous as possible (play their own sounds, for example), but might be so kind as to let us know that they did something like that.
If such protos could be 'standardized' and supported by Flux Studio, Rawkee, Max, UnrealToX3D, etc, what a wonderful world it would be, or that we could create.

I hope that made sense, if it helped at all.
See comments below:

Len Bullard wrote: 
Dave A. asks:

Define 'inline opaqueness'? 

Ok.

Inlines:  getting events to an inlined object/world in the containing world
and from one.  VRML97 doesn't allow that (because naming conflicts as I
recall make composition harder to manage, cascades, etc.).

I don't know anything about all that. I was under the impression that Inlines were opaque to the world no matter what. They know about what they contain, but not what contains them, and can't message in or out. For that, you have to go to Import or ExternProto. I've been using ExternProtos myself. Perhaps Tony could correct me on this, and how Import/Export might affect Inlines.

Admittedly, I am not expert but this is what I am doing.  It might help if I
elaborate some composition theory with some running code primitive as it is.

Here are some definitions and some code samples.  I'm open to suggestions
for improving the code, but the definitions are there to provide a
higher-level description of how a non-tech (say English/History/Lit major)
or storyteller might describe this, and how tools might be structured to
enable higher level composition toolkits.

See! That's just what I've been telling you kids! THESE types of authors are the future of X3D, if it's ever to really get out of the universities and onesy-twosy commercial ventures. Until these magic tools exists, it's hard, harder than most people will want to deal with. We get some real experts in the story-telling domain making content, rather than geeks like many of us, it will ROCK.

Somewhere there could be a whole chapter on the topic of gesture chaining in
scripts to create

'acts: composite gestures sequenced in a script'. 

A reactive character (as I define it, an autonomous avatar as opposed to one
controlled by a user), has a repertoire of acts.  In some cases, an act only
In Unreal-speak, a 'bot'. Although your avatar may have repertoire's also, like 'recoil' if hit, 'auto-taunt', and 'idle' when just standing. Eye-candy for others in multi-user worlds to see.
occurs once, but it might be repeated. The two requirements are that there
be event interfaces that can receive a message (an SFString from a script)
or a standard event such as a proximity SFTime, an isActive SFBool,
whatever, and a script function(s) that sequences the act.
I've personally found Bools to be easiest to work with. Script/proto accordingly I do.

BTW: the 'intensions' of a reactive character which compose a 'personality'
can be named as a set of tuples of (source, message, act). The aggregate
intensions of all active characters in an affective proximity compose the
'situation' which play out in some time-proscribed scene/scenario. We don't
need to get into that now, but for the RDFgeeks among us, it's something to
think about.
Right, like event, instigator, anim as described above, I'm with you..

Doing the basics: 

A avatar is initially situated in a world:

      DEF Kamala Transform {
	
         translation 277.5 7.8 -74 rotation 0 1 0 1.57 scale 3 3 3 children
[
	    DEF WalkHer TouchSensor {}
            Inline {
               url "kamala.wrl"
            }
         ]
      }

Event sensors (eg, proximity, touch) embedded in an avatar (kamala4.wrl)
initiate the gestures typically by turning time sensors for those gestures
on or off.  Typically these are routed through scripts to chain gestures to
create an 'act'.   A user with the main world open can initiate those
sensors, but the sensor is located in the kamala.wrl.  That is a limit
unless one routes SFStrings as messageTypes (an obvious extensibility
technique because it is relatively straightforward to build a dispatching
script inside the avatar).
Strings make lovely messaging, I agree 

    DEF AvatarProx ProximitySensor { size 3 1 3 }

In the basic scenario, we have the character, Kamala, currently located on
the bridge of the scene, ROL.  For this scene, we only have her and the
user.  The user approaches her on the bridge.  The Prox fires and sends an
enterTime (SFTime) event to a script.  For now, we aren't collecting any
history so we only have the one act.  She will wave off the user, then turn
and walk to the Temple of Saraswati and 'wait' there.

I assume in this mail that all of the readers understand the basic VRML
engines.  Avatar Studio creates a single mesh character that has a defined
set of gestures (12 from 0 to 11 in the product, but you can cut and paste
more).  Without getting into the details, each gesture can be said to be
represented by the time sensor that starts and stops it: say ts1, ts2, etc.
One way of doing it. The game stuff I've seen, they don't even have bools or times, they are more likened to an 'impulse' which is to say a 'trigger' which says 'do this now' or 'this happened now', rather than 'at this time' (SFTime) or now/not-now (SFBool). X3D has a little of that in Bool events that happen even if state doesn't change. eg. Set an SFBool to true as an output-only and it should trigger whatever it's routed to. 


A script for an 'act' includes these via an array of USE statements.
Depending on how one structures the code, one might include all available
acts as functions, and all gestures in a single MFNode array, then call the
acts via different eventIns.   Because AFAICT, an avatar of this kind can
only do one gesture at a time, and because the goal is to compose acts of
atomic gestures, scripts are needed to chain these into a linear sequence.
(Similar to monophonic sequencing for the soundGeeks among us).  A Time
event is required to start an act so a timer is provided:

DEF actStart TimeSensor {cycleInterval 1 startTime -1}

The field values are obvious.  This is a monotonic event started only if it
receives an SFTime, in this case, the entertime of Kamala's prox, a device
to simulate for the avatar, personal space.  (SociologistGeeks among us know
this varies by culture.)

The route, ROUTE AvatarProx.enterTime TO doAct.actWalkFromBridge

initiates the act.  For now, she only can do one, but extensions here are
obvious.

DEF doAct Script { eventIn SFTime actWalkFromBridge

# Get all gestures for creating acts
field MFNode tsGesture[USE TS0,USE TS1,USE TS2,USE TS3,USE TS4,
USE TS5,USE TS6,USE TS7,USE TS8,USE TS9,USE TS10,USE TS11, USE TS12, USE TS13]

  # A view is bound here just for building purposes (to find her if she
  # decides to go to badoondoon).
  field SFNode kamView USE KamalaView

directOutput TRUE

url "javascript:

// entertime function for one act. function actWalkFromBridge (value) { var inc = tsGesture[5].cycleInterval + 0.5;
// wave off user.
tsGesture[5].startTime = value;
if (tsGesture[5].enabled == TRUE){
# Turn away tsGesture[12].startTime = value + inc; inc = tsGesture[12].cycleInterval + 3.5;
# start walk cycling
tsGesture[11].loop = TRUE;
tsGesture[11].startTime = value + inc;
kamView.set_bind = TRUE;
# translate to Temple
tsGesture[13].startTime = value + 5;
# stop walk cycling
//THIS DOESN'T WORK. //if (Browser.getTime() > (value + 60)){tsGesture[11].loop = FALSE;}
}

}

"
}

This approach can be improved with PROTOs, I'm sure but I'm not there yet.
Happy for any help because this lets us create 'personalities' in a
consistent way that can be taught to non-VRML/X3D geeks (such as trainers,
sociologists, authors of entertainment and so on).

Right. I'm gonna assume ExternProtos or Imports (rather than Inlines as I understand them). So one way to do this would be to pass in a string describing the action to play, have the avatar's script determine if it's supported, and if so, play it till it's run through (timesensor fires completion) or another event interrupts it, or until the instigating event is complete ('stops firing', or whatever, then go back to 'idle'. Another is to have an interface (say SFBool) for any supported actions and just have the caller set that event true to play it. Probably many other ways to go here.
One could even envision a programmable bot: it supports actions (as above), but you could also dynamically create ROUTEs (or script associations) that link types of events or instigators to those actions.
Eg one version of the bot would recoil when hit, another instance of that same bot could be set to strike back.

And hey! Don't forget sounds to go with! Footsteps, grunts, scratchy noises, clanking, whatever fits the character and motion. So much more fun with that.

One more authoring note: as implied above, have more than one of any give type of action, and randomly change them up. So much more interesting that way. Esp. with 'idle' anims.

Cheers

Dave A 

len


-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html