Animated objects ?

[ascottk]

Ugh, I hate AFs . . .

 

Anyway, some potential problems:

 

Joint hierarchies, and potentially the original joint not in lower case on the model (don't quote me on that).

 

Contained joints in a body. Suppose . . .

 

origin

|_

lower joint

|_

middle joints up to upper joints

 

If you want only the origin joint, just

containedJoints "origin"

(no asterisk).

 

If you want to group joints like the lower & middle:

containedJoints "*middle_first -*middle_last"

(space between the first joint & the dash but not after the asterisk).

 

If you want to contain everything above, & including, a joint:

containedJoints "*upper_joints"

 

Aside from having no constraints types, I can't really see what's wrong by looking at it.

 

Here's oDD's wiki topic on editing AFS:

http://www.thirdfilms.com/darkwiki/index.p...int_Hierarchies

 

Also, Doom 3's AF folder has a lot of examples you can look around (extract one of the pk4's from the Doom3/base directory.

[Baddcog]

Still making progress, thanks for the input,

 

but if it's not one thing it's another.

 

The AF file is pretty much there. I have the base of the chest set up as a box, correctly sized and positioned, same with the lid, but that's a cylinder.

I changed all names to lower case, and think I fixed the organization of the bones structure. Now I can spawn and af chest in game and it won't crash.

 

I can shoot it and an arrow will bounce off. I can throw a crate at it and the crate will bounce off. I can set a crate on the round top and the crate will roll off. blocks ai, blocks player. All good.

 

BUT, if I hit it with my sword or blackjack, or too many arrows (usually more than 5) it will die (talking about the spawned AF chest). At this point it flings wildly across the room and the lid spins, not locked down at hinges. Not being locked at hinges is alright I think cause it should never fly across room anyway.

 

Along with that problem there is one more.

I can create a chest entity in the editor and go in game, the animation is running. However, the chest created in hiearchy has no af chest attached, no physics unless I set a bounding box in def file which shouldn't be needed if AF works.

 

I've looked everywhere but I can't find these 2 things:

1-How do I make the chest impervious to attacks, sword should bounce off.

2-how do I make the AF info appear with an entity created in editor? I do have this in the def file

"articulatedFigure" "chest_collide.af"

 

I have used ragdoll instead of articulated, I have also tried with/without chest_collide.af

I have seen examples of both in files, either darkmods or doom3

[greebo]

ad 1) Maybe the clipmodel_contents have to be set correctly? I think Ishtvan said something about this, but I never did this myself.

 

ad 2) Do you mean how to display inherited properties in the Entity Inspector? If yes, this can be done by ticking the "display inherited properties" checkbox on the upper left corner of the Entity Inspector. If not, then I don't know.

[Baddcog]

No, I know about the check mark to show inherited props. The problem is when I create the chest from the entity list, it shows everything in the def file (including "articulatedFigure" "chest_collide.af"). I've also used "ragdoll"

and "chest_collide" and all four in every combo possible, but that doesn't work. The AF file is never created WITH the chest entity.

 

Does anyone know where I can find the rope.def file? It's so hard findsing def files that are buried in some random file. As far as I can tell the rope is NOT in the rope arrow def. Maybe that would help, cause when I create a rope entity it have the AF model with it.

 

 

-------EDIT-------

OK, I changed the af file to chest21.af so it matches the rest of the files. Not sure wehy it matters as I refernced the correct file in the def.

 

I also changed the spawnclass to idAFEntity_Generic which is the same the rope has.

 

Now when I go in game it has the collision data, chest is laying in a weird pos and the lid is also weird in an odd position. Like I had already hit it with my sword. And still, if I hit it with my sword it flies around the room. One time it killed me.

 

Now I get an error

..chest21_4 has multiple tree structures, but if I try to put the joints in the contained by of other bodies I get an error that says "bone already contained by...another body"

 

This is the current af:

 

 



/*

Generated by the Articulated Figure Editor.

Do not edit directly but launch the game and type 'editAFs' on the console.

*/

