Changing the RenderFilterSettings.Layer at runtime does not take effect

[silent orbit]

Modifying the Layer of an entity while at runtime does not seem to take effect. Is there something else I need to do to tell the engine to update the layers when changed at runtime?

[leaden finch]

how are you changing it?

[silent orbit]

in the example, its the renderfilter.Layer that takes an int.

RenderFilterSettings are shared components, so I have to reapply back the same way.

I check using CollisionWorld.CheckBox() and set the filter to 1 << 16 and then previous value 1 << 15. CheckBox() returns true on 15 (previous value) and does not on 16 (new value), which means the layer hasn't changed behind the scenes, eventhough the Inspector shows the value was changed.

[leaden finch]

yeah this looks fine, just wnated to make sure you were actually updating the shared object

it's pretty painful to have to write the shared component to update the layer, we were looking at doing this a few months ago and decided to just handle this in the shader for what we wanted to do instead

so i never actually tested if changing the layer actually worked

looks like we might have dodged a bullet accientally

[leaden finch]

wait hang on, this layer has nothing to do with physics

this is a rendering only layer

[silent orbit]

took me a while to understand what was going on, until I used CheckBox() with different filter settings to see which value CheckBox was seeing when it does the physics check.

[leaden finch]

checkbox does not use this layer at all

[silent orbit]

oh?!

[leaden finch]

PhysicsCollider.Value.Value.GetCollisionFilter()

physics layers are stored in the physics collider

renderlayer is just for rendering

[silent orbit]

so its just a rendering layer value....

