Hi. I’m making a very low poly game. I have for example, a bridge which is 78 faces / 156 tris. I know that per poly (complex) collisions are usually fairly expensive, however I am wondering if that is still the case when dealing with such small numbers of polygons. It seems logical to me that adding 12 box collisions to this model (which is what it would take) would be less efficient than just doing per poly collision.
Is this logic flawed?
The only way I can think of to maybe accurately test the efficiency of this is to create some dummy project with 2 versions of the same model with these two different collision types and then spawning hundreds / thousands of them in the air and having them falling to the ground and seeing which one eats more CPU time. Is there a better way to test which physics type would be better?
Interesting Question. I want to add to the question, if there is any difference between collisions of a static mesh sphere and a sphere collsion component.
This is the question I wanted to ask. I have a series of relatively low-poly rooms in a building, with non-standard but not overly complex geometry. This one has 88 polys, for example. The next shot shows the collision hulls I’ve set up.
With negative spaces like this, there is also the fact that the collision hulls create more collision than is needed, because each box is two-sided, but the walls are one-sided (there will be a separate mesh for the whole exterior so as to avoid seams). I don’t know if that has any impact on the efficiency, though.
Does anyone have any ball-park idea of how much more efficient collision hulls are? Is there ever a time when per-poly collision is more efficient than collision hulls? If creating a 1:1 match between collision hulls and polys will usually increase the efficiency (effectively what I’m doing in LightWave), can that be added as an import feature in UE4?
(PS the pics are swapped around - I fail at edits)
From my personal experience, it is ok to use per poly collision if the number of faces isnt extreme(i.e. a wall with door opening would require about as much complexity if you made a custom collision box as per poly collision so you might as well use per poly collision) But i used to have collision issues with particles when i used per poly collision and i dont know if that’s still the case so keep that in mind.
I should also point out that it is never a good idea to bring a building mesh as a single piece like fatmarrow’s example, and you should use closed meshes(not planes) for walls to prevent lighting problems in the long run. If you bring every wall as a separate mesh you can use per poly collision for the ones with door opening and the others could use simple box collision.
Thanks for the feedback. Splitting a building into walls rather than rooms is going to be a bit of a logistics headache (as well as making it a pain to edit a room after the event), so I would like to be sure I understand before I take that step.
When you say closed mesh, do you mean creating what will be (when in situ) unseen back, side, and top/bottom faces for each wall? I envisage that would add lots of unneeded polys and also possibly create tedious collision overlaps on adjacent rooms with thin dividing walls, etc. But if that’s needed to get good lighting I guess I’ll have to do it - but no lighting problems experienced so far though…
By closed mesh i mean the ceiling, for example, needs to be a box, the floor needs to be a box, etc. Extra poly count for such simple geometry is neglectable really, and collision intersection wont cause any issues as long as they are static meshes in the level.
Regarding lighting, even thin walls may cause light bleeding sometimes so i’m sure you’ll have issues with single sided planes at some point. Also if you use planes for a room you’ll have to enable two sided shadowing, which will add to performance cost, which will eventually wont benefit you in any way. It is fine if you arent having any problems for now but keep in mind that it can be the cause of the problem if you happen to have one in the future.
