Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

91
Salut,

J'applique le même principe que toi, mais mon algorithme est un peu plus compliqué que ça... Je me suis peut être compliqué la vie pour rien lol En fait je n'ai pas géré les intersections des formes concave, mais je pense savoir comment faire alors je testerai ça prochainement.

Par contre je ne comprend pas pourquoi la pointe "est trop longue" ?? cette longueur semble logique pourtant... enfin... pour moi... B)-
Jerome

Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

92
Pascal_L a écrit:
-------------------------------------------------------
> Salut Roland et Jérôme,
>
> J'ai attaché un screenshot qui montre les 2 pbs.
> 1. Roland, ne pas générer le point, tu parles du
> point du .dat transformé en point décalé ? si
> c'est oui, de loin ca me semble un peu trop
> direct. Autrement, si c'est point par point, ca
> veut dire que tu travailles directement sur le
> systéme de points à l'echelle de la découpe? Tu
> pourrais me dire ce que ca donne avec la figure en
> attachement?
> 2. Jérôme, il parle de la figure du bas. La pointe
> du triangle décalée est trés trés trés longue
> alors qu'en fait on peut s'arrêter bien avant...
> En fait on peut tourner dés que l'on a dépasser la
> pointe plus le décalage.
>
> Vous utilisez quoi comme algo, moi pour faire les
> figures en attachement, j'ai resorti les maths et
> j'ai fait:
> Je calcul l'équation de la droite // à la droite
> d'orgine (2 points du .dat) à une distance d, puis
> l'intersection des droites (celle-ci et la
> suivante) me donne le nouveau point décalé et
> j'avance comme ca d'un point à un autre. Arrivé au
> bout si la structure est fermée je reprends le
> premier point sinon je cherche l'image du point
> sur la perpendicukaire à une distance d.
> Formule de l'équation de la droite //à MM' et à
> une distance d avec M(u,v) M'(u',v')
> (v'-v)*x+(u-u')*y+u'v-uv'+d*sqrt((v'-v)²+(u'-u)²)=
> 0
>
> - Pascal

Oui, c'est aussi comme ça que je procède (avec quelques subtilités pour un dessin "fermé". C'est vrai que la suppression des points "trop près" est un peu violente, mais ça induit très très peu d'erreur.
Pour la "figure du bas", c'est effectivement le problème. Ce n'est pas génant si l'angle n'est pas trop pointu mis à part que ça augmente le temps de travail

Roland

Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

93
Bonjour Jérôme,

J'ai attaché le fichier à nouveau avec cette fois ci la représentation du rayonnement (cercle noir) et non juste la nouvelle position du fil.
Tu peux voir que très rapidement les 2 cercles se touchent, d'ou plus de matériau à couper et donc il n'y a aucun intérêt à aller jusqu'au bout... sauf à perdre du temps et de bruler de la matiére pour rien... et même dans certains cas faire des erreurs de coupe...
Le plus génant c'est que plus l'angle est fermé (pointu), plus l'intersection des 2 droites est loin. Ce point d'intersection s'éloigne très rapidement...

- Pascal
Fichiers joints
Erreurs_1.JPG Erreurs_1.JPG Vu 4447 fois 44.68 Kio

Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

95
Salut,

J'ai pensé à une méthode simple et rapide pour résoudre le problème d'un bord de fuite très pointu.
Il suffit de faire une premiére passe et de vérifier si l'angle entre 2 droites est en dessous d'une certaine valeur, si c'est le cas, on ajoute un point fictif en le décalant suivant x ou y ou perpendiculairement d'une valeur très très faible (genre 0,00000001). Lorsque l'algo de compensation passe, il va faire le parcour correctement car il ne s'agit plus d'une pointe composée de 2 droites mais bien de 3 droites. On obtient tout simplement la figure avec le stop que j'ai tracé dans mon précédent post.
Si je ne suis pas clair, je peux faire un dessin...

A+ Pascal

Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

96
Pascal_L a écrit:
-------------------------------------------------------
> Salut,
>
> J'ai pensé à une méthode simple et rapide pour
> résoudre le problème d'un bord de fuite très
> pointu.
> Il suffit de faire une premiére passe et de
> vérifier si l'angle entre 2 droites est en dessous
> d'une certaine valeur, si c'est le cas, on ajoute
> un point fictif en le décalant suivant x ou y ou
> perpendiculairement d'une valeur très très faible
> (genre 0,00000001). Lorsque l'algo de compensation
> passe, il va faire le parcour correctement car il
> ne s'agit plus d'une pointe composée de 2 droites
> mais bien de 3 droites. On obtient tout simplement
> la figure avec le stop que j'ai tracé dans mon
> précédent post.
> Si je ne suis pas clair, je peux faire un
> dessin...
>
> A+ Pascal
C'est pas très clair, mais je subodore qqchose de génial ! Un dessin ?

Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