articulatedFigure chest_collide {

settings {

model "chest21"

skin ""

friction 0.0099999998, 0.0099999998, 8, 0.5

suspendSpeed 20, 30, 40, 60

noMoveTime 1

noMoveTranslation 10

noMoveRotation 10

minMoveTime -1

maxMoveTime -1

totalMass 200

contents corpse, playerclip

clipMask solid, body

selfCollision 1

}

body "desperate" {

joint "origin"

mod orientation

model box( ( -5, -5, -5 ), ( 5, 5, 5 ) )

origin joint( "origin" )

angles ( 0, 1, 0 )

density 5

friction 0.0099999998, 0.0099999998, 8

contents corpse, playerclip

clipMask solid, body

selfCollision 1

containedJoints "origin"

}

body "chest_lid" {

joint "lidbone"

mod orientation

model cylinder( ( -14, -14, -19 ), ( 14, 14, 19 ), 5 )

origin ( 0, 0.3600000143, 20.8656997681 )

angles ( 270, 0, 0 )

density 5

friction 0.0099999998, 0.1000000015, 0.8000000119

contents corpse, playerclip

clipMask solid, body

selfCollision 1

containedJoints "lidbone"

}

body "chest_base1" {

joint "basebone"

mod orientation

model box( ( -19.5, -12.5, -11.5 ), ( 19.5, 12.5, 11.5 ) )

origin ( 5.9200000763, 0.1492310017, 8.8499403 )

density 5

friction 0.0099999998, 0.0299999993, 0.8000000119

contents corpse, playerclip

clipMask solid, body

selfCollision 1

containedJoints "basebone"

}

hinge "chest21_constraint" {

body1 "chest_base1"

body2 "chest_lid"

anchor ( 0, 0, 0 )

axis bonedir( "basebone", "lidbone" )

friction 0.5

limit 12, 8, 2

}

}

 

and this is the def

 

//chest animated

model chest21 {

mesh   models/md5/props/containers/chest21.md5mesh
  anim af_pose			   models/md5/props/containers/af_pose.md5anim

anim idle  models/md5/props/containers/chest21_idle.md5anim
anim open  models/md5/props/containers/chest21_open.md5anim
anim opened  models/md5/props/containers/chest21_opened.md5anim
anim close  models/md5/props/containers/chest21_close.md5anim


}

entityDef atdm:chest21 {

"articulatedFigure"   "chest_collide.af"


"spawnclass"   "idAnimated"
"model" "chest21"
"editor_mins"	 "-12 -12 -52"
 "editor_maxs"	 "12 12 52"
//	"cylinder"	"10" 
"size"	  "18 18 18"
"start_anim"	  "open"
"density"	   "200"
"mass"	 "200"
"solid"	 "1"

"snd_bounce"	 "material_metal_impact"
"friction"	 "10.2"
"damage"	"0"
	"frobable"	"1"
"frob_action_script"  "frob_item"
"usable"   "1"

}

 

[ascottk]

Now I get an error

..chest21_4 has multiple tree structures, but if I try to put the joints in the contained by of other bodies I get an error that says "bone already contained by...another body"

If you want to group joints in a body, you'll need to be specific about the contained joints. Let's say we have origin, joint_1 through joint_8, and joint_a through joint_f. You want to group origin through joint_6, joint_7 through joint_c, then joint_d through joint_f:

 

body "base" {
...
containedJoints "*origin -*joint_7" //anything starting at origin through joint_6
}

body "middle" {
...
containedJoints "*joint_7 -*joint_d" //joint_7 through joint_c
}

body "top" {
...
containedJoints "*joint_d" //everything above and starting with joint_d
}

 

So if you have a declaration of "*joint" it'll include everything above that joint in the hierarchy. Things not to do:

 

body "base" {
...
containedJoints "*origin -*joint_7" //anything starting at origin through joint_6
}

body "middle" {
...
containedJoints "*joint_5 -*joint_d" //oops, joint_5 & 6 is already contained in body "base"!
}

body "top" {
...
containedJoints "*joint_b" //oops, joint_b & joint_c is already contained in body "middle"!
}

 

So no overlapping contained joints or you'll get that error.

[Baddcog]

I understand that to a degree, and that's wh ythis puzzles me, I think I only have one joint per body, correct me if the above example show differently.

 

Basically this is my hiearchy

 

origin (contains no verts)

basebone (contains all verts for bottom of chest - only keyframed for AF_pose.anim)

lidbone (contains all verts on lid - keyframed for all anims)

 

Maybe I need to add containedJoints "-*lidbone" to basebone so that bone isn't included below the lidbone?

 

Alright: I was under the impression that -*lidbone would contain up to AND including the lidbone into that body, when actauuly it stops lidbione from being a part of that body.

 

I'm gonna Wikify this stuff when it's all said and done.

 

So the error is gone, all bones/joints seem to be in proper places along with their respective bodies.

------------

Now the biggie.

 

Anytime anything physical (crates/weapons) but not player touches the chest it flies off wildy. And the chest starts off broken when I load a map. If I go into editafs and choose the chest and adjust any parameter it rights itself until I hit it, at which time it flies off.

[Ishtvan]

The chest shouldn't be "dying", I think that's the major problem. When it dies, it stops animating forever and just uses the AF as a ragdoll simulator, which I don't think you want. Have you tried setting "health" to "0"?

