[WF-General] Entity movement constraints, animation and the mode property
erik.hjortsberg at gmail.com
Mon May 11 11:36:29 PDT 2009
Hi, this is really good to go through.
As you say, we really should separate the information on how the entity
moves from how it should be positioned.
Basically, the client can infer most thing about how to animate the
entity from the existing entity.
Whether it's walking, running, going backways, sidestepping, sneaking
etc. can be inferred from the velocity in relation to the orientation of
the entity. Though, how to distinguish between walking slowly and
sneaking? Jumping? It might be good to retain an attribute for those
entities that are moving and are animated (i.e. creatures) which
describes how they move.
The placement is another issue.
As I see it there are these placement types:
* gravity affected (i.e. snapped to the ground or its current container)
* fixed (here I count both those that are fixed in the air and in the water)
* floating (on top of the container, which usually should be a body of
* attached (anything wielded, a character on a horse etc.)
* falling (not entirely sure that's this is needed, but I don't think we
can represent things that are falling otherwise)
The "fixed" is easy; just use the position.
However, the other ones I'm thinking that we should use the vertical
position as an offset. So that if something is "gravity affected" or
"floating" the vertical position should define an offset. This way we
can express when things are submerged (like a boat, or a carrot). The
way we currently do that is that we place the origo a little further up
the mesh. This make is possible for us to show carrots as submerged into
the ground, but makes it impossible to easily show them when out of the
ground. It would be much more nicer if we could have the mesh instead be
positioned normally (i.e. the origo at the bottom of the mesh) and then
let the server decide whether it's submerged or not. So as an example,
if we would like to represent a carrot which is in the ground, and the
entity has a height of 0.2, the server should use "gravity affected"
positioning and offset the height of the entity by say -0.1. Note that
for entities which are fixed to the terrain, such as houses, the client
representation will need to have a foundation part which extends below
the origo. This is to avoid gaps when the terrain underneath is uneven.
I'm thinking that it would be good to also include this on the server,
so that the bounding box for these entities extend a bit below the
origo. However, in the case with the stakes it should just be an offset
in the stake's vertical position (since a stake, in difference to a
house, can be represented lying on the ground, when it's not embedded
For "attached" I'm thinking that the whole position should be an offset
from where it's normally attached. The issue with this is that the
position of the entity is then very much dependent on how the client
represents it. And this might perhaps not be much of an issue, since I'm
thinking of stuff like wielded entities or ridden mounts here, where the
client pretty much _has_ to determine where the entity is placed in
order to make it look good. However, with your case of a tree house
(I've previously also thought about attaching fruits to trees, for
example apples to an apple tree) there will be some discrepancies
between the model and the server representation (unless there will
always be a 1-to-1 match between the server side representation and the
client model, which I think is really hard to achieve). However, it's
also hard not to do it that way: it will look strange otherwise. I think
in the end it's best to do it like that (i.e. letting the client control
where to attach it) and then put effort into making sure that the server
and the client have approx. similar representations. As we in the future
add a better physics support on the client I think it's a requirement.
I'd like to return to the "gravity affected" one. This is the default
placement mode. What Ember does currently is that each entity which is
placed using this mode queries it's parents in order about how it should
be adjusted. In most cases they'll end up at the world entity which will
do a height query against the mercator height map and tell the entity to
adjust itself so that it's snapped to the ground. In some cases however
another parent entity will respond, for example with the entities placed
on the stalls where the stall will return an adjustment so that the
entities are shown as lying on the table. This is however currently done
very crude (there's a fixed height offset set on the stall Model). It
should perhaps instead be done by doing ray checks against the geometry
to make sure that the actual mesh geometry is used. As we add physics
support to cyphesis this will also be changed.
And finally "falling" or "projectile". I'm not entirely sure how to
handle these. In some sense they are "gravity affected" but just haven't
reached the ground yet. It might very well be that they will need a
separate position mode.
However, to start I think it's just a good idea to separate out the mode
of positioning from the mode of movement.
And then to think a little more on whether the "gravity affected" and
"floating" positioning modes should use the vertical position as a pure
Alistair Riddoch wrote:
> How much use does Ember currently make of the various different uses
> of the "mode" property?
> This property currently feels very overloaded and ambiguous as its use
> has changed an mutated over time. In the old 2d client days it was
> used to directly access the various named animation sequences
> character sprites used. As server simulation and terrain moved into
> the third dimension we started using it to indicate if an entity sits
> on the surface of the terrain or not, then gradually extended it to
> cover other ways in which position might be constrained, or otherwise
> modified automatically by either client or server.
> If all current uses are to be covered I think we should break it down
> into at least two properties, and while we are doing an overhaul of
> this we should probably revisit the requirements.
> 1) What do clients really need in order to be able to get animations
> right? I am guessing a property giving the current motion type?
> 2) Independent of the animation of the model, what is the best way to
> express the current position constraints of an entity? Tracking the
> surface is going to be one of the most common cases, but other
> important ones include:
> a) flying linearly through the air (birds, flying carpets etc,
> including stationary floating objects)
> b) projectile flight through the air (missiles, falling characters)
> c) moving freely through water (fish, diving things)
> d) tracking the surface of the water (surface swimmer characters, ducks)
> e) embedded in the terrain. (buried treasure, palisade stakes)
> f) pinned to another entity (Tree houses)
More information about the General