Collision Model issues

[Baddcog]

I was scared for a minute. added all chairs to def and was looking at the in DR. most of them have a collision model that uses 2 boxes.

One on top that is concave on at least one model (an edge being turned could make it convex)

 

That shouldn't work either but it does

 

just posting for prosperity, we are gonna figure these things out at some point.

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

 

As far as chairs go I think we only have 2 options though:

 

1-moveables with arrows sticking into them weird (if a player feels inclined to shoot a chair, shoot thru the legs or let errant arrows fly)

 

2-non-moveable chairs.

 

Of course I think we all want them to move so this got me thinking about another option.

 

Arrows sticking in the chairs is OK, not a big deal to me if they do or don't. Usually I'd say I don't use broadhead much and when I do it's usually not inside.

But arrows sticking in the air under chairs DOES bug me. It's just ugly and breaks immersion IMO.

 

So what I suggest is it might be better to use the regular collision texture instead of tdm_collision_wood. Arrows would break and not stick into chairs but I'd rather have that than air-arrows.

Since the chairs are entities now we wouldn't even have to re-export the lwo's, we could just change it with a skin and put that skin on the entity and nobody would be the wiser.

[Springheel]

Hmmm. I've been wrestling with this issue myself. I'm not a fan of arrows in the air either, but it would add an inconsistency for players if they can see a model is clearly wood but then their rope arrow breaks.

[Baddcog]

Yeah, it's one of those comprimise situation. Best of 2 evils.

 

The one good thing about breaking arrows on chairs is there really isn't any reason to shoot a chair. Most cases it would be the errant arrow, in which caase it might be a long shot that they missed and they might not even notice.

 

But if the arrow sticks in the air and they walk up they probably will notice. And they'll be able to pull their arrow out of the air and reuse which is really stranger than having it break.

[Xonze]

I agree with Baddcog, it's less likely that a player, during the game, well question where their arrow went after a long shot, many won't even look. The only time it'd be noticeable is if the play is standing infront of a chair and catches the edge of the collison box and the arrow breaks. But if we have to choose arrows in the air under a chair or broken arrows-- broken arrow would probably be the least noticable and the least questioned during the game.

[Ishtvan]

What if the player wants to shoot a rope arrow into a chair and then drag it off something, or wedge it against something so they can climb down?

[Crispy]

Any reason why a chair can't have more than one collision model, and have them intersecting?

 

The idea being you'd have:

 

* An L-shaped collision model, surface type wood, to allow arrows to stick into the chair's back, seat, and legs

* A box-shaped collision model, regular collision surface (arrows break) to fill the gaps between the front legs and the back legs

* Ditto, to fill the gaps between the left legs and right legs

 

Or can't a moveable have multiple collision models? I seem to remember someone saying that, actually, so maybe this won't work after all...

 

Doom had moveable chairs in a few places, didn't it? How did they handle that?

[Baddcog]

Doom chairs were most likely a box, they were not intended to have arrows shot into them not have people hanging on them.

 

I guess it's possible that someone could find a situation in an Fm that they could wedge a chair and use a rope arrow but come on, now we're stretching it. Do we want some major ugliness in game so that in the probably VERY rare case that there's a situation this could happen the shairs will all be ready for it?

What if the player wants to bungee jump, shouldn't the ropes stretch?

 

Pulling a chair with a rope is less of a strecth but still, what's the purpose. If a guard notices he will work towards the chair which you are pulling towards yourself. He's alert. Anyway, as it is currently I have tried this and it doesn't work, I can't seem to frob the rope on the ground, maybe I need to jump on it to grab it.

The reason the crates get pulled down in that video is because someone jumped on the rope, they didn't just pull it. I think once your feet hit the ground you no longer hold the rope (is this how it works?)

 

Models can have multiple collisions, my chests do for metal and wood. However they are not moveables.

 

Some of the chairs are moveables and have 2 boxes (One for back/top) on for seat and legs. They work as moveables but but use the smae collision material so I don't know. it's worth a try. I think that is the best idea so far. Most likely tough an l shape AND a cube would not work.

2 cubes has a better chance, and most likely the player wouldshhot the arrow into the vertical surface on purpose, not the seat anyway.

[Springheel]

Pulling a chair with a rope is less of a strecth but still, what's the purpose.

 

I can think of lots of situations where you might be on a lower level looking up at a terrace or patio that has a chair on it. Shoot the chair with a rope arrow and you could use it to climb up.

 

Changing the collision mesh surface to something other than wood will also mean that incorrect impact sounds will be played.

 

I think we should exhaust all other possibilities before arbitrarily changing the surface type. Maybe there's a method we haven't thought of yet.

 

