SBSP Projectile Collision

[XZodia]

So I was doing some experiments altering the sbsp, but nothing I did was able to effect the projectile-sbsp collision. I was only able to change the player collision map.
Does anyone have any insight into how I could change the projectile collision map?

[JacksonCougar]

they would be separate right?

[troymac1ure]

Is the projectile collision possibly one with the visual mesh?
I may have a map to test that theory if I can still find it.

EDIT: Don't have the map I was looking for, but the more I look at the map the more I'm sure it is this way. You could try altering a visual mesh point a bit and see if it effects the projectile collision. The map I was thinking of I lifted one of coagulation's bases off the ground 20' or so and tilted it a few degrees. If your viewport left the original base's location the floating base would disappear. I wanted to see where grenades & bullets would bounce off of.

[troymac1ure]

So I edited the SPShared map and changed the roof plane from -5 to -3 and sure enough bullet collision stopped at just over half-way up the height of the wall.
So the projectile collision is contained within Collision BSP (offset 36) reflexive in the planes (offset 8) reflexive.

Planes are for projectile collision

* Also, not sure if from a previous edit of this map, but if I took the banshee above the -3 mark, Guardians killed me.
* Increasing to -25 allowed me to fly quite high in the banshee (I had also increased the collision model, Offset:36/56, to 25 as well) before being killed. I also noticed I had set the vehicle height to 0, so maybe that's why it didn't stop?

[troymac1ure]

Thinking about all this makes me believe it would be quite easy to create a base map with a large square playing area, basing it off the SPShared map.
Should be able to export the visual mesh, enlarge it, and inject it over a base map. Then, Transfer the collision data and modify it accordingly and finally copy the MOPP data across. Since there is only 8 vertices, it shouldn't be very difficult. Then you could add scenery or machines as needed.
Just a thought I had anyways, but it has been so long that I'm sure I'm forgetting some major parts.

[XZodia]

Interesting stuff troy, strange though because I thought I nulled the planes reflexive, to no effect....
I'll need to look at it some more.

[XZodia]

I can confirm there use for projectile collision.
Further analysis has shown that the planes appear to also appear to be used for occlusion culling in some fashion...
They also effect player collision...
They are also a giant pain to edit...

[XZodia]

The top bit in a Plane Index appears to have some special meaning, could be to reverse the normal?

[JacksonCougar]

No, its probably a short-circuit to another reflexive

[neodos]

I remember editing the coagulation collision mesh, I don't remember in which part of the BSP it was, but it definetly was a regular mesh with vertex definitions.

Though I can't remember why I didn't end up doing something with it, maybe it was because if you modified the collision mesh, like moving it too far from its original position then then those edited verts the faces would loose collision, I think it might have normals that need to be recalculated, or some optimization list like the mopp code.

Hence maybe the mopp thing had to be recalculated with havok, though I think that was for the physical collision and no the visual, not sure.

[troymac1ure]

So I was partially able to move the projectile collision around and have it work. I need to play with it more to get angles going (my math is long lost). Anyways, it seems that the projectile collision does not stop the player, however, if the player leaves the "closed" collision area, boom! "Killed by the guardians".

So if a map was made with all horizontal & vertical surfaces (to avoid calculating plane angles) and created as a closed environment, it may be possible to use it for projectile collision ATM. From what I remember, visual mesh could be injected (without lightmap however) as well. Anyways, the main thing is that it all needs to be enclosed I believe.

EDIT: Now I'm not sure again if the projectile collision was actually working as expected. Oh well... something to look into for another night.

[XZodia]

The planes and vertices need to match, or they end up fighting each other. (which results in a variety of effects including constant bouncing and death)

[JacksonCougar]

The collision is in a bsp structure guys. That will have paths that need to be recalculated for the collision to work properly. And I am guessing you die when you leave the convex shape because of a short circuit in the bsp tree

[XZodia]

I am aware of that, and I'm fairly sure troy is to.
The edits and observations that we are making take that into account.

[troymac1ure]

I wasn't surprised by lack of player collision, just the fact that flying past the projectile wall in a banshee killed me. I expected to fall through the floor though. That's where it seems like the BSP (projectile) collision is used as a boundry point for the guardian kills.

[JacksonCougar]

Yes, but changing the verts basically invalidates the tree

[XZodia]

Not completely.
The tree is just an optimised search algorithm. You can move them a small amount before they will become invalid, and in the case of the shared bsp, I think its so simple that you should be able to expand the box with no issues.

[troymac1ure]

I think I need to lay everything out side by side for the box and have another look.
If others are interested, here's some compiled information:
The Points, Edges, Faces and i,j,k directions


An excel file containing the above information all in one place, although I think the height vales may have been modified in this version.

sbsp-collision data.csv

The BSP collision Data (possibly slightly modified)

(740 Bytes) Downloaded 454 times

[troymac1ure]

Does anyone know what the values are for the planes (i,j,k,d)?

The best I can figure is they are ASin() values. This seems to hold true as long as one of the i,j,k values is (close to) 0. Then the two calculated angles add to 90 degrees. Planes that appear to be at 45 degrees have two values of approx 0.707 which yields 45 degrees.

When there are three values however, the total angles no longer add up to any constant angle. I have an angle that appears to be 45 degrees in the x,y,z axis, but the values are 0.577 which gives a result of 35.26 degrees each.

Maybe this is a simple answer for some, but I never did pass calculus and all other Math was many years ago now.
I'd just like to know how to calculate our own planes from given points.

This is data I compiled for the tower above the sniper rifle on lockout (except for plane 50 which is on the front edge of the opposite tower where the ledge corner has been "broken off")

LockoutPlaneData.JPG

Compiled Lockout Plane Data

(180.56 KiB) Not downloaded yet

* The titles give the plane # and possibly description
* Columns B,D,F,H,J,L give the i,j,k,d values as listed
* Columns C,E,G,I,K,M give the i,j,k values converted to degrees and the total angle sum

[JacksonCougar]

it should be a vector3 and a length along that vector on which the plane lies?

Mobile:

Here's the real layout: https://github.com/jacksoncougar/Moonfx ... nerated.cs



Going off and of memory the bsp tree works like this: the graph is roughly a tree with a root node, and every node has two children (left/right, or forward/back, I forget which one). Each node has an index to a plane. The bsp code tests which side of a plane that a ray lies on and chooses the left/right child node based on this. Sometimes the left/right nodes will be null which means the ray lies outside of the collision shape defined by the bsp structure. Sometimes the left/right index will be a leaf (it might be an msb flag on the value that indicates this). Leaf nodes will reference the 2d nodes and work basically the same as 3d nodes. They reference a plane and two nodes, one each for left/right children. The 2d nodes are all defined in the space of the 3d node's plane that referenced it. So the planes are perpendicular to the calling parent 3d nodes plane. I sort of forget how it finishes reading the tree

Edges shouldn't be used, nor vertices. They are for debug/leftover