PolyedresII.mac

Bonsoir,
Je suis de nature têtu, mais là !
J'ai suivi tes conseils de A à Z, et si je comprends bien, en faisant un simple copier-coller de ton code, je dois VOIR une figure..... bah non!
PS : Que veux-tu dire par " on ne voit rien du tout !" ?
J'obtiens exactement la même fenêtre en chargeant les fichiers.

As-tu réussi à charger le fichier?

Bonsoir,
J'ai fait un grand nettoyage, puis j'ai tout réinstallé.
Je crois pouvoir dire que cela marche :
Merci pour tes compétences et ta très grande disponibilité.

Salut salut tout le monde!

Quel travail Patrick!! Et quelle efficacité!!!

Récapitulons un peu :

F.Couvreur a écrit:[...] notamment grâce au formidable travail de Mr Capriani.

Merci merci!!!

P.Fradin a écrit:D'ailleurs pourquoi n'as tu pas repris ton ancienne macro pour Tetrahémihexaèdre()?

Si j'ai changé la définition de la macro (qui marchait parfaitement à l'origine), c'est parce que j'avais défini initialement le point d'intersection des faces carrée (centre du solide!) Par souci d'homogénéité, j'ai défini tous les polyèdres (à l'exception des solides de Kepler-Poinsot : pas encore eu le temps!!!) par leurs faces sans passer par les éventuels points d'intersection! La force de ton modèle scene3d provient justement du fait que l'on a pas besoin de se compliquer la vie avec ces points d'intersection (je pense pas être très clair!!) Par exemple, initialement, pour le grand icosaèdre, j'ai du définir 92 sommets dont 80 d'entres eux sont des points d'intersection de faces!!! Avec le modèle scene3d, les 12 sommets initiaux suffisent à définir le solide en question!!!!

P.Fradin a écrit:Autre soucis, il y a une erreur à rectifier à chaque fois que tu dessines les arrêtes, par exemple:
Code:

[2, ColorL, Aretes([C, T])]

n'est pas correct, car pour les segments, après la couleur, il faut Width+i*LineStyle avec la liste des segments ...

En effet, j'avais quelques problèmes : certaines arêtes ne se dessinait pas! Et justement, je voulais te demander comment il fallait faire pour changer le style et l'épaisseur des arêtes : j'ai ma réponse!!! Je ne connaissais pas la syntaxe pour les arêtes!!! Je modifie tout ca dans mon fichier et je reposte ca dans quelques minutes avec les explications qui vont avec...

P.Fradin a écrit:Pour en revenir aux macros de polyèdres uniformes, je pense qu'avec un argument supplémentaire, elles pourraient renvoyer soit la liste des facettes, soit la liste de ce qu'il faut mettre dans Build3D (ou Add3D), mais c'est la macro de dessin qui utiliserait Build3D (ou Add3D), je ne sais pas si je suis bien clair?

Euhhh... Pas trop!!!
Tu peux nous en dire un peu plus? Grace à un exemple, j'y verrai probablement plus clair...

P.Fradin a écrit:Le problème des couleurs est réglé, par défaut on distingue le devant/derrière des facettes, pour empêcher cela il suffira de changer le signe de l'opacité, donc dans ton fichier cela donnerait: Color1:=red-i et Color2:=yellow-i.

Nickel!!!

P.Fradin a écrit:D'autre part je pense qu'il serait bon d'ajouter une variable "contrast", initialisée à 0, qui si on l'augmente permettrait d'augmenter un peu le contraste entre les différentes facettes

Très bonne idée!!! Il est vrai que pour certains polyèdres (notament ceux qui ne sont pas convexes), il peut être intéressant de changer le contrast pour voir de quelle manière s'intersectent les faces. Ton exemple avec le rhombicosaèdre en est une très bonne illustration!!!


Je vais regareder toutes les modifications que tu as apporté au modèle scene3d et apporter les quelques modification nécessaires à mon fichier PolyedresII.mac! Je vous tiens au courant au sujet de tout ca...

F.Couvreur a écrit:Bonsoir,
J'ai fait un grand nettoyage, puis j'ai tout réinstallé.
Je crois pouvoir dire que cela marche

