Object/Mesh conventions

[OrbWeaver]

It's possible that things like GUIs could use quads, since these are guaranteed to be planar.

[PinkDot]

Doesn't D3 cut it into tris anyway?

I don't know. I'm not an expert but since they're not being rendered maybe it's easier for computing collisions to operate on polygons rather than tris.

[sparhawk]

It's exactly the other way around.

[Crispy]

I shouldn't think it makes much difference algorithmically whether you're testing for collision against a 3-vertex polygon or a planar 4-vertex polygon, but then again I've never written a 3D mesh collision algorithm. (And I hope to never have to do so - 2D is bad enough!)

 

The advantage of using polygons with more sides, of course, is that you end up testing fewer polygons. But on the other hand, you have to consider more vertices per polygon, which I suppose might have an impact. So maybe it cancels out.

 

Either way, I doubt it has any noticeable performance impact for our purposes.

[OrbWeaver]

I have a feeling that collision detection operates by testing against planes, rather than polygons. This would be why the number of vertices in a polygon is not important, but the collision model must be convex.

[Springheel]

but the collision model must be convex.

 

I thought we had discovered that this was a myth?

[OrbWeaver]

I thought we had discovered that this was a myth?

 

I haven't heard that, but it's possible. Perhaps it's just that collision models are often made with brushes, and brushes have to be convex.

[Baddcog]

It is most deffinately a myth. This is my teapot collision model and it works beautifully. Why? I don't know, but it does. It is only 16 polys (tris)

[PinkDot]

Collision mesh doesn't have to be convex but each polygon has to be convex. Actually that's what polygon is - convex flat shape- no matter how many sides (vertices) it has.

 

Baddcoq - you could really go for something closer to teapot shape, if you use actual polygons, not just tris.

[Springheel]

Yeah, I wasn't aware that the collision limit refered to polys of any number of verts. That does open up the possibility of more accurate collision models. We might even be able to get chairs that allow you too shoot through the legs! What was the actual limit again, btw? Is it 16 or 32?

[Baddcog]

I don't know, first that collision model does fit my teapot pretty good and when thrown about it lands and rolls pretty realistically.

Also, since it works I don't have to go in and out of Doom another hundred times trying to get it to work again.

 

I've had really mixed results with collision modes. The best I've gotten to work so far has been a 7 sided cylinder. 8 sided gave me the too many polys error.

I'm pretty much done testing out weird collisions but if anyone else wants to give it a shot I'd like to see what they can get to work.

[Springheel]

It turns out my first test was a little flawed...only one of the two lights was actually hitting all the models. I did the rope test again with a few more lights, and it definitely makes a difference.

 

With 3 lights

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

 

highpoly model on selfshadow:

outside of pov: 30

inside pov: 10

 

highpoly model with lowpoly shadowmesh:

outside of pov: 30

inside pov: 15

 

With 4 lights

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

 

highpoly model on selfshadow:

outside of pov: 20 (this was a little odd--are shadows rendered when they're out of pov?)

inside pov: 6-7

 

highpoly model with lowpoly shadowmesh:

outside of pov: 30

inside pov: 10

 

 

So that would suggest that when more than 1 or 2 lights are involved, the savings from shadowmeshes are well worth the effort.

[Crispy]

I have a feeling that collision detection operates by testing against planes, rather than polygons.

Collision mesh doesn't have to be convex but each polygon has to be convex. Actually that's what polygon is - convex flat shape- no matter how many sides (vertices) it has.

Ah. So the collision mesh itself doesn't need to be convex (in the 3D sense), but each polygon must be convex (in the 2D sense). Actually that makes a lot of sense; the collision algorithm probably involves testing the polygons against something else in a 2D fashion, and there are lots of 2D collision algorithms that assume convex polygons (for simplicity and speed). But If we're just testing every polygon separately from every other polygon, then it doesn't matter how you arrange them - meaning the overall 3D mesh can be concave, convex, or even have holes in it.

[sparhawk]

I shouldn't think it makes much difference algorithmically whether you're testing for collision against a 3-vertex polygon or a planar 4-vertex polygon, but then again I've never written a 3D mesh collision algorithm. (And I hope to never have to do so - 2D is bad enough!)

 

Yes, but the problem is that first, you have to be sure that the 4-vertex polygon is indeed planar. A triangle is ALWAYS planar, because you can not create a triangle, which is connected by straight lines that is not planar. With four vertices this may not be the case.

 

The advantage of using polygons with more sides, of course, is that you end up testing fewer polygons.

 

Well, that depends, on how accurate your test should be. If you create a box with the max vertices, then the collsion may not be very accurate, but easy to do. Depends on the shape of the object.

[Crispy]

Yes, but the problem is that first, you have to be sure that the 4-vertex polygon is indeed planar. A triangle is ALWAYS planar, because you can not create a triangle, which is connected by straight lines that is not planar. With four vertices this may not be the case.

You only need to check this once though, on load, since collision models never change after that. During actual collision computation you can just pick the first three vertices and assume that the others are in the same plane. A sane implementation would use this assumption, and avoid the performance hit of checking planarity every frame. Not that that would be a large performance hit, because it wouldn't.

 

Heck, you don't really need to check at all. It's a very good idea to do so, to ensure consistency, but it's not necessary for the algorithm to function.

 

Well, that depends, on how accurate your test should be. If you create a box with the max vertices, then the collsion may not be very accurate, but easy to do. Depends on the shape of the object.

I meant that "testing with polygons with >3 sides" means you test less polygons than if you take the same mesh (which has non-triangle polygons) and triangulate it.

[Domarius]

That really depends on the 3d program. In 3dsMax a poly can have inumerable tris in it. Some 3d progs count every tri as a poly.

 

I think ALL game engines count a tri as a poly, certianly Doom3 does. So in max I could have 1 poly, in Doom3 it would be 5.

But you can get max to tell you the true poly count (3 point triangle). I think later version have this built in, but earlier versions you can add the "poly select" modifier, then select all, then a number in one of the side panels will tell you the true poly count (can't remember exact details sorry).