I’m currently using box shaped trigger volumes in my level to demarcate specific areas of the map the player can interact with. Now I get are far more accurate volumes if I use the CylinderBuilder brush shape instead of BoxBuilder for these volumes but I’m worried that the additional vertices will come with a noticeable performance hit.
Eventually I’ll have a pretty large number (~50) of these volumes placed in the level so I want to set an appropriate shape before I get too far in building the level.
Will the performance impact be hard to tell without actual profiling or is this something someone has experience with? I imagine the performance considerations would be similar to that of collision shapes used for static mesh collision checks although given the large number of volumes I’ll be placing I’m not entirely sure.
Just to add one more dimension to the question - I’m now considering ‘hollow’ cylindrical volume triggers meaning a trigger volume that has an inner and outer radius such that the interaction volume is a concentric fringe. The idea behind this is that I want the player to be able to interact with a circular piece of land only when they stand at the edge of the circle. These ‘circular pieces of interactable land’ are scattered throughout the level.
I imagine a hollow cylindrical volume trigger will be even more expensive although it seems well suited to solve the problem of interacting on the fringes/edge of a circular plane.
A trigger volume has no vertices. The simplest (and cheapest) trigger volume is a sphere, because you just check if something is within the sphere radius.
If you add two trigger spheres and check if the player collides with the outer sphere, but not with the inner one, you get your hollow sphere with good performance.
Thanks Mars007, I think you’re talking about ‘shape’ volume components though as they indeed have no vertices.
I’m specifically talking about trigger volumes (you can find it in the place actor tab when you select all classes). These definitely have vertices as they are actually derived from ABrush.h and behave just like BSP brushes. The vertices can be moved using Shift-5 (geometry edit mode) and the volume checked by the class adapts to the vertex placement. I think they use the ‘EncompassesPoint’ generic volume function to do this check.
With that in mind, should one prefer shape based volume triggers to the Volume Trigger class? In my level I’ve been using Trigger Volume based actors extensively for things requiring precise placement and shape component based trigger volumes for simpler things like skeletal mesh collision volumes, interaction points for simple static actors in the level, etc.
What platform are you targeting? Vertices are basically free on PC, what with modern GFX card technology; I mean, that’s an exaggeration, but taking 24 vertices for a cylinder and multiplying it by 50 cylinders is, what, 1200 verts total? That’s freaking NOTHING. Especially since these meshes don’t contribute draw calls, you can just pump them into the level and pretty much never sweat it. 1200 verts is like, a single piece of irrelevant scenery in modern games.
Maybe that isn’t true for mobile, I couldn’t say. But for a conventional system, adding 1200 verts to a level map is basically nothing.
Thanks, that’s quite relieving to hear I’m targeting PC indeed.
I think I’ll go ahead with using brush based trigger volumes for most of my volume needs. The amount of flexibility I get from being able to choose brush builder types and move vertices around makes it so easy and convenient to use during level design.
Hey VSZ, Mars is correct. Spheres are the cheapest.
If you want to know the order of cheapest to most expensive it is:
Sphere < Capsule < Cylinder < Box
The reason, as Mars indicates is that collision is done by sweeping checks from a point. So with a sphere, that’s one point sweeping 360 degrees (very cheap). A capsule is a sweeping half sphere on the top and bottom, then one degree sweeps at each point along the shaft (still pretty cheap).
Where things get more complex and expensive is with flat surfaces, You can’t do a centralized sweep on the side of a cube, many more points are needed to calculate a flat collision surface. So if you want optimization, stick to spheres and capsules and only use cubes when really needed.
Thanks everyone. The outer-sphere+inner-sphere approach certainly seems most performant.
I just discovered that Trigger Volumes (anything derived from AVolume.h) are very unstable if you create a blueprint subclass from them as the editor simply crashes when you are setting up the volume builder within the blueprints components screen (see this thread from Answers hub) so that in turn means custom trigger volumes are effectively C++ only.
I think I’ll just use a simple Actor with two Shape components (set to Sphere) as suggested instead.
Thanks for reporting the crash! Especially with the detailed repro steps! This helps immensely on our end and to get crashes reported and fixed as soon as possible. We’ve got a support team member assigned to start looking into this soon!
I’m targeting PC indeed.