
Si le composant charnière contient des sous-composants, ce sont ces sous-composants que prendra OpenCutList.
Il te suffit donc d'éclater ses sous-composant pour en refaire des groupes seulement et alors seul le composant charnière sera vu comme un "pièce" par OpenCutList.
Chaque sous groupe peut avoir la matière que tu veux.
Pour que la charnière soit vu avec une matière type Accessoire, il suffira d'appliquer cette matière sur l'instance.

Salut,
Tu devrais trouver des infos sur les plans de section en vue de les utiliser dans Layout dans cette vidéo.
Par contre, merci d'apprécier l'export vers Layout d'OpenCutList, mais sur ce coup, il ne sera pas ton copain, malheureusement.
En effet, cet export redessine les pièces exportées et crée un modèle temporaire pour les intégrer dans Layout. Donc, même si tu as mis des plans de section dans ton modèle SketchUp, ils ne pourront jamais apparaitre dans Layout par cet export.

Si les matières de Scalp ne te servent pas et que par définition elles n'ont pas de type. Tu peux utiliser le bouton Filtres (l'entonnoir à droite) pour masquer les matières Sans type.
Tu peux même faire un double clique sur un type pour ne voir que celui-là.
En passant, depuis cette interface, tu peux aussi :
- Faire un double clique sur une matière pour l'éditer
- Appuyer sur la touche + du clavier pour ouvrir directement la fenêtre d'ajout d'une matière
- Défiler dans les matières avec les flèches gauche / droite du clavier
... Mais c'est pas la question


Salut,
FredoSpline, permet de choisir le nombre de segments dans ce type de courbes.
C'est une extension payante, avec démo de 15 jours.


J'ai pas de solution miracle à te proposer. J'avoue avoir pesté longuement contre les faiblesses de FaceSVG et c'est pour ça que je suis en train de travailler sur une fonction remplaçante pour OpenCutList .
Mais pour le moment, ce n'est pas encore dispo.
Sinon, pour répondre un peu à la question, FaceSVG me semble donner de meilleurs résultat si la face que tu sélectionnes n'est pas trop loin dans l'arborescence de ton modèle.

Si tu veux aller plus loin dans l'analyse du temps sur chaque tâche d'un projet. Tu peux utiliser les Processus.
Tu peux lancer chaque tâche, la mettre en pause et la reprendre et voir le temps que tu y as passé.
Et même essayer de battre ton record si tu refais le projet :)

Bonjour deportivo35,
L'idée est séduisante, mais j'ai peur que la finalité ne corresponde pas bien à la manière dont OpenCutList et SketchUp gèrent les matières.
Contexte
OpenCutList utilise les matières natives de SketchUp et leur ajoute simplement des métas données.
Ce qui veut dire que la façon dont sont enregistrées les matières est celle de SketchUp.
Dans SketchUp il faut distinguer 2 états pour une matière :
- quand elle est sous la forme d'un fichier SKM dans un répertoire externe défini comme une Collection de matières.
- quand elle est dans la liste des matières d'un modèle.
Dans l'état 1. la matière peut être copiée dans n'importe quel modèle, mais n'est pas directement modifiable.
Dans l'état 2. la matière est une copie propre au modèle. Elle est modifiable, mais les changements ne seront pas répercutés dans la matière origine de la collection si elle en est issue.
Importer des listes ?
Dans ce contexte, je pense que ce que tu veux, c'est te créer une collection de 500 matières. Et non pas avoir 500 matières dans ton modèle.
OpenCutList ne connait que les matières contenues dans le modèle actuellement ouvert. Il ne connait pas du tout les collections externes.
Bien entendu, il ne serait pas techniquement impossible d'écrire un petit bout de code qui va créer à partir d'un fichier texte une liste de fichiers SKM pour les enregistrer dans le répertoire d'une collection. Mais ça resterait un outil assez déconnecté du fonctionnement de l'onglet Matières d'OCL qui ne liste que les matières contenues dans le modèle.
J'ai donc du mal à voir comment OpenCutList pourrait répondre correctement ce besoin.


