Model Request: Simple AFs

[Ishtvan]

I don't think we have any non-corpse ragdolls for testing physics.

 

It would be nice to get some of these, and they can be very simple. For example: Take the existing bucket model we have, and add a handle to it. Then make a ragdoll for it that just has two bodies (bucket, handle) and one joint (hinge joint connecting bucket and handle). Making the AF file for the ragdoll can be tricky, but I think we have some modelers with some experience in that now.

 

Another more labor-intensive example would be a morning star or flail.

[Baddcog]

that should be easy enough.

 

most likely a cylinder for the bucket.

 

The handle is a little tougher...

Could be a cube in the middle where an Ai would hold it.That would flop around and basically get the physics close enough.

 

Or could be a cube the size of the entire handle itself. Might have weird corners that stick out beyond handle, might also bump into bucket itself in weird ways.

 

---------

I'll try and do it but give me a grace period (maybe a week). I can only sit down for short spells and am working alot. Should be fairly simple though.

[Ishtvan]

Yeah, maybe the handle could just be a thin rectangle in the plane of the half-circle model. That would mean the player couldn't shoot arrows through the loop, but this is just a test item anyway. The handle doesn't actually have to collide with the bucket. You can turn selfcollisions off and just set the min/max hinge angles such that it doesn't let the handle turn enough to clip into the bucket.

[Baddcog]

I whipped up a quick model. Nothing fancy, just for test purposes.

 

skinned it and added bones. exported with an idle anim. created a def file. also have a start to an AF file.

 

weird issues though:

1- the md5 mesh shows that I have 6 meshes, I had to apply the shader name to 6 spots. I have only one mesh in Max and 3 bones (origin, bucketbone, hand)

I haven't seen that before.

 

2-got the bucket created in editor, but try to go in game and get error "cannot load collision model for atdm:phys_bucket_1"

 

Here is my somewhat messy def file. I added the last part just now, got same error before and after. got to sleep, maybe someone can clean it up a bit.

////////////////////////////////////
//Physics Bucket requested by Ishtvan

model phys_bucket {
mesh  models/md5/phys_bucket.md5mesh
anim idle models/md5/phys_bucket_idle.md5anim

}

entityDef atdm:phys_bucket {

"editor_color"	 "1 0 0"
"editor_mins"	 "-16 -16 -16"
"editor_maxs"	 "16 16 16"
"size"	  "32 32 32"
"mass"	  "50"
"origin"	 "0 0 0"

// "inherit"	 "moveable_base"
"model"	 "models/md5/phys_bucket.md5mesh"
//"density"	 "0.005"
"friction"	 "0.2"
"bouncyness"	 "0.03"
"snd_bounce"	 "material_wood_impact"

"nonsolid"   "0"
//"nodrop"   "0"
"noimpact"   "0"
"notpushable"   "0"
 "articulatedFigure"	 "phys_bucket_af"
}