Super! Je vois que ton interface ta police de caractères est grande! Tu es sous Ubuntu? Parce que la barre d'outils semble bien rabotée par le bas! Je vais l'agrandir un peu pour la prochaine version test (qui ne saurait tardé, aujourd'hui ou demain)

Merci pour tes compétences et ta très grande disponibilité.

De rien, c'est toujours un plaisir de partager ce que l'on aime bien!

Euhhh.... Est-ce que les la version de TeXgraph avec les nouveautés de scene3d.mod a été mise à jour?
Si oui, quel lien il faut utiliser pour la télécharger? Celui qui est dans le post initial du sujet sur la nouvelle version?

Alphonse Capriani a écrit:Salut salut tout le monde!

Salut Alphonse,

Quel travail Patrick!! Et quelle efficacité!!!

Merci!!

Si j'ai changé la définition de la macro (qui marchait parfaitement à l'origine), c'est parce que j'avais défini initialement le point d'intersection des faces carrée (centre du solide!) Par souci d'homogénéité, j'ai défini tous les polyèdres (à l'exception des solides de Kepler-Poinsot : pas encore eu le temps!!!) par leurs faces sans passer par les éventuels points d'intersection! La force de ton modèle scene3d provient justement du fait que l'on a pas besoin de se compliquer la vie avec ces points d'intersection (je pense pas être très clair!!) Par exemple, initialement, pour le grand icosaèdre, j'ai du définir 92 sommets dont 80 d'entres eux sont des points d'intersection de faces!!! Avec le modèle scene3d, les 12 sommets initiaux suffisent à définir le solide en question!!!!

Effectivement, je l'ai compris après! J'aurais du m'en douter avant car le dodécadodécaèdre Ditrigonal que j'ai envoyé à Syracuse était justement construit comme ça! Le seul inconvénient que j'y vois est que ces intersections correspondent à des arêtes qui ne vont pas être dessinées, mais ce n'est pas très grave en soi.

Euhhh... Pas trop!!!
Tu peux nous en dire un peu plus? Grace à un exemple, j'y verrai probablement plus clair...

Par exemple, on aurait la macro: Tetrahemihexaedre(centre, sommet, facettes) qui serai définie ainsi:

Code:


[$M1:=[0,1], $M2:=[-1,0], $M3:=[i,0],
$M4:=[-i,0], $M5:=[1,0], $M6:=[0,-1],
$L:=[M1, M2, M3, M4, M5, M6],
$C:=MakePoly(L, [2, 4, 5, 3, jump, 1, 3, 6, 4, jump, 1, 2, 6, 5, jump]),
$T:=MakePoly(L, [1, 2, 4, jump, 1, 5, 3, jump, 6, 2, 3, jump, 6, 5, 4, jump]),
[1+i*contrast, Color1-i, C], [1+i*contrast, Color2-i, T], NilC([2, ColorL, WidthStyle, Aretes([C, T])]),
%3:=[C,T]]


La macro renvoie la liste à inclure dans un Build3D, et dans le troisième paramètre (qui doit être une variable), on récupère juste la liste des facettes si ce paramètre est présent. Ainsi , l'utilisateur pourra faire:

..., T:=Tetrahemihexaedre(Origin, M(0,04)), Build3D(T, ...), Display3D(), ...

Je suis revenu en arrière, j'ai laissé tomber l'idée de New3D() et Add3D(), car l'algorithme actuel ne s'y prête pas bien, on reste donc avec Build3D() et Display3D().

PS: j'ai du allonger la taille max du nom des identificateurs (de 20 à 25) pour certaines de tes macros!

Alphonse Capriani a écrit:Euhhh.... Est-ce que les la version de TeXgraph avec les nouveautés de scene3d.mod a été mise à jour?
Si oui, quel lien il faut utiliser pour la télécharger? Celui qui est dans le post initial du sujet sur la nouvelle version?

Pas encore! mais j'espère aujourd'hui, ce n'est pas sûr car j'attends de la famille.

Ok pas de problème!!!

Préviens juste quand ce sera fait et je modifierai ensuite mon fichier...

Tiens? J'ai l'impression que tu as édité ton précédent message!!! J'avais pas vu que tu avais donné des précisions sur la suggestion que tu avais faite dans un post précédent!!!