[Springheel]

I'm not sure if you're using the chest just as a test object, but it might be worth talking to Sparhawk about it. My understanding is that there were more reasons than just the bounding box issue for using the door method on the chest lid--you wouldn't be able to interrupt the opening animation to quickly close it, for example, like you could if it were a door. And there might be other icoding ssues as well related to lockpicking.

[Baddcog]

Yeah, I guess that's true about the chest.

 

Might not be good to animate them. I just wanted to start from scratch with an animated object and take it thru the entire process to make sure I was rigging correctly and all that.

If I can figure this out then any other objects like the clock would be easy.

 

I did try health 0, didn't seem to work, and I thought that might actually 'kill it' too, like it starts out of health.

Also trying "damage" "0" which is supposed to make it not take damage. Don't know if I've tried em together though.

 

I did upload test_baddcog.map, the chest files and sphere light and stairwell if anyone wants to take a look at that stuff. I've got particles in the light, close maybe but not perfect.

[sparhawk]

I guess for chests it may not matter that much if you can't interrupt it, but of course it's better to use the same methods for same objects. And frankly I don't see what an animation would achieve in this case, that the code doesn't as it is just a simple rotation.

[Baddcog]

Forget I'm working with a chest.

 

It's just an animated object with 4 anims (in this case idle, opening, open, closing)

 

AF attached, but it flips out when the game starts and 'springboards' across the room. However the af is a box and cylinder that are attached to bones so a crate drop on the round lid will roll off.

Basically I think it's very close to what we need to have proper physics on ANY animated object, but having simple collision models instead of Combat Model checking everyface for collision.

 

The main prob right now is getting it to stay where it is placed, and to keep it from moving when it gets touched by anything other than player. Sometimes it only budges which isn't that bad, but sometimes it flips upside down or flies across room. And also having the anim run WITH an AF attached.

 

--EDIT---

I tested with

health 0

damage 0

 

That did seem to help the flying across room a bit, only does it once in every 10 sword hits now, for the most part just twitches a little.

[Ishtvan]

In the programming thread we solved this issue, so we can assume an SDK mod is on the way to allow an idAnimated to use the AF bodies as collision models that move along with the animation. I think we can safely say we can get an animated object ingame now! There are some drawbacks to the animated object approach described in the programming thread, so we probably shouldn't use this approach too often unless the model is really simple. Baddcog also figured out how to get a standalone ragdoll for an inanimate object ingame with the AFEntity_Generic approach, which is another thing that no one's done from scratch before.

 

IMO we should probably document both these things (I still have to choose the exact spawnarg to allow animated objects to use the AF bodies as CM's, but the rest should be the same).

 

Animated Object

Set up AF file. Use an idAnimated for the animated object, use "ragdoll" for the name of the AF. Set spawnarg that is TBD to make it use the AF bodies as collision models, and use "combatModel" "1" to use the render for projectile collisions, if desired. If the combatModel is used, the AF bodies "contents" must be set to "corpse body" to allow the projectiles through the outer bodies but also block the player.

 

Non-Animated ragdolls

For a standalone AF that is not animated, use idAFEntity_Generic (or WithAttachedHead if it's a corpse with a head), use "articulatedFigure" for the name of the AF file. We should probably also mention the constraint "fixed" that fixes part of the ragdoll to the world.

 

Object requests: Shop sign, anything else?

The chest used in this example would probably work better as a prefab chest body with mover lid. We did have a request for a shop sign that swings earlier. We could do this one of two ways:

 

1. Animated shop sign:

Pros: Doesn't require any script thread to run

Cons: Won't move any differently if you hit it with an arrow, Swing limited to the number of anims for it

 

2. Ragdoll sign made up of two bodies: a post with a fixed constraint to the world, and a sign with a hinge constraint to the post.

Pros: Will react believably to an arrow, can swing an infinite number of ways depending on the way you push it

Cons: Requires a script thread running to give it a push to simulate win (programming wise this would be very easy, I wrote a function for this already to jiggle the rope arrow. Performance-wise I'm not sure how running a script thread and physics compares to running an animation. It's possible that one "wind object" with a single script thread could control multiple objects, but that requires more setup on the part of the mapper than a self-contained script on each object)

[Baddcog]

This sounds great Ishtvan!!! I'm excited, but need a break right now. Been setting up AF for bot, lots of bodies, kindof working.

 

I'm a little unclear on some of it though (sorry, it's still all a bit confusing having 4+ files per object, sometimes I get lost going back and forth):

 

TBD is the name of new spawnarg? oh wait, you mean To Be Decided, right?

So the CombatModel 1 is actually reading the simple AF bodies, not the entire mesh?

And everything you listed under Animated Object goes into the af file, except idAnimated which goes in the def file.

 

Think I got the non-animated part. Just figured out how to get the 'fixed' part to work with my lantern bot, not sure I even had that right on chest, could've been why it was flying around, will check.

 

I'd almost go with #2 on the shop signs. That would be like flourescent lights in doom, looks cool when you whack em. I think for the most part that would be the best base to have for the mod. Just objects that react to player input.

Wind is more of an enviromental, that can add alot to missions for sure. Although in T2 I saw it rarely used on signs even though they did have joints. If it could be controlled by scripts and used by authors that wanted too great, but i think signs that move when hit would just be a better every FM prop. My opinion though.

 

There is the one machine we have so far that could be animated, more would be good. Not sure who made that or the gears, unfortunately they are in obj format and I haven't had luck getting those thru textured.

Maybe I could get a base file to work off of? or a 3ds if someone can export that.

I'd just like to have the gears and any equip that can be used for all working machines, that way they'd match better instead of having 3 machines that look made by 3 different people.

 

Did I mention I'm excited?

[Ishtvan]

This sounds great Ishtvan!!! I'm excited, but need a break right now. Been setting up AF for bot, lots of bodies, kindof working.

 

I'm a little unclear on some of it though (sorry, it's still all a bit confusing having 4+ files per object, sometimes I get lost going back and forth):

 

