Add these guys to the team members when you can ;)

[X3msnake]

@Reonarudo This is Leonardo from altLab Collective the maker of the PCB2PHOTON project and the hex template that made exposure test possible, we need to convince him to add his pcb2photon to this project.

@Antharon This is Ivan, came to us from the Photon forum, contacted me trough Fuste in the Anycubic Group. He wants to develop the algorithm to hollow models from 2D slices, he can also help with the 3D voxel visualization

These features added to the project can make the editor a cool swiss knife tool for modifying photon files

[NardJ]

Done! Didn't find a message box to explain them why I invited them. As I understand Antharon expects the invite, and Reonarudo could be surprised.

A Voxel engine was on my shortlist, would be very nice if Antharon can develop this! An I hope Reonarudo can clear up the usage of the remaining unknown bytes in the Photon file.

(Also as we now have the possibility to import bitmap slices made by another source than the Photon Slicer, it would be nice to also be able to calculate supports.)

[X3msnake]

Both were tipped beforehand. Reonardo is a close connection of mine since he was one of the original founders of our hackerspace and the first draft of the hex editor was discussed on altLab collective group

No dia segunda-feira, 18 de junho de 2018, Nard Janssens < notifications@github.com> escreveu:

Done! Didn't find a message box to explain them why I invited them. As I understand Antharon expects the invite, and Reonarudo could be surprised.

A Voxel engine was on my shortlist, would be very nice if Antharon can develop this! An I hope Reonarudo can clear up the usage of the remaining unknown bytes in the Photon file.

(Also as we now have the possibility to import bitmap slices made by another source than the Photon Slicer, it would be nice to also be able to calculate supports.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NardJ/PhotonFileUtils/issues/4#issuecomment-398055179, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-pFxW17qpufj9OxvjInompN05qqKks5t96wjgaJpZM4UrpTN .

-- Com os melhores cumprimentos, Vinicius Silva

[Rob2048]

Hi Guys,

I am also very interested in developing tools for the Photon. I have already made a voxel based previewer for the layer slices and will be uploading the code to my github shortly. I would love to see better automatic support generation as Photon Slicer is just terrible at that.

[Reonarudo]

Is there a list of existing utilities/features that are wanted? What should be tackled next?

From what I see @Rob2048 already solved all file parsing issues. (Looks great!)

Maybe we should organize ourselves a bit better if the team will be this big. From what I see @Rob2048 is developing in Javascript, @NardJ in Python and myself in Swift. What would be a good common base? Or should we just throw pseudocode at each other? 😄

The utility I was doing was meant for single layer exposure from an image but can easily be changed. More importantly, its a command line utility that can be run from another program. SO example.

[X3msnake]

I say we stick to python, it it powerful enough, easy enough for the common folks like me to understand, lots of libraries and more accessible to everyone in terms of keeping this most cross platform possible.

I can import the issue tags from the other python project and that will give us a great base for managing the issues.

@Rob2048 @NardJ @Reonarudo @Antharon what say you :)

---

btw the project is inkstitch a embroidery software for inkscape (python)

[X3msnake]

@Rob2048 @NardJ @Reonarudo @Antharon

Another question is do we make base project here or you guys prefer we create a organization for the project and build it there?

[X3msnake]

@NardJ @Rob2048 @Reonarudo @Andoryuuta @Antharon

While we decide on the above i started a list feature requests #7

[NardJ]

I myself am not a native Python programmer, but I did choose Python for two things: Its accessibility and thus to the amount of people who can contribute and substitute existing members if they want so themself in the future. The other main reason is that it is cross plaform and I myself use an linux pc with my 3D printer (for its stability).

O and do import the issue tags, they look very usefull.

I am not that familiar with Github and its organisation functionality. What are the benefits?

[NardJ]

@Rob2048 Really like that voxel engine!

[Reonarudo]

I don't know about working here or on a new repo, this is up to @NardJ . My repo has a very specific PCB related context so it would make no sense to further develop unrelated features there.

