evoMotion

Pursue Applet -- Rough Draft

noreply@blogger.com (J) — Fri, 27 Aug 2010 14:56:00 +0000

I've got a rough pursue behavior going. No evolution yet, I haven't made time to wrangle the variable flow into something controllable by genes yet, but here is at least a start...

Wander behavior with working timeline and trails

noreply@blogger.com (J) — Mon, 23 Aug 2010 16:06:00 +0000

The wander applet now has a working (scrubbable) time line and two types of trails (all history and partial history). The partial history is slower b/c it draws all previous positions in the partial history at every frame. The full history mode never clears the buffer, so the screen can get messy. Both are probably useful for different types of analysis. Also, the timeline can have start and end frames (no UI for this yet), they are set to 50 and 150 frames. You can also change the agent display type to cone or sphere.

Wander behavior with UI enhancements

noreply@blogger.com (J) — Wed, 18 Aug 2010 18:28:00 +0000

Try it out here.

(Note: the timeline isn't working yet, it's just a UI stub for now)

P.S. What is that weird flashing on the right side? It looks like some sort of refresh problem. This only shows up in the applet -- not when run out of Processing. Any ideas?

Wander behavior is complete

noreply@blogger.com (J) — Wed, 11 Aug 2010 19:08:00 +0000

Test drive it here.

Evolve it here.

Thoughts on interfaces for directing

noreply@blogger.com (J) — Tue, 10 Aug 2010 18:26:00 +0000

Aside from the interactive evolutionary aspects of our system we need to think about interfaces for directing things like target positions, flow fields, and post simulation fixes.

Target positions can be any number of things:

randomly distributed points within a user-defined shape (keyframed interpolated shape controller?)
particular target points in space with a radius of influence (keyframed sphere controller?)
a particular individual in the crowd or a keyframed individual not governed by behavior rules (spline controller?)

Flow fields are difficult to provide an intuitive interface for, especially if they are time varying. Any ideas here?

Post simulation fixes are a must with any usable crowd system. Perhaps this is better done in a typical animation environment (i.e. Maya). Maybe we can just provide space-time data output that can be imported easily into Maya or something else for direct animation fixes.

Perhaps if we were actually creating a crowd system to compete with Massive, a layered approach would be nice. (much like layers in Photoshop) The particle motion would form the bottom layer. Fuzzy-logic and motion clip blending would take place at the middle layer. And post-sim fixes could be at the top layer.

Pixar Crowds Chat #2

noreply@blogger.com (J) — Tue, 10 Aug 2010 18:14:00 +0000

These are my notes from a chat I had with Paul Kanyuk, Arik Ehle, and Dave Ryu from Pixar about practical issues in crowd simulation for animation production...

There are two primary software packages used at Pixar for crowd sim:

Wilma - FSM based environment used for switching between animation cycles (non-locomoting) with .xls output
Massive - fuzzy-logic based environment used for blending between animation cycles (locomoting)

Massive has a few additional features not mentioned in the last chat with JD:

lanes - these are splines with color values that control flow of "traffic"
vision - each agent has some sort of computer vision

Problem: retargeting (animation cycles/deformers/simulation) to different timings, body sizes, etc.

for animation retargeting they usually just end up making cycles at various speeds and then blending between them to avoid problems with IK and rate changes (i.e. the physicality of the animation is ruined)
original anim cycle is king! The animators put a lot of work into getting a cycle to look expressive/convincing - don't ruin it during crowd sim

Directability Problems:

Meet very specific end poses given the start poses
How do we get characters to look alive at all LOD? (can we have authoring access to anim cycles w/in the crowd modeling environment?)
Close-up crowd shots need better choreographic control (especially w.r.t. the camera shot)
Character jitter from indecision
Very particular actions at precise locations (i.e. high-speed precise turns w/out collisions at the edge of a cliff)
Large, swarm-style crowds are easy in Massive. The close-up shots with more constraints are hard.
Getting agents to start transition animations at the right time (based on desired final position + animation)
Dressing eye-positions to the camera

M.O. = Sim with too many characters so we can kill the bad ones off. Also, shots are usually pretty quick so some intersection is okay (perceptually).

Pixar Crowds Chat #1

noreply@blogger.com (J) — Tue, 10 Aug 2010 17:53:00 +0000

These are my notes from a chat I had with JD Northrup from Pixar about usability issues in Massive...

There are a few tools that Massive provides for directing crowd motion:

paint input values for fuzzy logic computations (static over time)
flow fields
sound beacons (attraction to/repulsion from a location in 3 space)

M.O. = get most of the agents working then add in special cases for the individuals who aren't cooperating (or just kill them off)