97
Salut Roland,

J'ai pris l'interface de Jedicut pour faire l'exemple cette fois ci ;)

Exemple:
Le triangle du haut est la représentation de Triangle_ori.dat:
0.500000 0.000000
0.000000 0.000000
0.020000 0.020000
0.500000 0.000000

On voit très nettement le problème, ca ne rentre même plus dans la fenêtre...

Résolution:
On voit sur le dessin que les 2 angles en bas du triangle sont < à 90°.
Donc, si on modifie le dat en mémoire (au chargement) par l'ajout de 2 points de la façon suivante:
Le triangle du bas est la représentation de Triangle_modif.dat:
0.500000 0.000000
0.500000 -0.000001 ; ajout pour corriger l'angle en bas à droite
0.000000 0.000000
0.000000 0.000001 ; ajout pour corriger l'angle en bas à gauche
0.020000 0.020000
0.500000 0.000000

On obtient donc la figure du bas sans rien modifier à l'algo de rayonnement ou diamètre de l'outil (promis je n'ai pas le source de Jedicut).
La modification est infime donc il n'y a aucun impact sur la forme finale.
Il faut garder le même sens dans le parcours des points ce qui explique le changement de signe, il y a aussi la possibilité de l'insérer avant (0.0,0.0) ce qui fait que l'on aura le même signe...

J'espère que l'explication est plus simple avec cet exemple 8-)


Remarques pour Jerome sur Jedicut:
- il serait bien de rajouter de la couleur pour le tracé de la peau/rayonnement
- quand on agrandit la fenêtre la visualisation la largeur des 2 tracés augmente mais pas la hauteur...

@+ Pascal
Fichiers joints
erreurs_2.JPG erreurs_2.JPG Vu 4447 fois 61.22 Kio

Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

98
Hello Jérôme,

Un petit bug dans l'apperçu du cycle de découpe : la hauteur d'entrée dans la matière n'est pas à l'échelle du profil.

Un petit exemple ci-joint. Le cercle fait 230mm de diamètre (corde = 230) et la hauteur d'entrée est à 125 (115+20mm de marge). On voit bien dans le cycle de découpe qu'il a un soucis, on devrait commencer juste en-dessous du cercle. (Bon, la dernière verticale est à modifier, elle devrait être de -125.
Si on va dans l'aperçu avant découpe par contre c'est bon, donc c'est bien un problème de mise à l'échelle dans le cycle de découpe.

A+

Renaud.

Re: Futurs évolutions de Jedicut - Qu'en pensez vous ?

100
Bonsoir Jérôme.

Quelques remarques sur l'interface utilisateur après de longues heures d'utilisation:

- les sauvegardes de fichiers, la sauvegarde de toutes les données attachées au fichier est souhaitable, j'entends les données de l'assistant de découpe ( très important) ainsi que la sauvegarde de la peau. Ceci permettrai d'éviter beaucoup d'erreurs de découpe, on est confiant lorsque que l'on charge un fichier qui a déjà été utilisé et on a tendance à lancer la découpe directement, car pour l'utilisateur il est évident que toutes les données y soient sauvegardées.

- la notion de position de référence est une très bonne idée, mais elle perd beaucoup de son intérêt du fait que cette référence est perdue lorsqu'il y a abandon d'une découpe manuelle ou automatique, car c'est dans ces cas là que l'on a le plus besoin du retour au point de référence, d'autre part le retour au point de référence se fait en vitesse lente c'est peut être un choix délibérer prendre l'avis d'autres utilisateurs. Un bouton dans l'interface manuelle pour le retour au point de référence faciliterait l'utilisation de cette fonction.

- pour ce qui est de l'interface manuelle, je préconise qu'il y ait un champ "déplacement X "avec des flèches avant & arrière et un champ "déplacement Y" avec des flèches haut & bas. Ce qui motive cette proposition est que lorsque que l'on utilise les déplacements manuels on fait souvent des allers et retours sans utiliser la fonction guillotine (puisque qu'elle ne marque pas d'arrêt contrôlable avant le retour ), ceci permettrait de conserver en visuel le dernier déplacement qui vient d'être fait en X & Y et de pouvoir en un simple clic de faire le déplacement inverse sans réécrire la valeur (cas de tranchages horizontaux ou verticaux avec manipulation du bloc).

Est bien pour l'instant c'est tout, bon courage Jérôme.

Alain
`); }); })(jQuery, window, document, phpbb);