P.Fradin a écrit:Le seul inconvénient que j'y vois est que ces intersections correspondent à des arêtes qui ne vont pas être dessinées, mais ce n'est pas très grave en soi.

Je vois ce que tu veux dire, mais en fait il ne s'agit pas vraiment d'arêtes. Les arêtes des polyèdres en question sont finalement les cotés des faces, que le polyèdre soit convexe ou non. De la manière dont j'avais défini les solides de Kelpler-Poinsot, alors là, je suis d'accord, on peut appeler ca des arêtes, mais on s'éloigne un peu du concept de polyèdres réguliers (en fait les faces ne sont plus des polygones réguliers mais des triangles quelquonques, ou autre...) ( Encore un gros manque de clarté dans mes propos!!!)

Je viens de lire tes suggestions concernant la syntaxe des macros de PolyedresII.mac. C'est vrai que ce serai bien mieux comme ca!!! Je vais faire les modifiactions nécessaires!

A noter que la syntaxe Polyèdre(<Centre>, <Sommet>, ...) n'as pas été faite pour les derniers polyèdres que j'ai construit : je voulais le faire a la fin, mais j'ai oublié!!! Je vais donc corriger tout ca...

P.Fradin a écrit:PS: j'ai du allonger la taille max du nom des identificateurs (de 20 à 25) pour certaines de tes macros!

Ouais!!! es polyèdres uniformes ont des noms a dormir debout!!!

Un truc me chifonne concernant la syntaxe que tu propose. Si je lis bien le code que tu as mis, on aurait :

Code:

[1+i*contrast, Color1-i, C], [1+i*contrast, Color2-i, T], NilC([2, ColorL, WidthStyle, Aretes([C, T])]),

Donc la macro renverra une liste et une seule. Or la macro Build3D() ne prend pas qu'un seul argument! Donc le Build3D(T) risque de poser problème, non?

Bon : je confirme, ca pose problème!!! Après quelques tests, ca ne marche pas!!!

Je suis en train de réfléchir à une parade pour contourner le problème... L'idéal aurait été que TeXgraph soit capable de gérer les listes de listes mais ce n'est pas le cas!!! A dire vrai, je vois pas bien comment faire...

Je vois éventuellement une possibilité, mais elle ne me plait pas trop :

Le truc, ce serai d'utiliser la même syntaxe que tu as proposé, mais en la modifiant de cette manière :

Code:

{Tetrahemihexaedre(<Centre>, <Sommet>, [<Faces 1>, <Faces 2>, <Côtés>])
[
$M1:=[0,1], $M2:=[-1,0], $M3:=[i,0],
$M4:=[-i,0], $M5:=[1,0], $M6:=[0,-1],
$L:=[M1, M2, M3, M4, M5, M6],
$C:=MakePoly(L, [2, 4, 5, 3, jump, 1, 3, 6, 4, jump, 1, 2, 6, 5, jump]),
$T:=MakePoly(L, [1, 2, 4, jump, 1, 5, 3, jump, 6, 2, 3, jump, 6, 5, 4, jump]),
[C,T],
%3:=[1+i*contrast, Color1, C],
%4:=[1+i*contrast, Color2, T],
%5:=[NilC([2, ColorL, StyleL, Aretes([C, T])])]
]

(J'ai modifié la variable WidthStyle en StyleL par souci d'homogénéité avec les autres variable globales que j'ai définies (Color1, Color2, ColorL, ...))
Et donc, la macro en question renverra la liste des facette et pour dessiner le solide en question en utilisant les macros de scene3d, il faudra utiliser :

Code:

Tetrahemihexaedre(Origin, M(1, 0, 0), Carres, Triangles, Cotes),
Build3D(Carres, Triangles, Cotes),
Display3D()

Je pense que comme ca, ca devrait marcher!

T'en pense quoi? T'as une autre solution?
(En tout cas je viens de tester ma dernière méthode et ca marche nickel!!!)

Bonjour Alphonse,

Oui tu as tout à fait raison! Mon idée n'était valable que pour une seule liste en fait (comme quoi je n'avais pas testé ). Je pense que ta proposition est la bonne en effet.

PS: je conseillerais de mettre le -i dans la macro et non pas directement dans les Color, car si un utilisateur change la couleur il n'aura pas l'idée d'ajouter ce -i!

Oui, tu as raison!!

J'avais fait comme ca pour faire simple, mais c'est vrai que du point de vue pratique, il vaut mieux l'ajouter!!

Je vais faire les modification des toutes les macros cet après midi (enfin je vais essayer)
J'espère pouvoir poster une nouvelle version du fichier dans la soirée...

Je te tiens au courant!!!

Alphonse Capriani a écrit:
Je vais faire les modification des toutes les macros cet après midi (enfin je vais essayer)
J'espère pouvoir poster une nouvelle version du fichier dans la soirée...
Je te tiens au courant!!!

Y a pas le feu! J'ai encore quelques petits détails à régler avant d'en faire une version officielle (d'ailleurs si tu vois des fautes, des oublis ou imprécisions dans la doc n'hésite pas!), j'ai aussi quelques macros à ajouter que m'a demandées quelqu'un (que tu dois connaître car il s'appelle comme toi ).