@X3msnake If we use the GitHub project management system I would suggest splitting all those features requests into individual ones. I'm also not very familiar with the GitHub project management functionality so I'm not sure if it would make sense to have something like a Trello to help us.

Another thing that we would need to do as a strong group is to agree on an architecture. This will allow us to develop the functionalities we are looking for and be flexible enough for future extensibility. I'm not very familiar with design patterns in Python but I'm pretty sure they cannot be that different from the GoF specifications. Also, this resource seems very useful(accompanied by the video).

Before developing new features we need to merge all our development into a single project. I have no idea about current Python project structure standards.

Please tell me if you think this approach is ok or if I'm over-engineering it.

[NardJ]

I agree and no not over-engineering. It's best to discuss this beforehand so we are all on the same page. So:

I have no problem if other utilities are brought to this repo. I think it is a lot easier for the developer to have everything in one place. For us as developers one repo would help sharing info and making sure the different tools work well together. On the other hand, if it is better to make a new GitHub repo, I also have no problem to migrate to there.

I think an agreed upon architecture is best. (I am also not very familiar with design patterens.) As a sidenote: In my opinion the programming code should remain readible for average Photon users/programmers so they can contribute to further development. Because of this I am a bit opposed to using overly deep hierarchial or abstract class systems.

Regarding merging: If we agree Python as the main language is best, I don't know (yet) if Python can call upon functions written in other languages. If not possible we should decide whether we merge by rewriting code in Python (or vice versa) or keep the utilities seperate but calling on them like external programs and reading results from diskfiles. (like PCB which for instance could be called by the PythonEditor from a commandline and reading the results from disk)

I don't think we should stop developing until it's fully merged, but we should keep merging in mind and document our code well (This is something I have to put some time in.) Of course while merging we should stop development.

[Reonarudo]

@NardJ Regarding external tools like the PCB, a nice trick of being able to run command line functions is that you can pipe the results to your own input. I'm not sure if it is possible with Python. If there is a well-established support for this in the language it could help mitigate this issue.

@NardJ I agree that the structure should not be too deep or abstract but it still should be sound even if some aspect will indeed be too complicated for a new user. New users are not meant to start extending complex parts of a program. They have to ease into it. That said, my opinion is that we should keep a simple core structure and VERY GOOD documentation. 📖

I vote (is this a democracy? 😄 ) that we keep everything in this repo. What is the best way to proceed about dis/agreeing on issues? Is there a voting system on GitHub?

I don't mind migrating and maintaining a Python code base. I should have already taken some time to learn more advanced Python. 🐍

Anyway, I'll await other people feedback before going further down the rabbit hole.

[NardJ]

@Reonarudo, I completely agree on structure/documentation/repo. Piping info to Python seems possible with subprocess library, see these examples.

Awaiting other votes...

[X3msnake]

Ok guys, here is the place then. :)

Let's avoid other channels like trello or stuff, we can manage all here.

• There is a kanboard like tool in the project (image below)
• We can use travis to do automatic releases for multiple platforms if we chose to (ask @lexelby if you need help on setting it up)
• And communications should all be public so that anyone interested can keep track of the development and heartbeat of the project, we at inkstitch have a free talk issue marked as not issue and named as discussion forum. Using the issue sistem as a comunication is a great way as long as we keep it tidy and tagged
• Also good for communications is that you get a mail if you are mentioned in a issue and can reply back from email and go into a reply and edit with backlog. so it is quick and convineent
• It is easy to refer other issues directly, and for the wiki uploads if we don't want to go full fledge with gitpages as we did in inkstitch we can easyly add images with a small trick i foun. Start a new issue dra-n-drop or paste from clip copy the code it gives you and past in the wiki, then just exit the issue without commiting it, the image is uploaded and there to use as long as you know that code :)

Issues can be closed automatic by refereing to their number with releases

[iplayfast]

You might be interested in this guys stuff. https://github.com/doug-moen/curv

[Reonarudo]

@iplayfast looks cool but 3D prints are rarely based on mathematical functions. But maybe we can take some ideas from there.

@X3msnake for communications I would suggest using Gitter. It is less messy, public and has all the nice features. But again up for community vote. The Kanban board looks cool, didn't know there was one in GitHub.

