résolution des arcs

[krunch]

Bonjour

Est ce que par hasard quelqu'un connaitrait l'algorithme de résolution des objets à lissage arc* ?

C'est à dire le nb de segments rectilignes utilisés pour tracer ces segments... (ce n'est pas par curiosité c'est pour éventuellement pouvoir les retracer).

Apparemment il y a 3 paramètres : la variable ArcSmooth, le facteur de zoom et la courbure de chaque arc

* cercles, arcs, polys2D lissées, LWPolys à courbure et même splines je crois

[didier]

coucou

 

je ne comprends pas bien ta question,

en effet les arc et autres courbes sont parfaitement dessinées dans Autocad

 

il ne pas se fier à l'aspect à l'écran, qui dépend de variables d'affichage

 

la meilleure preuve c'est que tu peux t'accrocher au CENTRE d'un arc

cet objet est la définition mathématique des arcs.

 

amicalement

[bonuscad]

Bonjour,

 

Regarde ce sujet

 

Dans cette routine j'utilise un algorithme pour simuler le tracé de courbe.

Il va de soit que c'est moi qui ai fixé la définition (de mémoire 1/36 de quart de cercle)

 

c'est pour éventuellement pouvoir les retracer).

 

Je t'en extrait le code essentiel pour que tu cerne mieux la procédure (cela dessine un oeuf en virtuel, s'efface avec un REDESS)

 

Ça ne répond pas directement à a question, et ne sais si cela te sera utile!

 

Autrement la commande _VIEWRES définie "l'apparence" graphique des entités dessinées, ou aussi la variable WHIPARC

(defun fig_pts (pt_cen pt_begin pt_end rad / inc ang nm p1 p2 p3)
(setq
	inc (angle pt_cen pt_begin)
	ang (+ (* 2.0 pi) (angle pt_cen pt_end))
	nm (fix (/ (rem (- ang inc) (* 2.0 pi)) (/ (* pi 2.0) 36.0)))
)
(repeat nm
	(setq
		p1 (polar pt_cen inc rad)
		inc (+ inc (/ (* pi 2.0) 36.0))
		p2 (polar pt_cen inc rad)
		lst (append lst (list p1 p2))
	)
)
(if lst
	(setq
		p3 (polar pt_cen ang rad)
		lst (append lst (list p2 p3))
	)
)
)
(defun c:test ( / loop ptx key pt_drag rad pt1 pt2 pt3 pt4 cc1 lst)
 (setq loop T)
 (while (null (setq ptx (getpoint "\nSpécifiez le point: "))))
 (while (and (setq key (grread T 4 0)) (/= (car key) 3) loop)
	(cond
		((eq (car key) 5)
			(redraw)
			(setq pt_drag (list (caadr key) (cadadr key) (caddr ptx)))
       (setq
				rad (distance (list (car ptx) (cadr ptx)) (list (car pt_drag) (cadr pt_drag)))
				pt1 (polar ptx (- (angle ptx pt_drag) (/ pi 2.0)) rad)
				pt2 (polar ptx (+ (angle ptx pt_drag) (/ pi 2.0)) rad)
				pt3 (polar pt1 (+ (angle pt1 pt_drag) (/ pi 2.0)) (* 2.0 rad))
				pt4 (polar pt2 (- (angle pt2 pt_drag) (/ pi 2.0)) (* 2.0 rad))
				cc1 (polar pt1 (+ (angle pt1 pt2) (/ pi 4.0)) (* (sqrt 2.0) rad))
			)
			(fig_pts ptx pt1 pt2 rad)
			(fig_pts pt1 pt2 pt3 (* rad 2.0))
			(fig_pts cc1 pt3 pt4 (- (* 2.0 rad) (* (sqrt 2.0) rad)))
			(fig_pts pt2 pt4 pt1 (* rad 2.0))
			(if lst (progn (grvecs lst) (grdraw ptx pt_drag 7)))
			(setq lst nil)
		)
	)
)
(prin1)
)

[krunch]

Bonjour

 

Oui c'est aussi pour les retracer avec grdraw comme dans cette routine

 

Il va de soit que c'est moi qui ai fixé la définition (de mémoire 1/36 de quart de cercle)

