Closed neofelis2X closed 8 months ago
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?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.
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:
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.
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).
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.
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).
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
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:
1.
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.
2.
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!
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.
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.
@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
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.
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:
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.
@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.
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!
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 #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.