Fichier easm vers STL, perte dimensions.

[duredetrouverunpseudo]

J'ai un fichier de pièces assemblés en format easm. Je l'ouvre avec Edrawing.

Je peut sélectionner individuellement chaque pièce est l'enregistrer en STL uniquement.
Ça s'ouvre dans fusion sans problème, mais les dimensions deviennent n'importe quoi.

Existe-t-il un moyen d'avoir les cotes réels ? Ou est-ce propre au format STL ?

 

[AllGorythme]

C'est propre au format STL : il ne contient que la description des surfaces de l'objet. Dans le fichier STL, les unités ne sont jamais définies.

En général, ça ne pose pas de problème car les soft partent du principe que les valeurs qui décrivent les surfaces sont des mm. Mais parfois, on tombe sur des bizarreries (par exemple un export en pouce)

 

[duredetrouverunpseudo]

Les cotes semble être divisé par 10.

Bizarre comme format de fichier.

 

[AllGorythme]

Comme le sujet m'intéresse un peu, j'ai essayé de créer un fichier STL à la mano. Une pyramide avec 4 faces s'inscrivant dans un cube de 10 (sans unités) :

Vous devez être connecté pour voir ce contenu.

J'ai importé le STL dans PrusaSlicer. Le soft considère bien que par défaut les unités sont en mm :

 

[Ubert]

Bonjour,
A chaque fois que je dois reprendre un STL sous Fusion, je dois diviser les cotes par 10.
A bientôt!
Jean-Philippe

 

[duredetrouverunpseudo]

Moi il faut que je les multiplies par 10.

75 mm sur l'easm en edrawing enregistré en STL me donne 7,5 mm sous fusion.

Je vais essayer Autodesk Meshmixer pour lisser les triangles et voir si je peux en faire un Gcode pour la fraiseuse.

 

[dh42]

Salut,

C'est propre au format STL : il ne contient que la description des surfaces de l'objet. Dans le fichier STL, les unités ne sont jamais définies.

En général, ça ne pose pas de problème car les soft partent du principe que les valeurs qui décrivent les surfaces sont des mm. Mais parfois, on tombe sur des bizarreries (par exemple un export en pouce)

Exact, les valeurs numériques sont des valeurs "générique" (sans unité) ; c'est le cas dans tous les formats de fichiers 2D ou 3D que je connais. Dans le cas du STL, en plus il n'y a aucune indication de l'unité utilisée donc c'est au soft qui lis le fichier de choisir. Sur CamBam, si on est réglé en mm à l'ouverture du fichier, le fichier sera interprété comme étant en mm, si on est en pouce, il sera interprété comme des pouces.

Sur SolidWorks, il y a un réglage pour définir l'unité à utiliser, mm, pouce, cm, etc ... il y a certainement un réglage aussi quelque part dans Fusion.

Le soft qui exporte le fichier STL peut aussi avoir son propre comportement, en principe il utilise simplement la cote dans l'unité courante, dépouillée de son unité, donc ça dépend aussi du réglage d'unité en cours sur le soft source, une cote de 10mm donnera 10 dans le fichier si on est réglé en mm, mais une cote de 10cm si on est réglé en cm donnera aussi 10 dans le fichier ...

++
David

 

[AllGorythme]

c'est le cas dans tous les formats de fichiers 2D ou 3D que je connais.

J’utilise 2 formats de fichiers 3D qui gèrent nativement les unités : le STEP et le 3MF

 

[dh42]

J'utilise aussi beaucoup le STEP, mais ce n'est pas un format de maillage. L'avantage c'est que l'on peut choisir la densité du maillage lorsque l'on convertis du STEP vers du STL, 3MF ou autre format maillage vu que l'on part d'un objet "Solide" ou "Surface" décrit mathématiquement (CSG ou B-Rep) alors que si on a un maillage au départ, on est limité à la densité d'origine du fichier (ou on peut la réduire par décimation, mais pas l'augmenter)

Il me semble que dans ses dernières versions Prusa Slicer peut lire le STEP, par contre il le convertis en maillage pour exploitation, il ne travaille pas directement sur les données du STEP, mais ça permet probablement d'avoir un maillage de meilleur qualité et de s'affranchir des "erreurs" de conception du maillage source. (si le convertisseur STEP>maillage fonctionne bien )

Il y a aussi .OBJ et .3DS en format de fichier maillage, qui sauvent plus d'infos que le STL (unité, couleur des facettes, texture, ...), mais je pense que ce sont des formats propriétaires contrairement au STL et au 3MF.

++
David