Projectlayer: Some maintenance and improvement

[neofelis2X]

Hello. A while ago I spent some time on the Projectlayer module. The more I work on it, the more I realise how incomplete and buggy it is. I think I've fixed some of the problems, but it is far from being a useable feature.

• Projectlayer has been renamed to Layer Projector. Makes more sense to me.

• Changed the way files are loaded and made sure all supported file formats work as expected. Now only layered .svg files can be loaded, normal .svgs are rejected. This fixes Projector: TypeError on loading SVG #1360

• The Layer Projector can now load Prusaslicer SL1 and SL1S files! If you want to try it, you probably have to use a 'Scale' of 0.6 or so, because they have a higher resolution. One of the examples I used was this file:
  https://www.printables.com/model/297351-m3-nut-for-2020-5mm-profile/files

• Closing one of the two windows now closes the other as well.

• Perhaps the most important change: cairosvg has been replaced by wx.svg, which already comes with wxpython. This saves the extra dependency on that library. After comparing the output of the two libraries, I can confirm that wx.svg produces pixel-perfect the same result as cairosvg.

Tested on python win 3.10, mac 3.11 and 3.7.9.

[rockstorm101]

• I can confirm this successfully addresses Projector: TypeError on loading SVG #1360
• I don't use the layer projector feature myself so I cannot really print something to see if the output is correct. @DivingDuck, I believe you use this? Could you test it maybe? Though, if the output is pixel-perfect to what it used to be it should be no issue at all.
• I'm happy with the deletion of cairosvg as a dependency in favor of wx.svg. cariosvg is heavily hard-coded on Windows build actions and on release_windows.bat. So I guess some work will be needed on this regard. @DivingDuck what you think? Is it feasible?

[DivingDuck]

Hi @rockstorm101 , @neofelis2X ,
Sorry for answering so late. I was on a longer trip and came back yesterday.

Unfortunately I don't have access to this kind of printer for testing too. I only corrected the errors in the code that came with the switch from 1.x to 2.x back then and build a test file for testing (#1360) the program in general.

Anyway, I think replacing cairosvc with wx.svg is a good idea. Adjusting the windows build actions and releasewindows.bat is no problem. I can do that this weekend.

[DivingDuck]

Hi again,
I had today some time for testing. Over all I like the new Projector GUI. But there are some issues that need some attention:

1. Window management
   -->Projector -->Load -->Open File to Print
   After opening a file the Layer Projector Control window (and Projector Display window) went to background and the Pronterface GUI is selected as active Window (not every time, it seems to happen randomly?). This makes it very fiddly to come back to the control window. In addition the display window is as well somewhere and need to be found too.
   Better solution: After opening the file set window Layer Project Control in foreground as active window and window Layer Projector as second window.
   In addition don't allow to activate the main window of Pronterface while running the Projector instance (or block the menu item as long as one instance of projector is active). Why? Because you can call Projector again and then window handling become quite confusing as you now deal with additional windows and not knowing what is the window to deal with.

2. Calibrate
   The grid is working again, but the grid should use the same scaling as the scale value set under Scale in Layer Projector Control and should fit the Layer Projector Display window. Remark: The grid is respecting the offset (perfect).

3. Offset X and Y
   The Layer Projector Display do not respect the offset settings from Layer Projector Control. Therefore the model won't be printed on the correct location.

4. Decimal representation
   There are mixed representations, sometime as comma (for Scale, Overshoot, First Layer display time) and sometime as dot (for Layer, Exposure, Blank, Offset X, Offset Y, Projected X, Status for total height).
   In addition I guess we need some additional digits for layer height (Layer in mm) as the slices are mostly in microns (5 ... 150).

