[SOLVED] ConvertToEntity PhysicsShape.BelongsTo always sets first bit?

I have a PhsyicsShape on a prefab which has ConvertToEntity with the following selected for BelongsTo

6492020--729953--upload_2020-11-5_0-55-38.png

When trying to use a collision filter, in a raycast, the hit result of that object always has first bit set (irrespective of selection, making entry 0 useless?)

var raycastInput = new RaycastInput
{
    Start = mouseRay.origin,
    End =  mouseRay.GetPoint(_farClipPlane),
    Filter = new CollisionFilter
    {
        CollidesWith = 1u << 0,
        BelongsTo =    1u << 0,
    }
};

physicsWorld.CastRay(raycastInput, out var hit);

The above gets set as 5 (0b00101) rather than what I would expect which is 4 (0b0100).

Checking/Unchecking entry 0, looks like it makes no difference to the filter, no matter what bit 0 is always set.

Not sure if this is expected behaviour and I just couldn’t find it anywhere in the docs? (I am new to Unity)

I am using Unity 2020.1.11f1 and Unity Physics 0.5.1-preview.2

Did some more testing and in the following Categories

6492055--729967--upload_2020-11-5_1-18-18.png
0: = 0b0001
1: = 0b0011
2: = 0b0101
3: = 0b1001

In another place I have a IConvertGameObjectToEntity which seems to be set correctly, 1,2,4,8 etc.

public class PhysicsTerrainAuthoring : MonoBehaviour, IConvertGameObjectToEntity
{
    [SerializeField] PhysicsCategoryTags belongsTo;
}

This is really strange, especially since you have another place where things work fine. Do the default physics categories work fine for you (PhysicsCategoryNames)? Like the ones you would see by default in the samples project.

Edit: to answer your question, it’s normal to have values 1, 2, 4, 8, … so it’s definitely an issue if you have 0 always set.

It works when I set it using a custom field, but doesn’t work when I set it on the “PhysicsShape”.

This is broken (Set to 0b11 which is 3 in decimal):
6497962--731281--upload_2020-11-6_19-13-59.png

But this works (Set to 0b1000 which is 8 in decimal)

6497962--731284--upload_2020-11-6_19-14-21.png

That script is simply has

[SerializeField] PhysicsCategoryTags belongsTo;
[SerializeField] PhysicsCategoryTags collidesWith;
[SerializeField] int groupIndex;

Just made a sample project with a cube and will attach.

I am guessing there is a bug in the Conversion workflow for PhysicsShape

You will see the Cube has set 2, but in Console you will see Collider Filter has 3.

6497980–731299–Dots-Phsyics-BelongsWithTest.7z (65.7 KB)

I can also see the editor saves it correctly into the files at least:

6497989--731308--upload_2020-11-6_19-24-3.png

I’ll take a look and get back to you. Thanks for the repro!

The problem seems to be due to the fact that the Cube has both a legacy BoxCollider and a PhysicsShape component.

This means for your Cube body, you are actually creating a CompoundCollider with 2 BoxColliders as children - one from the legacy BoxCollider and setting the CollisionFilter.BelongsTo based on the gameObject.layer, and the second from the PhysicsShape component with your own settings that you are expecting.

At the top level the CompoundCollider combines the CollisionFilters of all the children into a single Filter for the compound, which is why you are seeing the first bit set (from the gameObject.layer) and the other bits from the BelongsToCatergories.

Ditch the BoxCollider and things are fine.

2 Likes

Sorry, wasn’t aware of that! Thanks!

Just ran into this and spent a few hours debugging it. Would be nice if there was some kind of warning message in the physics shape inspector letting you know that you’re basically doubling up your collider and messing up your filters by having the legacy collider on there too

1 Like

Thanks for the suggestion, we’ll definitely consider it.

Adding multiple colliders to one Body is a valid use-case though. If you get any of the children from the compound collider, they will have the expected filters on any single one of them. The problem is that the filter at the root is a combination of all the child filters. A warning could mention the mixing of legacy and dots colliders but it isn’t actually a problem.