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

Erik Hjortsberg erik.hjortsberg at gmail.com
Wed May 13 05:55:17 PDT 2009


Another thing that I've been thinking of as a result of this discussion 
is how to represent the geometry of the entities. Currently we only use 
one property, the "bbox", which is used for both collision detection and 
visibility culling. However, we have a lot of more advanced meshes 
available which would require more complex collision data. Initially I 
think it would be ok if these collision primitives are boxes, as long as 
we have the ability to provide multiple ones for a single entity.
Currently, for the house3 entities that are by the village, we use a 
system where a number of invisible "wall" subentities are created. This 
approach is limited in mainly two ways:
1) It decouples the bounding boxes from the actual entity. They should 
instead be an intrinsic property of it.
2) It requires that the bounding boxes are created along with the 
entity, in the house3 case through scripting on the server side. This is 
a kludge.

I weren't around when they were implemented, but I'm guessing that they 
are a hack to get something up.

I would rather propose that we add a "geometry" attribute (or is it 
"property", I always mix those two up) to the entity types. This 
attribute can take multiple types of shapes (though for now we'll just 
go with boxes) which are then tagged to mark their use ("solid", 
"visual" etc.). At the same time we'll remove the "bbox" attribute. The 
current concept of the "bbox" would then be a geometry box shape tagged 
with both "solid" and "visual" (i.e. used both for collision detection 
and visibility culling).
This would allow us to for example build castle gates or houses, 
comprised of multiple collision boxes which allows the user to move 
under or inside them.

The bulk of work would need to happen on the server side, where instead 
of one entity having one bbox the server now would have to deal with 
each entity having multiple boxes.

What do you think?

/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/07153b67/attachment-0001.html>


More information about the General mailing list