C'est bien pour ça : je cherchais la "définition" correspondant à l'environnement courant de façon à retracer les segment pile-poil (sinon ça "bave"). Apparemment cette définition dépend d'un algorithme pas simple, avec les 3 variables dont j'ai parlé (je découvre que la valeur _VIEWRES est justement celle de ArcSmooth, c'est la même).

 

Par contre je découvre aussi que j'étais en WHIPARC=0.

Si je passe en 1 les arcs sont de vrais arcs (c'est à dire avec une résolution "infinie"), VIEWRES ne compte plus, et il ne trace plus les courbes avec des segments de résolution ? Je croyais que tout se faisait forcément avec des segments..

 

En vous remerciant

[(gile)]

Salut,

 

Avec grread, plutôt que d'utiliser grvecs ou grdraw qui ne donnent pas toujours satisfaction avec les courbes, les textes etc... Je préfère utiliser entmake(x) ou entmod, on supprime l'entité créée avec entdel (comme on le ferait avec redraw), il faut juste penser à l'ajouter dans une fonction de gestion des erreurs.

 

Un exemple simple ci-dessous, un plus sophistiqué ici (et message suivant)

 

(defun c:test (/ *error* cen gr loop p1 p2 pl)

 (defun *error* (msg)
   (and pl (entdel pl) (setq pl nil))
   (princ (strcat "\nErreur: " msg))
   (princ)
 )

 (setq	cen  (getpoint "\nCentre: ")
loop T
 )
 (while (and (setq gr (grread T 12 0)) loop)
   (cond
     ((= (car gr) 5)
      (and pl (entdel pl) (setq pl nil))
      (setq p1	(cadr gr)
     p2	(polar cen (angle p1 cen) (distance cen p1))
     pl	(entmakex
	  (list
	    '(0 . "LWPOLYLINE")
	    '(100 . "AcDbEntity")
	    '(100 . "AcDbPolyline")
	    '(70 . 0)
	    '(90 . 5)
	    (cons 10 p2)
	    '(42 . 1.0)
	    (cons 10 p1)
	    '(42 . 1.0)
	    (cons 10 p2)
	    '(42 . 1.0)
	    (cons 10 cen)
	    '(42 . -1.0)
	    (cons 10 p1)
	  )
	)
      )
     )
     ((= (car gr) 3) (setq loop nil))
     (T (and pl (entdel pl) (setq pl nil)) (setq loop nil))
   )
 )
 (princ)
)

[krunch]

Salut et merci

C'est vrai que ça peut aussi marcher avec des entités. J'avais laissé tomber cette méthode que je trouvais pas assez light, et parcequ'il est fréquent d'avoir des entités superposées avec des résolutions différentes (qui ne se superposent pas vraiment), mais peut-être pas avec WHIPARC=1

[zebulon_]

Bonjour,

 

J'adopte cette méthode étant donné que grdraw est vraiment très limité. Merci pour le tuyau.

Par contre, j'ai une petite question : tu utilises un entmakex, alors que tu es un fan des vla-etcetera. J'en conclue que ça ne marche pas avec les fonctions vla ?

 

Fausse conclusion, ça marche aussi avec des vla-add et vla-delete.

 

Amicalement

Vincent

 

 

[Edité le 17/3/2009 par zebulon_]

[(gile)]

Par contre, j'ai une petite question : tu utilises un entmakex, alors que tu es un fan des vla-etcetera.

 

Je ne suis pas plus fan des fonction vla* que des fonctions ent*, j'aime bien les deux et tout dépend du contexte.

Pour certaines choses les fonctions vla* sont incontournables (blocs dynamiques, propriétés mécaniques...), pour d'autres je n'ai jamais trouvé en vlisp et continue à utiliser les données DXF (retrouver l'entité viewport liée à une polyligne transformée en fenêtre).

 

Les vla-get-*, vla-put-* sont souvent plus commodes qu'un entmod, mais je trouve entmake plus pratique que vla-add* pour les polylignes en particulier. L'accès aux données étendues et aux dictionnaires/xrecords est aussi plus facile avec les listes DXF, mais pour scanner une collection, j'aime bien vlax-for...

 

Et la fonction command est parfois aussi bien pratique...

[zebulon_]

C'était une boutade. C'est effectivement mieux de ne pas être sectaire et de choisir la méthode la plus appropriée au cas à traiter. Approprié peut évidemment prendre plusieurs significations : au mieux de ses connaissances, ce qui s'écrit le plus facilement, ce qui est le plus rapide d'exécution etc ... Tout dépend du contexte.

 

Amicalement

Vincent