We can't change this index to an integer, because varying variables can't be integer, even though this variable will only really be tested on vertex level. Not sure if varying was the right choice, but I don't want to change that.
This prevents a crash, probably only occurring on certain GPUs.
Contributes to issue CURA-8657.
Instead of re-uploading the mesh each time the range changes, handle the range in the shaders with the new draw-range parameters. This does however, mean the range has to be in vertices, not in elements. This necessitates some changes to the simulation-view, and some added bits deeper in the base code. Mainly, since each time the type of a line changes, there is an extra vertex, there needs to be a type-change count available to get from 'paths' to range indices.
If the range of the colour spectrum is 0, i.e. there is only one value for the current colour spectrum, then this would previously give a division by 0 in the shader, causing the final colour to become black. This is unexpected and makes the layer view hard to read. Instead, we'll now use the middle of the range then.
This was likely a problem for a long time but only really became visible due to the colour spectrum now showing only the range of values for the visible structures. Previously it was a problem e.g. for layer thickness if all layers had the same thickness (i.e. initial layer height == layer height).
All of our current layer view colour schemes are properties of a line, not of a vertex. The line has a single feedrate, a single line type, a single layer thickness, a single material colour and a single width. This is even limited by the g-code specification itself, which is unable to represent lines with varying line width. However, we store this information in the vertices, the vertex data being the only data sent to layer view since layer view is sent as polylines to the shader.
This change makes the entire line take on the colour scheme of the vertex where its representative data is stored. This data is intended for the line, not just for that vertex, so it makes sense that the entire line listens to the data of the correct vertex, not just the nearest vertex of the line's endpoint.
Encountered as I made a failed attempt at solving the issue with rendering transparent support. I tried to order vertices appropriately but failed miserably.
Also adds a "show starts" option to the SimulationViewMenuComponent and corresponding logic
SimulationPass.py adds a prev_line_types attribute to the shader, which the shader uses to compare with its line_type to detect starts.
Since the tubes are symmetrical, instead of using an extra vertex to flip the winding order, I just mirror all horizontal coordinates so that the triangles flip inside out.
This adds a front-facing primitive towards the back side of every travel line, causing those lines to be visible from both sides regardless of backface culling. This doubles the number of vertices for travel moves, but due to backface culling it comes down to approximately the same performance as the original.
in the Feedrate color scheme. Due to the travel speed is normally very
high compared with the other speeds in the model, the gradient is now
gradual instead of linear in order to show more changes in the low
values and less changes in the high values.
Adapt also the button styles and themes' colors.
Set the play/pause button to the left and reduce the size.
