Age | Commit message (Collapse) | Author |
|
In preparation for release of the 4.8.
CURA-7795
|
|
CURA-7641
|
|
CURA-7106
|
|
|
|
|
|
THis speeds things up a fair bit for build plates with multiple models
CURA-7106
|
|
This prevents us from having to re-create them everytime
CURA-7106
|
|
Wont add anything to speed, but it will make it easier to read
CURA-7106
|
|
The check is called a lot, especially if there are a ton of models.
CURA-7106
|
|
CURA-7106
|
|
CURA-7106
|
|
CURA-7106
|
|
CURA-7106
|
|
CURA-7106
|
|
SolidView
|
|
X-ray errors showed as green and translucent instead of read and solid. Now fixed.
CURA-7407
|
|
Probably it'll still crash somewhere else then, but we'll rely on Sentry to find that for us.
Fixes Sentry issue CURA-KW.
|
|
CURA-7383
|
|
The renderer isn't active when the view is activated. As such,
no opengl context *ever* exists. In some cases this might cause it to get
stuck in an indefinate loop.
The comments around it are explaining a situation that can't occur. The activateView
event of SolidView isn't triggered when switching to another view...
|
|
part of CURA-7262
|
|
|
|
|
|
|
|
textureSize() is not available in opengl 2.1, so we calculate the xray error image scale outside the shader (which is also a theoretical performance improvement because now the scale does not get computed over and over for each pixel)
|
|
Now that we have no noise any more we can do this.
Possibly cuts the processing time in half, too.
Contributes to issue CURA-7262.
|
|
QImage's bytes are aligned to memory words per column of pixels. That means that one of these columns contains 99% valid image data, but with several bytes of unassigned noise at the end. How many of these padding bytes there are would depend on the image size, i.e. Cura's window size. In the end, the total number of bytes in the image ends up slightly more than w*h*3. As a result, Cura would crash because it couldn't reshape the image. Reshaping was completely unnecessary anyway, but this random noise was giving false positives also.
But how do you then get only the actual pixels from each column of data? We can't just go iterating over this array, as that would be an iteration of thousands of columns which is prohibitively slow in Python. No, we're going to do some Numpy magic. We're going to create a class that pretends to be a Numpy array. Give this class some data and say that this data has a certain pixel size but also a certain STRIDE LENGTH. This stride length can be the length of the actual pixel data. As a result when Numpy sees this object it will read out the data using these strides, all done efficiently within the C code of Numpy.
Framerate is fantastic on my computer. No problems at all. Pretty powerful computer though. But also a big 5k screen. Still no problem for Numpy. Seems to be decently efficient.
Took me quite a while to figure all of this out.
Contributes to issue CURA-7262.
|
|
That's what that function is meant for. It's executing essentially the same, since before it was executed right after the call to _checkSetup() and now it's at the end inside that function.
Contributes to issue CURA-7262.
|
|
|
|
|
|
|
|
I don't understand why, but any deviation from this produces worse results
|
|
I don't understand why it only seems to work if I define u_color via [default]
andd why it doesn't work when I set it inside the shader itself.
|
|
|
|
|
|
|
|
|
|
includes SVG source file
|
|
|
|
temporarily use the cura logo as placeholder image
didn't correctly determine window size yet
|
|
|
|
|
|
Somewhere between the xray.shader and the xray_composite.shader the colors are stored as unsigned int.
Since we want to count the integer number of faces behind a pixel in the red channel, we simply use a color with an r value of 1/255.
|
|
|
|
|
|
We've added new things to our API. This allows plug-in developers to use them.
Contributes to issue CURA-7205.
|
|
|
|
CURA-6858
|
|
|
|
Icon thanks to Yi-An Lai.
part of CURA-6754
|
|
feature_bottom_face
|