Otarie

Super @(gile), c'est parfait ! Merci beaucoup !

Bonjour @(gile) Je vous remercie bien, effectivement avec une largeur de 13,5 cm au lieu de 14cm pour les grandes longueurs du losange, on a une répétition sur la droite tous les 1,35 m au lieu des 4,62 m dans mon exemple. Ce qui fait bien un fichier plus simple. Merci encore.

Bon en fait j'ai trouvé mon erreur. Ça venait des dimensions de la tuile utilisée : j'avais fait des pans coupés avec des dimensions qui ne tombaient pas juste. La conséquence est qu'il n'y avait pas répétition du motif selon l'axe X de la ligne, car le demi-décalage entre chaque tuile n'était pas un multiple de la largeur de la tuile. Bref, j'ai refait avec des dimensions "qui vont bien" et je n'ai plus de décalage. Je vous mets le code du fichier .PAT au cas où. ;%VERSION=1.0 ;%UNITS=M *MES_Ardoises-Losanges,Ardoises en losange 20 x 20 ;%TYPE=MODEL 0,.09899495,0,.12020816,.09899495,.04242641,-.19798990 45,.14142136,0,.155,-.015,.14,-4.62000015 45,.38183767,0,.155,-.015,.14,-4.62000015 45,.62225398,0,.155,-.015,.14,-4.62000015 135,.09899495,0,.155,.015,.14,-4.62000015 135,.33941126,0,.155,.015,.14,-4.62000015 135,.57982757,0,.155,.015,.14,-4.62000015

Bonjour @Olivier Eckmann Je vous remercie bien, je vais essayer ça !

J'ai corrigé, mais vu qu'il y a 9 projections Lambert Coniques Conformes, je pense que ça pouvait également s'écrire au pluriel... 😉

Oui j'ai créé une hachure proche du 0,0 du SCG pour mes tests. Je suis bien au courant de ce problème 😅, travaillant régulièrement en coordonnées Lambert Conique Conforme, et je redéfinis toujours l'origine des hachures proche des hachures.

Bonjour @La Lozère Je te remercie pour ta réponse, mais il ne me semble pas que ce soit un problème d'origine, car ça le fait même proche de l'origine de la hachure. Il est vrai qu'il faut zoomer, mais je ne trouve pas ça très propre... 😅 Et comment peut-on passer à plus de 8 chiffres après la virgule ? La commande "_UNITS" ne permet que d'en afficher 8. Merci d'avance !

Bonjour, Je revenais vers vous, car je me confronte à un problème dans la définition d'une hachure d'ardoise en losange (de 20 x 20 avec angle biseauté) comme l'exemple ci-dessous : Voici la définition du fichier .pat que j'ai créé à la main : ;%VERSION=1.0 ;%UNITS=M *MES_Ardoise-Losange,Ardoises en losange 20 x 20 ;%TYPE=MODEL 0,.09857864,0,.12,.09857864,.04284271,-.19715729 45,.14142136,0,.15455844,-.01514719,.13941125,-7.66733320 45,.38142136,0,.15455844,-.01514719,.13941125,-7.66733320 45,.62142136,0,.15455844,-.01514719,.13941125,-7.66733320 45,.86142136,0,.15455844,-.01514719,.13941125,-7.66733320 45,1.10142136,0,.15455844,-.01514719,.13941125,-7.66733320 135,.09857864,0,.15455844,.01514719,.13941125,-7.66733320 135,.33857864,0,.15455844,.01514719,.13941125,-7.66733320 135,.57857864,0,.15455844,.01514719,.13941125,-7.66733320 135,.81857864,0,.15455844,.01514719,.13941125,-7.66733320 135,1.05857864,0,.15455844,.01514719,.13941125,-7.66733320 Mon problème est la jointure des lignes (même proche des lignes de base) : J'ai pourtant pris les dimensions avec 8 chiffres après la virgule... 😓 Auriez-vous une solution à ce problème ? Je suis désolé si c'est une question de débutant ou si la hachure existe déjà, mais j'aimerai essayer de bien comprendre le fonctionnement des hachures sous Autocad. Merci d'avance !

Bonjour @(gile) Merci bien pour ce fichier qui a le mérite de mettre en forme les explications du site Autodesk. Je vous remercie également pour les liens qui sont très instructifs, notamment sur les pavages apériodiques !