Ouais je vois qui c'est : c'est celui qui arêtes pas de te harceler avec ses suggestions!!!

Bon : je me mets au travail de suite! (j'ai que ca a faire cet après midi!!! )

En fait, je laisse Color1 a la place de Color1-i. La raison de ce choix est que si l'on veut changer l'opacité des faces (facteur du nombre i), ce ne sera pas facile à faire si dans la macro Color-i est utilisé. Par exemple, pour avoir un opacité de 0.75, il faudra définir Color1 de la manière suivante : Color1:=red+0.25*i ce qui n'est pas très pratique!! On voudrait plutot taper Color1:=red-0.75*i. A moins que je me trompe sur la définition de l'opacité avec le macro Build3D!

Bon : j'ai fini de mettre à jour PolyedresII.mac compte tenu des remarques faites ci dessus.

Finallement, rien ne change (pour l'instant) pour les polyèdres convexes. En revanche, la syntaxe des polyèdres non convexes change. Voici la syntaxe générale :


Chacune de ces macro renvoie la liste des facettes du solide en question. Les arguments 3, 4, 5 et 6 permettent de récupérer la définition des faces et des arêtes pour pouvoir dessiner le polyèdres avec la fonction Display3D (via la macro intermédiare Build3D) Ces 4 arguments optionneles sont des noms de variables. Ainsi, pour dessiner un petit dodécicosaèdre, voici la manière dont il faut s'y prendre :

Code:

[
contrast:=0.5,
Color1:=green-i, Color2:=gray-i,
ColorL:=yellow, StyleL:=8+i*solid,
PtDodecicosaedre(Origin, [1, 0], Deca, Hexa, Arete),
Build3D(Deca, Hexa, Arete)
Display3D()
]

A noter que j'ai égallement modifié les solides de Kepler-Poinsot : désormais, il sont définis comme les autres polyèdres non convexes (suppression de tous les points d'intersection)

S'il y a des questions concernant l'utilisation du fichier ou si des bugs sont détectés, n'hésitez pas a m'en faire part!!!

Je vais prochainement mettre à jour le PDF qui va avec : je vous tiendrai au courant...

Voici donc la dernière mise à jour du fichier :
PolyedresII.mac

Tu chômes pas non plus dis donc!

Je viens de jeter un oeil, personnellement dans les macros j'aurais mis Color1-i et Color2-i, à la plce de Color1 et Color2 tous seuls, c'est un oubli?

Salut salut Patrick! (et les autres!!!)

P.Fradin a écrit:Tu chômes pas non plus dis donc!

Ben ouais : le travail, c'est la santé...

P.Fradin a écrit:Je viens de jeter un oeil, personnellement dans les macros j'aurais mis Color1-i et Color2-i, à la plce de Color1 et Color2 tous seuls, c'est un oubli?

J'avais déja répondu a cette suggestion : t'as du rater la réponse car si je me trompe pas j'avais édité un message que tu avais du lire auparavant. Voila donc ma réponse :

Alphonse Capriani a écrit:En fait, je laisse Color1 a la place de Color1-i. La raison de ce choix est que si l'on veut changer l'opacité des faces (facteur du nombre i), ce ne sera pas facile à faire si dans la macro Color-i est utilisé. Par exemple, pour avoir un opacité de 0.75, il faudra définir Color1 de la manière suivante : Color1:=red+0.25*i ce qui n'est pas très pratique!! On voudrait plutot taper Color1:=red-0.75*i. A moins que je me trompe sur la définition de l'opacité avec le macro Build3D!

Sinon, si ca te dérange pas d'attendre une semaine pour poster la version officielle de TeXgraph 1.93, ce serai cool : je vais ce week-end finir de modifier le fichier PolyedresII.mac ("uniformisation" des syntaxes des macros) et je vais achever le pdf explicatif. Je posterai tout ca mardi sans fautes. Si tu peux pas attendre, c'est pas grave : ca fera partie de la version 1.94!!!

Salut Alphonse,

Pas de soucis, je peux attendre. J'ai encore quelques corrections à faire. J'ai ajouté la commande
HexaColor(<chaine héxa>), la macro Ryb, la constante Nil (enfin!). Quelques améliorations/corrections sur les macros axes, axeX, axeY et GradDroite.

Pour les polyèdres uniformes: je pensais ajouter la variable opacity, initialisée à 1, ainsi dans les macros on écrit Color1-i*opacity et dans Color1 on ne met que la couleur (idem pour les deux autres). Je pensais même aller un peu plus loin ajoutant une variable light entre 0 et 1, initialisée à 0, et écrire dans les macros: (1-light)*Color1+light*white-i*opacity, tu me suis?

Toujours plus loin: j'ai trouvé un moyen de faire en sorte que Buil3D puisse accepter toutes les faces et arêtes de ces polyèdres en une seule liste, en lui disant où s'arrêter! C'est possible en convenant par exemple de glisser un jump entre deux, mais c'est là qu'est la ruse, pas n'importe quel jump! En fait la constante jump est un complexe particulier (hors intervalle) qui n'est testé en interne que sur sa partie réelle, on peut donc glisser des infos dans la partie imaginaire et convenir par exemple que la valeur: Re(jump)-i sépare les différents objets pour Build3D et le tour est joué! L'avantage c'est que pour les macros il suffit une seule variable en sortie pour récupérer la liste, c'est bien plus pratique! Qu'en penses-tu?

P.Fradin a écrit:Pas de soucis, je peux attendre. J'ai encore quelques corrections à faire. J'ai ajouté la commande
HexaColor(<chaine héxa>), la macro Ryb, la constante Nil (enfin!). Quelques améliorations/corrections sur les macros axes, axeX, axeY et GradDroite.

Ok c'est cool! Mardi au plus tard, tu aura la dernière version de PolyedresII.mac et tu pourra poster la version ultime de TeXgraph...

P.Fradin a écrit:Pour les polyèdres uniformes: je pensais ajouter la variable opacity, initialisée à 1, ainsi dans les macros on écrit Color1-i*opacity et dans Color1 on ne met que la couleur (idem pour les deux autres). Je pensais même aller un peu plus loin ajoutant une variable light entre 0 et 1, initialisée à 0, et écrire dans les macros: (1-light)*Color1+light*white-i*opacity, tu me suis?

Ok : avec la variable opacity, je veux bien initialiser les variables Colork à couleur-i*opacity. Concernant ta variable light, il s'agit de la luminosité? Pourquoi dans ton exemple tu as rajouté light*white? J'ai l'impression que la luminosité que tu as défini est en fait un barycentre entre les couleurs white et Colork. Y'aurait pas un moyen de définir cet option sans avoir a passer par par le light*white?

Concernant ces dernières modifications, ce serai super si ca pouvait être classé d'ici vendredi après midi pour que je puisse fignoler PolyedresII.mac ce week-end avec ces dernières inovations!

P.Fradin a écrit:Toujours plus loin: j'ai trouvé un moyen de faire en sorte que Buil3D puisse accepter toutes les faces et arêtes de ces polyèdres en une seule liste, en lui disant où s'arrêter! C'est possible en convenant par exemple de glisser un jump entre deux, mais c'est là qu'est la ruse, pas n'importe quel jump! En fait la constante jump est un complexe particulier (hors intervalle) qui n'est testé en interne que sur sa partie réelle, on peut donc glisser des infos dans la partie imaginaire et convenir par exemple que la valeur: Re(jump)-i sépare les différents objets pour Build3D et le tour est joué! L'avantage c'est que pour les macros il suffit une seule variable en sortie pour récupérer la liste, c'est bien plus pratique! Qu'en penses-tu?

Finallement, le fait que les macros de polyèdres renvoient plusieurs listes différentes (une par types de face + une pour les aretes) ne me dérange plus! En fait, je trouve même ca mieux que si il n'y avait q'une seule liste renvoyée. La raison de cette préférence est que si l'on veut afficher qu'un seul type de faces d'un polyèdre, ca pose pas de problème. De plus, la solution que tu propose m'a l'air assez complexe.

Concernant ta variable light, il s'agit de la luminosité? Pourquoi dans ton exemple tu as rajouté light*white? J'ai l'impression que la luminosité que tu as défini est en fait un barycentre entre les couleurs white et Colork. Y'aurait pas un moyen de définir cet option sans avoir a passer par par le light*white?

A vrai dire je n'ai pas encore essayé, mais je ne vois pas comment augmenter autrement l'impression de luminosité .

Concernant ces dernières modifications, ce serai super si ca pouvait être classé d'ici vendredi après midi pour que je puisse fignoler PolyedresII.mac ce week-end avec ces dernières inovations!

Pas de problème!

PS: concernant ma proposition pour Build3D elle n'est pas si complexe que cela à programmer en interne! Je vais faire cette modification pour Build3D (ce qui ne change en rien son fonctionnement actuel et cela pourrait servir par ailleurs) mais on laissera les macros de PolyèdresII.mac renvoyer les données comme tu l'avais prévu.

Parfait!!!

Je suis en train de modifier macros de PolyedresII.mac pour qu'elles aient toute la même syntaxe. Quand je pense qu'il y a 92 solides de Johnson, j'en ait mal au crâne rien que d'y penser!!!

Alphonse Capriani a écrit:
Je suis en train de modifier macros de PolyedresII.mac pour qu'elles aient toute la même syntaxe. Quand je pense qu'il y a 92 solides de Johnson, j'en ait mal au crâne rien que d'y penser!!!

Je ne comprends pas trop. Pourquoi modifier les solides de Johnson? Je pensais que tu ne modifiais que les polyèdres non convexes! A mon avis pour les polyèdres convexes on a aucun intérêt à passer par Build3D, DrawPoly est plus efficace dans ce cas et les images sont bien plus légères.

Si je choisit de modifier égallement la syntaxe des polyèdres convexe, c'est pour que toutes les macros s'utilise de la même manière. Toutes les macros renvoient ainsi la liste des facettes du polyèdre ce qui, pour le cas des solides convexes, n'empêche en rien l'utilisateur d'utiliser la macro DrawPoly.

En revanche, grace a cette nouvelle syntaxe, pour tous les polyèdres (convexes ou non), on peut choisir de colorier chaque face de même type d'une même couleur en changeant éventuellement la couleurs pour différents types de faces.

Par exemple, avec le grand rhombicuboctaèdre, on peut obtenir le solide suivant, graphique qu'on ne pouvait pas réaliser avec la macro DrawPoly :

Alphonse Capriani a écrit:Si je choisit de modifier égallement la syntaxe des polyèdres convexe, c'est pour que toutes les macros s'utilise de la même manière. Toutes les macros renvoient ainsi la liste des facettes du polyèdre ce qui, pour le cas des solides convexes, n'empêche en rien l'utilisateur d'utiliser la macro DrawPoly.

Oui, très juste, si toutes les macros renvoie la liste des faces comme c'était le cas, ce n'est pas un problème.

En revanche, grace a cette nouvelle syntaxe, pour tous les polyèdres (convexes ou non), on peut choisir de colorier chaque face de même type d'une même couleur en changeant éventuellement la couleurs pour différents types de faces.

Je me doutais bien un peu que c'était la raison essentielle, et en effet c'est très bien ainsi. Ton exemple est très parlant.

PS: j'ai testé mon idée avec le paramètre light, bof... c'est pas ça