Collision Model issues

[Baddcog]

OK, I just split those two boxes apart in the armchair and gave one collision box wood and one metal.

 

in game they both sounded like metal and broke arrows. So I swapped them, now they are both wood and accept arrows.

 

Good news is that collision models can be 2 boxes, I have no idea why. For moveables.

 

But, Doom only reads the first collsion material and apllies it to all collision surfaces anyway. So it looks like moveables can only have one collision type.

 

 

So I double checked. As a static entity it does indeed behave as metal and wood. Just not as a moveable.

-----------

 

@Tels, I saw you idea above, but using triangles below to cancel collision is very unlikely. collision models have to be very simple and the fact that 2 boxes are working suprises the hell out of me.

 

I have also tried the 6 box collision model thing (one for each leg, back and seat, just last week. It doesn't work)

 

-----------

I have one idea I will try now. basically a box for the back, maybe a Lshape will work for the top with a cube at bottom for base of feet,

of course then things could pass thru chair legs which could be odd.

[Baddcog]

No luck. I change the shape of those collision boxes quite a few times and kept increasing the names of them, saving as same file name.

 

The weird thing is if I left Doom running and used reloadmodels it reloaded the newer complex models and it seemed like I was getting somewhere. To the point where I had 6 collision models and it seemed like at least up to 3 were working, then it became hard to tell what was really going on.

 

But as soon as I shut Doom down and restarted the map wouldn't load because of the collision model.

 

I think we are lucky to be able to use 2.

[Crispy]

I remember hearing that you can have unlimited tris in submeshes, it's just the planes that matter, is that true?

I think you misinterpreted. The point of that little discussion was that the polygon limit in collision meshes is counted in terms of N-sided polygons, not triangles.

 

The practical benefit of this is that if you have two coplanar triangles which share an edge, you can merge them into a single non-triangular polygon to get the same effect. This saves a polygon.

 

The caveat is that all the polygons must be convex, i.e. must not have internal angles greater than 180 degrees.

[Ishtvan]

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.

 

Ah, sorry, I didn't know there was a texture called tudor. I thought you were referring to tudor architecture and my only logical conclusion was that it was sarcasm. We could always make that texture accept arrows if needed, but I think it's a separate issue.

[OrbWeaver]

The caveat is that all the polygons must be convex, i.e. must not have internal angles greater than 180 degrees.

 

Do we know that for sure, or was it still speculation?

 

It seems strange to me that the polygons (I suppose they are technically "windings") would need to be convex but the volume can be concave -- I would have thought that requiring a convex volume would simplify the collision detection, although my maths isn't that great.

 

It also means that you could only have an L shape if the sides of the L were split into multiple polygons, so that they would be convex, rather than a single concave N-gon.

[Springheel]

I think you misinterpreted. The point of that little discussion was that the polygon limit in collision meshes is counted in terms of N-sided polygons, not triangles.

 

Ok...doesn't that translate into pretty much the same thing? If you take a basic cube, D3 wouldn't care if one side was a single poly or 12 tris?

[Baddcog]

Ah, sorry, I didn't know there was a texture called tudor. I thought you were referring to tudor architecture and my only logical conclusion was that it was sarcasm. We could always make that texture accept arrows if needed, but I think it's a separate issue.

 

Well, I don't think the name is 'tudor' but there are tudor style textures, plus PinkDot was working on more.

It is very similar though. The tudor is a plaster with wood beams in it. There is no way I know of to make the arrow stick to ONLY the wood parts. That's the problem. One would assume that an arrow wouldn't stick to the hard sun baked plaster part.

So what do we do, we let arrows stick to air because the player would be puzzled why they can't shoot a chair? Then along that same line of thought we should let arrows stick to the plaster surface of the tudor so they don't wonder why they can't stick an arrow in the wood of that same wall.

 

But if we make that texture allow arrows cause it has little wood strips it's gonna look like hell when the arrow sticks to plaster, plus it'll make it hard on designers 'cause they can only use tudor in low spots or places where they wnat the player to go.

Alot of old buildings had a stone base and tudor floors above that. T2 didn't allow arrows to stick to tudor for the same reason.

 

My point being that players won't take long to figure out that an arrow doesn't stick there and they'll forget about it and move on.

 

If someone wanted a special chair in a certian spot for player to rope arrow up they could change the skin to use the regular wood collision surface. But I think in most instances players won't even want to or care about arrows sticking in chairs, thus why put in an immersion breaking feature on all chairs so that arrows will stick into the air.

It was quite common in T2 to put something inthe read-me like (you may have the ability to climb...) to clue a player into the fact that something might be out of the ordinary with some chairs in their mission.

--------

It has still not been determined that polys themselves have to be convex. again, I have brought this up at least 10 times.

My teapot works. The polys are NOT triangulated and at least 4 of them are concave. Also, theis means that the mesh itself has at least 4 concave parts. It does not mean that Doom will always accept a concave mesh either.

It means we really have no idea what the limits are.

 

We can also not have a cube with 12 tris on one side because Doom will spit an error about too many verts.

 

Things that doom spits errors over

 

too many polys

too many verts

too many sharp edges...

[Springheel]

I just ran into another error with a cm..."dangling edges". Anyone know what that even means?

[Baddcog]

Problems with the angle of the dangle eh Spring?

 

Um, not I.

[Springheel]

The weird thing is that it's a very basic shape:

 

 

I have no idea what 'dangling edges' means, or why it won't load something so simple.

[Crispy]

Do we know that for sure, or was it still speculation?

On second thoughts I think you're right, it was just speculation.

 

Ok...doesn't that translate into pretty much the same thing? If you take a basic cube, D3 wouldn't care if one side was a single poly or 12 tris?

No, it would care. (That's the theory/speculation at least.)

 

12 tris = 12 N-sided polygons

a single poly = 1 M-sided polygon

[Baddcog]

so is that just basicaly 4 tris? three sides and one up top? Or is it 4 sided with 2 up top?

[OrbWeaver]

I presume that a "dangling edge" is an edge which is not part of a face, e.g. an edge which goes out to a vertex in the middle of nowhere. I would check that model carefully to make sure you don't have any duplicate edges or vertices that might be hidden by the normal edges.

[Springheel]

No, it would care. (That's the theory/speculation at least.)

 

12 tris = 12 N-sided polygons

a single poly = 1 M-sided polygon

 

Oh wait...are you saying that D3 doesn't care how many points a poly has, and/or whether two polys are on the same plane? A poly is a poly and that's it? So it would definitely be in our best interest to merge any polys that can be merged on cms.

[Baddcog]

Things that doom spits errors over

 

too many polys

too many verts

too many sharp edges...

[Springheel]

(still don't understand the above, but moving on...)

 

Ok, I got the collision model working, and I have successfully bound one moveable to another. The problem? They don't move. Both moveables highlight separately, and my weapons drop when I frob either part like I'm entering grabber mode. But I can't seem to move the object at all (occasionally I get a collision sound, but that's it). Kicking and firing arrows at it doesn't move it either.

 

Obviously I'm missing something...any ideas?

[Ishtvan]

There's only one bind right, one is bound to the other? Otherwise if A is bound to B and B is bound to A, it may get weird.

 

Other than that, does the entitydef use a reasonable mass?

 

If you shoot a broadhead into a crate, you have the same situation, one moveable bound to the other, and that seems to work (although like I said, there is some jerkiness when the bound object collides with the ground and the bindmaster doesn't).

 

Is this a collision model that's pushing the limits, like one that's concave in some way? You might want to try it first with two moveables that we know work separately, just to rule out some possibilities.

[Springheel]

Is this a collision model that's pushing the limits, like one that's concave in some way? You might want to try it first with two moveables that we know work separately, just to rule out some possibilities.

 

I did. I tested the chair and the leg separately, and they work fine. I used the following line:

 

"def_attach" "atdm:moveable_chair_prop_chairlegs"

 

to attach the leg to the chair. It's just one way; the leg has no def_attach line.

[Crispy]

Oh wait...are you saying that D3 doesn't care how many points a poly has

For the purposes of collision models, yes.

 

and/or whether two polys are on the same plane?

AFAIK it doesn't distinguish between two polys that are on the same plane and two polys that are not on the same plane. i.e. There's no special processing to optimise this case, unlike what the map compiler sometimes does to adjacent brushes.

 

So that's correct, it doesn't care whether or not two polys are on the same plane.

 

A poly is a poly and that's it? So it would definitely be in our best interest to merge any polys that can be merged on cms.

Correct.

 

^--- Again, please note that this entire post is mostly speculation.

[Ishtvan]

I did. I tested the chair and the leg separately, and they work fine. I used the following line:

 

"def_attach" "atdm:moveable_chair_prop_chairlegs"

 

to attach the leg to the chair. It's just one way; the leg has no def_attach line.

Okay, are you sure the chair + leg combo is far enough above the ground even when the legs are spawned so it doesn't clip in? Sometimes things can clip into the ground and act weird, not sure what it would do if something bound to it started out clipping. You might want to use the "bind" method just to rule out any weirdness with spawning the second item later.

[Springheel]

I considered clipping, but even when I put the chair up into the air, it still doesn't move (doesn't even fall when you hit it with an arrow).

 

You might want to use the "bind" method just to rule out any weirdness with spawning the second item later.

 

How do I do it using 'bind'?

[Springheel]

Well, after some experimenting, I'm not much further ahead. I started with the cm on the left. It had too many edges if I tripled it and too many polys if I did not. The middle one, at 18 polys, was still too many. The last one (of questionably usefulness) actually worked.

 

 

 

But in game, it seemed kind of unstable. It got stuck on things it shouldn't have, and when I threw it at a wall, it seemed to just hang there.

 

 

So, it would seem that getting a chair shape out of single cm is not doable. I still have to figure out what the problem is with the attached version to see if that could work.

 

Oh, my tests seemed to give pretty strong evidence that D3 does not like cms that are not made of tris.

[Baddcog]

I tried that same shape a week or two ago. I think the pointy legs really mess with the collision.

 

I also tried an L shape with a cube at the base of the legs. It actually worked pretty good, but if the chair was tipped over you could stick an aroow in the bottom cube. It was hit or miss whether I hit the bottom cube with an arrow. So sometimes it was good, other times it was no better.

[Ishtvan]

How do I do it using 'bind'?

Place the two objects in the editor (chair and chair_legs). Go to the entity inspector on chair_legs and add the key "bind" with the value set to the name of the chair you want to bind to. E.g., "bind" "chair_1" Then you should be done.

[New Horizon]

Any potential value in the collision model code that was released with the Prey SDK back in October of 06? Might it help us work around some of these issues?

 

http://files.filefront.com/prey+sdk+200610...;/fileinfo.html