Bon, je viens de me rendre compte de ma bêtise... En fait le problème d'essayer de faire des hachures dans un rectangle (et non un carré), c'est qu'il n'y a pas de répétition des lignes (selon les axes X et Y de la ligne) : en effet, avec un carré, il y a répétition (des fois loin du carré de base, mais ça permet de créer un espace vide, créé par une distance négative dans les "dash" de la définition de la ligne). Donc je pense que je vais me faire à la main toutes les hachures simples (c'est-à-dire celles qui ont des angles de linge de 0° ou de 90°). Pour les autres hachures (de type pierres ou autres), je vais les faire avec le lisp HatchMaker. Il faut bien par contre bien avoir un angle de base de 0 (variable ANGBASE) et un angle dans le sens trigonométrique (variable ANDIR à 0), sinon on a des surprises... 😅

Bonjour @Olivier Eckmann Je vous remercie, je comprends mieux maintenant les 4000 lignes du fichier .pat 😅 Mon souhait à la base était de créer des hachures aux bonnes dimensions métriques pour que l'utilisateur ne se pose pas la question de l'échelle de la hachure et qu'en l'insérant à une échelle de 1, on ait les bonnes dimensions (par exemple 50 cm par 20 cm pour un parpaing standard). Parce que toutes les hachures récupérées à droite ou à gauche ne sont jamais à des échelles équivalentes : il faut toujours "jongler" avec les échelles pour avoir quelque chose de satisfaisant. Et certains hachures ne sont pas forcément bien définies (ni même bien dessinées), c'est dans cette optique que je voulais les refaire pour avoir des choses cohérentes. Je pense que je vais donc me lancer sur une réécriture complète du programme Lisp de création de hachures. Merci encore.

Bonjour @didier, Bonjour @Olivier Eckmann Je vous remercie pour votre réponse, et je suis désolé si je suis long à la détente, mais je ne comprends toujours pas la différence entre des "hachures" et des "motifs". Les "motifs" comme "GRAVEL" sont, il me semble (ou alors je n'ai rien compris, mais c'est fort possible), également définis par des droites (lignes infinies) dont on définit les segments pleins (valeur positive) et les segments vides (valeur négative comme dans la définition des types de lignes .lin), leur origine, leur répétition le long de la droite et le décalage de la droite. Je ne vois pas de différence dans leur définition. Ou bien alors Autocad les traite différemment : mais en se basant sur quoi pour les différencier ? Bon sinon je pense que je vais refaire le programme de création de fichier .pat, en demandant à l'utilisateur premièrement la sélection du rectangle (je ne parle pas de carré 😅) englobant les ligne de la hachure : la largeur de ce rectangle permettra la répétition en X des lignes et la hauteur en Y. Et deuxièmement la sélection des lignes (et points) constituant la hachure. Dans une première version le programme exporterait toutes les lignes et points de la sélection. Dans une seconde version du programme, j'aimerai l'optimiser de telle sorte que des lignes coplanaires ne soient définies que par une seule droite (et non plusieurs comme dans la première version). À voir si j'arrive à faire quelque chose (ça ne sera sûrement pas très optimisé vu mon niveau)... Je vous remercie bien pour l'envoi de ce fichier, mais celui-ci comporte plus de 4000 lignes, alors que la définition d'un motif de pavés ne nécessite que 4 lignes minimum... 😓

Bonjour @didier Je vous remercie bien pour votre réponse, mais je ne comprends pas trop votre phrase indiquant que Car quand je regarde la définition des fichiers sur le site d'Autodesk, je n'ai pas vu de référence à une définition d'un ratio 1x1. Il est indiqué le format d'une ligne de définition des hachures : angle, x-origin, y-origin, delta-x, delta-y, dash-1, dash-2 Je pense avoir compris le principe et j'arrive à faire (par exemple) une hachure de parpaings 50 x 20 : 0,0,.02,.26,.22,.50,-.02 0,0,.22,.26,.22,.50,-.02 90,.50,.02,.22,.26,.20,-.24 90,0,.02,.22,.26,.20,-.24 Je pensais que les hachures d'Autocad étaient constituées de droites (lignes infinies) sur lesquelles on appliquait des espaces (traits négatifs) que l'on répétait avec un espacement en X et en Y (espacement qui pouvait ne pas être uniforme en X et en Y). Je pensais (sûrement naïvement) également que le décalage que l'on pouvait trouver sur certaines hachures provenaient du nombre de chiffres après la virgule des origines et des deltas, et donc de la non-coïncidence exacte des lignes contenues dans la définition de la hachure. Et que lorsque l'on créait une hachure à des coordonnées très éloignées de 0,0 (par exemple à quelques millions en X et en Y en coordonnées Lambert Conique Conforme), si les lignes au départ ne coïncidaient pas exactement, on se retrouvaient avec des décalages proportionnels aux coordonnées où on créait la hachure (car la définition restait à l'origine 0,0) ; problème qui peut-être corrigé comme l'a dit @La Lozère par une redéfinition de l'origine des hachures proche de l'endroit où elles ont été créées. Il faudrait donc que que je modifie ce Lisp HatchMaker pour arriver à recréer des hachures qui n'ont pas un décalage uniforme en X et en Y (comme l'exemple de cette hachure "parpaings" qui a un delta-x de 0.26 et un delta-y de 0.22 sur la 1ère ligne).

Bonjour à tous, Je souhaite créer des hachures qui ne sont pas forcément carrées, c'est-à-dire qui n'ont pas le même décalage en X et en Y. Pour des hachures simples comme un mur en parpaings de 50 cm de large par 20 cm de hauteur avec un joint de 2 cm entre chaque parpaing, j'arrive à créer un fichier .pat à la main via un éditeur de texte. Mais je souhaiterai utiliser un Lisp qui me permettrait de créer des hachures plus compliquées. En cherchant je suis tombé sur le Lisp HatchMaker.lsp Le problème est que ce Lisp ne permet que la création de hachures selon un carré de 1 par 1. Or dans l'exemple d'un parpaing de 50 x 20, le décalage en X n'est pas le même que celui en Y, et je n'arrive même pas à faire une hachure aussi simple satisfaisante avec ce Lisp, alors des hachures plus compliquées... Donc, auriez-vous une solution (un autre Lisp ou alors comment bien utiliser ce Lisp que je ne sais peut-être pas faire fonctionner correctement 😅) ou bien sauriez-vous ce qu'il faut modifier dans ce Lisp pour pouvoir utiliser une zone personnalisée (par homogène en X et en Y) pour la création des hachures ? Merci d'avance !

Super ça fonctionne nickel, merci beaucoup !

Re-bonjour, J'ai un dernier petit soucis sur le tri des listes, au niveau des tris des entiers, les dizaines s'intercalent entre les unités : Cela produit le rangement suivant : 1, 10, 11, [...], 2, 20, 21, [...] Au lieu de : 1, 2, 3, [...], 10, 11, [...], 20, 21, [...] Mais je n'arrive pas à voir ce qu'il faut modifier dans la fonction "compare" pour arriver à ce tri numérique. 😓 Merci d'avance !

Bonjour Gile, Tout d'abord merci beaucoup pour cette réponse rapide ! Je comprends mieux (une de) mes erreurs : j'essayais de modifier directement les conditions dans le vl-sort, mais effectivement vu que je stockais les entiers sous forme de chaîne, le test (numberp x) ou (numberp y) renvoyais toujours nil sans rajouter un read devant x ou y... 😓 Bref, ça fonctionne nickel, merci beaucoup encore !

Bonjour à tous, Après avoir pas mal cherché et après avoir si souvent parcouru ce forum, où j'ai très souvent trouvé ce que je cherchais, mais sans jamais m'inscrire, je me suis lancé et je me suis inscrit. Je veux extraire une liste de cotations et les sommets associés. Les sommets peuvent être des lettres de l'alphabet (A, B, C, etc.) voir des doubles lettres (AA, AB, AC, BD, etc.) ou des triples lettres (AAA, AAB, AAC, BAA, BAB, etc.) ou bien des entiers (1, 2, 3, etc.) Je voudrai les trier d'abord par simple lettre ou double ou triple, puis par valeur numérique. Par exemple pour la liste suivante (deux sommets à chaque fois) : (("B" "2")("E" "K")("BC" "C")("A" "E")("A" "2")("AB" "3")("A" "B")("A" "1")("AB" "A")("B" "1")("A" "3")("C" "E")("BC" "4")("E" "2")("B" "F")("E" "1")("B" "D")) Devrait être triée ainsi : (("A" "B")("A" "E")("A" "1")("A" "2")("A" "3")("B" "D")("B" "F")("B" "1")("B" "2")("C" "E")("E" "K")("E" "1")("E" "2")("AB" "A")("AB" "3")("BC" "C")("BC" "4")) Avec les fonctions suivantes de Lee Mac j'arrive à trier selon le premier sommet et le deuxième sommet : (defun sort-list ( l ) (vl-sort l (function (lambda ( a b / x y ) (if (= (car a) (car b)) (< (cadr a) (cadr b)) (progn (setq a (LM:splitstring (car a)) b (LM:splitstring (car b)) ) (while (and (setq x (car a)) (setq y (car b)) (= x y)) (setq a (cdr a) b (cdr b) ) ) (cond ((null x) b) ((null y) nil) ((and (numberp x) (numberp y)) (< x y)) ((numberp x)) ((numberp y) nil) ((< x y)) ) ) ) ) ) ) ) (defun LM:splitstring ( str ) ( (lambda ( l ) (read (strcat "(" (vl-list->string (apply 'append (mapcar (function (lambda ( a b c ) (cond ((= 92 b) (list 32 34 92 b 34 32) ) ((or (< 47 b 58) (and (= 45 b) (< 47 c 58) (not (< 47 a 58))) (and (= 46 b) (< 47 a 58) (< 47 c 58)) ) (list b) ) ((list 32 34 b 34 32)) ) ) ) (cons nil l) l (append (cdr l) '(( ))) ) ) ) ")" ) ) ) (vl-string->list str) ) ) Mais les nombres entiers sont toujours avant les lettres de l'alphabet... J'ai bien essayé de bidouiller la fonction vl-sort, mais je n'arrive pas au résultat escompté... Si vous aviez une piste je vous en serai très reconnaissant. Merci d'avance !