Collision Model issues

[Springheel]

I have a few questions about collision models.

 

1. We currently have a bunch of specialized collision model shaders for different surface types (tdm_collision_wood, frex). Does the collision model always 'trump' the surface type of the model's material? In other words, if I shoot an arrow at a model with a texture set to surftype "wood", but the collision mesh is tdm_collision_metal, does the arrow bounce off or stick in?

 

2. Is it possible to split collision meshes up so that part of the mesh points to tdm_collision_wood and part points to tdm_collision_metal (frex)?

 

3. If an open bucket model has a collision mesh that is flat on top, that means nothing can be put into the bucket, correct?

 

4. What happens if no collision model is created for a model? A moveable won't work, IIRC, but what about a static mesh? We have an open barrel model, for example. It's too large to be a moveable, and if we create a collision mesh for it you won't be able to put an object inside the barrel (assuming #3 is true). How do we decide whether it should have a cm or not?

[Baddcog]

Yes, the new collision surfaces can be split on an object.

 

My round topped wood chest uses tdm_collision_ wood and metal. I made a basic collision model to fit the shape and used wood on it, then built a frame around it with the metal collision.

Works as expected, still alot lower poly that the chest. I did cheat a bit inside the lids of the chests, so arrows may/may not stick to inside of lids. Minor issue I think.

 

For the large open barrell, depends. It could probably be pushed if it had a collision model that allows things to be dropped in. I was thinking about this the other day. I was standing on one thinking what a cool hiding place it would be if I could've got inside.

I'd rather be able to jump inside and hide than push it around personally.

 

But I think the barrell could still be pushed with a complex collision model, I just don't thiink you could pick it up. I think that's where the collision model issue comes into play, whether or not you want to pick it up. Maybe if you want to make an elevator out of it, not sure.

 

Yeah, open bucket with closed collision could be picked up, but nothing will go inside. Maybe plaed inside by author, but not dropped in game.

 

Oh, if it had no collision it'll use the model as collision detection and complicate pathfinding.

[Crispy]

3. If an open bucket model has a collision mesh that is flat on top, that means nothing can be put into the bucket, correct?

Correct. If you want to be able to put stuff into the bucket, the collision mesh needs to have a dip inside it (making it concave). Otherwise, you'll try to drop an apple into the bucket and it'll hit the invisible barrier over the bucket's top instead.

 

But: My personal current theory is that concave collision meshes will work for moveables, as long as the polygons themselves are convex (in the 2D sense), but I may be wrong. Try it and see?

 

4. What happens if no collision model is created for a model? A moveable won't work, IIRC, but what about a static mesh?

I believe the display mesh is used as the collision mesh when no collision mesh exists. The exception to this rule is for moveables, because moveables have restrictions on the properties of the collision mesh; so they must have an explicit collision mesh or they'll refuse to function.

 

So yeah, static models don't need collision meshes AFAIK.

 