[leaden finch]

    /// <summary>   Describes which other objects an object can collide with. </summary>
    [DebuggerDisplay("Group: {GroupIndex} BelongsTo: {BelongsTo} CollidesWith: {CollidesWith}")]
    public struct CollisionFilter : IEquatable<CollisionFilter>
    {
        /// <summary>   A bit mask describing which layers this object belongs to. </summary>
        public uint BelongsTo;

        /// <summary>   A bit mask describing which layers this object can collide with. </summary>
        public uint CollidesWith;

        /// <summary>
        /// An optional override for the bit mask checks. If the value in both objects is equal and
        /// positive, the objects always collide. If the value in both objects is equal and negative, the
        /// objects never collide.
        /// </summary>
        public int GroupIndex;```

this is what controls physics collisions

[silent orbit]

hmm I will look into this. So I need to modify the entity's collisionFilter?

[leaden finch]

yes

https://docs.unity3d.com/Packages/com.unity.physics@1.2/manual/collision-queries.html#filtering

[silent orbit]

this is helpful, let me look into this! much appreciate you sending me in the right direction

[leaden finch]

explanation of how the multiple fields work together

[silent orbit]

hmm, i dont see how I can change the "layer" the collider belongs to. do I assign a new collisionFilter to replace the entity's current filter? apologies, I'm still grasping at this.

is there a way to view the collisionfilter an entity has in the Inspector?

[leaden finch]

so yeah unfortunately, much to my disagreement, the collisionfilter is part of the physics blob

so you must clone the blob and update the layer (or bake an alternate blob and switch between them)

[leaden finch]

yeah it should be visible by default

[silent orbit]

im still using 2022.3.25

[leaden finch]

hmm i haven't looked on 2022.3 but i think it should still work

[silent orbit]

not using beta

[leaden finch]

if you don't clone or replace the blob, it will affect all colliders of the same type

super pain

[leaden finch]

good news, next unity 6 version should be out of beta 🙂

[silent orbit]

this is all I see under Physics Collider under Inspector:

[leaden finch]

are you still on entities 1.0.16?

i think the inspector was added in 1.1

i would suggest updating to 1.2 though, it's full released - no longer in prerelease

[silent orbit]

hmm i see. yes 1.0.16

oh wow! do I manually add Entities 1.2 via package manager?

[leaden finch]

yeah it only appears on unity6 by default in package manager

[silent orbit]

or do i have to use beta 6000 version?

[leaden finch]

supposedly internal paperwork and blahblah

they haven't filed to get visible on the LTS

but it works fine and is fully supported on unity 2022.3

so yeah you'll have to add the version manually through package manager or just probably easier just change version in your manifest

[silent orbit]

im new to all this maneuverings within Unity, I'll have to read up on it

[leaden finch]

Packages/manifest.json

[silent orbit]

ahh

[leaden finch]

"com.unity.entities": "1.2.0",
"com.unity.entities.graphics": "1.2.0",
"com.unity.physics": "1.2.0",

yours will say 1.0.16

just change them to 1.2.0

[silent orbit]

ahh yes it does

[leaden finch]

anyway that'll get you the physics inspector

so you can actually see what the hell is going on

[silent orbit]

are these all of it:
com.unity.entities.graphics
com.unity.physics

[leaden finch]

there is netcode as well if you're using that

[silent orbit]

i have netcode on a different project, so maybe I'll do that there. my playground here is just for this

I only see these two entries that have 1.0.16 version, anything else you suggest I change?

[leaden finch]

unity 6 is so much better for like tiny minor things 😄

but yeah ah no need to update

[silent orbit]

i dont have an entry for com.unity.entities separately, is this ok? or should I add it?

[leaden finch]

nah it's fine

it's automatically being brought into your project through graphics/physics

and it'll be 1.2 because they depend on it

[silent orbit]

opening the project now

i was avoiding 1.2 because I thought I had to be a 6.0 beta

[leaden finch]

yeah LTS, package manager and internal politic things

[silent orbit]

this is what I see now. so it's now just a matter of changing the collisionfilter on Physics Collider at this point?

this confirms what I've tested that the renderlayer is changed to layer 15, but collisionfilter is still 16:

so I tried changing the "belongs to" to another value, and it wouldn't let me change it

do you know if changing this is an acceptable action at runtime?

[leaden finch]

you can change it

but as you wrote above all entities that have the same collider, share the same collider blob

so changing 1 of them will change all of them

you need to clone the collider first to ensure you only affect the 1 entity

[silent orbit]

yea for some reason, I can't change the value through the inspector. im trying to figure out how to change this in code as we speak

hmm, the physics collider doesnt seem to be a shared component.. is this how you understand it as well?

[silent orbit]

@leaden finch so I thought if I do GetComponentData<PhysicsCollider>(e) into a var, I effectively cloned it?

[leaden finch]

no

there's literally a method on physicscollider called .Clone

PhysicsCollider.Value.Value.Clone()

        /// <summary>
        /// This function clones the Collider and wraps it in a BlobAssetReference. The caller is
        /// responsible for appropriately calling `Dispose` on the result.
        /// Returned collider is guaranteed to be <see cref="Collider.IsUnique">unique</see>.
        /// </summary>
        ///
        /// <returns>   A clone of the Collider wrapped in a BlobAssetReference. </returns>
        public BlobAssetReference<Collider> Clone()```

alternatively it's a lot easier fi you know ahead of time that you're going to be having to do this

[silent orbit]

this threw me off since the GetComponentData returns the "value".

[leaden finch]

to instead just mark your collider as unique during baking

so you don't have to deal with cloning/managing it

[silent orbit]

i see!!!!

dunno, just seems soo kludgy to me... thanks for this.

[leaden finch]

💯

there was talks to move the filter out of the blob which i was very supportive of

but they decided not to do it for some reason

personally i'm waiting for 1.3 and i'll probably just fork and move it out of the blob myself because to me it's MUCH MUCH nicer

[silent orbit]

yea it would feel cleaner and clearer

the whole xx.value.value.yy is already messy

The .clone() returns a BlobAssetReference, which I then get the collisionFilter from, change it, but how do I reassing the blobasset as a new PhysicsCollider?

[leaden finch]

new PhysicsCollider {Value = newphysCollider}

https://github.com/Unity-Technologies/EntityComponentSystemSamples/tree/master/PhysicsSamples/Assets/9. Modify/Collider Filter

i would suggest looking at this sample

it will show proper setup of changing the filter

[silent orbit]

thanks for this!!

yea, there's much I have not looked at in here

[leaden finch]

yeah there's a pretty comprehensive sample suite now

[silent orbit]

I have to look at this whole physicsSample repo. there's lots here.

I've largely been fumbling through all this by loking at code alone

the process of marking a physicsCollider "unique", can I do it in the gameobject prefab via the inspector, or it has to be done completely through the baker Bake(authoring) ?

[leaden finch]

i think it can only be done through teh physicshape authoring atm

not hte built in boxcollider stuff

but i still use physics shape because its so much better

(accessed via adding samples in package manager)

[silent orbit]

oh then I can't do it since I'm using the builtin's

[leaden finch]

yeah the physicsshape stuff has a lot more settings and configs

i think you'll have to write your own custom bakers to work around this if you dont want to use it

[silent orbit]

well for what Im playing around with, clone the blob and replacing the physics collider is fine.

you have no idea how many days I poured over this, you helped me a lot, mate. thank you.