Opcode collider errata.

[safemode]

since the collider doesn't create a damage vector or have anything to do with dealing damage, I'm convinced this is a problem with our equations taking into account something that was collider specific and dependent on the behavior of the rapid collider.

Exploding on collision is not a collider problem. The collision is detected, you dont end up inside the mesh, there is something buggy about our physics code dealing with the results of a collision.

the only way the collider could be to blame directly is if i'm setting the collision pair vectors wrong.
Perhaps my collision pair vectors are wrong.

[ace123]

The ./configure line was flipped since we changed it by default to disable.
(--enable-opcode disabled it, and --disable-opcode enabled it, but the default left it enabled)

To anyone reporting bugs and used the --enable- or --disable-opcode options, make sure if you have run ./bootstrap-sh after updating to revision 11842

With the opcode collider disabled, I am able to fly all the way through fighter bays in the "fighter barracks". I also do not receive insane amounts of damage (I see my shield, and I eventually die, but for the most part I bounce in the right direction).

Using the new collider I die instantly if I touch the fighter barracks. I can reproduce this every time. On the Mac, I once managed to lose only about 95% of my health in one hit but survived.

Edit: I don't know how damage gets calculated but I would be interested in debugging it.
I'm still stuck on the part where "thisforce" is different than "smforce"... I would think both forces would be equal in magnitude, no?

[safemode]

line 311 of unit_collide.cpp and below that line is where things get possibly altered collider to collider.

I'm not sure what numhits is supposed to represent. I assumed it was the size of the collisionPairs.


I wonder if the radius is different as reported by the opcode collider from the rapid collider.

I dont have time to test that theory tonight, but it would explain a lot of things, since the radius seems to be used a lot in determining the magnitude of force vectors after a collision.

[ace123]

Turns out that the computed Normal for the fighter barracks is always <0,0,0>.

(gdb) print mycollide[0]
$56 = {
a1 = {x = -22.5822792, y = -3.68200016, z = -9.61828041},
b1 = {x = 113.005737, y = -90.500206, z = 183.851685},
c1 = {x = 45.2117271, y = -47.0911026, z = 87.1167068},
a2 = {x = 764.76001, y = -179.169907, z = 1157.46899},
b2 = {x = 698.948975, y = -134.417999, z = 1063.56299},
c2 = {x = 696.966003, y = -135.760803, z = 1060.73401}}
EDIT: removed subtraction; GDB has bogus vector subtraction

The line 325 in unit_collide.cpp has:

Code: Select all

	  sn.Cross (mycollide[0].b1-mycollide[0].a1,mycollide[0].c1-mycollide[0].a1);

which results in the vector <0,0,0>

I still have no clue why it *always* gets 0,0,0 on the fighter barracks.

I think the reason I always die on the fighter barracks is because it is much more massive (400 gigagrams), and the entire collision becomes inelastic when the normal is the invalid 0 vector.

I am going to test if the normal is indeed 0 in other places too.
EDIT: Indeed it happens with the Relay, and this time I got both bn and sn to be the 0 vector:

(gdb) print mycollide[0]
$61 = {
a1 = {x = -5.48137808, y = -1.00708997, z = 14.3928394},
b1 = {x = -5.48137808, y = -1.94628, z = 10.8665895},
c1 = {x = -5.48137808, y = -1.00708997, z = 14.3928394},
a2 = {x = 379.748383, y = 371.284424, z = -32.9056396},
b2 = {x = 314.173096, y = 392.863007, z = -34.3534927},
c2 = {x = 379.748383, y = 371.284424, z = -32.9056396}}

[jackS]

I've gotten at least one instance (in 11837) where the normal for the smaller craft was given as <0,0,0>, so it looks like there are cases where zero magnitude normals are being returned for either of the two input normals to the collision resolution function... which will do very odd things.

also (on a less important note),

I'm still stuck on the part where "thisforce" is different than "smforce"... I would think both forces would be equal in magnitude, no?