Massive uses the notion of behavior groups (don't quite remember the specific definition of this use of 'group')

Massive does not allow keyframe/direct authoring of motion for hero characters (i.e. especially important for when they are carrying a sound beacon)

There is no notion of state or stored memory for agents in Massive. The fuzzy logic model is purely functional. An FSM would be nice to have.

JD claimed that Massive is pretty much limited to characters on a ground plane.

Subframe calculations do not exist or cannot be accessed.

From moving shapes to anthropomorphication

noreply@blogger.com (J) — Tue, 10 Aug 2010 15:18:00 +0000

From Matt...

http://psychologie.fernuni-hagen.de/lernportal/Multimediamaterial/Video/Heider.mov

http://orphanfilmsymposium.blogspot.com/2008/05/national-science-foundation-grants.html

http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6W47-41GWN8R-1&_user=3366836&_coverDate=03%2F31%2F2000&_rdoc=1&_fmt=high&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1423302064&_rerunOrigin=google&_acct=C000058403&_version=1&_urlVersion=0&_userid=3366836&md5=b10f32edb9100ec9a1e898b50d552010

http://www.druglibrary.org/special/davies/myth1.htm

Limitations

noreply@blogger.com (J) — Tue, 03 Aug 2010 19:22:00 +0000

There seem to be some features used in a lot of crowd implementations that aren't currently a part of my proposed framework. These include (but are not limited to):

path planning
scripting at the behavior-group level
non-deterministic FSM's (probabilistic)
constrained optimization
social modeling (i.e. emotions and personal preferences)

What kinds of behaviors will we not be able to realize without these features? Should we include any of these?

locomotion

noreply@blogger.com (--r) — Wed, 14 Jul 2010 02:20:00 +0000

for locomotion there seems to be 2 strategies - cell-based or continuous space - similar to how

fluid dynamics is modeled: Euler or Langrangian. in fluid dynamics there is also a hybrid approach that might also be applicable to crowd simulation.

so by locomotion, you are planning on dealing with collision avoidance, collision detection, and collision reaction. there are also issues with 2-way traffic in corridors, passing someone going the same way, how to keep groups together under limits to navigation (e.g. in a corridor).

is this the level that you plan to identify issues?

Comments Enabled!

noreply@blogger.com (J) — Tue, 13 Jul 2010 19:31:00 +0000

I've re-enabled comments and found the magic box where we will be notified by e-mail when comments are posted, so hopefully that works now.

Comments?

noreply@blogger.com (matt) — Tue, 13 Jul 2010 15:39:00 +0000

So I want to comment on things you and Rick have written, but I'm not seeing how/where to do that in the usual blog-commenting kind of way... do you have comments disabled for this blog? Is that maybe not a feature of the template chosen for posts? I've created blogger blogs in the past and commenting on posts was always a feature that I wouldn't have known how to turn off... hmm

I was wanting to comment a few posts below that there seemed to be an analog to the "tags" vs "categories" debate for grouping media items (images, posts, links, etc). Tags being like keywords, supporting emergence and dynamic groupings - instead of pre-specifying a set of categories that things are sorted into. The distinction can get fuzzy and is probably more of a continuum.

crowd taxonomy

noreply@blogger.com (--r) — Tue, 13 Jul 2010 15:29:00 +0000

random thoughts - just wondering if all crowds are the same and can be modeled with the same formulation.

is there a difference between a crowd that is, say, in a market square versus a crowd that is an invading army versus a crowd that is an audience (like in a stadium or movie theatre).

what are common among *all* crowds (multiple agents - is that it?)?

what are features, if any, that differentiate crowds in meaningful (for animation) ways?

transient-ness? uniformity in mission? density?

what about viewing distance? are individual actions important? are the actions only statistically important? do the actions even need to be distinguishable?

what's the difference between a crowd and a large number of 'intelligent' agents? anything?

is your objective to be able to model all crowds in all situations - or are you identifying a subset of crowd type to focus on?

Re: Why groups?

noreply@blogger.com (J) — Tue, 13 Jul 2010 01:41:00 +0000

Rick -

Good questions. And yes, I think fuzzy logic could work well for defining proximity groups by any useful attribute. I'm not real clear on the details of using fuzzy logic (other than it's fuzziness) so I can't say whether or not this would add unnecessary complication, but this would be a good thing to look into. Proximity groups would be useful for group-interaction behaviors such as:

The other types of groups are only necessary insofar as they help us have meaningful conversations about input and output. The behavior groups are important from the crowd designer's point of view, because that is how s/he sets up the different behaviors of subsets of the crowd. The action groups are merely a way to recognize what's going on in the output animation and to talk about who's doing what actions when.

- J

noreply@blogger.com (--r) — Mon, 12 Jul 2010 14:17:00 +0000

