L'inconvénient de cette approche, c'est qu'il faut tourner les textures de chaque face des chaque pièce.
Tourner dans l'image alignera automatiquement le X (horizontal) de l'image à l'axe Rouge du composant si la matière est sur l'instance et pas sur les faces.
tourner dans l'image = faire une rotation des pixels dans l'image de la texture.
Reste plus qu'à cliquer sur les faces souhaitées pour modifier l'orientation
Ca sera long quand même. En appliquant la matière sur l'instance du composant plutôt que sur ses faces, c'est :
- plus léger dans le fichier (1 seule attribution de la matière par pièce)
- l'orientation de la texture sui automatiquement les axes du composant.
Si tu veux des texture de bois, voici qui peut aider :
La license d'utilisation des images de la xylothèque est indiquée sur chaque fiche.
Joli comme tout !
Content que l'export d'OpenCutList pour la Shaper Origine ait pu t'être utile 
(C'est certain que dans ce cas, les faire à partir de cercle était plus adapté que de dessiner à partir de courbes de Bézier.)
Ce menu n'est dispo QUE si la matière est appliquée sur la face. Dans ton cas Natha25, la matière est surement appliquée sur l'instance parent. Ce qui est bien.
Je confirme que dans l'onglet Texture des propriétés de la matière tu peux tourner la textures en 1 clique :)
Et il faut mettre le fil à l'horizontal dans l'image si tu veux que ça soit cohérent avec ce que dit OCL.
Bonjour BOISPE,
Y a-t-il une différence avec la fiche suivante ?
Dans ce cas, ça serait intéressant de le mentionner dans les fiches.
Ou tout simplement d'éditer l'ancienne fiche pour ne pas créer de doublons.
Oui, il y a rien à regretter dans l'investissement dans un Ecodrill.
La Shaper
C'est après avoir bricolé pour gagner 4 sous qu'on se rend compte que les outils bien pensés et fonctionnels sont vite rentabilisés quand on doit compter son temps (de fab autant que de pose avec des usinages imprécis).
Marge = Coupe de propreté 
Hmm, je veux bien voir des capture de l'écran de configuration du calepinage et de la matière ?
Je veux bien aussi une capture de l’onglet Configuration du calepinage.
(Sûrement une marge trop grande)
Et donc, aucune marge n’est configurée?
Envoi le fichier SKP, via le bouton Signaler un bug en bas de la fenêtre OCL, ça sera plus simple pour te répondre.
Quentin Xaillé merci Mais ton e-mail est vide. Il faudrait me joindre le fichier SKP :)
Quentin Xaillé je persiste à penser que c’est à cause de la marge qui ne doit pas être à zéro.
Le code couleur des type d'usinage est propre à la Shaper.
support.shaper...t-Type-Encoding
Elle ne peut pas avoir de Gcode, parce qu'elle ne bouge pas toute seule.
Hmm, c'est pas plus rapide de faire le changement sur la machine ?
Ok :)
Sinon, tu es content de l'exporter pour Shaper de OCL ?
Tu exportes les pièces à partir de la fiche de débit ou avex l'outil Exporter des pièces dans le modèle 3D ?
Ton évaluation Pro est arrivée à expiration, il te demande d'accepter d'être ne version SketchUp Make (qui retire certaine fonctionnalité).
Clique sur J'accepte et continue de l'utiliser.
Très joli travail !
Superbe la continuité du fil !
Merci EstOuest.
J'ajouterai que pour que les tracé soient des polylines continues dans le DXF, il faut "souder les arrêtes" dans SketchUp. Sinon ce sont des segments mis bout à bout.
Aussi, les calques créés ne dépendent que de la profondeur de l'usinage?
Deux perçages de même profondeur mais de diamètres différents apparaitront sur le même calque?
C'est ça. Le découpage en calque sert à distinguer les profondeurs.
Je comprends que c'est une contrainte pour toi. Mais j'ai du mal à voir comment il pourrait en être autrement tant le contenu de l'export peut être un peut n'importe quoi et pour n'importe quel usage.
Sans compter que même dans le modèle 3D, il n'est pas indiqué de différence entre un percement et une rainure, par exemple.
Dans quel cas est-ce que tu en as besoin ?
Salut, merci pour ces détails.
qu'en est il quand je souhaite faire un perçage de 5mm débouchant?
Les trous débouchants et non débouchants ne sont pas dans le même calque. Ils sont dans un calque qui fini en _HOLE et qui a DEPTH = l'épaisseur de la pièce.
Serait-il possible, envisageable, d'obtenir en plus de la profondeur d'un usinage, une autre caractéristiques, par exemple pour les cercles, leur diamètre ou pour une rainure la largeur?
Pour les cercles parfaits, ils sont exportés avec l'entité CIRCLE du format DXF qui contient donc les coordonnées du centre et son rayon. C'est au lecteur de DXF de savoir utiliser cette information.
Pour la largeur d'une rainure, ça me semble plus problématique. La seule chose qu'OCL peut connaitre à l'analyse du modèle 3D, c'est que la forme est un polygone. Dans ce contexte difficile d'en extraire une notion de largeur.
En l'état de ton besoin, je ne vois pas trop de solution qui irait bien. Tu as besoin de qualifier tes usinages et SketchUp et OCL ne vont pas le permettre de façon automatique. Parce que l'information de savoir différencier un rainure d'un usinage quelconque n'existe pas dans le modèle.
Le problème est bien plus large. La famille de 3 type d'usinage que tu proposes part du principe que la pièce est un panneau plat et que l'usinage ne se fera que sur 3 axes.
Pour l'export OCL, il était difficile de se contenter de supposer que la pièce dessinée était bel et bien plate en vue de dessus.
Donc ce qui est fait c'est que l'export est le résultat d'une projection de tous les segments du solide sur un plan donné. Là dessus, il faut recouper ce qui est masqué.
Avec ça tu te retrouve avec des traits qui peuvent ne pas correspondre à de réelles arrêtes du modèle 3D. Exemple pour les images jointes.
En bleu, c'est que OCL voit comme le contour, le blue clair ce qui est une cavité, en violet ce qui est une cavité traversante.
De là, j'ai fais un truc qui sait détecter ce qui est un cercle ou une ellipse, mais pour le reste ce sont des polygones et c'est tout. Je vois pas bien comment détecter des rainures sans faire des suppositions.
Et à mon sens, c'est au logiciel qui lit le DXF de savoir faire ça. Lui seul part du principe qu'on utilise le DXF pour faire de l'usinage 3 axes.
Ce qu'il faut bien comprendre c'est qu'en partant d'un solide sans autres informations, il n'y a pas forcément qu'une seule solution pour définir les usinages qui l'ont produit.
C'est dans ce contexte qu'OCL se limite à ce qu'il peut donner avec certitude. La forme (visible) et la profondeur de chaque cavité.
Par ailleurs, quelle est la différence pour l'usinage entre une rainure et une poche ?
Merci bipbip pour ses informations.
- C'est donc OK
- C'est pas loin de l'être. C'est un peu comme un poche alors. Mais pourquoi définir une largeur alors ?
- Ca ça serait bon si le lecteur savait lire les entités DXF cercle. En l'état, je me refuse presque à mettre l'information du diamètre dans le calque. C'est à la fois un doublon avec l'entité CIRCLE et aussi une possibilité d'avoir un cercle de D=12 et un calque qui dit D=5. A mon sens c'est de la bidouille. Et d'autre utilisateur m'ont informé avoir un analyseur de DXF qui sait se débrouille avec les entités CIRCLE du format DXF.
- Comment est-il possible de ne définir qu'une largeur et que le système sache dans quelle direction se trouve la rainure ? Tout ça sens compter que l'information est d'une certaine façon déjà dans la polyline.
Je comprends bien les limites de ton logiciel de génération de G-Code. Mais j'ai du mal à imaginer que c'est à OCL de les dépasser.
D'ailleurs, quel est ce logiciel ?
- Donc la largeur dans le calque est un problème. Puisqu'il n'est pas forcément cohérent à la géométrie.
- Je pense que l'utilisation du calque pour mettre des informations de géométrie qui sont déjà dans le format DXF est une source d'erreur. Et un dev, ça aime pas les source d'erreur :)
- C'est bien pour ça que la logique de mettre les informations d'usinage dans les calques a trop de limites pour répondre de façon générale au besoin.
Je sais bien qu'il répandu de mettre les informations d'usinage dans les calques. Mais c'est une vraie bidouille. Et un projet comme OCL qui est utilisé par une large communauté d'utilisateurs avec des usages très divers ne peut pas préférer une bidouille à une autre. T'apporter une solution avec ça c'est causer autant de problèmes avec d'autres.
J'ai mis les profondeurs dans les calque parce que le DXF est un format 2D, mais pour tout le reste, il suffit de lire la géométrie pour avoir les informations. La poser en double dans les calques c'est à la fois réinventer le roue et établir un format qui est bourré de failles.
Après, il y a d'autres formats comme le TCN qui seraient plus intéressant à utiliser. Parce que eux ils permettent de définir les usinages sans bidouilles. Et même sur plusieurs faces.
Peut-être a tu des conseilles pour résoudre cela.
Pas plus que ça. La grande majorité des soft sont payants et ne tournent que sur Windows. C'est au moins deux raisons pour lesquelles j'ai pas trop pu les essayer.
Les cercles dans SketchUp, ça n'existe pas. Ce sont toujours de polygones.
Pour qu'OpenCutList tente de recomposer les cercles en vrais cercles dans l'export DXF du calepinage, il faut lui activer l'option.
saurais-tu pourquoi, lorsque j'importe une un fichier .skp provenant d'un logiciel de création de meuble, les perçages des quincailleries dans les panneaux n'apparaissent pas dans OCL.
Envoi le fichier par email en cliquant sur le bouton Signaler un bug en bas de la fenêtre OCL.
Oui, on est d'accord que ce qu'exporte OCL n'est pas directement exploitable pour de l'usinage. C'est pour ça que c'est uniquement un export de la géométrie projeté. En soit, c'est le minimum vital pour qu'un logiciel de FAO sache trouver ce que tu veux. Sinon A quoi ça sert qu'Aspire coûte 2000 balles ?
Aller plus loin ferait entrer OCL dans une logique de FAO, donc. Et là c'est un autre job. Ce qui fait que pour le moment ça se limite à exporter de la géométrie c'est :
- Y a pas les fonds pour le faire. Sauf si tu as 100k€ pour commencer à financer le DEV des fonctionnalités de FAO.
- La FAO est un truc plus complexe que d'ajouter des bouts qui dépassent.
En règle générale je me refuse à mettre dans OCL des fonctionnalités qui apporte qu'un bout de la solution. Je préfère qu'il y ait rien du tout qui donne un début de piste à de la FAO plutôt que d'en faire un peu et se trouver au même point avec à nouveaux des utilisateurs disant que c'est pas complet donc inutilisable.
Aujourd'hui, on peut pas pas faire, mais au moins ça nous a pas coûté du temps de dev pour être dans cette situation :)
Ce qu'il faut voir c'est que les dons des utilisateurs à OCL donnent à peine 10k€ par an. Donc si les utilisateurs veulent les fonctionnalités de softs métier à plus de 3k€ dans un plugin gratuit il faudra qu'ils se rendent compte que c'est soit pas possible soit il faut le payer :)
Si tu veux mettre des sous dans OCL, la chose se réfléchi, ça va de soi.
Désolé d'avoir ramené la question aux sous. Mais j'ai tellement tous les jours des gens qui me réclament de fonctionnalités sans avoir jamais fait un petit don que parfois, ça m'inquiète de voir que le coût de création d'un logiciel n'a pas de valeur pour pas mal de gens.
A cette heure, je me rends bien compte qu'avec OCL, on a fait un soft qui répond de façon pro à des besoins pro et qu'on est content d'avoir fait ça avec le budget d'une asso de parent d'élèves.
Le besoin que tu exprimes avec les surlongueur pour les usinages qui dépassent de la pièce, je le comprends bien. Et il est largement partagé. Mais je reste étonné qu'Aspire ne le fasse pas déjà. Et je ne sais pas trop évaluer si juste cette fonctionnalité serait suffisante pour faire passer OCL à une autre dimension.
Après, je manque beaucoup de retour utilisateurs sur les questions CN. Pour tout le reste, ça rempli mes besoin propres, donc je vois bien ce qui est utile de ce qui ne l'est pas. Pour la CN, tant que j'en aurai pas, ça sera difficile d'avoir la bonne vision.
Est-ce qu'un débordement de ce type répondrai déjà à tous les cas de figure ?
Joli !