I know this topic has been discussed to death, and I understand the reasoning behind the issue; but none of the solutions I have read up on seem to work for me, or even completely apply to my situation.
I have been working on a simple demo, a flat grid of cubes (basic unity primitives), all the same size (1,1,1).
When I move the camera I get lines between the cubes. Additionally, when I apply (x and z) forces to a rigid body (capsule, with a capsule collider, rotation frozen) when it hits the “edge” of one of the cubes it has a chance to “hop”. Presumably from a miss alignment of the collision rectangles resulting from the same rounding errors that cause the rendering issue.
Interestingly if I rotate the camera by 0.1 degrees on the y axis, it makes the graphical artifacts go away (at least, on my machine); however the collision issues still remain.
I am using real time lighting, and the default textures on the cubes, running in the URP on the latest version of Unity.
The visual glitches could be reduced by welding the vertices on the cubes into larger groups, but this doesn’t really solve the issue (it just reduces the areas where it will happen) and doesn’t really address the physics issue. Is there something I am missing?
Isn’t a bunch of box colliders placed in a flat grid effectively the same as one box collider enveloping the entire grid? Are there any omitted reasons why you must stick with one collider per grid cell instead of covering the entire grid with one collider? That would be the best workaround I think.
This presumption may not be the real cause. All sphere-based primitives in Unity (and a capsule collider is one of them) have a quirk where if they hit the very edge of a box collider, the normal of impact is not the one you’d intuitively expect. Here is one of many discussions where yet another person discovered and described it: https://discussions.unity.com/t/554303
I don’t know how Unity does physics under the hood, but most collision-related algorithms use surface normals for resolution and it is possible that your capsule hops because it gets a bogus normal when the closest collision happens to be with the edge of a box beneath it.
Try replacing your capsule collider with a box collider and see if the problem goes away. If it does, you can blame the capsule for it.
The cubes are representing modular level pieces and prefabs so creating a single collider for the whole thing is not a viable option, and they will not always be pure cubes, those were just the simplest test case.
That’s interesting and I will certainly investigate more, but box colliders for player models are problematic.
Any insight on the graphical glitches, or can I just not have a camera that aligns with the axis?
I wasn’t suggesting you use a box collider in your final game, just that you do a test replacement to see if it’s the capsule collider that gives you this problem. If this gets confirmed then you can take a look at the article here describing one of the ways it can be dealt with https://catlikecoding.com/unity/tutorials/movement/surface-contact/
Is the visual problem that you’re talking about related to literally seeing the sky box through the tiny gaps in the cubes, or is it about the little black line at the seam that is a result of shadow mapping bleeding a little bit of shadow from the adjacent vertical face?
I’m not a level designer, but if these are modular level pieces, why not design them in a way that would obscure the seam? Think of a doorstep that goes over the seam to hide it, anything creative that you can fit in your environment.
From my experimentation it appears that the lines are a darker color of the whatever color the cubes are; so presumably its a shadow or lighting issue of some sort. I don’t have shadows turned on for anything in the scene but I do have a single real time directional light.
That’s not really possible, they are not just set pieces, the entire game world, from the land to architecture is composed of a grid of these modular components.