Updated the caching logic in SimulationView to use the id of the layer_data object instead of the node. This ensures the cache is correctly invalidated when layer_data changes, preventing potential issues when nodes are reused.
Added logic to track which node's layer heights are cached and only recalculate the cache if the data source changes. This improves performance by avoiding unnecessary recalculations and ensures cache validity when the scene changes.
Introduced a cache for layer heights to avoid recalculating them on every query. Added a method to populate the cache for all layers at once, and updated layer height retrieval methods to use the cache, improving efficiency when accessing layer height data.
Adds display of the current and minimum layer heights (in mm) to the Simulation View slider labels. Implements new properties and logic in SimulationView and SimulationViewProxy to retrieve accurate layer heights for both sliced and gcode data. Bumps plugin version to 1.1.0.
CURA-12660
This required a refactoring of the management of the active view. The previous behavior was that anyone could set the active view, depending on certain conditions. But now we also have a view that is set by a tool, so sometimes the actually set view would be incorrect. Now each Stage requests an active view, and each tool CAN also request an active view. Then the Controller decides which view should actually be active depending on the active stage and tool.
Wireprinting wasn't actively maintained, and almost an entire different min-engine. It's also rarely used, and presumed broken. Remove it, so it doesn't have to be maintained or clog up other maintanance and/or refactor tasks.
frontend part of CURA-10394
The max value was being calculated as the product of the max line width, max layer thickness
and max feedrate but it should be calculated as the maximum of the products of the width,
thickness and feedrate for each individual line. i.e. calculate the flow for each line
and use the min and max values of the flows.
The input array here is 2D, but always 1 by N long. The output of where then gives a tuple of two arrays, one indicating the Y positions and the other the X positions. The X positions were therefore always 0. The amin and amax functions were then always taking this index 0 along in their results, regardless of whether the line at that index was visible at all or not.
This will also improve performance since it's checking the limits now only for half as many indices.
This prevents previous measurements from influencing the colour scheme. Essentially previously it was showing the colour scheme based on all lines you had ever seen, rather than just the line types you were currently seeing.
If the user makes certain structures visible or invisible, and this then causes the limits of the colour scheme to change, this now triggers the layer view to be re-rendered and updates the legend in the simulation view menu component.
This is just a refactor that shouldn't have any influence on the behaviour.
It is a necessary prerequisite to be able to trigger the updating of the layer view colour spectrum more frequently, i.e. if the visible line types change.
This way, if travel moves are not currently visible in the layer view, the travel moves don't get counted with the limits to determine the colour spectrum to grade each line with. Quite often, travel moves had a much greater speed than other moves, like 120mm/s instead of the fastest printed line 60mm/s. This caused all of the layer view to be pushed into the lower end of the spectrum. It makes it hard to distinguish the differences in speed and line width because travel moves influence the spectrum so much. This way, the travel moves only influence the spectrum if they are visible. If they are visible, it might be relevant to the user. Otherwise, the user gets the full spectrum to differentiate between all the line widths and speeds.
This currently doesn't update correctly yet. That is something we'll need to fix.
