[WF-General] Entity movement constraints, animation and the mode property

Erik Hjortsberg erik.hjortsberg at gmail.com
Tue May 12 15:43:23 PDT 2009


I have to agree with you on the position semantics: it's better if the 
position of an entity _always_ is what the server thinks it is, and 
further hints on how to adjust it on the client are sent separately.
So, for our carrot example, if it is indeed half embedded into the 
ground, the position on the server and the position sent to the client 
would indeed be a position where the bounding box is half embedded into 
the ground. But to make sure that the client really understands this, 
and knows how to visualize this given different LOD and ground rendering 
techniques, a hint about the carrot really being offset a certain amount 
into the ground is also sent.
Likewise, for things that are attached, the server would send the 
position of the entity as it sees it internally, but also send 
information about the attachment. It's then up to the client to 
completely ignore the position if it so wants and only use the model 
specific attachment information. For those instances where the client 
doesn't have any attachment data it can fall back on the absolute 
position sent by the server instead.

I also like the idea of the "pose" property, you can go ahead with 
removing the "mode" and I'll update Ember to handle it.

Regarding containment hierarchy, I don't see any difference in having 
entities only as their immediate parent, since that parent, if not the 
world, probably will need to ask its parent. An example is the sty. The 
pigs in the sty has the sty as their parent, and the sty has the world 
as its parent. The pigs however needs to be aligned with the ground, 
since the sty only is an enclosure (I know it's a bad example since we 
want to model the sty using the separate fence sections instead, but 
there are sure to be other similar situations). So what happens when a 
pig is placed is that it asks its parent, the sty, whether is should be 
adjusted. The sty however has no such information, and passes on the 
request to its parent, the world, which do indeed have such information.
Another situation is the open crate with apples, as shown here: 
http://picasaweb.google.com/erik.hjortsberg/SomeOfUsCannotBeWrong#5332682391195548866 
. The apples' parent is the open crate, which in turn has the world as 
parent. Whenever an apple is placed it asks its parent, the open crate, 
if it should be adjusted. In this case the crate do indeed have such 
information (adjust it so that it rests on the crate floor) and the 
world is never asked.
I think this system works out very well.

