At the moment we have different options for planar slicing:

• meshcut
• numpy
• Cgal
  Which work well and which don't? Ideally they should all have identical output, i.e. the result should not depend on which method one uses.
  Investigate what works well and what doesn't. Remove the functions that don't work, or fix them. However, we should still have options for how to slice, and ideally they should not all depend on fancy libraries

Write tests!
Use tests!

Currently, tests are very outdated, and we never really used them anyway. Update tests, and add new ones for the additional classes. Then agree on a workflow where they are used!

I updated the align Seams function so that it also works with open paths. However, currently the align seams works with the next path. This is a bit weird, because on the next iteration we change the next path and so on. In my eyes it would make more sense if 'align seams' considered the previous path instead, which has already been changed. @joburger what do you think?

Proof of concept has been created, works with simple shapes.

-Test on more shapes. Especially shapes with separate branches.
-Open/closed contours, is it easy to evaluate that based on the initial mesh connectivity?
-Test on high resolution shapes to find where its limitations are.

Using 'compas_numpy' as a slicer gives buggy, or no results. @Ioanna21 maybe we should remove that functionality for now? We would still have 3 slicers that we can offer which is also pretty good.

Check that export .to_data() and import .from_data() exists for all classes. Update where missing/incomplete

Currently, unify_paths_orientation(slicer) not only orients the paths, but also seems to remove some points, see image:

I would expect the function to not remove any points but only switch the orientation of the curves and leave all points intact, as such:

The behaviour seems to be caused by this section of the code, because if I uncomment items.rotate(1) the behaviour is as expected, at least for example1.

if dot_vectors(v1, v2) < 0:
        items = deque(reversed(pts))
        items.rotate(1)  # bring last point again in the front
        pts = list(items)

Could you change the behaviour of unify_paths_orientation so that it does not remove points @Ioanna21 ?

Apparently, Blender would be a better option than Rhino, because all libraries can be installed there. However, it is not really part of our workflow. Does it make sense to investigate this?

It could be useful to store a list of the slicing parameters (layer height, generate_brim or not, simplify_points or not) that can then be accessed during the process, as well as stored for reference.

-Add visualization of the tool on grasshopper
-Add visualization of the print paths geometry

However these are not the highest priority at the moment

generate_robotic_commands_dict in the RoboticPrintOrganizer class should be extended to include additional printing parameters such as robot speed, acceleration, fillet radius, and others.

It also has to be considered if this can already be made general enough for multiple robots, or that different files would need to be generated for different robot types.

Investigate

Describe the bug
When slicing the model simple_cylinder_closed_mid_res.obj' with the default slicer, it seems like duplicate paths/layers are being generated. This also happens when the STL file is imported instead of the OBJ. However, it does not happen when cgal is used as a slicer. Should be investigated.

To Reproduce
Steps to reproduce the behavior:

1. Run the example file with

MODEL = 'simple_cylinder_closed_mid_res.obj'
slicer = PlanarSlicer(compas_mesh, slicer_type="default", layer_height=15)

Check if the len(layer.paths) == 1, as it should be.

We need to decide on what features we want to have ready for the students, and 'freeze' them in the main branch. Everythign that is there needs to be properly documented.

For everything else, we create a development branch that we can keep working on.

Add set_ functions to for example override the velocity, or extruder_toggle

Currently only closed print paths are supported.

The class Path has a boolean self.is_closed which is currently always set to 'True'. We should have a robust method that checks if the path is open or closed and assign the value to this boolean correctly.
Investigate which strategy would work best. We used to have a distance-based check, but that could easily fail depending on the points positions. A better check for opne/close strategy needs to be found

Also this self.is_closed should be used in:
-the visualisation methods (open paths should not have their ends connected)
-The generation of fabrication commands (robotic commands AND gcode). The extruder on/off should be set accordingly
Also, where to add Zhop? Only at the print interruptions, not at the beginning of every path.
-Other places where this should be changed? Investigate

Since the sorting_shortest_path algorithm, the following warning always appears:

