I am pretty sure it says “non-uniform scale”
so this breaks things - for example the CharacterWalker sample is broken due to non uniform mesh collider
[Blocker] We are seeing the same here. There’s a warning for using non-uniform colliders for 50-100 game objects in our game. We are trying to submit before launch.
What’s the best fix?
Can we make new parents that are uniform? And attach non-uniform colliders?
Make children with colliders that are not uniform?
Or do all colliders have to be cubes and square quads?
The Exclusive AR, Shared AR profile(s) does not support Collider Offsets on a GameObject with non-uniform scale.
Completely showstopper.
Unity: please QA releases with your own official PolySpatial Samples!
This is unfortunately not a bug.
The PolySpatial CharacterWalker having a validation error is a bug, need to fix that.
But, these validation rules reflect the constraints of colliders on RealityKit and were put in place to correct other issues people were reporting about interactions not working, or physics not working due their colliders in RK not reflecting actual placement in Unity.
The way transform orientation, scaling, offset and size affect RK colliders is different than Unity colliders. The same values put on each ends up with RK colliders in a different location and size unless certain constraints are followed.
So this solution is to force colliders into the constraints of what RK wants so that they always match unity.
It’s an unfortunate situation that Unity lets you place colliders any which way, while RK is more picky, and so projects will probably require some fiddling with colliders to get them correct. I also worry an automated convertor script could wreak havoc on some projects, it’d have to step through transform hierarchies undoing, or trying to counter, non-uniform scale and changing parents.
I am looking at these rules now and doing some tests to see if some of them can be relaxed, or if it’s error can be pushed to more specific circumstances during runtime checks. But it’s still not going to be a fully automated solution, you’d have to watch runtime logs and do some collider hunting if you do something which causes one to go out of sync.
It’s an odd balance in the UX. What’s harder to deal with? A bunch of errors up front that point exactly to the issue? Or a bunch of error logs in a runtime console that will require some debugging?
If you are making new content it’s best to follow these validation rules.
But yes I agree it could be a nuisance for converting existing content. I suspect some of these rules could be made less strict and a few runtime errors added to catch more specific issues, but unfortunately this can’t be a perfect 1:1 automated solution in all scenarios with how RK colliders work. But I’ll see what I can do.
I’d note, you can disable this in the PolySpatialSettings under ‘PolySpatial Project Validation’ but then there is a whole number of scenarios where colliders may not reflect unity. So be aware of that.
please provide some sort of converter or postprocess build script to fix this
After digging into this some more, I found that the collision shape debug data which the VisionOS simulator provides is completely incorrect. Don’t trust the collision shape debug data nor collision shape visualization in the VisionOS simulator. I’ve submitted an issue to Apple about this.
Fortunately this means these rules can be relaxed because some of them were dealing with erroneous output from Apple’s API that is not actually an issue. Even if the VisionOS Simulator debug info shows your collisions shapes to be in wrong position, they might actually be in the right position if you raycast for them. Hopefully this will get fixed in the visionos simulator soon.
The change for relaxing these rules on the polyspatial side will make it into the next release.
But it is still a good idea to avoid putting colliders into hierarchies with non-uniform scaling, but it will work in more scenarios than the current validation restricts.