TBD is the name of new spawnarg? oh wait, you mean To Be Decided, right?

Yep. I'll post full documentation and a testmap with an animated chest once I make that SDK change this weekend.

 

So the CombatModel 1 is actually reading the simple AF bodies, not the entire mesh?

No, CombatModel 1 always activates the render model as a collision model for projectiles, but the AF can also be active at the same time if it happens to be set up that way. You might want this for example if you want your object to use coarse AF bodies to block the player and bounce crates off of, but also want surface-based collision for projectiles and melee attacks (e.g., arrows sticking in wood parts of the object and bouncing off metal parts). If you're not careful about setting the contents of the AF bodies to "solid", the AF bodies will override the combat model and intercept incoming projectiles/melee before they hit the combat model, and just register a hit on surface type "none".

 

For the cases of machines, just using the AF bodies with no combat model should be fine.

 

And everything you listed under Animated Object goes into the af file, except idAnimated which goes in the def file.

Right, idAnimated spawnclass and "ragdoll" pointing to the AF file goes in the def. Plus combatModel if you want to use that (for very simple models that we want arrows to stick in, that's probably fine).

 

Wind is more of an enviromental, that can add alot to missions for sure. Although in T2 I saw it rarely used on signs even though they did have joints. If it could be controlled by scripts and used by authors that wanted too great, but i think signs that move when hit would just be a better every FM prop. My opinion though.

I agree. The specific request was for a sign that swings back and forth by itself as if in the wind, but that can be done with a script that pushes on the sign with one line of code, and could be simplified further for FM authors who don't want to write script things. The only thing I'm not sure about is a *squeak squeak* sound when swinging. With an anim this would be easy (you can play sounds with what's called a "frame command" in the def file where you define the anims). With ragdolls, I think there's a spawnarg you can set to play sounds as it rotates around the joint, but I'd have to look into it more.

[Baddcog]

Regarding sounds:

 

*I did find this in func.def (doom/base/def), under func_anim. I assume this just plays all the time:

 

"sound_bone" "origin" (choose which bone sound comes from)

 

*this is in env.def (doom/base/def) I think this plays on frame 1 of anim,

 

model env_storagecabinet_openback {

mesh models/md5/environments/storagecabinet2.md5mesh

anim open models/md5/environments/storagecabinet.md5anim {

frame 1 sound storagecabinet_open

}

}

 

*I've looked thru a few defs, and objects in game. The cahin and the swing lights both have collision sounds (metal) when hit with weapon and they swing due to their AF's. However they don't make swing sounds.

It's possbile we could use this

 

"snd_bounce" "bodyparts"

 

And have a "signparts" designation. maybe an overlap of a weapon hit and squeak all in one sound?

 

BTW----

I did add an animated object page to the Wiki before. It's gonna need some major updating now though.

[Ishtvan]

"snd_bounce" "bodyparts"

 

And have a "signparts" designation. maybe an overlap of a weapon hit and squeak all in one sound?

I'm talking about the AF sign though, that would have to squeak just from being pushed by the wind. For that you can't use a sound that only plays when it collides with things, like snd_bounce, you need a sound that plays when the joint moves. I thought there was a system for this, but am not sure.