What happens, for instance, if you bind two different objects with collision meshes together? What about def_attached objects?

[Tels]

I can think of lots of situations where you might be on a lower level looking up at a terrace or patio that has a chair on it. Shoot the chair with a rope arrow and you could use it to climb up.

 

Changing the collision mesh surface to something other than wood will also mean that incorrect impact sounds will be played.

 

I think we should exhaust all other possibilities before arbitrarily changing the surface type. Maybe there's a method we haven't thought of yet.

 

I agree.

 

Here is another crazy idea, is it possible to have a collision texture that is "no collision"? Than you could make a "hole" between the legs by having two triangles on each side (and the botton center) marked with that texture.

[Xonze]

Just wondering, but what would happen if the mesh didn't go down to the legs of the chair, would it not be moveable then, or would it sink into the floor?

[Tels]

Just wondering, but what would happen if the mesh didn't go down to the legs of the chair, would it not be moveable then, or would it sink into the floor?

 

It would sink into the floor (even if it does not do this at level-start, it would as soon as it is moved), as the CM is used to check all collisions against other models (or their CM, actually) or the world.

 

Still can't believe that D3 has such crappy hardcoded limits for CMs... it makes realistic objects almost impossible (unless your object is a cylinder or a box...)

[Ishtvan]

Just wondering, but what would happen if the mesh didn't go down to the legs of the chair, would it not be moveable then, or would it sink into the floor?

Sink into floor.

 

Re: Binding

Yes, I've been saying in posts above that you can bind a couple objects together to create a chair. With Greebo's bind physics, it should work. I'm not sure how much of a hassle it would be. It would certainly push toward the 4096 entity limit much faster in maps with lots of chairs. Maybe if it's just two objects, it could be okay. It also seems like the physics act a bit jerky when the bound object is in contact with the ground and the bindmaster is not, but I'm not sure if that's my imagination or not.

 

I'm also against changing the surface type. Springheel has a good point that it would suck to drop down from a desk to a chair and get a huge metal CLANG sound that alerts all the guards. Also, it's inconsistent if we have chairs that are cleary made of wood and arrows don't stick in them. There's no justification for making the player remember "oh yeah, I can't stick an arrow in that wood object, it's a chair." I'd rather have arrows floating in space under chairs than breaking on chairs made of wood.

[Springheel]

With Greebo's bind physics, it should work. I'm not sure how much of a hassle it would be. It would certainly push toward the 4096 entity limit much faster in maps with lots of chairs.

 

Well, that's a limit we're likely going to have to adjust sooner or later.

 

My thought was to create part of the chair's collision model as part of the chair model, and then to bind another one (preferably the back) to it at runtime. Glad to hear it's possible, so let's test it out. I'm not sure how to do that, however. I'm used to using def_attach but that can't work here because there's no joint.

[Ishtvan]

Well, that's a limit we're likely going to have to adjust sooner or later.

I wouldn't bank too much on that, it could run into unanticipated problems in the precompiled code outside the SDK.

 

My thought was to create part of the chair's collision model as part of the chair model, and then to bind another one (preferably the back) to it at runtime. Glad to hear it's possible, so let's test it out. I'm not sure how to do that, however. I'm used to using def_attach but that can't work here because there's no joint.

Def_attach works on idEntities with no joints. In that case, it works relative to the origin. I.e., the translational offset and orientation is relative to the origin and overall model orientation. No need to put anything in for the joint since it won't be read off if the entity doesn't have joints. Sorry if I wasn't clear about that earlier.

 

IMO it would be better to make a prefab rather than spawn part of the chair on map start, since the FM author would want to see things as close as possible to how they'll be ingame (they might want an overturned chair and they would want to know how far the back extends out, for example). To do that, all we have to do is bind and make a prefab. Position them how you want, set the spawnarg "bind" on the chair back to the name of the chair bottom entity, then make a prefab. I think DR's prefab system can handle binds, if not, we can always add that.

[Springheel]

Could the attachment be included right in the entity itself, like the weapons were with AI?

[Baddcog]

I'm also against changing the surface type. Springheel has a good point that it would suck to drop down from a desk to a chair and get a huge metal CLANG sound that alerts all the guards.

 

Also, it's inconsistent if we have chairs that are cleary made of wood and arrows don't stick in them. There's no justification for making the player remember "oh yeah, I can't stick an arrow in that wood object, it's a chair." I'd rather have arrows floating in space under chairs than breaking on chairs made of wood.

 