(Informational, but slightly off-topic aside for those who're interested: The different computation (rather than one just being the other *=-1) is to address potential cross-scheduling-frame collisions. Thus, each is computed using the sim_atom_multiplier from the timeslice appropriate for that object. In practice, things one is colliding will be at the same scheduling frequency. )

[ace123]

Examining the data more closely, and now unencumbered by GDB's random number generator (subtracting two vectors), I see that two of the vectors are the same in many of the triangles that the collider retursn.

I usually see a1 == c1, thus c1-a1 returns the 0 vector, and the cross product with 0 returns 0.

If the triangles are in the wrong format that would explain why there are two points in the same triangle that have the same value.

[charlieg]

In the development thread on opcode, you'll want to read safemode's latest post explaining why yours is acting strangely - something to do with non-Linux compiles being done differently due to defines / header files.

[safemode]

bsp_polygon gives me a triangle, + additional vertices that each represent the third vertex of an additional triangle (the other two vertices are the last two vertexes in the bsp_polygon).

So what i do is flatten that all out without re-using vertices at all. I copy the vertices that use the previous two. So if the bsp_polygon looks like this.

1 2 3 4 5 6 7 8

my vertexholder will look like this, where each number is a copy (not a pointer)
index 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Point value 1 2 3 2 3 4 3 4 5 4 5 6 5 6 7 6 7 8

Every 3 points should make a triangle as described in the bsp_polygon.

The indexholder, since everything is copied out, just holds the number for the current position i'm making a vertexholder equal to a point. So if indexholder has a size of 18 it will look like this

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Then when we want to retrieve a certain triangle it's done like this

vertxholder[indexholder[triangle*3]]

if we asked for triangle 3, indexholder would return the number at the 3* 3 position, which is the 9'th position and since we've flattened out the vertexholder, the 9th position of the indexholder is 9.


UPDATE 2:

we really dont need indexholder right now, because we copy out the vertices in the vertexholder, rather than use indexholder to save us from copying.

For sanity sake, we can not use indexholder and just use the array index directly on vertexholder.

[ace123]

In the development thread on opcode, you'll want to read safemode's latest post explaining why yours is acting strangely - something to do with non-Linux compiles being done differently due to defines / header files.

This happens for 32-bit windows, 64-bit linux and 32-bit mac... I am confused why other people *aren't* seeing what I am seeing.

Though if you were using --enable-opcode before I made that change I can see why not because you would have been using the old collider

perhaps there is some assembly code which quite possibly is different on each compiler, but I have some suspicion it is due to the format of the input, though I tried to debug through it and I haven't figured out where yet.

[safemode]

I'll be committing some changes tonight that will maybe help things.

So far we know that for whatever reason the triangles are getting F'd up. They are offset by 1 on the vertholder, how we dont know.

Before we worry about in-game observations, we have to tackle why this is occuring. then the rest should fall into place.

[Coragem]

Ace Said:

Touching any point of the fighter barracks will cause me to instantly die, however I can dock in the bays without any problem if I am extremely careful about where I am (using the pan camera)

This happens for 32-bit windows, 64-bit Linux and 32-bit mac... I am confused why other people *aren't* seeing what I am seeing.

I'm seeing what you are seeing , see report bellow.

1. svn rev #11843
2. successful collisions (with what and reaction observed)
i very slowly collided using the external view with those arms inside the docking bay on fighter barracks the collision happened just as the tip of my Sickle wing touched the arms, so visually it happened precisely where it should.
3. unsuccessful collisions (with what and what happened)
i was trying to dock with and Ox, and i went too fast. and hit the front of the ship, i managed to get Half my Sickle wing inside the Ox. (Got a nice screenshot I'll edit this post later), this is the second time i managed to do this, I still have to test with the old rapid collier see if i can get stuck into other ships as easy as i can now.
4. if segfault give back trace if possible (run with gdb (do not install bin))
Again not a single one.
5. any other weirdness related to collisions observed.
I blew up when i touched the fighter barracks, and was going really slow < 50m/s

Safemode:

Before we worry about in-game observations, we have to tackle why this is occuring. then the rest should fall into place.

I understand, ill keep reporting what i see in game (thats what i can do right now), so you can know if what you are trying to fix is working as you wanted to.

[safemode]

During tests, make sure you describe the exact place if/when you are able to penetrate into a mesh.

In my various permutations of the opcode settings, i've notices a visual anomaly in the fighter barracks when you speed towards it from atlantis launch position, right between the middle pillar and the first left bulge (side pillar) attached to it. When you get extremely close you can see the border between the two redraw. At this position i was able to fly straight into the mesh, but would hit against the wrong side of the bases walls. Just to clarify, this was using a different group of settings from SVN, but I just wanted to explain the reason for describing the exact position (or screenshot).

If we can determine that the issues with the collider (if any arrise) come from a specific situation we can better debug it. Try fast speds and slow speeds (more than 200kps and less than 50)

PS: I'm going to commit a "faster" group of settings as soon as I find the ones that minimize (eliminate) mesh penetrations.

EDIT:
by the way, I believe i fixed the issue of why our triangles were messed up a few revs ago. So test the latest svn and see how it goes. You shouldn't explode on contact anymore. What you may see happen is falling into a mesh, especially at internal corners (point facing away), and possibly inside docking bays. Also another thing to look out for is getting stuck to a unit. This may happen when travelling at very slow speeds at a shallow angle when colliding. Usually bringing your ship back to the original position of collision and cutting engines bounces you back away.
This may not be seen in the current svn. Test away