C:\ProgramData\Anaconda3\envs\compas_am\lib\site-packages\sklearn\externals\six.py:28: FutureWarning: The module is deprecated in version 0.21 and will be removed in version 0.23 since we've dropped support for Python 2.7. Please rely on the official version of six (https://pypi.org/project/six/).
warnings.warn("The module is deprecated in version 0.21 and will be removed "

I tried updating scikit-learn, but the warning persists.
Is this something to be worried about? Which library/function does it refer to?
Ideally we shoudln't use deprecated apps, unless there's no other way

Currently we have a lot of different models in the data/test_geometries, but we haven't really properly organized them.
We need to clean them up, and then create some naming convention that shows if the shape is
-watertight or open
-low poly or high poly
-what else?

This naming convention could then be used for the testing.

When extruder_toggle_type="off_when_travel" in the PrintOrganizer, the command add_safety_printpoints does not show the correct behaviour, since it adds a z_hop movement for every printpoint, as they are all set to False. See image.

The current export is incomplete. Add all the information that is needed for the commands export. Also, make it reconfigurable (i.e. the user can decide what information should be exported)

There should be a check to see if a brim is being generated, and if so: the behaviour of smooth_seams has to change

Restore curve slicing, according to the new slicers configuration

There are two things to consider:

1. Brim layer should not add safety printpoints between ever offsetting path, they can be print in one continuous motion.
2. Investigate if the decision on where to add safety printpoints could be simplified. At the moment we have two checks: (a) is it an interruption? and (b) is is the first point of a path that is not in the first path that comes after a layer of multiple paths whose last point had extruder_toggle=False. We generate one ppt whenever one of those two checks results to true. Instead we could simplify it be generating two ppts for the check (a). Investigate

Test with:
-planar slicing, single path per layer
-planar slicing, multiple paths per layer
-non-planar slicing.

We discussed that it is beyond the scope of compas_slicer to export robotic commands. Instead it will export instances of the PrintPoint class that have an orientation (plane), plus all the fabrication-related attributes (blend radius, extruder toggle, safety points and so on).

So concretely speaking.
-We simplify the print organizer so that it doesn't take a robot as an input.
-Export of robotic commands becomes export of Printpoints
-Change grasshopper file to correspond to the new things.
-Other changes that will be triggered by this

Investigate how github actions and how they could facilitate the compas_slicer processes

Is the robot transform really needed?
Weird results
Investigate

There seems to be a bug when using seams_align with the branches_70.stl file, as it deletes too many points.
Investigate.

A good idea was to put it under a very weird address, so that only the people we give it to can find it.
Another idea was to ask the IT department to put it on a server, so that we can control the access.
Decide what we want to do and put it in place.

The function compas.datastructures.mesh_contours_numpy produces very imprecise results. (Run 2_basic_slicing_example.py where the issue is obvious)
Investigate if this can be improved, or find better strategies

What is more, there is an issue with the last point of every curve. It seems that it considers every curve closed and adds the start point at the end. As a workaround, for now, I just remove the last point from every polyline outputted by the contours function, but I am not sure if that's the best strategy. Investigate.

Basic profiling of slicers and print_organizers

Find out if the mini facade projects plans to use infill for the structures, and in what way.
Ask if the facade example geometry can be used as an example for compas_slicer.

Apparently there is a really useful library that checks if something has been updated and only then recomputes:

https://docs.python.org/3/library/shelve.html

This can also somehow be used for the visualization in grasshopper, so that you don't need to press a button every time to update the jsons.

Investigate

The installation of the ml rose library was causing problems with the pytest.

Also, the sorting algorithm did not really return a good job and was very slow. I archived the function at the scripts folder, in order to be able to complete the pytesting. It would be great if we could find a better alternative for that sorting. I can ask Andrei who had mentioned that he had implemented his own function that does this job. Are there any other C++ libraries that could help with this?

Find out how to bring this feature from startum as a pre-processing step that happens before the slicing

Currently, some of the methods that we use are part of the Slicing class (slice_model, generate_brim) and some are not (simplify_paths, align_seams). We should have a clearer logic behind this, and possibly restructure.

Probably the python functions should be saved in the compas_slicer repository, so that they are easier to maintain. Also the grasshopper definitions should be turned into python / C#.

Create new folder called 'Functionality' that has all of the functions that we use and are currently in 'Positioning', 'Sorting' etc.
Remove these folders and only keep:

• Geometry
• Fabrication
• Slicers
• Functionality
• Utilities

Also every new function will currently go into Functionality, and we evaluate later whether to create a subfolder structure in there.

How can we add screenshots in the online documentation?
Decide on the 3/4 examples that we want to put up, and properly document them.

Currently we have two options:

1. compas viewer. It is very easy to use, the window appears automatically. However it is not so flexible as a visualization method

2. Export to Json, and visualization in Grasshopper.
   This is more flexible, but the current export only includes very few aspects of the slicer.
   The process should be:
   a) extended and
   b) properly documented, so that new people can understand and use it.

Currently the installation process of the package is rather tedious, relying on multiple repositories and many commands on the command line. It should be looked into how to simplify this process, so that it is more accessible for a wider audience.

Let's add here discussion topics for Wednesday / Friday:

-Add seam_align and unify_orientation of paths as default part of the slicer. These are always needed, maybe then we could them? Yes we do that
-Safety points. What do we want them to do? Check relevant issue

We should have a critical look at the examples, see which ones are necessary and which ones might not be.

The max_speed and min_speed are switched. Should be changed.

Archive materials and cleanup.

"""
hey @ioanna Mitropoulou something else: I was thinking it might make sense to also remove the MachineModel and the Material classes for now, since we are not really using them. In the example we are just calling them but then we are not using them.

--- Fabrication

robot_printer = RobotPrinter('UR5')
material_PLA = Material('PLA')
I think maybe in general we might not need 'Material' since I think often users want to set their own print speed, temperature etc. anyway and not use standard values, since robotic printing is not a standard process anyway. We can have some standard values but imo they don't have to rely on different materials.
Then as for robot models, I think for now our export is still general enough to be used by any kind of robot right? Sure we are focusing on UR's, but currently we are not yet changing something to make it only UR specific. I think at the current moment, compas_slicer is also more of a general slicing tool, which then allows the user to pick their favorite robot and command generation tool, right?
"""

Now compas comes with a plugin that allows to call compas_cgal without importing it, as long as it has been installed.
-Investigate it this works
-Change the code to work like that

Many commands and classes have no documentation or outdated documentation. Bring them up to date.

There are some packages that are only available through mini-conda, like igl.
-in the build.yml install miniconda, and then install igl.
-Then change all the igl imports so that they are normal imports

For example: generate_gcode, ..., ...
Investigate if more

When running example_1 with a layer height of for example, 10, there are paths resulting from the slicing process that are not closed, whereas they should be. I haven't properly investigated but the problem seems to be there.

It appears when using the default slicer in some of the small 'branches' of the model (see image 1). When slicing using cgal it seems good, but then there is one other path (in the middle of the geometry) that is also not closed.

The images just show the export of the slicer, so not the printpoints or additional functions are used. There are some messages about duplicate printpoints however, so that could maybe provide some clues on what is wrong.

The invoke docs routine doesn't work, it produces the following error. I initially thought that the problem was that there were various forgotten 'compas_am'. I renamed them all, but the problem remains. Investigate

Running Sphinx v2.1.2
C:\ProgramData\Anaconda3\lib\site-packages\sphinx\util\docutils.py:311: RemovedInSphinx30Warning: function based directive support is now deprecated. Use class based directive instead.
  RemovedInSphinx30Warning)
C:\ProgramData\Anaconda3\lib\site-packages\sphinx\events.py:103: RemovedInSphinx30Warning: autodoc_default_flags is now deprecated. Please use autodoc_default_options instead.
  results.append(callback(self.app, *args))
[autosummary] generating autosummary for: api.rst, api\compas_slicer.rst, examples.rst, gettingstarted.rst, index.rst, intro.rst, license.rst
Failed to import 'compas_slicer': no module named compas_slicer
loading intersphinx inventory from https://docs.python.org/objects.inv...
intersphinx inventory has moved: https://docs.python.org/objects.inv -> https://docs.python.org/3/objects.inv
loading intersphinx inventory from https://compas-dev.github.io/main/objects.inv...
intersphinx inventory has moved: https://compas-dev.github.io/main/objects.inv -> https://compas.dev/compas/objects.inv
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 7 source files that are out of date
updating environment: 7 added, 0 changed, 0 removed
reading sources... [100%] license
WARNING: autodoc: failed to import module 'compas_slicer'; the following exception was raised:
No module named 'compas_fab'looking for now-outdated files...
C:\dev\compas_slicer\docsource\examples.rst:5: WARNING: toctree glob pattern 'examples/*' didn't match any documents
none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] license
C:\dev\compas_slicer\docsource\api.rst:5: WARNING: toctree contains reference to document 'api/compas_slicer' that doesn't have a title: no link will be generatedgenerating indices...
C:\dev\compas_slicer\docsource\api.rst:5: WARNING: toctree contains reference to document 'api/compas_slicer' that doesn't have a title: no link will be generated
C:\dev\compas_slicer\docsource\api.rst:5: WARNING: toctree contains reference to document 'api/compas_slicer' that doesn't have a title: no link will be generated
C:\dev\compas_slicer\docsource\api.rst:5: WARNING: toctree contains reference to document 'api/compas_slicer' that doesn't have a title: no link will be generated
 genindex
writing additional pages... search
copying static files... done
copying extra files... done
dumping search index in English (code: en) ... done
dumping object inventory... done
build succeeded, 6 warnings.

The HTML pages are in docs.