Well, we don't have to have a wood chair with a metal sounding bottom of course. With the collision materials I'm sure we could have a "wood-no arrow" collision material that would break an arrow, or possibly just let an arrow pass thru?

Can we make arrows immune to a collision type? IMO that would be the best solution, but first we have to determine that we can actually use 2 collision surfaces on a moveable obj. Until then it's speculation.

What I'm talking about is 2 wood surfaces, one that accepts arrow where a chair is most likely to be hit with an arrow, and one surface that sounds like wood, that the arrow either breaks on or bounces off. That's not just "arbitrarily changing materials", that's putting ideas out there for the best possible solution. Is that worse than binding objects to other objects? It would be easier.

 

@Springheel, it would be great if you could export a chair and use 2 materials since you've already done all those chairs (I'm thinking the fancy armchairs) that had the 2 collision boxes and I can't use the lwos. I suppose you've got a scene ready to go.

 

So we're all for floating arrows so there isn't inconsistancy. Should we delete the tudor style textures too? Or are rope arrows gonna stick to the plaster surface. That's gonna make maps way to hard to control if players can climb up any tudor surface they want. Or we get rid of tudor, leave one plaster tex and authors will have to put the wood strips in by hand.

Why should arrows stick to air when they won't stick to wood?

 

Maybe we need to just have one cube with wood collision that arrows stick to attached to the back of all chairs. That collision could be made in editor and saved as a prefab. Then make the chairs have a wood collision that doesn't accept arrows so if you shoot the bottom of chair arrows fly thru.

There's no way to make a single L shaped collision model in editor so the seat would have to be excluded. But how many times are you gonna aim at the seat, if the argument is that you want to rope arrow most likely you'll be looking up at the top of the chair.

 

If the argument is just inconsistency we need to remember that all games have comprimises and players know this.

 

Collision is one of these, but it's not that bad. T2 had squares, the collision for this game is great, it's only moveables that aren't that great. Unfortunately chairs fall in this catagory. But still we are not limited to a cube or sphere. We can also make cones, cylinders and l shapes work. Even my teapot has got a damn good collision to match the shape, it's just that getting shapes like that is hit or miss at best and it gets frustrating trying too many shapes before a modeler just wants to revert to something tried and true.

 

I know that we can think of reasons or places where we could climb up a chair but then it comes down to where? These places haven't been created yet. Will they ever, in how many fm's? An author could always place a chair (static_func) for you to use if they want this to happen.

Do we want to make all chairs spawn 2+ entities just so arrows stick correctly?

[Ishtvan]

I know that we can think of reasons or places where we could climb up a chair but then it comes down to where? These places haven't been created yet. Will they ever, in how many fm's? An author could always place a chair (static_func) for you to use if they want this to happen.

Do we want to make all chairs spawn 2+ entities just so arrows stick correctly?

In the first version of Dram's mansion, about 2 years ago, there was a place. It was simply a balcony with chairs. The stone of the balcony would not accept a rope arrow, but the chairs did, so it was a way to climb up there.

 

I don't see the relationship between Tudor architecture and arrows that mysteriously break or pass through wooden chairs. There's a big difference between architectural/chronological consistency and physics consistency. I think you're taking the sarcastic consistency thrust a bit far. All I'm saying is that both are bad, arrows hanging in air underneath a chair, and arrows breaking on or ignoring a chair. But out of those two evils, I would pick arrows hanging in air underneath a chair.

 

I think someone got different faces of the collision model to have different materials in the past, maybe Dram? I don't know anything about modeling so I can't really say. We do have a list of collision materials in collision.mtr. Try applying some of those to faces on your collision model and see what happens? If we can do stone on one face and wood on the others, then in principle we could also do "pass projectiles" on that face and wood on the others.

[Baddcog]

Sorry, I'm not meaning to be sarcastic but you see my point don't you. players aren't gonna say'oh that's a building i can't stick an arrow to it, that's a chair I can stick an arrow to it"

 

either way people will be confused about why one material accepts arrows and another doesn't seeing how they are both wood.

 

IMO it would be better to have the arrows stick to tudor because it is terrain and people would be more likely to try to climb up a building to a window than a chair.

 

I think it would be great to get it working so chairs could be used to climb to a balcony. I just think if we're gonna argue consistancy then there are alot of other things like tudor that we need to consider.

 

 

Like I said above, I have used different coll materials on static models. However being a modeler I DO know how hard it is to get decent collision models working.

I will take a bit of time right now and see if i can get 2 materials to work on one model.

[Springheel]

@Springheel, it would be great if you could export a chair and use 2 materials since you've already done all those chairs (I'm thinking the fancy armchairs) that had the 2 collision boxes and I can't use the lwos.

 

