As you can see, this are basically 4 distinct meshes, seperated by empty space (which should have no collision, of course). In 4.7 I could place 4 box collisions around the 4 meshes and then apply the convex decomposition which then packed the meshes individually.
I tried to play around with the settings (1.0/32), but after nearly 10 minutes of calculation (half of it at 95%) with a blocked editor while not being able to cancel the operation I had to kill the process in the task manager.
In my test using at least 0.7 for accuracy results in correct convex collision generation. This may differ depending on the mesh of course.
As for time it takes to generate, this can be dependent on system specs and complexity of the mesh that the convex collision is being generated for. On complex meshes I’ve used in the past since this new method was introduced with 4.8 that provides more accurate collision generation and can take longer to generate depending on accuracy and hull verts.
While it may have appeared as though the editor froze at 95% it was still processing. You’ll just need to wait it out for the final results.
Definitely. Let me know how it goes. There may be some fringe cases that cause issues and if so it would be helpful to get things like that reported, especially since we just implemented a new version of V-HACD that replaced HACD method used before.
BTW: When I just leave the collision settings on ‘default’, add a simple box collision and scale it / move it around this is really, really slow (about 1-2 fps). It seems like the mesh is constantly updating/recalculating something in the background.
When I change the collision complexity to ‘Use Simple Collison As Complex’, I can manipulate the collision meshes without any lag and then restore it back manually to it’s original setting.
I let it run through the complete collision generation with 1.0/16 and it took about 3 hours. While this may seem long, it’s an itterative process for what is a that will require time to generate the complex collision for. You have 6 objects here that the accuracy process of the new V-HACD is having to iterate on and get the collision hulls down to 6.
If you watch the process tick while it’s seemly “stuck” at 95% you will see that it’s iterrating. About an hour and a half in a i stopped checking the iterations which at that time was already up to ~300 with ~20 collision hulls. In the end this gets whittled down to the 6 collision hulls, but with the accuracy turned up it takes significantly longer because this means more vocalization of the mesh to get accurate results.
In this instance, it would be better to create custom collision in a modeling program. Also, the very high poly count is coming into play as well to be as accurate as it can. When I did my original test my mesh only had ~100 triangles.
As for the movement of the collision hulls, I can grab them and move them just like any other. I’m not seeing a slow down on my end here, unfortunately.
look, I appreciate all the effort of yours to investigate this (I really do!). And V-HACD seems to calculate really good results for small-poly meshes, as far as I can judge this.
But I basically just need an automated solution to pack individual (sub)meshes like these into simple collision hulls on import and exluding empty spaces between them. A few scaled and rotated boxes would be absolutely fine.
BTW: Are about 30.000 polygons really such an extreme number in 2015? I have some highly-detailed meshes which have several 100.000 polys, runtime-performance is really ok and they look great in the engine, especially in VR where you can’t fake much with normal mapping.
Suggestion: If this is basically a non-solvable problem with high poly models than maybe you could at least provide some warning message about exceptional long calculation times and make the process abortable?
Many thanks,
PS: Here’s a video about the lag when moving/scaling the collision meshes in the static mesh editor with default settings: - YouTube (I can reproduce this with several meshes, UE 4.7/4.8 on all tested machines)
I’ve entered a feature request to cancel the collision generation with UE-17040. I think this is a very helpful and useful idea.
I was able to reproduce the lag using a simple box, one with 60k and 120k tris. The collision placement smoothness is based on the poly count of the mesh. I’ve reported this with UE-17048.
Thank you for your help and patience. It’s always greatly appreciated.
I also didn’t mean to suggest that High-poly is bad, just that the calculations needed when doing the voxelization and combining the multiple hulls down to fix the mesh can be a long process. The more verts there are the more calculations there are.
