12019 collision issues

[safemode]

This has nothing to do with opcode, but rather the code that decides what to do with the data from opcode and when to call opcode.


Apparently, the change in orbiting, while making orbiting noticeably smoother (fighter barracks no longer jerks when up close), seems to have made the handling of the data returned by opcode a little off. It seems that i bounce just before i actually "hit" the surface of a base...and the force (both torque and other) are of a greater magnitude than they should be.



I'll experiment with some edits to unit_collide, but this may be somewhat more annoying than just a simple one liner. Especially if our collision code is unable to cope with the deeper penetration of the actual positions of the mesh as opposed to the displayed positions ...or whatever the hell is happening.

[loki1950]

Bit of a first here a preemptive bug report so anything to add to our own reports to this thread as i imagine stdout and stderr won't have much useful info for you to work with.

Enjoy the Choice

[safemode]

some of the behavior i'm seeing almost seems like a type issue. like, maybe someone used an int with a double calculation.


I changed WarpVelocity during our Collide call in unit_collide with Position....seemed to lessen the effect at lower velocity...but higher velocity causes Crazy torque forces to be applied. The bounce force seems to be ok, it seems only the torque force is overwhelmed.


edit: i keep saying unit_collide, but unit_generic's reacttocollision is where all the fun is.

[safemode]

Arghhh this is pissing me off. I got all the various constants with f suffixes now to make sure we're not screwing something up in a dumb way. Then i'm playing around with removing the torque force altogether, and working on why we dont call the collider when we get very near the mesh at very slow speeds...or at strange angles... And i can't figure out why. It's like there is some kind of granularity that we're getting lost in or some magic value where we dont call the opcode collider's collide function when we should.

It seems like the trick to falling into a mesh is to hit the wall and turn at the same time. It seems like hitting something along the sides of the ship will let you drop into it. Then when you try to correct, you fall further in and since you're trying to fly out of it, your nose hits the inside of the wall and everything works correctly ...just inside out.

Getting out of the mesh is done sort of the same way. You have to exit by falling through sideways or so.

Something is seriously F'd.

[safemode]

ok, I've worked out most of the issues involving falling into meshes i think

but i get things like this that cause the force reacting to the collision to be HUGE

this is what opcode returned

*1 was me, in the stock llama.begin ship
*2 was the fighter barracks.

a1 : 1.30626 5.33281 6.1034
b1 : 0 5.48657 5.33935
c1 : 0 5.58898 6.49239
a2 : -20.493 157.969 242.212
b2 : -79.362 156.146 223.757
c2 : -79.2723 -208.772 223.501


It seems like the triangles returned when this type of massive reaction force is seen are very sliver like. With two points being very close to eachother.

[safemode]

Here's some more interesting data.

Perhaps float doesn't have enough precision here and it's messing up our computing of the normals, since the loss of precision may be confusing coordinates that are very close but not the same.


1 = Llama.begin 2 = fighter_barracks
a1 : 4.55 1.09799 1.73489
b1 : 4.55 1.09799 -3.822
c1 : 4.55 1.09799 -9.37888
a2 : -20.493 157.969 242.212
b2 : -79.362 156.146 223.757
c2 : -79.2723 -208.772 223.501
numhits = 1
1 normal 0 0 0
2 normal -0.346753 0.0615094 0.935937



Massive force after very small velocity collision.

[safemode]

I seem to be stuck.


I dont fall through the mesh and inside it.. But the collision isn't being checked fast enough, so i end up deep in the other mesh, then it's detected and because of elasticity, I'm thrown like a rag doll.

The reason i'm thrown so hard is because the results opcode returns makes no sense to the game, because you should never be that deeply penetrating another mesh.



We need to figure out why we're being allowed to deeply penetrate the mesh before the opcode collider kicks in and says we've hit something.

I dont know if it's this priority thing with orbiting (very likely since i didn't see this issue before), or just something else.

[safemode]

reversing the changes to planet_generic and unit_util_generic results in a much more predictable and appropriate manner.


Though, more work is needed to finally fix "getting stuck" on a mesh and "falling through" a mesh.

at least we dont penetrate and then register a collision....we just penetrate and never register one when we do manage to fall through.


I'm confident now though that the root of the problem is not in OPCODE, but rather in the collision queue and pre and post OPCODE collider code that deals with when to call opcode, and what to do with the results that opcode gives.

[ace123]

I have a feeling things worked that way with the old collider to (at least I remember the turning to get out of a mesh thing).

Possibly the reason you can torque your way through a mesh is because it only looks at velocity of the whole object, but if I am stopped and turning, it might not apply any force/torque back...

[safemode]

i haven't tested it with the current round of commits. But they seem to only effect what goes on outside of the current system. In which case things are still very broken.

It's going to come down to this. This orbital fix is based on priorities. It seems obvious that this priority change is what is breaking the granularity with collisions. So basically we're going to have to undo this to get collisions working.