Pour avoir décortiqué le code de FaceSVG pour trouver des solutions pour OCL, je dirais que c'est étrange, mais pas impossible.
En effet, comme on le sait, les cercles n'existe pas dans SketchUp. Ce sont en fait des polygones à X facettes.
Pourtant si un cercle n'a pas été trop transformé, SketchUp garde l'information que cette suite de segments est une ellipse avec ses deux rayons (sous forme de vecteurs). Rayons qui seront identique si on a pas étiré le cercle.
C'est cette information que FaceSVG va utiliser pour recréer un path dans le fichier SVG qui va simuler les cercles, arcs, ellipses.
Mais le format SVG à sa manière de faire pour définir un arc via un Path. C'est pas juste un centre et un rayon. C'est sacrément tiré par le cheveux, mais offre un plus large façon de définir ce type de ligne.
A rx ry x-axis-rotation large-arc-flag sweep-flag x y
Du coup, ça ne me semble pas impossible que le calcul que fait faceSVG capote dans certains cas, notemment sur le calcul des flags ou du point central de la courbe.
J'espère qu'OpenCutList fera mieux. Mais même s'il aura une stratégie différente pour récupérer les rayons, il aura une façon similaire de décrire le trait en SVG :)
Et voici ce que OCL 6.0 va exporter de ton modèle. C'est du SVG, faudra faire un copier coller dans un nouveau doc :)
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generator: SketchUp, OpenCutList Extension, Version 6.0.0-dev -->
<svg width="386.5mm" height="190.0mm" viewBox="0.0 -190.0 386.5 190.0" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:serif="http://www.serif.com/" xmlns:shaper="http://www.shapertools.com/namespaces/shaper">
<g id="OCL_DRAWING">
<path stroke="none" fill="#000000" shaper:cutType="outside" shaper:cutDepth="18.0mm" d="M 136.496,-13.9 A 30.0,30.0 -0.0 0,1 145.283,-35.113 A 30.0,30.0 -0.0 0,1 166.496,-43.9 L 196.496,-43.9 A 30.0,30.0 -0.0 0,1 217.709,-35.113 A 30.0,30.0 -0.0 0,1 226.496,-13.9 L 226.496,-0.0 L 386.5,-0.0 L 386.5,-190.0 L 0.0,-190.0 L 0.0,-0.0 L 136.496,-0.0 L 136.496,-13.9 Z M 2.0,-158.0 A 6.0,6.0 0 0,1 14.0,-158.0 A 6.0,6.0 0 0,1 2.0,-158.0 Z M 372.5,-158.0 A 6.0,6.0 0 0,1 384.5,-158.0 A 6.0,6.0 0 0,1 372.5,-158.0 Z M 50.0,-123.864 A 10.0,10.0 0 0,1 70.0,-123.864 A 10.0,10.0 0 0,1 50.0,-123.864 Z M 146.0,-123.864 A 10.0,10.0 0 0,1 166.0,-123.864 A 10.0,10.0 0 0,1 146.0,-123.864 Z M 242.0,-123.864 A 10.0,10.0 0 0,1 262.0,-123.864 A 10.0,10.0 0 0,1 242.0,-123.864 Z M 338.0,-123.864 A 10.0,10.0 0 0,1 358.0,-123.864 A 10.0,10.0 0 0,1 338.0,-123.864 Z M 98.0,-75.864 A 10.0,10.0 0 0,1 118.0,-75.864 A 10.0,10.0 0 0,1 98.0,-75.864 Z M 194.0,-75.864 A 10.0,10.0 0 0,1 214.0,-75.864 A 10.0,10.0 0 0,1 194.0,-75.864 Z M 290.0,-75.864 A 10.0,10.0 0 0,1 310.0,-75.864 A 10.0,10.0 0 0,1 290.0,-75.864 Z M 2.0,-32.0 A 6.0,6.0 0 0,1 14.0,-32.0 A 6.0,6.0 0 0,1 2.0,-32.0 Z M 372.413,-32.0 A 6.0,6.0 0 0,1 384.413,-32.0 A 6.0,6.0 0 0,1 372.413,-32.0 Z M 50.0,-27.864 A 10.0,10.0 0 0,1 70.0,-27.864 A 10.0,10.0 0 0,1 50.0,-27.864 Z M 338.0,-27.864 A 10.0,10.0 0 0,1 358.0,-27.864 A 10.0,10.0 0 0,1 338.0,-27.864 Z" />
<path stroke="none" fill="#656565" shaper:cutType="pocket" shaper:cutDepth="6.0mm" d="M 2.0,-158.0 A 6.0,6.0 0 0,0 14.0,-158.0 A 6.0,6.0 0 0,0 2.0,-158.0 Z M 372.5,-158.0 A 6.0,6.0 0 0,0 384.5,-158.0 A 6.0,6.0 0 0,0 372.5,-158.0 Z M 4.0,-158.0 A 4.0,4.0 0 0,1 12.0,-158.0 A 4.0,4.0 0 0,1 4.0,-158.0 Z M 374.5,-158.0 A 4.0,4.0 0 0,1 382.5,-158.0 A 4.0,4.0 0 0,1 374.5,-158.0 Z M 2.0,-32.0 A 6.0,6.0 0 0,0 14.0,-32.0 A 6.0,6.0 0 0,0 2.0,-32.0 Z M 372.413,-32.0 A 6.0,6.0 0 0,0 384.413,-32.0 A 6.0,6.0 0 0,0 372.413,-32.0 Z M 4.0,-32.0 A 4.0,4.0 0 0,1 12.0,-32.0 A 4.0,4.0 0 0,1 4.0,-32.0 Z M 374.5,-32.0 A 4.0,4.0 0 0,1 382.5,-32.0 A 4.0,4.0 0 0,1 374.5,-32.0 Z" />
</g>
</svg>

Haha, il y en a qui ont l'oeil !
Oui, c'est pour l'intégration de la lib C++ Clipper2 de Angus Johnson dans OpenCutList. Cette lib permet de faire des unions / intersections de polygones 2D
Ce dépôt ne sert qu'à porter le petit bout de code d'interface Ruby <-> C et à générer la DLL (pour Windows) et le dylib (pour Mac) via les GitHub actions.
Idéalement, ça serait bien que tout ça soit intégré au dépôt OpenCutList.
Mais j'ai tellement galéré à faire une DLL qui marche que pour l'instant, c'est resté comme ça :)