Discussion :

[orelero]

Bonjour,
j'aimerai trouver un algo qui permet de tracer un cercle en ayant comme parametre les angles qui ferment l'arc de cercle . Je pensais à bresenharm ou la variante de martin, mais j'arrive juste à tracer un cercle entier et j'arrive pas à trouver un moyen de tracer seulement un arc. Je prefere pas utiliser les cos et sin pour eviter de tracer deux fois le meme point (enfin avec mes algo c ce qui arrivait ).
Voilà merci !

[j.p.mignot]

est-il possible de preciser
1- données du problème ( centre du cercle, rayon du cercle, vecteur normal au cercle )
2- angles ? est-ce un cecle ou un secteur angulaire défini par T1 et T2?
3- doit-on tracer la périférie de cette surface ou la remplir ( granulométrie, arrondis pour accepter ou non un 'pixel' à cheval sur la frontière?
4- But et problème?

[orelero]

1- parametres donnés=centre cercle,rayon cercle,angle de départ, angle d'arrivé (en allant dans le sens trigo= sens inverse des aiguilles d'une montre).Ainsi angle de l'arc de cercle= angle arrivée - angle depart.
2-?? excuse, je ne crois pas comprendre :-(. C'est juste un arc de cercle.
3-seulement la peripherie
4-but: visionner les pixels qui feront l'objet du annalyse colorimetrique (j'en dis pas plus, je vois pas trop à quoi ca sert ).
Merci bien.

[méphistopheles]

je crois qu'un simple (x+a)²+(y+b)²=R² suffit si tu arrive à identifier ton xy de départ et ton xy d'arrivée. pour cela, tu fait une identification en cos et sin avec comme parametre: sinx/cosx =tanx
(pour eviter les angles doubles. Attention au +-pi/2)

salut

[orelero]

j'ai beau eu faire des études de maths mais je comprends pas comment ta methode puisse arriver à éviter de tracer 2 fois un meme point sur l'arc (il y a un infinité de points dans un pixel, il faut donc trouver le bon pas pour tanx).
la methode qui m'aurait le plus facilité les choses aurait été une equation parametrique:
x= xcentre+rayon*cos(t);
y= ycentre+rayon*sin(t);
avec t qui varie de "angle de depart" à "angle d'arrivé". Mais le probleme c'est le pas de t, ...NOrmalement ca serait: "pas de t" = ("angle d'arrivé"-"angle de depart")/("nombre de pixels sur l'arc").
Mais "nombre de pixels sur l'arc" est (je crois) impossible à determiner avant qu'on ait tracé le cercle...
Le mieux serait de choper l'algo de bresenham appliqué à des arcs.

[j.p.mignot]

Il est tout à fait possible de trouver les pixels "traversés" par l'arc. Mais il faut plus de données
1- taille dX en X des pixels,
2- taille dY en Y des pixels.
3- fixer le centre du cercle par rapport au maillage aussi obtenu. En effet suivant la position du mapping, les pixels et même leurs nombres peuvent changer.

Cela demande un peu de calcul mais est facile à faire. On se positionne sur le 1er pixel, de là on cherche parmi les 8 voisins quel est le bon, on s'y met et ainsi de suite. [ Le chiffre 8 doit pouvoir être sensiblement réduit car on connaît la pente p de la droite qui va du centre au point courrant donc celle de la tangente ( -1/p). A voir lors d'1 implémentation ]

Il n'en reste pas moins vrai que suivant le cas il est + rapide de tracer "à l'aveugle" (c.a.d. en utilisant à priori (x,y) = (xc+Rcos(t),yc+Rsin(t)). La distance calculée entre les points est R * dTheta ( dTheta étant le pas choisi pour aller de Theta1 à Theta2). par ailleurs la distance entre pixel est inférieure à min(dX,dY) [dx et dy comme notés dans les remarques 1 et 2]. Si on choisi d Theta = min(dX, dY) / R, on peut définir le nombre de pas comme n = abs(t2-1t1) *R /min(dX, dY) { après avoir correctement recentré t1 et t2 qui sont à 2kpi près }
dans les parties à "45°", la distance entre pixels est typiquement sqrt(2) X plus élevée si dX=dY ( ce qui est en général la cas ). Il y aura donc quelques pixels réécrits mais assez peu et le temps perdu est certainement compétitif avec celui nécessaire à éviter la réécriture. Sans avoir réfléchi, je pense par ailleurs qu'il serait tout à fait possible d'utiliser un pas variable en dTheta en fonction de theta afin de réduire encore la réécriture.
Suivant le but, il vaut mieux être 1 peu prudent et en réécrire 1 de temps en temps plutôt qu'en louper 1! ( fuite lors de remplissage de surface, ...)

[diogene]

J'ai écrit, il ya qq temps, une fonction de tracé de cercle (centré à l'origine mais ce nest pas un problème de le translater en un point quelconque).
Partant d'un point (pixel) donné du cercle, elle fournit à chaque appel le pixel suivant (dans le sens trigo) sur le cercle. Le principe est de rechercher le pixel voisin du pixel actuel le plus proche du cercle que l'on veut tracer. Il n'y a donc aucun calcul de sinus ou cosinus. La courbe tracée est continue et chaque pixel n'est obtenu qu'une fois (à moins qu'on fasse plusieurs tours sur le cercle).
Pour tracer un arc, c'est assez simple, puisqu'à partir du rayon et de l'angle de départ, on peut trouver le point d'origine et il suffit d'arreter le calcul lorsque l'angle final est obtenu.
La fonction est écrite en C. Si le code t'interresse, fais le moi savoir.
Cordialement

[FreddyONE73]

tu fais une boucle qui va te remplir un tableau de points (java.awt.Point)
le calcul de tes points est donné par la formule paramétrique plus haut :
x= xcentre+rayon*cos(t);
y= ycentre+rayon*sin(t);
avant de stocker le nouveau point, du test s'il a les mêmes coordonnées que le précédent
il faut étudier la valeur de ton pas pour être sûr qu'il n'y aura pas de "trous"
ainsi, tu obtiens un tableau contenant juste ce qu'il faut
une simple boucle sur ce tableau (réutilisable) et le tour est joué