I'm not 100% sure how that is done. Do you break the collision model up into sub-meshes? And how do you do that without adding more tris? I remember hearing that you can have unlimited tris in submeshes, it's just the planes that matter, is that true?

 

I suppose a compromise is that we could make the 'air' in between the legs a different surface. That way arrows will stick into the chair everywhere you'd expect. But if they hit between the chair legs, they'll connect with the other surface type and break, so you don't get arrows in the air. Not perfect, but acceptable.

 

I'm still hoping we can do something with attached entities, however. Two per chair is not a big deal. That way chairs could be handled and stacked more realistically.

[Tels]

@badcogg:

 

Having "combined" textures (wood+plaster) is "bad" in the sense that you can have currently only one material per texture - and this leads to inconsistencies as rope arrows breaking on obvious wood beams, or rope arrows sticking into obvious plaster parts.

 

This is, however, a technical limitation that could (theoretically could) be overcome by using material textures, these are, however, not implemented in the D3 engine, and so can only be added as it goes open source.

 

So for the time, we do have two options:

 

* 1: use them, but seldom.

* 2: avoid them at all cost

 

In my mill level I opted for option 2, but each method has drawbacks and advantages:

 

Option 2 drawbacks:

 

* performance loss - doom has to render many many more triangles if you make each beam a brush

* more complicated mapping, slower load time etc.

 

Option 2 advantages:

 

* with a "combinational texture", each wall part looks exactly the same. With brushes, you can make variants of texturing quite easily. (some similiar effect can be created with decals, tho)

 

Also note that the player being able to stick a rope arrow into *every* beam also means the player can easily climb up walls - and this makes the level design more complicated - some times it is just convient that the player can't go up and look "out" of the level.

 

As for the "realistic" effect of having a rope arrow stick into wood, you can also think of it this way: If the beam is very small, it won't support the weight of the arrow+rope+player, anyway. And if the beam is very old and very hard, you won't be able to drive an arrow in it, anyway. So having a wood+plaster texture and making it not accept arrows at all is a good compromise.

 

Likewise for my shingles+wood stripes texture - it doesn't accept rope arrows either.

 

So coming back to the chairs, I'd say having the arrow stick into the backside and the seating area, but going straight through the legs (or break on impact on the leg) would be a compromise.

 

Having arrows stick into solid air just looks wrong, tho.

[Baddcog]

Well, the armchair uses 2 boxes that are not one mesh. They might have been 'combined' into one mesh, but I can easily see that the top boxes bottom sticks out over the bottom obx in the model viewer.

When I was making moveables I thought for sure Doom wouldn't accept it. But it's one of those collision models that I just can't figure out.

There is now way it should work but it does. So maybe if it was 2 materials it would work.

 

I'll go ahead and mess with it casue I'm curious.

 

Oh, you should read jdudes thread about entity limits, I think he's already getting scared of maxing. (course his level is BIG)

[Tels]

I'm not 100% sure how that is done. Do you break the collision model up into sub-meshes? And how do you do that without adding more tris? I remember hearing that you can have unlimited tris in submeshes, it's just the planes that matter, is that true?

 

I suppose a compromise is that we could make the 'air' in between the legs a different surface. That way arrows will stick into the chair everywhere you'd expect. But if they hit between the chair legs, they'll connect with the other surface type and break, so you don't get arrows in the air. Not perfect, but acceptable.

 

Instead of breaking, they could also just go through? (see my posted idea way above

 

I'm still hoping we can do something with attached entities, however. Two per chair is not a big deal. That way chairs could be handled and stacked more realistically.

 

Wouldn't you need 6 (seat+backside+4 legs)?

 

One potential advantage of this method would be that with enough force, throwing chair could break the legs of it.

[Springheel]

Wouldn't you need 6 (seat+backside+4 legs)?

 

I don't think so. Currently the seat and backside are a single mesh. Worst case we have to add a new cm for every leg, but it might be possible to combine the 4 legs into a single cm.

[Tels]

I don't think so. Currently the seat and backside are a single mesh. Worst case we have to add a new cm for every leg, but it might be possible to combine the 4 legs into a single cm.

 

But if I understand a previous post right, the backside and the "bottom" part are two different CM meshes already? Couldn't you then do 5 (or 6) CM meshes each one a box?

[Springheel]

But if I understand a previous post right, the backside and the "bottom" part are two different CM meshes already?

 

They aren't in the chairs I've looked at, but bc may have seen something different--he's looked at more than I have. I don't think there's any benefit to having them be separate cms...in fact, it seems like the more cms, the more instability we risk and the more entities.