Collission on flat surfaces (like a tennis net)

Hi, I’ve been making models in Blender and importing them into Unity and I’ve run into this problem where I have a vertical flat surface with a partially transparent texture (like a net or a fence), and a character with a Character Controller component, and it behaves weirdly when I run into the plane from one of the sides (I can pass through it or in some cases get stuck there).

I’ve checked Generate Colliders on the import settings and I know this could be the expected behaviour for planes since a character shouldn’t face a surface from the wrong side due to its normal vector, my question is how to proceed in this case.

If I add some volume to the plane, the polygon count would increase, and I’d have to make some textures for the top and side views, with a plane I just enable render on both sides, but that doesn’t affect collissions.

I also tried to duplicate the faces and invert normals without changing their position so no volume is added, but it’s also kind of glitchy, as it prevents me from passing through it but I also can’t run parallel to the surface if I’m touching it.

I’ve also read about back culling but I don’t see where to enable/disable it, I’m on a URP project and the shader doesn’t have that option. I have the option in Blender though, but it doesn’t seem to have any effect on Unity. I’ve also read that enabling it can cause performance issues, so is it worse than just adding more polygons?

I also know I could add a separate collider in Unity, but one of my cases is a soccer goal net, which is curved and I don’t want to prevent the player or the ball from entering it by adding a cube collider.

How is this handled generally in low poly video games?

Thank you.

RE: backface culling,
for coded shaders: Unity - Manual: ShaderLab command: Cull.
for shader graph:

But I don’t think your issue will be solved by adding or removing backfaces either via the mesh or via the shader. It sounds like the problem is that Unity’s physics engine is always attempting to determine whether a collision has enough velocity to pass through an object rather than bounce off of it, using the many attributes of each rigidbody. If the net is supposed to be impenetrable, but its depth is 0, I believe the rigidbody would determine its mass is 0, thus it would give infinitely small opposing force.

I suspect the problem goes away if you replace MeshCollider w/ a BoxCollider, but that may get weird you intend to have deformation when a ball strikes the net. Perhaps a box collider just for the player and cloth physics for the ball would each need to be configured separately if that’s the case.

EDIT: Also, you might first try to adjust the Collision Detection property on the net collider’s rigidbody. If it’s set to discrete, then it’s trying to optimize performance by limiting the total number of checks, so it can miss checking for detection if the object is fast enough.

First of all you have to differentiate between rendering an object and it’s collision / collider. You could use a MeshCollider with the same mesh, but things like backface culling only apply to rendering.

Non-convex mesh colliders do not represent a volume but only collision surfaces, all the triangles it has. Those surfaces can always only collide on one side. This side is the front side and is determined by the winding order of the triangle (in modelling software also known as “face normal” which should not be confused with vertex normals).

Convex mesh colliders on the other hand do represent a closed volume. Here the surfaces are essentially clipping planes and enclose a certain surface. That’s also why convex colliders can not have holes or negative surface angles. Here we also have collision surfaces that only collide on the “outside”. Convex mesh colliders are limited by the number of vertices (I think it always was 256). When you select “convex” on a MeshCollider, Unity will calculate the convex-hull of your mesh. This always needs to have volume and may not perfectly represent your original mesh.

If your fence / tennis net is actually a flat surface, it’s usually better to just use a narrow box collider and not a MeshCollider at all. The BoxCollider is a primitive collider which is much faster to compute and generally more reliable. The primitive colliders all represent convex volumnes but they are internally described mathematically and not by surface planes. So primitive colliders will always be faster than mesh colliders.

When you use primitive colliders, it’s usually the best approach to use separate gameobjects (maybe added as children or siblings in a parent) in order to position and scale / adjust the collider(s). Even a more complex tennis net may be just a single box collider and maybe two capsules for the poles or something like that.

ps: Almost all shaders perform backface culling because in the majority of all cases double sided shaders would not work. That’s because vertices have vertex attributes and they include the vertex normal. The vertex normal has nothing to do with from which side the surface can be seen, but it’s used in calculating the lighting / shading of the surface. So when you want to render a single quad from both sides, one side (usually the backfacing side) would have wrong vertex normals and the lighting is wrong. The only cases where shaders do not use backface culling are things like particle shaders (as they usually do not even calculate any lighting) and some other rare effect shaders. If an object mesh should have two sides, you almost always want to model both sides with separate triangles so that each side can have their own vertex attributes (normals, uv coordinates, etc). So backface culling isn’t that much about performance but about rendering correct results. If anything backface culling will improve performance as in a closed volume you usually don’t see the backsides of the other side as it’s obstructed by the camera facing side. Backface culling will reduce the unnecessary overdraw. But as I already said, backface culling only applies to rendering, not collision detection, even though both have similar concepts.