I am currently making a mini-golf-like game, similar to “Golf with your friends” and “Golf Around”, and I want to know how bad it would be if I make the ground have complex collision.
I would use simple collision but because of how small the ball is you’d easily see that the ball is either hovering or clipping through the ground. My ground tiles range from 2 triangles to around 150 triangles on more complex shapes like the hole. I know complex collision does cause performance loss, but I feel the game needs the accuracy. Is this a bad idea?
Hey there @HybridPosts! I agree with Everynone here, in most cases it’s still recommended to use simple collisions when possible, or at least decimated versions of your complex meshes to get as much performance possible while retaining the shape. That said, for practical reasons you should definitely have the functionality working first so you can accurately stress test this later. Since the meshes themselves are basically decoupled from most workflows, it shouldn’t be a problem to change before you start making many tile types.
Simple and complex collision can behave differently, if physics are gameplay in your game, I’d really make sure your not just switching between simple and complex collision arbitrarily where it can matter. Random statue in the background? Either one is good enough. The course itself? probably want to stick with simple.
You’d use simple collision for the course? How come? Even if you laboriously handcrafted every nook & cranny with UCX, the results would be worse than underwhelming…
Random statue in the background? Either one is good enough.
So background props are OK with Complex collision?
I’ve found simple collision is much more consistent, if you were to hit a ball up a ramp 100 times, in my experience simple collision would be more consistent than complex which would act very weirdly maybe 4 out of 100 times. They should probably test and see what works for them.
Simple can’t concave so making any kind of undulating terrain or anything more complex than a ramp / step is a no-no. If the course is flat as a pancake and has sharp angles only then maaaybe, you’d still get pretty unremarkable collision at the edges.
You wouldn’t even be able to make a hole. And were you to cobble loop de loop out of spline mesh components, you’d immediately see what that does to simple collision… It does not work at all.
simple collision would be more consistent than complex which would act very weirdly maybe 4 out of 100 times
You wouldn’t make a game using standard collision settings, there’s a lot to massage, especially now with Chaos which to many feels like a step backwards because of the defaults.
But this would then be the equivalent of complex collision, you’d collide against every face - just like Complex… but worse since this actually wastes triangles as there’s a bunch we cannot see that will never be utilised. For every 8 faces, you never utilise 4 unless you’re using different pieces for start / mid / end. Or merge them. Or later on turn that into actual procedural mesh which would be most optimal here.
And it still cannot make sloped terrain. Besides, note:
the ball is you’d easily see that the ball is either hovering or clipping through the ground. My ground tiles range from 2 triangles to around 150 triangles on more complex shapes like the hole
Judging by the original post, OP already has pre-set pieces so that probably could never work for them anyway.
@HybridPosts If you ever run into performance issue or start optimising, do look into UCX collision. It would need to be done outside the editor and then imported, it allows you to hand craft much more complex and tightly matching custom collider shapes that can be used as Simple. It’s the best of both worlds but laborious.
If your tiles are 150tri, it’s probably irrelevant. And very relevant if we’re talking high poly.
- just like Complex… but worse since this actually wastes triangles as there’s a bunch we cannot see that will never be utilised. For every 8 faces, you never utilise 4 unless you’re using different pieces for start / mid / end. Or merge them. Or later on turn that into actual procedural mesh which would be most optimal here.