Hello ev! 
A flash question : If UCX I made in Blender to use as simple collisions are similar to complex collisions of the same meshes, the impact on performance will be the same or there’s always a difference beetween them?
Thank y’all!
Hey there @Cykablatta! The answer is that there will be a performance and a bit of utility difference, but I can’t really tell you how much. However I can tell you that there are systems in the engine that will not function with a complex mesh at all and require a mesh considered as simple, even if they are the same.
1 Like
Ehi @SupportiveEntity thank you so much for answering! Can I ask you some examples about that? Because, in the last period, I noticed for example, sometimes my navmesh does not work on simple collisions and I’m constrained switching them to complex , then the nav is gonna works properly
Some portions of the physics system will only test against simple collision, such as the vehicle physics and destructible mesh modules. Most of the engine is built to use simple collision for performance, so it’s best to use a simplified hull wherever possible that doesn’t damage your gameplay.
This sounds like an issue I see from time to time where a mesh doesn’t have a simple collision generated, so a user will toggle Use Complex as Simple and see that it now has collision. Alternatively the navigation mesh may just generate with a bit more accuracy at the cost of performance (when building the nav mesh specifically).
1 Like
could it be that it happens because the ucx I made in blender are flat, that is without extrusion? @SupportiveEntity
That’s a great hypothesis! Theoretically it shouldn’t have much of an effect, but thinking back I’ve noticed a significant amount of issues with very thin meshes, overlapping thin meshes, or stairs with NavMesh that were solved by adding some depth, so it’s entirely possible.
1 Like
@SupportiveEntity I’ve redone from 0 my simple collisions, now it seems nav is calculating them in runtime also. Their thickness was the problem. But I’m not 100% sure I can proceed with their hull count. Can I send you a screen?
Of course, feel free to post screenshots! If the hull count is too high, there’s definitely ways to simplify in the collision menu but if you have lots of meshes it could be tedious or outright unfeasible for large projects if the automatic methods don’t pan out.
1 Like
I’m using simple collision I made in Blender as complex, but how you can see, their hull count is very similar to complex ones. For this reason I asked before. Should I find a way to reduce them? Or I’m fine because they’re simple?
Ahh yeah I see what you mean, that’s way too many to be optimal, though depending on the scale of the game extra optimization here may or may not be worth it.
How many permutations of the vents do you have? If it’s just a handful, you could just place some boxes for collisions, but obviously this scales poorly if you have more than a few
Alternatively if you aren’t having larger networks of vents, this might be fine while definitely not ideal.
1 Like
What do you mean? Anyway my game is not heavy. It’s not open world, most of meshes are hierchical instanced, txtrs are low res (in atlases, excluding heroes assets and uniques) , meshes are also very low poly, for each level there’re 3-4 master instanced materials maximum to “cover” the entire world , meshes have only 1 material slot each one, few bps to manage levels. in the actual state the project is less than 1gb.
This is the work I have done on optimization until today in a nutshell
@SupportiveEntity
@SupportiveEntity do you just go complex as simple when navmesh fails or fix simple first??
Honestly your game seems fine to use them like this, as long as the nav mesh itself isn’t distorted, I doubt this would cause any significant performance issue in a game that’s well optimized other wise. It’s just nice to have cleaner collisions and NavMesh hull. I’d go ahead and stress test it as is, and if it works in a series of vents fine, I’d leave it as is.
The permutations would be how many different vent types you have, if there’s 10 you could manually make the collisions but it’s not always worth the effort.
do you just go complex as simple when navmesh fails or fix simple first??
This is dependent on the game, if I’m trying to get the very most out of performance, I’m making as simple a collision first, but a couple more collision points won’t hurt a well optimized or already very small or simple game.
1 Like
@SupportiveEntity I keep them like so, if in future tests I’ll have perf issues , I’ll remake them in a simpler way. (I can’t understand what you mean for vent types, sorry is my eng’s fault ahahah)
Also, if can I ask you, is it possible to have an hybrid collision system? For example :
I’ve 2 meshes merged in 1. But one uses simple ones and the other uses complex ones, is it possible in ue?
Thank you so much!
Oh I misunderstood, I thought these were vents like air ventilation shafts, my apologies. As long as the NavMesh is fine AI should walk it no issue (You can verify this by hitting “P” in the viewport). The difference when it comes to collisions will be how many you have active and colliding at a time. “Hybrid” in the sense that you can use them both at once? Not really. You could make any shape, but it would always be treated by the engine as whatever the collision type is set to.
1 Like
Dw about that, anyway they could be hundreds maximum. How you would proceed? Is complex collision still a good solution if meshes are lowpoly? @SupportiveEntity
Theoretically it should be fine to proceed as is, but I would definitely stress test early once you have a solid game loop established and know what your game’s baseline performance is.
1 Like
I agree, maybe is better to reach that point first. Anyway, I really thank you! Your help has been very helpfull! @SupportiveEntity
Can I ask you a thing in pm? It’s not about collisions anymore
1 Like
Absolutely, feel free to private message me whenever you need!
1 Like