(I *think* I'm adding a post to Jae's blog - we'll see if this works)

I think we can borrow from fuzzy logic for group membership. groups are basically dynamic, a member can be in more than one group at a time (by 'in', I mean in a fuzzy way - some degree of being 'in'). a crowd member can be more or less in a group. groups can be defined by any attribute that is useful. or do fuzzy groups complicate the issue too much?

so why are groups even necessary - what does it buy us? a way to treat group members collectively? to identify other members for orchestrating interaction or relationships (in an animation sense)? what's the point of groups? does being in a group according to one criteria have an effect on how other values evolve? just asking ...

Thesis and Crowd Paper Abstracts

noreply@blogger.com (J) — Mon, 12 Jul 2010 00:06:00 +0000

I've updated the "Proposals" page with two rough abstracts (one extremely rough for the thesis, and one for the crowds paper). I've also started a high-level outline for the crowds paper.

Suggestions, comments, re-directions are welcome!

- J

Crowd Choreography Tool Framework (Meeting with Matt on Thursday July 8th)

noreply@blogger.com (J) — Fri, 09 Jul 2010 17:01:00 +0000

Matt and I met and hashed out some details and terminology of the initial framework I'm proposing. Most of the details are above, but here are a few more definitions of things that might not be clear:

The steering primitives are from Reynolds's list of steering behaviors. There are about 14 items in his list. We may need to add to these or remove a few, but this is a good starting place.
Each state in a Finite State Machine (FSM) diagram corresponds to one row of the genotype (pictured above). The row contains a weighting of steering primitives and also any necessary variables for the steering behaviors (threshold radii, following distances, etc...)
A crowd has an FSM for every behavior group, and these FSM's are defined by the designer using the system. The designer assigns initial steering primitives to each state as well.

Re: the nature of group membership

noreply@blogger.com (J) — Wed, 07 Jul 2010 23:44:00 +0000

Yes! Good points.

We need to define some sort of working terminology for groups, sub-groups, etc. Set theory would be a convenient way to describe the group membership of individuals, especially when it comes time to write down our ideas on paper with precise mathematical notation.

Here's my current train of thought on groups for evoDesign crowd purposes:

Crowd = the entire set of individuals contained in one phenotype

Group (defn. A) = a subset of a crowd (could contain the entire crowd) where the behaviors of all the individuals at a given moment in time are defined by the same set of genes -- i.e. these five guys have a flee value of 0.3, a hide value of 0.5, and a wander value of 0.2 so they are behaving like prey.

Group (defn. B) = the same as defn. A, but instead of sharing the same behavior state an any given moment, the individuals in this type group would have the exact same state diagram and behavior gene makeup (note: members of this type of group do not necessarily form members of a group by defn. A)

Group (defn. C) = a subset of a crowd defined by locality -- i.e. those 3 guys over there in the corner.

I think we need all 3 notions of group defined above, but obviously we shouldn't use the word "group" for all three meanings. Any ideas on what we could call these three different meanings of the word group? Are there other possible definitions y'all can think of?

Group (defn. B) is definitely static. Groups (defn. A+C) have dynamic membership, which is interesting, especially when we start talking about behaviors defined by locality or interaction with other groups. One thing to think about with regard to the dynamism of a particular group is explicitness vs. implicitness. Is the dynamic nature of the group membership defined by a variable or does it emerge from the interaction of a lot of behavior variables among a couple of groups? My guess is probably the latter and this is one of the things that makes crowd sim really interesting to watch! Thoughts?

- J

The nature of group membership

noreply@blogger.com (J) — Wed, 07 Jul 2010 20:55:00 +0000

An e-mail from Matt...

Jae: skimming through your initial content on your blog pages...

Sub-group membership seems a key concept/challenge for me...

I wonder about whether "subgroupings" as categories are sometimes fixed and sometimes dynamic, depending on the qualities of a given group of people. There should be a name for this attribute of a crowd: how dynamic its subgroups are.

-"Subgroups" might be an emergent quality, or not... dependent on group.

Words I don't fully understand that need a working definition: crowd, group, subgroup.
One way to look at this would just be as sets. Sets have sub-sets. subsets may or may not overlap. set theory...

BUT, I also wonder about whether set membership is a Universal Truth, or is in the eye of the beholder, context dependent, etc. e.g. Each person in the room avoids the subset of ugly people and moves toward the center of the subset of attractive people, where these subsets are relative to each individual and may shift depending on context.

(other subjective qualities: dangerous, fast, large, etc...)

-matt

The evo-motion blog is ready to go!

noreply@blogger.com (J) — Mon, 05 Jul 2010 02:11:00 +0000

I've put together a rough framework and fleshed out most of the preliminary info that y'all requested.

Main - will contain posts about what's new and also discussions about the topic du jour
Background - useful links and literature search progress
Proposal - proposal work in progress
Implementation - details on the practical side of things as well as demos
Conferences - a running list of possible places to publish
Previous work - a summary of the motion related work we've done so far

This is a collaborative space so please leave comments and make posts as you see fit!

Bienvenidos!

noreply@blogger.com (J) — Thu, 01 Jul 2010 20:21:00 +0000

This blog should serve as a centralized place where I'll keep track of my dissertation research progress. Paper references, demos, writing-in-progress, important links, and other useful tidbits will all either be located here or linked from here.