Animated objects ?

[Baddcog]

Well, I've successfully exported my first animated obj and viewed it in Der_tons model viewer.

 

real simple, just a lever moving down.

 

So what I'm wondering is why we don't want to use this option for small objects. Of course I have done very little with the editor so I'm curious.

 

Wouldn't it be easy enough to have a switch, animated going down and up. Then have a script that used the anims when frobbed rather than having 2 objects, linking them as an entity?

 

I ask mainly because I have wanted to start doing stuff this way for along time, in T2 you couldn't but you did have the options of joints.

Since we don't have joints but can animate ...

 

Anyway, I can deffinately rig/animate simple things liek this so if it's a question of taking animitors time...

I just think switches, machines, chests... could be done this way to great effect. For instance a chest lid could rasie slow but slam shut...

[sparhawk]

It depends on the obkects. Animation is better in some cases, but if it has to interact with code, like doorhandles, then it's better to have the animation done by code. An animated lever is IMO not a good thing, because it is a very simple movement, and if you connect it to a door for being frobbed, then you need to define the states.

[Baddcog]

So for machines it would actually be better, as most of the time they would just be running.

 

I should be able to get SVN running tonight and dl newer stuff so that'll help me out some I suppose.

But is it harder to define the states than it is to script the lever movements?

I figure with things like levers, once we have the scripts (or whatever is needed) for one it should work for all. Say we make a script to handle the translating, it would just call up animations (on, off, ect...) so that should also work for a rotating lever too. ?.

[OrbWeaver]

I suspect the reason that animated MD5 models are not used as much is because the process of creating them is slightly more complex and many people don't know how to do it. For example, not everybody who knows how to model necessarily knows how to use the rigging and animating tools in their 3D app.

[Baddcog]

Well, I would deffinately like to start using the rigging stuff more myself.

 

My problem though is scripting, I can copy/paste and figure out basic stuff if I've got something to look at, but I don't know C++ or any other language. (does pig latin count?)

 

But if someone could write up a script, or help me figure out how to get a frob to work the anims that would be most excellent.

[sparhawk]

IMO you don't need C++ for animating. Most of the AI code is written in scripting, so you should be able to trigger animations also from scripts. I just assume this, because putting the AI code in scripts without appropriate animations don't really make sense. Never looked intot his myself though because I didn't have the need for animations yet.

 

I think for complex movements, or more realistic movements, an animation is definitely better. So wether you should use animations or scripting really depends on how complex that movement is. I would never think of using a scripting code for programming an AI animation where it has to scratch it's nose, look around, etc.. For my watermill a script is appropriate because the animation would be just a rotation, which would be a lot of work to set up, while I can write such a command in a few minutes in a script to do the same.

[Baddcog]

Well, that's what I mean. I can do the animations, I just figured it would take a script to trigger them. ie: player frobs lever, script turns on animation. Isn't that how it would be done?

[greebo]

If it's a simple triggering of an animation you could also do it via a Frob Response, but for more sophisticated behaviour (e.g. frobbing again while the lever is still moving) a script is more adequate.

[Baddcog]

Yeah, I figured frobbing while it was moving might be more complicated, and would actually be happy with one frob per direction. (not while moving).

 

Something like a light switch would be such a quick movement anyway I don't think it would be necessary to stop it halfway.

[Springheel]

So for machines it would actually be better, as most of the time they would just be running.

 

There's also the problem that md5 models default to nonsolid, and the last time I looked into the issue, no one knew of a way to fix that problem. You can check out the grandfather clock entity for an example. It's an md5 file (for an animated pendulum) but when you put it in a map you can walk and shoot arrows right through it.

 

Here's the original thread about the gfather clock. I checked around on D3W and other forums at the time and no one had a real solution for this.

http://forums.thedarkmod.com/index.php?showt...andfather+clock

[sparhawk]

Well, for such simple cases you can put a clipbrush around it, right?

[Baddcog]

