Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

matplotlib dependencies prevents from use in Rhino #153

Open
jf--- opened this issue Dec 14, 2021 · 2 comments
Open

matplotlib dependencies prevents from use in Rhino #153

jf--- opened this issue Dec 14, 2021 · 2 comments

Comments

@jf---
Copy link
Contributor

jf--- commented Dec 14, 2021

the following import statement:

from compas_slicer.post_processing import generate_brim

seems to rely on matplotlib

Expected behavior
matplotlib is tricky / impossible to install to on IronPython
hence this dependency renders compas_slicer incompatible with Rhino
moreover, since matplotlib is a pretty hefty package ( can depend on Qt5 in turn ) it takes a whopping ~10s to load

Desktop (please complete the following information):

  • OS: osx 10.10, Rhino 6
  • IronPython
  • compas 1.21.1
  • compas_slicer ( HEAD )

Screenshots

image

@jf---
Copy link
Contributor Author

jf--- commented Dec 14, 2021

  • factored out matplotlib, loading is still slow
  • btw on compas python this all pans, out, this is IronPython / Rhino specific
  • hmmm this is suspicious:

from .geometry import * # noqa: F401 E402 F403
from .slicers import * # noqa: F401 E402 F403
from .print_organization import * # noqa: F401 E402 F403
from .utilities import * # noqa: F401 E402 F403
from .post_processing import * # noqa: F401 E402 F403
from .pre_processing import * # noqa: F401 E402 F403
from .parameters import * # noqa: F401 E402 F403
__all__ = ["HOME", "DATA", "DOCS", "TEMP"]

  • yep, commenting the above out reduces the time to import from 11 -> 1s
  • that said, the pattern of loading all available (sub)modules continues, probably not a good idea, since "import compas_slicer" in turn will recursively load all modules; that feels heavy handed

# Polyline simplification
from .simplify_paths_rdp import * # noqa: F401 E402 F403
# Sorting
from .seams_align import * # noqa: F401 E402 F403
from .seams_smooth import * # noqa: F401 E402 F403
from .sort_into_vertical_layers import * # noqa: F401 E402 F403
from .reorder_vertical_layers import * # noqa: F401 E402 F403
from .sort_paths_minimum_travel_time import * # noqa: F401 E402 F403
# Orienting
from .unify_paths_orientation import * # noqa: F401 E402 F403
# Additional
from .generate_brim import * # noqa: F401 E402 F403
from .generate_raft import * # noqa: F401 E402 F403
from .spiralize_contours import * # noqa: F401 E402 F403
from .zig_zag_open_paths import * # noqa: F401 E402 F403
__all__ = [name for name in dir() if not name.startswith('_')]

@joburger
Copy link
Collaborator

Hi Jelle, so actually compas slicer is, at the moment, not designed to work directly within Rhino. Reason for this is to avoid all of the constraints of IronPython. So the envisioned workflow is as follows:

  • Export STL/OBJ from your favorite software
  • Run the Python slicing file (outside of Rhino)
  • Json files with slicing result are generated
  • Visualize json files in Grasshopper (or using compas viewers)
  • Repeat slicing if adjustments are needed

This is somehow described here (https://compas.dev/compas_slicer/latest/tutorials/02_grasshopper_visualization.html), but I realize it's probably not clear enough so will add some documentation to describe this workflow better.

Also, we are not considering making compas slicer available for current versions of Rhino, since CPython will be introduced in Rhino8, we would probably wait until R8 is out and then direct some efforts to integrate compas slicer into a Rhino workflow.

Cheers,
Joris

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants