Roadmap PFE / Most urgent issues

[NardJ]

@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:

1. 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:

   • (+) User only has to install one program.
   • (o) User only has to use one program.... however programs can call upon each other which could make the user experience transparent.
   • (+) Speed is faster, since we don't have to exchange (and thus import and export photon-files).
   • (o) Speed is slower since some components cannot be programmed in the most suitable/ faster language, like C++/Node.js... However, in python (language of PFE) we can use Cython successfully to speed up things (see Slicer for example)
   • (-) Development and bug hunting is more complex for bigger programs.
   • (-) Development is slower. When having different programs, each can be developed independently/Releases will be less frequent.

2. We are missing some things:

   • a voxel viewer which is maintained (Is Rob's application still maintained?)
   • integration with/of CAD open source functionality like openScad / freeCad
   • import of 3d formats apart from stl/photon/svg (multilayer)

3. Improve the following:

   • layer editing
   • file dialog

I would propose to simplify PFE to make development less complex and releases more frequent. For this we need to

• go back to basics, remove all functionality related to 3d viewing and slicing (and thus the need for OpenGL),
• investigate usage of tkinter for GUI elements instead of home brew GUI (which was necessary for usage in OpenGL).

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?

[thetrebor]

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

[X3msnake]

@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 :(

[thetrebor]

@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.

[X3msnake]

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 <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKke-vnPu1UIIYEOuj2kdyTPTiDQmQLWks5u_4VDgaJpZM4ZpyYx> .

-- Com os melhores cumprimentos, Vinicius Silva

[NardJ]

@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:

• Maybe I should also try a more common compression algorithm like zip files as exchange format.
• I'll also try to exchange data in memory, e.g. only exchange the memory address as a file and let the program read directly form memory (if possible/alllowed by OS).
  For reference and to update: Photonsters API

Btw: I do not suggest a visual revamp, just streamlining/minimizing the code base.

[X3msnake]

@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.

[X3msnake]

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

[NardJ]

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.

[X3msnake]

some ideas for compressing optimizing

@Photonsters/ppi

Perfect Spatial Hashing - Youtube | github | Paper

[NardJ]

new version is coming :-)

[X3msnake]

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 <#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