Instanced line rendering for gizmos based on bevy_polyline

[irate-devil]

Objective

Adopt code from bevy_polyline for gizmo line-rendering.
This adds configurable width and perspective rendering for the lines.

Many thanks to @mtsr for the initial work on bevy_polyline. Thanks to @aevyrie for maintaining it, @nicopap for adding the depth_bias feature and the other contributors for squashing bugs and keeping bevy_polyline up-to-date.

Before

After - with line perspective

Line perspective is not on by default because with perspective there is no default line width that works for every scene.

After - without line perspective

Somewhat unexpectedly, the performance is improved with this PR.
At 200,000 lines in many_gizmos I get ~110 FPS on main and ~200 FPS with this PR.
I'm guessing this is a CPU side difference as I would expect the rendering technique to be more expensive on the GPU to some extent, but I am not entirely sure.

[aevyrie]

Performance is better on my machine up until 220,000 lines in many_gizmos after which FPS suddenly tanks from ~200 down to ~60. Noting this so I can investigate later.

IIRC, you're going to want to batch lines to get really good performance. bevy_polyline can handle many millions of line segments by batching lines with the same material into the same polyline and separating each polyline in the single gpu struct with NaNs. See: ForesightMiningSoftwareCorporation/bevy_polyline#20.

You could probably aggregate all polylines during extract, and shove them into a single GPU uniform, where each set of vertices and colors are separated by a NaN, if you aren't doing this already. This would result in a single draw call for all polylines.

It's also possible bevy_polyline has a much higher ceiling because it doesn't include color information in instance data.

[irate-devil]

I should have clarified that bevy_gizmos is currently exclusively an immediate mode API.
This means that, unlike with bevy_polyline, those 220,000 lines are being sent every single frame to render them, so it works a little differently (i.e. I'm not expecting the same performance characteristics here).

many millions of line segments

I assumed above that this number is referring to static polylines. Is that right?

You could probably aggregate all polylines during extract, and shove them into a single GPU uniform, where each set of vertices and colors are separated by a NaN, if you aren't doing this already. This would result in a single draw call for all polylines.

I learned the NaN trick from @IceSentry iirc, wouldn't be surprised if they got it from you :)

All lines are split across just 2 batches. One for the NaN separated linestrip topology and one for linelist topology (Used only for single segment lines)
Those 220,000 lines are all in the linelist batch.

It's also possible bevy_polyline has a much higher ceiling because it doesn't include color information in instance data.

I wonder how much this might affect the performance of this implementation. I would like to keep the fancy color gradients q:

[aevyrie]

All lines are split across just 2 batches. One for the NaN separated linestrip topology and one for linelist topology (Used only for single segment lines)

Sorry, I didn't see that when I did a brief review of the changes. It's pretty awesome you're already doing this. 🙂

I wonder how much this might affect the performance of this implementation. I would like to keep the fancy color gradients q:

Yeah, it's a nice feature to have. You might have luck by treating it like mesh indices, and only storing colors as a list of indices into the list of colors. My guess is for most cases, this would significantly cut down on the amount of data that needs to be yeeted (yoten?) over to the GPU. You would be reducing memory use for color from 16 bytes ([f32; 4]) per vertex down to 2 bytes (u16). This would allow you to store at most 65k distinct colors across all polylines, which is probably a reasonable limitation (1MB of color data). Though you could have 4 billion colors if you use a u32 as your color index.

Alternatively, you could keep the same approach as now, but use run length encoding to losslessly compress color information for polylines that use a single color. Another upside of that is it would allow you to easily add per-vertex line width and depth bias without blowing up memory usage in most cases.

Anyway, these are obviously some potential optimizations for a future day. This PR is definitely a nice addition.

[irate-devil]

No need to apologize :) Thanks for all the pointers!

Another upside of that is it would allow you to easily add per-vertex line width and depth bias without blowing up memory usage in most cases.

It's good that you mention this. I was planning to enable more granular control over these settings in a future PR

[IceSentry]

This PR is pretty big, is there anything that could be done in a follow up PR in order to keep this one a bit smaller?

I learned the NaN trick from @IceSentry iirc, wouldn't be surprised if they got it from you :)

Yep 😉

[irate-devil]

This PR is pretty big, is there anything that could be done in a follow up PR in order to keep this one a bit smaller?

This is pretty much the minimal change required to do this line rendering technique. I already stripped down the code a quite a bit compared to bevy_polyline. Especially considering this includes both a 3d and a 2d pipeline.

[nicopap]

LGTM. You say it's a perf upgrade compared to LineList? That's surprising, but good for us, because that would be amazing to have size (even if joints are still an open question). I'd just like to avoid some magic numbers.

[nicopap]

So only a global line_width and depth_bias is possible? Given you only upload two instances.

[irate-devil]

Currently, yes. I'll look into more granular configuration in a future PR.

[hate]

This looks great, the performance increase is a significant one

[IceSentry]

LGTM, there's a couple of things that could be improved in the future, but it's already in a really nice state for 0.11

[alice-i-cecile]

Merging for you: y'all have carefully considered this and have more than enough expertise between you. The code and changes look good from my end too.

[nicopap]

Dang merge failed