I guess this might be about the same as a clipbrush (I suppose that's an invis brush made in editor)

 

Maybe we could make a collision model as an ase or lwo with that data, and tie it together with the md5 as an entity? Then we could get close to correct shape for most parts at least, maybe moving parts we'd have to fudge a bit. But arrows wouldn't stick to moving metal parts anyway. wood though?

 

Does the grandfather clock cast shadow? if not that could be with collision model.

 

I guess the bonus of this would be havin machines with many moving parts only being

md5 model

collsion model

 

Not base + 10 moving parts that all need scripted.

[Springheel]

Maybe we could make a collision model as an ase or lwo with that data, and tie it together with the md5 as an entity?

 

I'm not sure whether you can include two different 'models' in an entity. I haven't seen any examples that do that.

 

Mappers can add the brushes later, of course, but that's not ideal as it's easy to forget to do it (or not realize you have to).

[OrbWeaver]

I don't see how all MD5 models can be insensitive to physics, since ragdolls are also MD5 models and they have plenty of physics -- or is it some aspect of the scripted animation, rather than the MD5 format, which interferes with physics?

[ascottk]

I don't see how all MD5 models can be insensitive to physics, since ragdolls are also MD5 models and they have plenty of physics -- or is it some aspect of the scripted animation, rather than the MD5 format, which interferes with physics?

They might need their own AF but I'm not too sure . . .

 

Doom 3's animated models have AFs & they might hold the collision info.

[Ishtvan]

The grandfather clock was placed as a func_animate, which inherits from spawnclass idAnimated.

 

Apparently, if you want projectiles to hit an idAnimated, you can set the spawnArg "combatModel" to 1.

// allow bullets to collide with a combat model
if ( spawnArgs.GetBool( "combatModel", "0" ) ) 
{
combatModel = new idClipModel( modelDefHandle );
}

 

This will make the grandfather clock hit by projectiles. However, every face of the model will be checked, which we might not want or need for complicated models. I'm not sure how to make individual collisionmodels for each part of it instead. Maybe if you explicitly texture parts of the model nonsolid, they will be ignored in the collision test.

 

I think this class was written with AI in mind, because this is how AI are treated (projectiles check every solid face of the AI model). (It also has events for making footsteps and launching projectiles ).

 

Question to people who have modeled AI: Have you made parts of the AI mesh nonsolid to collisions, maybe just by using the nonsolid keyword? If so, the same method could be applied here to make simplified collision boxes around the various moving parts of an animated object. That would make evaluating their physics much less expensive.

[Baddcog]

I did post at doom3 world. Sounds like it needs an AF file and the bones are set to a size I believe.

 

I looked at it a bit, but the AF files say to edit thru editor, that complicates things as I'm not sure what to do in the first places.

 

I suppose one of these days I'll look into it a bit more. For now simple static models.

[Ishtvan]

The AF bodies in the AF file determine some collisions, like physical objects bumping into them, but for projectiles (a special class of objects like arrows, bullets that use different physics because they move so fast), it will use the "combat model" by default, which is the whole model. That's why I was asking if it's possible to set individual faces nonsolid on AI and have them pass arrows through, because the same approach could be used here to avoid checking every single face of the model when arrows are fired at it. It doesn't matter if the model itself is already low-poly though.

 

Btw, you can edit the AF file without using the editor despite what it says, but without the editor it would probably be hard to place the AF bodies in the right positions. To use the ingame editor, type "editAFs" in the console. Beyond that I don't know, I know AscottK has used it.

[Springheel]

Apparently, if you want projectiles to hit an idAnimated, you can set the spawnArg "combatModel" to 1.

 

That's good to know. But that only applies to projectiles (basically arrows, for us) and nothing else, right? The player and other AI could still go through it?

[Baddcog]

Yeah, looks like we have to have an af file for collision models, based one the bones. Then we would need combat model 1 for projectiles.

 

I'd say for animated objects like a machine or clock the AF file is required, having ai and player walk thru is just wrong. Having projectiles, if it eats up processing resources, to me isn't that important.

 

We've lived with T2 terrible physics for years, shooting an arrow thru something that you most likely wouldn't shoot an arrow at anyway, no biggie.

 

There is always the pobbility of using 2 objects for alot of stuff anyway.

I think for a grandfather clock with would be more than adequate. You have the wood shell around the outside, that's shadows and physics. You have the moving parts inside, no need for physics.

 

There are alot of objects that could be done this way, maybe gears inside a wall behind a metal grate ect...

We could have a turbine body with collision model that goes around external gears, then have animated external gears. Of course there might be oddities, set a cup ontop of gear but it stays 'cause it's on collision model, not gear.

But again, who's gonna set a cup on a gear?

 

ease of use/setup vrs any possible outcome you can imagine..

[Ishtvan]

I'd say for animated objects like a machine or clock the AF file is required, having ai and player walk thru is just wrong. Having projectiles, if it eats up processing resources, to me isn't that important.

 

We've lived with T2 terrible physics for years, shooting an arrow thru something that you most likely wouldn't shoot an arrow at anyway, no biggie.

On the other hand, what if you're taking cover behind some huge piece of machinery and an AI shoots you thru it?

 

There is always the pobbility of using 2 objects for alot of stuff anyway.

I think for a grandfather clock with would be more than adequate. You have the wood shell around the outside, that's shadows and physics. You have the moving parts inside, no need for physics.

Yeah, that could probably be done with a prefab of a static clock body and an animated face.

 

That's good to know. But that only applies to projectiles (basically arrows, for us) and nothing else, right? The player and other AI could still go through it?

I think so. I've always been a little mystified about all the multiple collision models an AI has.

[Baddcog]

Yeah, it seems like to me a combo object is preferable for now. I'm thinking that a machine with say 3-4 gears is going to be fairly hi-poly adn we probablt don't want all polys to be checked all the time.

 

All moving parts animated, then a base model with collision data for the entire thing. We could always have that 'kill me' tex or whatever around serious moving parts like big gears.

 

There are probably exceptions too like sparhawks watermill. Large parts like the stone wheel need to be seperate and able to crush player (I stood in front of it and it just stopped-I know it's just a test). But the arm holding the wheel kept going, so that would need to be one piece.

 

Still figuring this stuff out myself so if I say something obvious forgive my ineptitude.

[Domarius]

There are huge pistons etc. in Doom 3, and AFAIK, they are just animations but they apply physics to whatever touches them. But the animation doesnt stop of course.

[Baddcog]

Well, I officially got a switch in game animated, I had watched it before in der_tons model viewer but not actually in game.

Now to figure out the AF file.

Then we'd need some scripting action I guess to actually make it do anything, send signals/ switch anims.

[Baddcog]

Hey, could someone help me set-up an Af file for this switch. It should be fairly simple but all I have to reference is character and the rope which all are overkill.

 

I've been messing around with editaf editor but can't get this to work. I think corpse as contents is probably the prob.