Open NardJ opened 5 years ago
So the thing I would really love is a complement to chitubox.
I suspect they are going to be the go-to community available solution for slicing, preparing, supporting, and exporting.
The things that I would need that are photon specific that are unlikely to make it into chitu are things like: post processing slice images with masking checking for islands checking for artifacts (slicing errors, misplaced triangles, thin shells) after the fact editing of photon files (changing layer time, base layers, etc)
but overall i've loved this project and it was very helpful in understanding my photon
@NardJ Rob has fallen off the map, something must have happened to him since there is no activity on his github account nor his pages.
If the idea is to revamp and repack the PFE then I sugest we revisit the common file type?
@thetrebor What you are asking for is already implemented in the Validator no?
It would make more sense if we could just tie everithing together but keep it easy to use modules, makes no sense to have each project use it's own .photon writer, when we could all be using the one that is better optimized and could that way call another packer for another future format. not sure how easy this can be done tho :(
@X3msnake I'll take a look at validator, didn't know it did all that. Conceptually i think there are several phases to the operation, and it's okay if they are separate programs: Model (cad/cam, blender, etc) Model Prep: slice, support, hollow (chitu, mango, etc) Printer Prep: resin settings, dope chart, mask, operator checklist ( current gap ) Print (Photon Firmware)
The printer prepare step would be taking a generalized sliced model for a Photon class machine and then specializing it for a particular photon / resin combo. I think PFE might best fill that gap, somehow. Alternatively you're running up against well funded efforts to make feature rich generalized slicers. Just my thoughts.
you should also try the Slicer CLI that Nard made, it allows you to slice directly from meshmixer into a .photon file
all projects are listed in photonsters.org
Robert Maefs notifications@github.com escreveu no dia sexta, 4/01/2019 à(s) 16:45:
@X3msnake https://github.com/X3msnake I'll take a look at validator, didn't know it did all that. Conceptually i think there are several phases to the operation, and it's okay if they are separate programs: Model (cad/cam, blender, etc) Model Prep: slice, support, hollow (chitu, mango, etc) Printer Prep: resin settings, dope chart, mask, operator checklist ( current gap ) Print (Photon Firmware)
The printer prepare step would be taking a generalized sliced model for a Photon class machine and then specializing it for a particular photon / resin combo. I think PFE might best fill that gap, somehow. Alternatively you're running up against well funded efforts to make feature rich generalized slicers. Just my thoughts.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Photonsters/PhotonFileEditor/issues/98#issuecomment-451498808, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-vnPu1UIIYEOuj2kdyTPTiDQmQLWks5u_4VDgaJpZM4ZpyYx .
-- Com os melhores cumprimentos, Vinicius Silva
@X3msnake I'll do some tests what causes the main slowdown when exchanging data between programs: reading/writing data of decoding/encoding images. Some other ideas:
Btw: I do not suggest a visual revamp, just streamlining/minimizing the code base.
@NardJ
Well if we are thinking and well imho in using Tkinter then we might as well think if we want to spruce up something in the GUI
I for once like the choice of a horizontal display of the layers like @bonosoft chose for the interface, the two main reasons is, it is more natural when you look at the machine (landscape) and also it fits the scren layout better.
I am in debt when it comes to this UI thing since i promised a mockup that i never dedicated the time to do.
we can use something like PyGubu - video or to quickly rebuild the UI for Tkinter
Other similar Rapid App Dev tools for Tkinter are; Visual Tkinter | PAGE | Rapyd Tk
https://stackoverflow.com/questions/14142194/is-there-a-gui-design-app-for-the-tkinter-grid-geometry
As alternative we can us Qt Designer and pyqt or qtpy to transform that UI files to .py. https://www.youtube.com/watch?v=Dmo8eZG5I2w
I agree, why not make the GUI better at the same time. Should not be too difficult in Tkinter.
For data exchange I found this on wikipedia. Pipes and shared memory seem possible candidates. These will rule out any delay by file writing/reading.
new version is coming :-)
Awsome Master
No dia segunda-feira, 22 de julho de 2019, Nard Janssens < notifications@github.com> escreveu:
new version is coming :-)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Photonsters/PhotonFileEditor/issues/98?email_source=notifications&email_token=ACUR56QD32IKHJ6YUKZ3H2TQAWFDZA5CNFSM4GNHEYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2PQUUY#issuecomment-513739347, or mute the thread https://github.com/notifications/unsubscribe-auth/ACUR56XWANAHNC3NN55654DQAWFDZANCNFSM4GNHEYYQ .
-- Com os melhores cumprimentos, Vinicius Silva
@Photonsters/photon-file-editor Hi all, I am planning on doing some development of PFE and have some thoughts which I wish to share. Please comment:
PFE was initially meant to be a one-stop-solution. However at this moment we have separate projects like VoxelOps, Validator and Slicer. Some pros (+) and cons (-) of the one-stop-solution:
We are missing some things:
Improve the following:
I would propose to simplify PFE to make development less complex and releases more frequent. For this we need to
After this we can take care of the improvements after which extra functionality can be implemented.
So what do you think about this? Is this the way to go? Did I omit points to consider?