Pauldrons On Cvs

[ascottk]

I put the lwo equivalents of the AI pauldrons on cvs:

 

builder guard:

bg_pauldron_l.lwo

bg_pauldron_r.lwo

 

citywatch:

cw_pauldron_l.lwo

cw_pauldron_r.lwo

 

elite citywatch

ecw_pauldron_l.lwo

ecw_pauldron_r.lwo

 

Let me know if there's a ny problems

[Ishtvan]

Maybe this isn't the place to voice this concern, but how much is having all this stuff attached as separate entity's/models on the AI going to drag down peformance? We know that 2 entities with two textures render slower than 1 entity with 1 texture, so I wonder how much it will effect AI rendering performance to break them up into a bunch of attached models? Not to mention the fact that these all have separate collision models too. They would have to, to be able to detect hits on the AI.

[Domarius]

Well it's doing bounding box collision untill the bounding boxes acutally intersect, so it mightn't matter much?

 

I'd like to think that the AI still has one bounding box even though it has seperate models attatched. I don't think the pauldrons need to be seperate entities.

[Springheel]

The pauldrons aren't being removed from the existing AI (afaik). But this way they're available if mappers wanted to add some to the proguard, model, for ex.

[Ishtvan]

Oh, okay. I had this vision of attaching everything to the AI to make it more customizable, but at the same time possibly impacting performance badly.

 

@Domarius: I haven't seen this optimization you mention anywhere in the code. Maybe it's in the hidden collisionmodel manager code, but it seems like projectiles check against all render models, not just the bounds of those render models, then the render models. To prove this, you can shoot an arrow at the hands/feet of an AI while they're walking, which moves them outside of their bounding box, but it still hits.

[Domarius]

Wouldn't the bounding box be re-calculated to encompass the extents of the animation?

 

It just doesn't make sense to check for collisions against the polygons of someones fingertips when they are not even within arms reach... across the other side of the room. At the very least, I'd expect a bounding box that is always present that encompasses the furthest extents of the animations.

 

I doubt Carmack would have left out such a basic optimisation.

[New Horizon]

Couldn't we verify this by looking at the Prey collision source code that was accidentally leaked? I posted it awhile back.

[Gildoran]

I'm under the impression that the D3 engine does use bounding boxes. It only does detailed model collision detection if it intersects the model's collision box.

 

From Q4's performance page:

Traces: The game performs a lot of traces per frame. It constantly traces beneath the player to keep track of what he's standing on (if anything), in front of the player to check for NPC's to flip up their crosshair ID, in front of every projectile and moving object, and even on some effects (like sparks that bounce or drips that splash on the floor). These work hand in hand with the physics listed above - sparks bouncing off of ragdolls can become costly. Any trace against an MD5 is also inherently expensive, because if a trace is determined to hit an MD5's bounding box it will then have to evaluate against every poly in the MD5 to determine a hit with more precision. In the singleplayer map "Putrefaction Center", several sources of terrible framerates were revealed to be traces through the MD5 intestines strung around the map. Many of them were made as one huge MD5, meaning their bounds often encompassed whole hallways or rooms, which in turn meant that shooting in any direction in that room led to traces against every poly in the entire mess of intestines ... not good. They were since split and given low-detail collision hulls (as were all of our creature MD5s). Keep an eye out for any excessive or unnecessary traces by enabling r_showRenderTrace.

[Ishtvan]

It just doesn't make sense to check for collisions against the polygons of someones fingertips when they are not even within arms reach... across the other side of the room. At the very least, I'd expect a bounding box that is always present that encompasses the furthest extents of the animations.

Now that you mention it I think that is what's done. There's an outer bounds that can be seen with r_showcollisionmodels 1. It definitely doesn't use that to stop the AI from clipping stuff, but it may well use it for collision tests like you say.

[Domarius]

That's a good tip there - avoid huge MD5s, split them up into reasonable boxes.

 

@Ishtvan - yeah that would make sense, you wouldn't want that same "all encompassing" bounding box to be used for letting the entity walk into walls. That sort of bb needs to be smaller, to let it through spaces reasonably, even if their arms clip through the wall sometimes.

[Ishtvan]

What I'm saying though is that that optimization doesn't apply to attachments made from separate entities. If you have 5 attachments on an AI, collisions have to test 5 bounds, because it doesn't know not to check the attachments if the trace is outside the AI bounds, because the collision system doesn't know those attachments are part of the AI. So you do add to the number of collision/bounds test with each additional attachment.

[Domarius]

Why would pauldrons need to be attatchments though? We're not going to have stripping guards Only the weapons need to dynamically attatch.

 

The pauldrons could be seperate meshes in the mesh file, but still belong to the same mesh in a single entity. I don't think ascottk intends for them to be dynamic attatchments.

[Ishtvan]

The pauldrons aren't being removed from the existing AI (afaik). But this way they're available if mappers wanted to add some to the proguard, model, for ex.

I read that as adding them as attachments rather than editing the model, since mappers might not have access to modeling/rigging programs. It's not a big deal though.

[Domarius]

Ohh... yes that's probably not a great idea... though if its really important we should profile it to see how much it matters.

 

I don't think we should be clothing the characters in real time. Most costumes are so unique anyway, and the game is going to be calculating these things 100% of the time for every frame "Hm, his arm is oriented this way, so that means the pauldron should be oriented this way and placed here..." when it should just be part of the mesh anim.

[ascottk]

Where did stripping/clothing characters in real time come into the picture? We want a versatile tool set & customizing AI adds versatility Besides, the pauldrons were on the models needed list.

[New Horizon]

Ohh... yes that's probably not a great idea... though if its really important we should profile it to see how much it matters.

 

I don't think we should be clothing the characters in real time. Most costumes are so unique anyway, and the game is going to be calculating these things 100% of the time for every frame "Hm, his arm is oriented this way, so that means the pauldron should be oriented this way and placed here..." when it should just be part of the mesh anim.

 

T3 used attachments to change the look of different AI, surely it shouldn't be that much of a performance hit if we have maps that do it for one or two AI?

[Domarius]

Where did stripping/clothing characters in real time come into the picture?

That means the parts are dynamically attatched in real time. (The "stripping" refers to the fact that they are capable of being detatched at any time, as opposed to a helmet that is part of the mesh of the entire AI.) Having a model like this would have to entail more CPU processing than an entity with less attatchments. But how much, is anyones guess, unless we profile.

 

I have no idea how the renderer works, but Ish seemed concerned it might mean our AI become more expensive to render.

[Springheel]

Yes, it might make them more expensive to render, but that's the mapper's concern, not ours. Our models are not designed to *require* attaching pauldrons, but it is an easy way for mappers to add a little variety to existing models.

 

In most cases, attachments won't require collision tests, since they'll be things that shouldn't affect arrows anyway (hats, hair, belt pouches, probably weapons when sheathed, etc). Pauldrons and helmets are the only things I can think of that would really need to detect collisions when attached (well, and weapons held by the AI, obviously).