[iplayfast]

I agree, that 3d prints are rarely based on mathematical functions, but that is because 3d prints are based on triangle models. This isn't which makes it perfect for proton. (slice is just a segment of the mathematical model). Just suggesting you keep it in mind. It's in heavy development as an openscad type language. If you can import the slices as bitmaps, then you will probably be compatible.

[X3msnake]

@Reonarudo gitter is not bad, but i still rather have all in one place rather than bouncing around between platforms trying to find where we talked what.

My vote is all here.

@iplayfast thanks for the tip, we will keep a look on it, but i think the implementation of thes math model won't come in handy before we decide to add ability to do som form of automatic placement of supports :)

[Antharon]

Hi people, I am sorry for starting by inactiviti, but this is a hell of a week in work.

But let's jump to voxel manipulation roadplan.

1, I want to start with implementing conversion to binary voxels and back. Since we work with black and white bitmaps for these algorithms would be best representation three dimensional array of binary values. This might increase speed a little and keep memory usage at bay.

2, then I want to implement simple boolean functions for two overlaying voxel groups. It is necessary for hollowing objects and will be usefull in loads of future functions

3, then we need to implement erode function, it will shrink model and in combination with boolean difference, we will be able to create empty shell of wanted size. This will be enough to hollow simple shapes.

4, for more complex shapes we need closure function. It finds narrow spaces and fills inaccessible areas. This will discard small hollows that might hold uncured resin or produce sucction.

5, at this point we will have tool to print hollow models (holes might be made with booleans). Much nicer would be automatic detection of best placement and sizes for holes.

6, this will be similar to automatic support creation. With ability to detect new islands, we can drop supports. I do not know how to generate tree supports, but there is lot of time to make research.

7, last step is generation of internal infill structures, which combines with booleans will nicely fill hollow.

8, at this point we will have working suite to print hollow models

[NardJ]

@iplayfast: On facebook Julian Braun commented about Povray (raytracing language/engine). He notes:

I render only with ambient light and a camera up in infinity. Then I shift a plane upwards which cuts away the lower part. The result are just cut images as we would need it. I save a load of cut PNGs to disk. It is not a visual environgment but if the 'import bitmaps' functionality is working correctly this is very easy to implement. (Although support generation is still essential.)

I also vote to have all here.

@Antharon: Sounds great! Is this doable within Python and which libraries are you planning on using?

[NardJ]

Never done something like this on github, how does this work? Do we need to appoint a projectmanager/leader to extract results from discussions, set the path forward and 'issue the work orders'? (If so we should check who is willing to fill this role)

[Rob2048]

I agree with the collaboration all happening in one place, however my tool is specifically designed for use through a web browser.

I'm going to continue development on my tool but I'd be more than happy to help out on this too, porting any of my code to python as needed, and maybe copying back some of the ideas here if people are okay with that.

[Reonarudo]

@Rob2048 I would say that is exactly what it is expected. No one wants you to abandon your projects 😉

@NardJ We are on the same boat... never have done this through GitHub. @NardJ What was the rationale behind using pygame as GUI?

[X3msnake]

Anyone on the team can open edit set milestones etc...

https://help.github.com/articles/about-project-boards/

[Reonarudo]

@X3msnake but there is no team yet. 😉

[X3msnake]

All ppl in this issue have been added to the github project in open source dev. I consider core team the ppl who has direct editing permissions and the ppl in this issue do.

No dia quarta-feira, 20 de junho de 2018, Leonardo Marques < notifications@github.com> escreveu:

@X3msnake https://github.com/X3msnake but there is no team yet. 😉

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NardJ/PhotonFileUtils/issues/4#issuecomment-398699586, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-vmeZBqyCRexMtwZbd-IUvDJ2id0ks5t-iE-gaJpZM4UrpTN .

-- Com os melhores cumprimentos, Vinicius Silva

[NardJ]

@Reonarudo: Rational behind Pygame was my experience with it, the good documentation online and the ease of installing it (I didn't encounter any dependecies).