OpenCutList - gestion des arrondis des tailles des matières

bonjour, merci beaucoup pour ta réponse

j'ai rencontré le problème avec d'autres outils; l'exemple des géodésiques est juste un exemple parmi d'autres

non, non, il ne s'agit pas d'un problème d'alignement comme celui que tu décris dans ta réponse
ton outil d'alignement de la version 7 est génial (il me semble que c'est une nouveauté de v7); sur un modèle de dôme importé depuis acidome.com (.obj), j'ai tout réaligné en quelques minutes juste en cliquant sur chaque composant du modèle.

pour défendre un petit peu ma question j'argumenterai ceci :

• de mon expérience professionnelle (rien à avoir avec le bois) j'ai retenu que deux valeurs réelles pouvaient être considérées comme égales lorsque que leur différence en valeur absolu était inférieure à une certaine valeur (1, 0.1, 0.01, ...); je crois avoir lu quelque part que OCL utilisait 6 ou 7 décimales; donc quelque part il fait déjà un calcul similaire de façon explicite ou implicite
• au moment du calcul du débit, si je comprends bien, l'algo trie et regroupe par matière puis par largeur et/ou épaisseur
  matière doit être équivalent a un entier (ce qui est facile à regrouper) alors que largeur et épaisseur sont représentés par des nombres réels qui sont informatiquement arrondis ce qui rend aléatoire le regroupement

bien sur
on peut contourner le problème en corrigeant le modèle sketchup composant par composant (par exemple grâce aux composants dynamiques qui permettent de définir les valeurs de largeur et épaisseur), c'est ce que je fais si je rencontre ce problème

encore merci pour ta réponse

ton outil d'alignement de la version 7 est génial

Merci, il est nouveau depuis la version 6 :)

je crois avoir lu quelque part que OCL utilisait 6 ou 7 décimales

Pour la répartitions des groupes, c'est 3 décimales mini (code), ou la précision du modèle si elle est supérieure à 3.

Matière2 / 2095,05 mm x 100,73 mm Section non standard
Matière2 / 2050,02 mm x 100,73 mm Section non standard
Matière2 / 1770,97 mm x 100,73 mm Section non standard
Matière2 / 101,60 mm x 101,60 mm Section non standard

N'y a-t-il pas déjà un problème en amont ? Pourquoi as-tu des sections de 2m x 10cm ?
Est-ce que les 100,73mm et les 101,60 doivent faire la même valeur ? C'est plus une erreur d'arrondis à ce niveau là, c'est un dessin à main levée

par exemple grâce aux composants dynamiques qui permettent de définir les valeurs de largeur et épaisseur

Les composants dynamiques n'aident pas vraiment à ça. C'est plutôt l'utilisation de l'outil "Echelle" qui ferait ça. Mais là encore, c'est déplacer le problème.

j'ai rencontré le problème avec d'autres outils;

Je serais curieux que tu me partages les SKP qui posent problème.

Pour comprendre le contexte, il faut déjà savoir que SketchUp ne connait pas le millimètre. En interne tout est en pouce. Il y a donc un conversion permanente entre les deux unités. Et avec une précision à 1mm, c'est impossible de conserver des valeurs correctes.

Par ailleurs, lorsque j'ai voulu pousser plus loin l'extraction de la géométrie, il est apparu que pour détecter correctement les arcs de cercle, il me fallait un minimum de précision à 10e-6 sur la valeur en pouces.

Et je ne te parles pas de la conversion mm <-> pouces qui demande le maximum de précision possible pour ne pas virer en 1,99999999.

Donc tout ça me confirme que forcer l'utilisateur à un minimum de précision dès le dessin, c'est régler le problème à la source. Et donner solution à tout.
Il n'y aura donc jamais d'arrondis au mm dans OCL. Déjà, je trouve que l'arrondis à 0,001 est déjà un peu trop grand pour ce qu'on veut extraire ensuite.