5. Other
   The calculation for height and width in status seems to be wrong for Slic3r svg files.
   Value for model height (Projected Z (?) --> not available jet and width (Projected X) can be take over from Slic3r-svg file
   (line 3: <svg width="182.5" height="134.5" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:slic3r="http://slic3r.org/namespaces/slic3r">)

I attach the screenshots and test file for my test below. Slic3r version was Slic3r-master.2020.08.24

#1387Test.zip

[neofelis2X]

Hello,
thank you for taking the time for testing, that's really helpful.
There are some very good points that you make and I can address most of them without problems. I can't say how soon I will have time for it tho. Some extra comments on point 1 and 2:

Pronterface GUI is selected as active Window (not every time, it seems to happen randomly?)

Maybe it happens randomly because as soon as you hover over the 3D OpenGL panel of the main GUI, the focus jumps to this window? This is a known bug (windows) and I am working on it in another branch. We could make the layer projector a modal dialogue that always stays on top. I will have a look.

In addition don't allow to activate the main window of Pronterface while running the Projector instance

Yes that is a problem with all of the panels (Platers etc.) and I already have a solution for it in my next PR. That PR is a bit bigger, already complete, but I'm still testing it. So I would not change it here now.

but the grid should use the same scaling as the scale value set under Scale

The grid should scale too? I thought the models scale and the grid always has 10x10 mm squares. Which ideally can be measured as pyhsical 10 mm on the display. I am going to give some thought to the whole resolution - dpi - millimetre pipeline. At the moment I'm confused about the difference between model size (mm) and display size (mm)

Have a nice day!

[neofelis2X]

Good evening, while I’m in the train it is a good time to upload the latest changes.
I took a very close look on how the files are transformed and presented.

1. I could not recreate this behaviour on windows, but I added a Raise() command after loading, just to be sure.
   Nothing done about multiple instances, but as I said, the problem of multiple instances of the same tool will be addressed in my next pr.
2. The grid has been rewritten to use a GraphicsContext and I made sure it has the correct dimensions. Please note: I deactivated offset and scaling of the grid for now. I believe the calibration grid should stay the same all the time and only the object has an offset and gets scaled. It can easily be activated if we want that. Further, the size of the grid is based on the X and Y resolution entered in the control panel. 
The display frame itself opens with 1024 x 768 px and can be made bigger by hand. A better solution is currently not implemented.
3. This has been implemented. Conversion from millimeter to pixel is corrected. Please note: Offset values are not scaled.
4. This has been implemented. All input fields are SpinCtrlDouble (float) or SpinCtrl (int) now. wxPython uses comma (,) for them and I can not influence that.
5. This has been implemented. Status gives out now a corrected and more helpful message. And width is imported from the svg file.
 Note: Newer versions of Slic3r (1.3.0+) export z-height in scientific notation. Something like slic3r:z="1.035e-006" I guess it’s a bug, but.. I’m not going to bother to work around this.

[DivingDuck]

Hi @neofelis2X
This looks nice. Thanks for the changes.

To 1.: This is solved now. I like this behavior.

I did a test and found a little glitch (sorry):
When you load a model in Prusa format (.sl1s), activate 1st layer: model is shown in the center
Now activate fullscreen: the model went out of center in direction top left.
When you unselect fullscreen and come back to the windows representation the model seems to shift more to top left.
When you try then to load an other model this model will also placed in the wrong place top left. This looks like you lost the coordinates. This happen as long as you don't close the projector module. Once it had been closed and restart the projector module everything is working correct as long you don't do the same procedure again.
With a slic3r .svg model I was able to force this behavior sometimes too when I activate the calibration grid and switch between fullscreen and 1st layer

Regarding Slic3R, there seems to be indeed something wrong with z. Need to look if I have somewhere an older version.

[DivingDuck]

@neofelis2X,
Regarding Slic3r, this is solved. The problem was sitting in front of the keyboard...
There are two ways to generate a svg file in Slic3R (-->File --> Slice to SVG... versus -->Window -->DLP Projector) and I hadn't recognize that the quick way (1st one) generating the svg file do not slice the model correctly.

I update my example
#1387Test.zip

[neofelis2X]

Hi @DivingDuck ,

thank you for looking at it again!
That the model is shown in the center was a very helpful information. That is a windows specific behaviour and is not what the frame should do. Long story short, I think this glitch is fixed now. A panel and sizer make sure now that the bitmap is always at the right place. Good that you noticed that. Now the offset also makes more sense, as it is always from the upper left corner.

There are two ways to generate a svg file in Slic3R

Ooh interesting, I overlooked that too. Yes, the new file works well.

[DivingDuck]

Hi @neofelis2X,
this is working very well now. As a little test I connect a 3d printer it move the Z axis like with a resin printer. Only rudimentary test but at least one that I can do for now.
Over all we can be very happy with the changes you made to this module. Thanks a lot for spending your time to make the module useful again.

What do you think, should we implement the changes now or is there anything you want to improve? From my side there is nothing what is against it and I will approve it too. Guess, @rockstorm101 is as well happy with the great work you did.

There are maybe two future feature requests from my side:

1. Implementing a slider for showing a specific layer like we have it for the gcode viewer. This will give a possibility to inspect layers of the model before starting a print or to continue a print on an specific layer.
   I think a good place for the slider in horizontal orientation can be between display and info section of the projector control window.
2. Adding the total and actual height in the info section during printing.

[neofelis2X]

Hello @DivingDuck, @rockstorm101
Great, thank you very much. It is motivating when the changes are well received :)
I would suggest that we implement the changes now. For now, hopefully it is a working and bug-free tool.
I'll be happy to come back to it after I've had a chance to finish some more urgent things. It seems that there are other, more critical parts of the interface that need updating. But your feature requests won't be forgotten. It would also be fun to rewrite it in a proper mvc or mvp pattern at some point.

[DivingDuck]

@rockstorm101, I will made the changes regarding the switch from cariosvg to wx.svg for Windows build actions and release_windows.bat as soon as this request is implemented.

[rockstorm101]

I would suggest that we implement the changes now.

I will made the changes regarding the switch from cariosvg to wx.svg for Windows build actions and release_windows.bat as soon as this request is implemented.

All good then! Thank you very much to both. Great effort!