For flying or swimming objects I don't see the need for any "height" 
property. The position as it is ought to be enough to determine where to 
put it.
I do like the idea of implementing falling objects. The world entity 
should have a gravity property so we can model different worlds. And 
then it would just be an issue of setting a velocity and the mode to 
"falling". Things like arrows or spears in flight could easily then be 
modeled on the server (I didn't quite follow whether you completely 
wanted to remove the "mode" property or you only wanted to remove the 
places where it's tangled with the pose of the moving entity).

I don't know if I like those mode examples you gave. I do however like 
that "mode" is a complex type. The issue with that is however that we 
need to implement a new set operator in atlas. The current set operator 
will by eris always be interpreted as "add and replace", i.e. it's not 
possible to remove something from a map (unless you first send an op 
where you set the mode to another entity type, say a string, and then an 
op where you set it to a map, but that's a kludge).
My thoughts is that for things that are snapped to the ground they will 
use the mode "grounded", and have an optional "offset". In most cases 
only the vertical component of the offset will be used (or should the 
"offset" instead be just the vertical component and then instead be 
called "depth" as you suggested? Perhaps that's best...).
For things that are flying or swimming I think "fixed" will be enough. 
Or do you think of any situation where we would need to differentiate 
between these two?
For things that are attached, the mode should also be "fixed" (since 
it's fixed in relation to the parent's space) but with an optional 
"fixture" property which is descriptive (so for a hat which the user is 
wearing, the hat should be contained by the user entity, it should have 
mode "fixed" and a position of where the server thinks the head of the 
user should be, and then have the property "fixture" (which is a 
property in the "mode" property) set to "scalp". The client would then 
look in the user model to see if it can find information on any "scalp" 
fixture, and if so attach the hat to there.)
For floating things I think the mode should be "floating", with a 
similar offset as found in "grounded" (to model half submerged items 
etc.). The semantics of "floating" is that it's always  floating on top 
of it's container (so we can have things floating in the ocean entity as 
well as in a pond or bowl entity (in the latter case there would 
actually be a small "water" entity contained in the bowl). I'm not sure 
how well this meshes with the containment code in cyphesis, since we're 
then saying that the floating entity both should be contained by the 
water entity, but at the same time be on top of it. But I think it's the 
only way to do it semantically, since otherwise you would have to have 
the floating entity outside of the water entity, but linked to it 
anyway, which might lead to all kinds of strange situations placement wise.
And then we have falling objects, which has the mode "falling". Given 
the gravity of the world, and the velocity of the entity when it was 
discovered by the client it should be enough to accurately model it on 
the client. As soon as the entity hits something (ground mostly) the 
server will send an updated mode ("grounded" in most cases). However, 
this means that the server needs to calculate the correct velocity of 
the entity for when it's sent to the client (for example if its 
discovered by the client mid flight). I don't remember, but doesn't all 
sights from the server have a time stamp? This should then be used by 
the client to determine where the entity should be when the sight op 
actually reaches the client.

Anyway, go ahead and start on the changes in cyphesis. I'll see the 
changes in git and change in Ember accordingly.

/Erik

Alistair Riddoch wrote:
> 2009/5/11 Erik Hjortsberg <erik.hjortsberg at gmail.com>:
>   
>> 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.
>>     
>
> I think most of these cases can be covered independently of the core
> movement code, and are related mostly to scripted gameplay elements.
> How about a property called something like "pose" which is independent
> of how the character is currently moving?
>
> My current plan is to strip out the "mode" code from the core
> entirely, as I think this will not remove any functionality.
>
>   
>> 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
>> water)
>> * 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 problem with this is that it means server coordinates as sent by
> default are not longer euclidean, and it massively increases the
> complexity of the server code for handling visibility calculations and
> physics. We actually tried this approach a long while ago while still
> working mostly with a 2d client.
>
> If we are going to want to specify an offset like this then I think it
> should be specified separately, and the Z coord kept accurate, but
> more often than not ignored by the client code.
>
> One approach would be to make the new "mode" property complex, and
> allow it to contain in addition to a name other optional attributes
> like this;
>
> "mode" = {
>     name = "buried",
>     depth = .03,
> }
>
> "mode" = {
>     name = "flying",
>     height = 22.5,
> }
>
> I do think we need to be very careful about handling flight this way
> as it can lead to some very odd behavior over rough ground. Things in
> flight don't track every detail of rough terrain, and it would be
> better if flying things were usually specified in terms of their real
> height thus freeing their trajectory, and allowing them to crash.
>
>
>   
>> 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 into it).
>>     
>
>   
>> 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.
>>     
>
> This all gets very media specific and I think the server is probably
> better off staying out of it for things like wielded entities,
> mounting on horseback etc. The server should just specify the
> relationship between the entities in abstract terms, and the details
> are down to metadata associated with the media. I hope this doesn't
> sound like I am trying to offload the problem onto the client, but I
> really don't think the server can do much to help here.
>
> The case I was more considering was more freeform construction like
> pioneering where players are building things by attaching lumps of raw
> materials together, like building a platform in the branches of a
> tree.
>
>
>   
>> 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.
>>     
>
> The fruit case is different again. I am happy to leave it to the
> client to make that look good.
>
>   
>> I'd like to return to the "gravity affected" one.
>>     
>
> "gravity affected" is I think overly broad and non-specific here. It
> covers a number of cases that need to be treated quite differently.
>
>   
>> 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.
>>     
>
> I am really reluctant to start down the road of depending on physics
> for stuff like that. We need to devise ways of marking up where the
> contents of entities get placed so that it can be done right. The more
> I deal with cascading up the containment hierarchy the less I like it
> and the more I am inclined just to make the immediate parent
> authoritative for contained entities placement constraints.
>
>   
>> 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.
>>     
>
> "falling" and "projectile" are the same case. In both examples of the
> case an acceleration should be specified for gravity, and the
> constraints once they intersect with the terrain will be the same as
> for default grounded objects.
>
>   
>> 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
>> offset.
>>
>>     
>
> I am really against using the Z coord as an offset as explained above,
> though I am more than happy to allow for an offset to be specified
> elsewhere as I have explained above.
>
> I am going to go ahead now and start stripping out the "mode" code as
> it stands as only a negligible portion of it is concerned with any of
> the things we have discussed here, and the vast majority relates to
> triggering looped animations. This will really help me with the
> refactoring of the movement code at which point I can have a better
> perspective on how to handle the constraints issue better.
>
> I'll assume you can proceed with ensuring Ember can handle doing
> animations without "mode"?
>
> Al
>
>   
>> Alistair Riddoch wrote:
>>     
>>> Erik,
>>>
>>> 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)
>>>
>>> Al
>>>
>>>       
>> _______________________________________________
>> General mailing list
>> General at mail.worldforge.org
>> http://mail.worldforge.org/lists/listinfo/general
>>
>>     
>
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.worldforge.org/pipermail/general/attachments/20090513/169f9587/attachment-0001.html>


More information about the General mailing list