I'm really starting to wonder why we decided to do this change right before 0.5 is to be released rather than just disable orbiting until after 0.5 is released. Granularity in collisions is infiinitely more important than orbiting.

[jackS]

I have a feeling things worked that way with the old collider to (at least I remember the turning to get out of a mesh thing).

Possibly the reason you can torque your way through a mesh is because it only looks at velocity of the whole object, but if I am stopped and turning, it might not apply any force/torque back...

No, the angular velocity of the colliding polygon is taken into account. As for why you can continue to spin through during a collision - I've actually got a pretty good idea of why that's happening.
While linear thrusting is briefly disabled during a collision, rotation is currently not. Rotation thrust values are, in general, extremely large, and rotational properties are limited by the rotational governor cap, not the potential thrust. When the thrust value is larger than the force applied by the collision, then you can turn into collision.

Some time ago, I experimented with turning off rotational control during collisions, but I vaguely recall there being some unpleasant side effects. I can revisit this, and if there is an easy fix, I'll apply it. Otherwise, it's not worth tinkering with at this time.

i haven't tested it with the current round of commits. But they seem to only effect what goes on outside of the current system. In which case things are still very broken.

Look at 12025 -- 12026 is just for non-current systems, but 12025 is the main fix. Behavior has reverted, for all orbiting objects not moving faster than a configurable cutoff, to exactly what it was before. If you continue looking earlier in the logs, you'll see that orbital velocities in Sol were nerfed by yet another factor of ten, thus meaning that, in the VS data set, there are precious few, if any, orbiting objects that will have the new code applied to them. However, since the behavior is governed by a configurable parameter, it will be easy to continue testing engine interactions with orbital mechanics without having to rewrite a bunch of code each time.

[jackS]

I'm really starting to wonder why we decided to do this change right before 0.5 is to be released rather than just disable orbiting until after 0.5 is released. Granularity in collisions is infiinitely more important than orbiting.

Mostly, we were looking at tracking down some orbit-related multiplayer bugs in a fashion consistent across both single and multiplayer. As mentioned in my above post, we ended up with a configuration in which the changes will likely not be applied, primarily because of the nearness of the release.

[safemode]

I'm very interested in the rotational thrust not being treated like linear during a collision. It'd be great if this whole falling into mesh issue was resolved. Perhaps even more importantly is to get the code in there that takes a look at penetration depth and corrects, then calls opcode again then acts on the collision, so crazy behavior doesn't ensue.

[safemode]

OK, i just want to first say that Collisions are functioning normally again

most of the time.



I still have an issue with the base that's right after the Fighter Barracks. I can't collide with that base at all. I'm wondering if there is a python bug that has me "prepared to dock" with that base and has collisions turned off (as is the default when preparing to dock)... I Can't think of any other reason why that base would not be collideable but everything else is.

[jackS]

Actually, the problem with the relay station was a units.csv problem. Mass was improperly specified. This has now been fixed.

Python doesn't enter into the equation for player collisions. The relaxation of collision detection during docking is only applied to AI craft.

[safemode]

I'm not sure if this is due to my video driver bugging out and causing the frames to go on too long or whatever .... but without the following fix, when i collide with a base, i do not always bounce off correctly

With the fix i do, though at the expense of some cpu. I am pretty sure this was enabled prior to my recent change to the file. So if it's broken on other people's boxes, it's a new breakage.

If other people are still having issues with colliding, i'll commit this change to head and we can see if that fixes it for others as it has for me.

--- src/cmd/collide2/CSopcodecollider.cpp (revision 12075)
+++ src/cmd/collide2/CSopcodecollider.cpp (working copy)
@@ -42,7 +42,7 @@
vertholder = 0;
pairs.IncRef();
TreeCollider.SetFirstContact(true);
- TreeCollider.SetFullBoxBoxTest(false);
+ TreeCollider.SetFullBoxBoxTest(true);
TreeCollider.SetTemporalCoherence(true);
opcMeshInt.SetCallback (&MeshCallback, this);

[safemode]

Well, the issues with the collider were found to be due to temporal coherance being on (after the changes to orbiting things and relay base patches were committed).

I should have read this from the manual.

Code: Select all

OPCODE takes advantage of temporal coherence in two different ways : - for "First Contact" queries - for "All Contacts" queries In "First Contact" queries, clients are only interested in a boolean answer : does X overlap Y, yes or no ? They usually don't care about the exact list of overlapping entities (else theywould have selected "All Contacts"). Temporal coherence in that case is implemented bycaching the one-and-only previously touched primitive. Then, before everything else, the cached primitive is tested for overlap in subsequent frames. If it's still overlapping, we can return immediately without doing the actual query, which saves a lot of time. Else we do a normal query and cache the newly touched primitive (if it exists) for next frames

We had first contact mode on, and it worked properly, but we were checking both cache id's, when we were supposed to assume 1 and only check one of the returned id's.

I'm guessing this is more for constant contact. in any case, it was disabled and things are fixed now.