I created a blueprint that has 4 line traces by channel. The traces are fairly short and spawn from the player camera in the shape of a “+”. They’re only activated after a certain speed has been met but that’s not a hard barrier to pass. They are used to keep track of distances from colliding objects so that other parameters can be modified. The traces are needed for gathering the colliding object, the collision position, and how far the player is from that object. Is there a less CPU intense trace or a better way of creating that “+” shape from the player? The system seemed to be fine but as more artwork makes it into the game the traces are too CPU heavy to continue using this method. I’m hoping I can find a replacement for most of the traces while keeping one. I think I can change some of the traces to a collision box. I don’t need as much information from three of the raytraces as I do another. Is a collision box capable of providing accurate positional data of where the collision started?
I’m not 100% sure but it seemed like the most expensive task in my blueprint and removing it improved performance moderately. Optimization is not something I’m entirely familiar with but I think my biggest issue was reducing the rate at which I update some variables.
Yes, you could try to use sphere trace and see if it’s better - it’s also worth to put your traces in a timer (so you can control its intervals and optimize them depending on current situation), not in event tick - but that depends on your game, if you need to be very accurate at high speeds then probably event tick is fine.
One thing I noticed with lots of traces going is there was a SIGNIFICANT PIE hit, but a more minor stand alone hit
as in the packaged game or the stand alone mode run game runs waaaaay better than play in editor or new editor window. I get 120fps in stand alone versus 40-60fps with lots of projectiles (using traces) going
Traces are most likely not your problem, in my AI Plugin for pathfinding I used traces and in one tick it can fire up to 200 traces without a noticeable performance hit.
we’re always getting pies thrown back in the face with this editor. Maybe the editor runs the game more slower because its using extra windows resources.
Traces should not be your problem - perhaps you left the debug line print turned on?
You should easily be able to trace many times against a large number of objects.
Internally, the trace is processed in 3 phases (taken from PhysX Docs)
Broad phase traverses the global scene spatial partitioning structure to find the candidates for mid and narrow phases.
Midphase traverses the triangle mesh and heightfield internal culling structures, to find a smaller subset of the triangles in a mesh reported by the broad phase.
Narrow phase performs exact intersection tests (ray test for raycast() queries, and exact sweep shape tests or overlap tests for sweep() and overlap() queries).
If traces still seem to be the bottleneck, perhaps it is the work yo uare doing after the trace?