We have an open barrel model, for example. It's too large to be a moveable, and if we create a collision mesh for it you won't be able to put an object inside the barrel (assuming #3 is true). How do we decide whether it should have a cm or not?

I think someone should try making a concave collision mesh for a barrel just to see if it works as a moveable (to at least give mappers that option). If it does, great! If not, it may still be worth making a collision mesh that doesn't work with moveables, because reducing the amount of collision polygons gives an optimisation benefit. OTOH, unless the model is reasonably high-poly there's probably not much point doing that for a static barrel; it'll be able to have its physics "go to sleep" anyway since it probably won't collide with many other objects.

[Springheel]

There is definitely a potential for some crappy-looking situations where objects are placed 'on top' of an open bucket and just float there, or when arrows hit and stick into the space between chair legs. I have a feeling that coming up with good collision models might be something that is going to require some serious investment at some point.

 

I'll see if I can test concave collision models, as that would certainly help.

[Ishtvan]

I posted some documents on collision models for moveables a while ago, and I seem to remember the Id documentation specifically said they have to be convex, but we might as well experiment in case that documentation is wrong. Stranger things have happened.

[Springheel]

I guess it's not entirely clear what is meant by 'convex'. Our chairs, for example, have a collision model that is distinctly 'L' shaped, which I would interpret as convex. Baddcog's teapot has something similar. They both seem to work. But perhaps they meant convex as in 'a hole enveloped by the collision mesh on three or more sides' which I don't think we've tested.

[Springheel]

Hmm, it seems confirmed that at least simple convex collision meshes are possible. I was experimenting with the dining chair. I added vertex in between the legs and created a convex shape under the chair. I was then able to load the new chair, and even set it down on top of the static skull in the image.

 

[Baddcog]

That's a step in the right direction no doubt. I wonder why I had soo much trouble getting my tray to work. I think the version with the shape like the bottom of the chair worked, but I was trying to make a square inside it instead of just a vert. It would go in game and I could pick it up but it was very unstable like a bad AF. You grab it and it would fly off at 100 mph, bounce of a wall, hit you. SHAS.

[Ishtvan]

That's encouraging Springheel. I'm not sure if we have enough polies to do the inside of a bucket (I think the limit is 16 faces or something?), but we can try. We should also test it rather thoroughly to make sure that no physics interaction goes crazy when it has a convex shape, so that we don't find out months later that we're screwed.

[greebo]

For what it's worth, the above mesh is not convex, but concave. A sphere is convex, but a bowl is not.

 

There are a few good images here, for those who are interested: http://www.garagegames.com/index.php?sec=m...w&qid=10389

[Crispy]

For what it's worth, the above mesh is not convex, but concave. A sphere is convex, but a bowl is not.

My mnemonic: A shape with a cave in it is concave. Cheesy but effective.

[OrbWeaver]

My mnemonic: A shape with a cave in it is concave. Cheesy but effective.

 

Where a "cave" is defined as "any part of the object where a straight line drawn between two points on the surface crosses space outside the model".

 

I guess confusion arises because an L-shape is not seen as having a "cave" as such, but in fact it does, in the form of the inside corner of the L.

[sparhawk]

My mnemonic: A shape with a cave in it is concave. Cheesy but effective.

 

Yeah, I always confused this two, until I realized this, and now I can remember them.

[Baddcog]

Well, I think alot of the confusion lies in the fact that although a mesh is supposed to be convex, they can indeed be concave and work properly.

 

Doom seems very iffy on what will and won't work though. For example, my teapot collision is concave in at least 5 or 6 places, and yet I got it ingame with no problems and it's very stable. I was laughing when I first tried it out because there is no way it should work. The only thing is does conform to is that it only has 16 polys (tris) but is not triangulated. In fact one of the polys that has 3+ tris in it itself is very concave.

 

I've uploaded a test chair. Couldn't be more of a screwed up collision mesh but it almost works. You can create it and go in game, you can pick it up and set it on a wall with legs on either side. But it's like my tray collision, very unstable.

entity: chair_test

I recommend you check it out

 

I think at this point we've either gotta settle for the chair collision we have (L-shape) because it works at least good enough to move the chairs. I really don't see a 'realistic' collision mesh working. But that's games for ya, it's better than T2 and at least as good as T3 anyway.

[Tels]

Doom seems very iffy on what will and won't work though. For example, my teapot collision is concave in at least 5 or 6 places, and yet I got it ingame with no problems and it's very stable. I was laughing when I first tried it out because there is no way it should work. The only thing is does conform to is that it only has 16 polys (tris) but is not triangulated. In fact one of the polys that has 3+ tris in it itself is very concave.

 

So what happens if you leave the collision mesh off completely? Will D3 use the entire model as CM, and will this then f.i. allow arrows to fly under the chair legs?

 

Another idea would be to use more than one CM per model - is this possible?

[Springheel]

For what it's worth, the above mesh is not convex, but concave

 

You're right. I wasn't paying much attention when I was writing those posts.

 

I'm not sure if we have enough polies to do the inside of a bucket (I think the limit is 16 faces or something?), but we can try. We should also test it rather thoroughly to make sure that no physics interaction goes crazy when it has a convex shape

 

Yes, that's true. I did notice a little bit of strange behaviour when I tried to put the chair on top of a *moveable* skull (instead of the static one). There were three bits of odd behaviour:

 

1. The chair was difficult to frob (it didn't always highlight when looking directly at it). I don't know if this is a known issue with frobbing or not, but it seems to occur regularly for me with ragdolls as well.

 

2. The chair did go flying away from me with more force than it should have at one point, but that was when I was trying to put it on top of a moveable skull. I'll play around some more and see if it happens again.

 

3. (the most disturbing) The chair exhibited the 'rising' behaviour that we had with trees. Sometimes when I was going near the chair I'd start to rise into the air. Is this because some of the chair model extrudes outside the collision mesh? I know D3 has the collision mesh clip into the visible model occasionally, and I hadn't noticed that behaviour before on any default models. It would be quite annoying if the collision mesh had to encompass every possible part of the visible mesh.

[Springheel]

For what it's worth, the above mesh is not convex, but concave

 

You're right. I wasn't paying much attention when I was writing those posts.

 

I'm not sure if we have enough polies to do the inside of a bucket (I think the limit is 16 faces or something?), but we can try. We should also test it rather thoroughly to make sure that no physics interaction goes crazy when it has a convex shape

 

Yes, that's true. I did notice a little bit of strange behaviour when I tried to put the chair on top of a *moveable* skull (instead of the static one). There were three bits of odd behaviour:

 

1. The chair was difficult to frob (it didn't always highlight when looking directly at it). I don't know if this is a known issue with frobbing or not, but it seems to occur regularly for me with ragdolls as well.

 

2. The chair did go flying away from me with more force than it should have at one point, but that was when I was trying to put it on top of a moveable skull. I'll play around some more and see if it happens again.

 

3. (the most disturbing) The chair exhibited the 'rising' behaviour that we had with trees. Sometimes when I was going near the chair I'd start to rise into the air. Is this because some of the chair model extrudes outside the collision mesh? I know D3 has the collision mesh clip into the visible model occasionally, and I hadn't noticed that behaviour before on any default models. It would be quite annoying if the collision mesh had to encompass every possible part of the visible mesh.

[Springheel]

2. The chair did go flying away from me with more force than it should have at one point, but that was when I was trying to put it on top of a moveable skull. I'll play around some more and see if it happens again.

 

I played around with this some more. When I threw the chair, it did fly away much faster than it should, but I assume that's because the player's throw force hasn't been toned down yet.

 

The only other time it did that was when I picked it up and ran into another object while holding it in front of me. At one point it slipped out like a bar of soap and shot across the room. Don't know if that was due to the concave shape or the pushing action. I haven't noticed anything else odd.

[Baddcog]

I belive that's because it's unstable but its hard to say. I uploaded a chair test, it will get deleted eventually but you should check it out

entity:chair_test

 

It's got collision for the legs back and seat.

[Ishtvan]

So what happens if you leave the collision mesh off completely? Will D3 use the entire model as CM, and will this then f.i. allow arrows to fly under the chair legs?

No, for moveables, it will just crash the map if it doesn't have a CM when it tries to spawn. For statics you can use the model as a CM, so there is no problem with static chair legs.

 

Another idea would be to use more than one CM per model - is this possible?

I'm not sure, you could check the SDK for multi model entities. There is a class, but I don't think Id ever implemented it in D3 or tested it thoroughly. I think it's a static.

 

One thing you could do is bind several entities together, and using the new binding physics, it should work. Problem with that is that if a chair takes 5 entities bound together, you would rapidly approach the 4096 entity count limit when placing a lot of chairs.

[Baddcog]

No, I tried using a collision model for each part of a chair last light. Basically just 6 boxes. Doom3 said too many polys...

At least that's how it is now.

[Ishtvan]

No, I tried using a collision model for each part of a chair last light. Basically just 6 boxes. Doom3 said too many polys...

At least that's how it is now.

I know, there is a separate class called multimodel entity or something, but it may only be for statics. You could theoretically bind together several entities, but I'm not sure it would be worth it.

 

For testing the physics, the throw force and push forces are both too high. Also if you're not setting the mass directly, but setting the density, changing the clipmodel volume will change the mass. IMO we should always use mass instead of setting the density, but some objects with only density may have leaked thru. The best test right now is probably picking it up and dropping it on things (maybe noclipping up in the air to drop it on things). That will depend on the "bouncyness" setting, but hopefully that's fairly low already.

[Baddcog]

This is an issue that comes up over and over. Not collision models but physics forces.

 

Can we possibly get those set closer to what they will be on release so that we're not always running circles? Would be alot easier to set everything up if this stuff was even close. We can't shoot a fire arrow at anything 'cause it's completely screwed, ect...

 

It's possible that we're just wasting time with alot of stuff, AF's included because we have no idea how stuff is actually going to react.

 

I know we've got awhile to go into release and I'm not suggesting we completely fine tune everything, but at least bring this stuff close enough to have fairly accurate testing.

[Ishtvan]

Sure, it's all in cvars (except the fire arrow force which is in /def/weapon_firearrow), they've been posted before and you can use listcvars, so have at it.

[Baddcog]

Alright, I'll look into it. May be back for help