Though HISM is awesome its collision never works. I tried everything.
I also tried detecting overlap, doesnt work also.
The project, and video:
Pool_Game.rar (20.1 MB)
Is collision hopeless for HISM?
If you have simple shape detection then you can use this hierarchy
The overlap will then be detected.
2 Likes
Try setting the collision from BP - they do support collision per instance. They don’t support physics though.
If this doesn’t help, make sure the cube has a collision shape and that it’s enabled in the Mesh Editor.
1 Like
I tried this. It didnt work. Also checked on the Mesh editor for the collision, its set up there too.
I placed Set Collision Enabled on both Actor Blueprints.
I understand since its an HISM the collision and physics might not work properly like it would work for an Static Mesh.
Though I cant see it anywhere written that this is the case. So im trying to clear this.
So basically spawning a Collision and disable the collision of the HISM. Yeah this is nice work around and works, i tested this before.
Though i was trying to figure out if HISM collision works or not. I cant see it mentioned anywhere.
If its not possible then i can do this. Though its weird because officially its supposed to work?
I’ve read that sweep only works when a collider is the root component.
1 Like
Okay so ill set your first answer as the solution, but if anyone wants to chime in, or has alternatives, let us know
Thanks 
If you look into the collision debug view then HISM have a different color to other meshes. They seem to have a peach color.
They can collide with types of collisions but HISM x HISM seems to be ignored.
1 Like
Thats right. So this means its different.
ITs okay. I think ill go with your solution of the collision in the root.
Or i can create a collision manager, with an array of Collision Components, and each time i move a instance of an HISM, i move also its corresponding collision.
That’s interesting - I hadn’t thought about HISM → HISM collision before - you ask some interesting questions!
If you’ve got a lot of objects - just doing a manual overlap test by radius from their transforms would be fast and save a lot of collision components - especially if you have sorted the objects into grid arrays or some such.
1 Like
At that point I think it would just be optimal to do a distance check between each instant element center and if the distance is smaller than the radius of half of the element then treat it as collided (if the object is reasonably square shape).
Maybe a sphere collisions would use an octree calculation somewhere in the background for optimizations but a distance check might be cheaper and if these are armies then the units will probably in close groups most of the time so octree optimizations probably wouldn’t happen too often (you would need to have 1 soldier split off from the group in some way).
You could also do a box approximation of the group based on the hism bounds extent, it would need some tests to see what is optimal.
I think hism to hism collisions probably don’t occur as they were made with the thought of being an optimized masses of polygons that are supposed to be mostly background assets that don’t interact with other assets of that type.
Instancing also occurs purely on GPU so much like particle GPU collisions their calculations are tougher to do. You need a CPU collision doppelganger at that point that handles the collisions.
2 Likes
Thanks. I love HISM, i use them all the time. So i think the solution is to just spawn collision separately for each instance if its necessary. Its still gets great performance.
Though if used on a very large scale and with units that are moving a lot, then maybe a particle system becomes a better option. Though niagara are quite confusing to set up and control units separately.
HISM are simple and intuitive. And if your units get idle a lot, like in a more strategy type of game, then i think its better to use HISM.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.