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 :)
Bonjour,
Oui, c'est un paramètre global à SketchUp. Mais tu peux aussi le configurer depuis OpenCutList.
Clique sur l'onglet Paramètres en bas de la fenêtre OCL ou va dans le panneau Infos sur le modèle, onglet Unités de SketchUp.
De là, dans la fiche de débit ou dans l'export, il n'y aura plus le "mm" ou le ,00.
Si qu'on peut !
Il faut que tes éléments de quincaillerie soient avec une matière du type Accessoire.
Et ensuite dans les propriétés de la pièce, tu vas dans l'onglet spécifique pour les quincailleries et tu y trouveras le champs Prix.
D'ailleurs ce champs reprend la même valeur que le champ Price qui est dans le panneau natif "Info sur l'entité" de SketchUp.
Il s'agira du prix à la pièce et cette pièce peut représente run lot.
Exemple ici 2 coulisses (= 2 unités) et le prix c'est celui du lot (= la paire = la pièce)
Les prix sur les autres types de matières sont des prix volumiques. Ce qui ne peut pas s'appliquer sur une quincaillerie. Ca ne se paie pas en €/m3 . C'est donc sur chaque pièce que se défini le prix indépendamment de sa forme et son volume.
Le type de matière Accessoire sert juste à traiter les pièces sans compter leur dimensions.
Le plus simple me semble d'utiliser la matière Panneau et pour s'éviter des calculs de division saisir le tarif à en €/unité.
Exemple, si j'ai un plan de 650mm de large qui à 10 €/m.
Tu crée un panneau de taille standard de 5m x 650mm (exemple)
Et tu y mets le tarif de 10€ x 5m → 50€ en choisissant €/unité.
Après, peut-être qu'on peut imaginer ajouter €/m sur les matières panneaux et que ça fait tout seul le calcul en considérant cette valeur sur la longueur ...
Mais est-ce que ça sera clair pour tout le monde ... ?
Sans donner ou avoir un avis tranché sur d'autres logiciels, voici les avantages que j'ai à utiliser SketchUp + OpenCutList, hors de l'effet, je l'utilise parce que tout le monde l'utilise.
SketchUp
Les plus
- Coût = 319€/an (ce qui au prix des logiciels des métiers du bois représente des clopinettes)
- Conception, Modélisation (SketchUp) et Présentation 2D PDF au client (Layout) avec le même produit
- Dessin de l'environnement et du projet avec la même fluidité
- La 3D peut facilement être envoyée sur un smartphone pour discuter de détails sur le chantier avec le client sans sortir l'ordi
- Y a même la réalité augmentée si tu veux pousser le délire.
Les moins
- Gère pas très bien la courbe
- Non paramétrique (si tenté que ça soit vraiment plus rapide de l'avoir)
OpenCutList (devis et prod)
Les plus
- Coût = ta générosité.
- Intégré à SketchUp ... tout au même endroit et à jour dans les modifications du modèle.
- Fiche de débit (avec filtre et tri)
- Calepinage barre et panneau
- Estimation fine du coût matière + accessoires
- Sortie de dessins de tout ou portion du projet en 3D filaire éclatée ou non avec numéros des pièces. (Idéal pour repérage, fab ou montage)
- Exportation vers Excel ou autre
- Impression d'étiquettes
- Gestion du placage des chants droits
- Gestion du placage de surface
- Comptage des pièces de quincaillerie (avec mise en lot. ex "par boîte de 80")
Les moins
- Ca ne fait pas le café
Sinon, pour sortir des classiques SketchUp ou Fusion, je vois un bel avenir à
C'est un mixe très intéressant entre la simplicité de SketchUp et la profondeur (voir le paramétrique) de F360 et autres SolidWorks sans toute la lourdeur de l'industrie.
Pour l'instant, à part placer la référence dans le nom, il n'y a pas de champs prévu pour ça.
Peut-être serait-il envisageable d'ajouter une sorte de champ "description". Mais les matière n'étant affichées que par des images, il n'y aurait pas trop de place pour avoir accès à cette description dans l'onglet Matières
On peut imaginer un truc comme ça ?
Bonjour Adrien,
Merci d'apprécier OpenCutList
Il n'y a volontairement aucun paramètre pour multiplier virtuellement les quantités.
Ceci afin qu'OCL reste au maximum dans la logique simple de compter ce qui est visible dans le modèle.
Tu as donc bien la bonne façons de faire : dupliquer les "modules" dans le modèle.
Avec l'outil "Déplacer" c'est 2 cliques. Et si tu combines ça avec le "x" que tu peux tapper ensuite, tu as en 2 secondes le nombre d'éléments voulus sur la scène.
Et étant donné que tout est composant, ça ne va pas vraiment alourdir le modèle.