/****************************************
************************
/////////////physics bucket Ragdoll//////////////////

model phys_bucket_af
{
mesh				models/md5/phys_bucket.md5mesh
anim af_pose		models/md5/phys_bucket_idle.md5anim

"editor_color"					"1 .5 0"
"editor_mins"					"-2 -2 -2"
"editor_maxs"					"2 2 2"
"editor_ragdoll"				"1"	

"editor_usage"					"Ragdoll for phys_bucket"


"bleed"							"1"
"sleep"							"1"
"smoke_wound_flesh"				"bloodwound.smoke"

"model"	"phys_bucket"
//	"articulatedFigure"				"idAFEntity_Generic"



//  "snd_bounce"					   "bodyparts"

}
////////////////////////

 

I haven't done this yet so still a little foggy on what we need exactly.

I assume to have a AF file it HAS to be an m5d mesh. The anim might not be nessecary, it's just one frame that I think IS needed for an af pose. But the md5 export does one with a mesh export anyway, no harm.

 

Not sure if the def needs to be movable_base or not

[Ishtvan]

I think the spawnclass for these things is usually idAFEntity_Generic

 

Here's a template that should hopefully work. Anywhere with "<stuff>" you'll have to fill in.

Ragdoll / AF Entity Template

// First you'll need a modelDef
model <modelDef name>
{
mesh					   <your md5mesh file>

anim af_pose		 <your .md5anim file, single frame pose>
// NOTE: The af_pose here is needed, another name won't work
}

// Now the entityDef
entityDef atdm:env_ragdoll_<your ragdoll>
{
"spawnclass"			"idAFEntity_Generic"
// NOTE: You can also use idAFEntity_WithAttachedHead, and attach a head as normal

"editor_color"			"1 .5 0"
"editor_mins"			"-8 -8 -8"
"editor_maxs"			"8 8 8"
"editor_ragdoll"		  "1"  // Not sure if this is needed	

"editor_usage"			"Ragdoll template"


"model"				  "<name of modelDef above>"

"articulatedFigure"   "<your AF file>"

"snd_bounce"			"<collision soundshader (optional)>"
"frobable"			"1" // set to 1 for frobable object
}

 

I'll repost this in the documentation forum in case it's useful.

[Fidcal]

[MOVED TO COMPREHENSIVE THREAD]

[Crispy]

This is probably not the best thread in which to make that request.

[Fidcal]

This is probably not the best thread in which to make that request.

Mmmm... I saw the heading 'Model Request' and thought I'd make an erm... request for a model?

[Baddcog]

@Fidcal, a good idea, maybe the comprehensive models thread...that way iot'll be around when someone is looking for a job

 

@Ishtvan, thanks. I actually thought that using mover was probably the problem but was tired and had already spent more time than I meant to last night. I'm tired now so maybe tommorrow I'll do more.

 

Just so we're clear what this is to be used for...

This isn't to be grabbed by player correct? 'cause then it needs to be a mover. But then it needs a collision model which md5's can't have. And only md5's can have 'joints', or bones.

This is just for say "setting on a shelf and the player shoots with arrow to watch it fall"

 

Can we make an md5 mesh a mover??? that's the question. Can a mover use an af file instead of a simple collision model for colliion.

But this is like a corpse, player can grab and pull a corpse. Sorry, thinking out loud.

[Crispy]

Mmmm... I saw the heading 'Model Request' and thought I'd make an erm... request for a model?

It's not "Model Request", it's "Model Request: Simple AFs". Difference. Get yer own thread.

[Ishtvan]

Just so we're clear what this is to be used for...

This isn't to be grabbed by player correct? 'cause then it needs to be a mover. But then it needs a collision model which md5's can't have. And only md5's can have 'joints', or bones.

 

...

 

But this is like a corpse, player can grab and pull a corpse. Sorry, thinking out loud.

Exactly, an AFEntity can also be picked up or dragged around, it doesn't have to be a moveable. It also doesn't need a collision model, because it uses the AF bodies defined in the AF file for collision, and the constraints in the AF file determine how the AF bodies interact with eachother (in this case a hinge between the bucket and handle). It's exactly like how you set up the chest earlier, except instead of being animated it will just flop around, so it only needs the one frame animation to set it up initially.

[Fidcal]

It's not "Model Request", it's "Model Request: Simple AFs". Difference. Get yer own thread.

 

Ah! I thought it said 'Simple OAFS' and thought this is the one for me!

[Baddcog]

Ok, got it. Does this mean an AFEntity can also be rotated when player is holding it like a moveable?

 

@Fidcal, LOL. You silly oaf.

[Ishtvan]

Ok, got it. Does this mean an AFEntity can also be rotated when player is holding it like a moveable?

Originally they could be rotated, but it didn't work very well for corpses, so I turned it off. For smaller AF objects though that you can entirely pick up, I think rotation will work, but I'll have to work on it and figure out if I just want to rotate the master AF body or what. That's why this would be nice to have.

[Baddcog]

OK, Ive got the bucket in game. Got a simple AF working, but its very buggy so far.

Been too long since I messed with this stuff.

 

The handle rotates, but limits need to be fine tuned to say the least.

 

It is not frobbable anymore though. It was before I added a body constrain I believe.

 

It has 3 bones:

origin

bucket

handle

 

I'm not so sure it needs the bucket bone.

 

that's all for now

[Ishtvan]

Great, thanks! I'll take a look at it and see about tweaking the AF settings.

 

By "it's no longer frobable", do you mean it no longer frobhilights, or it does hilight but doesn't move anywhere when you grab it? Whether it moves can depend on the constraints, if there's too much friction, your grab force won't be able to move it. Anyway, I'll work on making the bucket AF work nice for dragging, then I'll work on the grabber code to see about rotating simple AFs like this.

 

Incidentally, I thought of a couple other simple AF models that might be nice to have in the future:

 

1. A book with a hinge joint on the spine. Right now, an opened book can't be made moveable, because it looks too bizzare to have an opened book not close up when you drop it. I'm not sure how well this could work, seems like it might clip somewhere, might need more joints to prevent obvious clipping, but maybe it's possible. It would miraculously open to the same page every time, but that's okay.

 

2. A shop sign with a hinge constraint. This could be a constraint to the world, since the FM author might model whatever post to attach it to, we might as well just constraint the sign itself to the world at the point where it would be attached. I think we may already have an MD5 mesh for a shop sign, but could be wrong.

[Baddcog]

OK, I'll finish up the bucket first and go from there.

I'm not sure if it is highlighting or not. I'm gonna finish watching 300 tonight. Will finish bucket this weekend.

 

For the book it would probably be best to have 3 bones for cover. origin would be the spine, then one bone for each front and back (covers?) possibly many pages could be boned. Once AF was figred for one it would be copy/paste for all pages.

Problems: pages would have to be rigid sheets. putting multiple bones per page wouldn't be worth the effort, would be cool, but very big PITA.

 

True, probably always open to same page, but all open books do eh? Have you played NV's The Haunting?

Very innovative FM/ lots of trix. My open book model was given turning pages, probably a huge hassle for now.

 

I think I discussed the street sign with Springheel. We weren't really sure which way would be best.

Seperate hanger, with signs. ase or lwo's. We have several of these now.

Or an Md5. It was mostly about how to mke them blow in wind, if we wanted to do AF's. ect...

I think having the hanger as an ase/lwo is best for physics, but having the sign itself an md5 would be best for sword bashing/animating/ect...

What do you think?

[Ishtvan]

OK, I'll finish up the bucket first and go from there.

I'm not sure if it is highlighting or not. I'm gonna finish watching 300 tonight. Will finish bucket this weekend.

Cool, don't stress too much over the AF, I think I can make it work once I get some free time.

 

Problems: pages would have to be rigid sheets. putting multiple bones per page wouldn't be worth the effort, would be cool, but very big PITA.

Yeah, I don't think we should try to do multiple pages just yet. Each extra body adds to the computations the AF has to do, so I'm guessing it would slow down pretty fast.

 

Re: Street Sign

I think I discussed the street sign with Springheel. We weren't really sure which way would be best.

Seperate hanger, with signs. ase or lwo's. We have several of these now.

Or an Md5. It was mostly about how to mke them blow in wind, if we wanted to do AF's. ect...

I think having the hanger as an ase/lwo is best for physics, but having the sign itself an md5 would be best for sword bashing/animating/ect...

What do you think?

I'd vote for the MD5 sign, separate hanger option. The FM author might want to customize the hanger in various ways (maybe it's longer or shorter, more fancy with a flowery wood cutout or more basic wooden post, depending on the location). The sign part we could make an AF, but put the hinge constraint with respect to the world, so it will just swing about wherever it's placed as if there is a post there. Then the FM author could place it on whatever post, and it would already be setup to swing.

 

Then the author has a choice of whether they want to animated it via animation, which would not react to sword bashes, arrows or explosions, or, if they want to animate it via a script that pushes it with physics (we could set up a canned entity for this or something), which would swing back and forth and also respond properly to other stimuli. I think whatever route they take, the sign will need to have an MD5 structure. It needs one to actively animate it, and it needs one to handle the ragdoll constraints if it's a passive AF. So if we just made a sign with an MD5 and an AF file, it would then be easy to create both an animated version and a physics versions (the physics version wouldn't use the animation, and the animated version would never use the AF data).

[Baddcog]

OK, what I have is on SVN

 

Keep in mind, I only made this as a quick placeholder. Once we get it working we will worry about real useable models. I don't intend for this bucket to actually be released. it's pretty ugly.

 

Anyway, got most of the basics there. The AF file is set-up with bodies and constraints.

 

You need to tweak the bucket_const to do what is needed. Right now it IS frobbable, does highlight.

If you frob and move it WANTS to follow but is stuck in one spot in space so it flops around as you pull.

 

The handle moves in correct axis but spins freely. I think I have the min and max transversed but have to go to bed.

 

I barely understand these AF files as is so I'm sure you'll be able to pinpoint probs quickly.

 

This is gonna be cool though

 

it's phys_bucket_af

[Ishtvan]

Cool, sounds good! I'll check it out tonight after work (assuming I don't work until I'm about to fall asleep).

[Ishtvan]

Okay, I tweaked it up. There was an extra constraint you didn't need in there binding it to the world, which is why you couldn't drag it anywhere. Set the mass to a semi-realistic 10 kg, and tweaked the friction. Also, I renamed atdm:phys_bucket to atdm:env_bucket to be consistent with the rest of the ragdolls, rather than start a new group with just the bucket in it.

 

It's pretty cool, you can choose between holding it by the handle or by the bucket based on which your view-center is closer to when you frob (maybe at some point we should make a system for showing you which AF body you're frobbing before you frob it, if that's even possible. Something like a subtle secondary hilight around the particular body).

 

The grabber currently won't let you rotate this, and it's also applying the dead body drag force to all AF's, meaning the drag is artificially high on this bucket. Also, for some reason when you are grabbing on to part of an AF, you seem to be able to exert less force on the entire AF the lower the mass of the thing you're grabbing is. Not sure why. Could be that the grabber is only calculating the desired acceleration based on that particular body, neglecting that the rest of the AF is connected to it. I had to scale up the mass of the handle a bit artificially to make this work. Anyway, that's why we're doing this test, to iron out these issues.

[Baddcog]

Cool, updating now so I can play with it (a little behind on updates so it's taking a bit)

 

I originally started that with 3 bones, it now only has 2. Hence the extra constraint probably, although I thought it only had 2.

 

It'll be cool to see your settings, give me a little more idea of what to use in future. Not sure about all the numbers for friction, ect...

Don't know kg either. Is all the weight metric? What's the conversion kg>lbs?

 

I had just used that name as it was VERY easy to find, pull up editafs, hit p, wala, phys_bucket

(I also figure it will eventually be deleted, but I guess a new model can be made to just override that one when it's all done)

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

 

This got me thinking about what other objcts could be used this way. This is just a list that I'd like to hear comments about:

 

Globe, could have the globe spin. physics wouldn't be as good. Can we do a shpere (question to self)

 

 

 

Objects planned but not made:

Sextant, calipers, scissors (things oif that nature would be great)

[sparhawk]

There already is a globe, done by Oddity. Don't know what happened with it though.

[Baddcog]

Yeah, there's a static globe, I'm talking about giving it AF's though so the player can frob/spin it.

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

 

This is really cool. While not finished I suggest everyone creates an atdm:env_bucket and plays with it. Thanks Ishtvan!

 

You can grab the handle and swing the bucket around, the bucket swings around under the handle. Or you can grab the bucket and the handle swings around. I found i pretty easy to pick the part I wanted to, I'm not sure we need to have seperate highlights.

 

I also don't mind not being able to rotate it, no biggie.

 

But I can't seem to throw them like other objects, Can only drop it.

[Ishtvan]

For some reason throwing only works when you're holding the handle, not sure why. It also throws WAY too far, because our throwing force was calibrated for throwing around 200 kg crates. We'll have to update those forces as we update the masses.

 

Rotating shouldn't be that hard to code, I just have to decide which body to rotate about for small AFs like this (maybe the most massive one?), and make sure the constraints don't fight the rotation in a bad way.

 

Dragging the bucket around is lagging behind more than it should be. When the only AFs were bodies, I had put in a general AF damping number for extra damping, but this should really be a per-entity spawnarg, not an overall variable.

 

In terms of tweaking the AF, what I've been doing is starting with a sensible mass for the whole thing using the TotalMass variable. Then I set all the densities to 1 as a first guess, and use af_showmass cvar to check it out ingame, make sure no body part is too light (significantly under 1.0). Then I adjust the constraint frictions, setting them fairly low until it starts moving like you'd expect, but not so low that it's unstable. After that first guess, I go thru and tweak the densities and frictions as needed to make it stable. The contact friction of the body itself is also critical, if those are too high, the bodies will get stuck when they're trying to slide against the floor, and it will come to rest too early. Too low and the whole thing will slide across the floor too easily.