Ah, I see… So you don’t want this effect to update when the player changes position, but to cast a coloration on the environment in the form of a static point cloud which then remains until the player pings again?
Actually, what you’re doing with traces makes good sense, then.
What I would maybe advise you do is try to break up the traces… If you search the forums you’ll find someone who created a macro which processes a ForLoop across multiple ticks. So you could use this to process, say, 500 traces every tick. That SHOULDN’T be so slow as to cause an appreciable framerate drop, I wouldn’t think (traces are fairly cheap as long as you aren’t trying to process 90,000 of them in a single tick!)
If your game is running at 60FPS, that would make the entire “LIDAR ping” operation take about 3 seconds, which isn’t too long. Visually, rather than appearing as a framerate hitch, it would appear as a “radar sweep” type effect where the point cloud materializes in vertical/horizontal bands that sweep across the screen.
You would have to take a couple extra steps to make this work right (store the player’s location at the time of the sweep as a vector variable and use that value as you iterate, otherwise the process would be broken if the player moved while the sweeps were occurring, and of course making sure the trace you use can’t touch any part of the player himself).
The more pressing question, and I have no answer to it, is what sort of performance cost is incurred by the actual DrawDebugPoint operation. God forbid each point is generated with a single draw call, nothing you do will save your framerate from the cost of 90,000 draw calls.