PolyedresII.mac

Oui : c'est pas compliqué!!!

Code:

{persp(<Liste de points>, <Point de fuite>, <Plan>) : Perspective de centre C (2ème argument) sur le plan (3ème argument)}
Map3D(interDP([%2, M-%2], %3), M, %1)


Voici un exemple :

Obtenu avec ce code :

Code:

% TeXgraph version 1.93
% Fenetre Xmin Xmax Ymin Ymax Xscale Yscale
100#-5.687830687831#4.312169312169#-5#5#2#2##
% Marges gauche droite haut bas cadre gestion_couleur comptgraph
101#0#0#0#0#0#1#2##
% Affectation des Variables theta et phi
18##[theta:=0.7231, phi:=1.2799, OriginalCoord(1)]##
% Déclaration des Macros
16#persp#{persp(<Liste de points>, <Point de fuite>, <Plan>) : Perspective de centre C (2ème argument) sur le plan (3ème argument)}
Map3D(interDP([%2, M-%2], %3), M, %1)
##
% Déclaration des Eléments graphiques
% axes3D1 (Utilisateur)
18##[tMin:=-5,tMax:=5,LabelSize:=1]##
14#axes3D1#Axes3D(0,0,0,1,1,1)#-1##
% Perspective (Utilisateur)
18##[LabelSize:=3]##
14#Perspective#[
FillStyle:=none,
Color:=lightblue, Width:=Thicklines,
$L:=Seq([2*exp(i*k*pi/60)+4, -1], k, 1, 120),
Ligne3D(L, 1),
Lp:=persp(L, [0, 1], [[1, 0], vecI]),
DotStyle:=bigdot, Color:=green,
Point(Proj3D([0, 1])),
Color:=gray, Width:=thinlines,
Ligne3D([[0, 1], [2*exp(i*36*pi/60)+4, -1]]),
Ligne3D([[0, 1], [2*exp(i*72*pi/60)+4, -1]]),
Ligne3D([[0, 1], [2*exp(i*105*pi/60)+4, -1]]),
FillStyle:=bdiag, FillColor:=Light(lightpink, 0.75),  FillOpacity:=0.75,  Color:=black,
DrawPlan([[1, 0], vecI], vecK, 5, 3),
FillStyle:=none,
Color:=crimson, Width:=Thicklines,
Ligne3D(Lp, 1)
]
#-1##


Salut Alphonse,

Je viens d'essayer ton fichier avec un solide:



Le problème que tu soulèves je suppose est celui des parties cachées. Je remarque ausi que pour illustrer cette perpective tu as utilisé (et moi itou) la commande Proj3D, c'est à dire la projection orthographique

Je pense que normalement dans ce type de projection, le point de fuite est l'oeil et le plan est l'écran, le vecteur \n est donc celui dirigé vers l'oeil, c'est lui qui permet de gérer les parties visibles ou non. Je fais un test comme ça et je reviens.

Bon, voilà j'ai fait un test avec l'oeil à la position: 20*\n, et le plan de projection : yOz. J'ai donc modifié ta macro de la manière suivante:

Code:


Map3D([$R:=interDP([%2, M-%2], %3),Im(R[1])+i*Re(R[2])], M, %1)


et j'ai testé le code suivant:

Code:


[$Oeil:=20*\n, plan:=[[0,0],vecI],
FillStyle:=none, Color:=black,
axe:=persp( [M(Xinf,0,0),M(Xsup,0,0),jump,M(0,Yinf,0),M(0,Ysup,0),jump,
            M(0,0,Zinf),M(0,0,Zsup)], Oeil, plan),
Ligne(axe,0),
FillStyle:=full,
Color:=lightblue, Width:=Thicklines,
$L:=SortFacet(Parallelep(M(0,0,0), 3*vecI,3*vecJ,3*vecK),i),
Lp:=persp(L, Oeil,plan),
Ligne(Lp,1)]


Pour obtenir finalement:


PS: si tout cela est concluant, il est envisageable d'ajouter en interne une variable pour le mode de projection, la commande Proj3D s'adapterait au mode de projection et cela serait transparent à l'utilisateur et ça éviterait de devoir réécrire des macros de dessin déjà faites...

Salut!

Après un peu de réflexion, je propose une projection centrale non pas sur yOz, mais sur le plan passant par l'origine et normal au vecteur \n (le même plan que pour la projection orthographique), pour définir cette projection il faut définir la distance D de l'observateur (par rapport au plan) le vecteur position de l'obervateur est alors D*\n. L'avantage de prendre le même plan, et qu'après avoir projeté nos points sur le plan, on peut utiliser Proj3D pour avoir l'affixe écran! Ce qui donne pour la macro persp:

Code:


{persp(<Liste de points>, distance)}
Proj3D(Map3D( interDP([$M,M-%2*\n],[[0,0],\n]),M, %1))


Un petit essai:

Code:


[$distance:=10, FillStyle:=none, Color:=black,
axe:=persp( [M(Xinf,0,0),M(Xsup,0,0), jump, M(0,Yinf,0),M(0,Ysup,0), jump,
                      M(0,0,Zinf),M(0,0,Zsup)], distance),
Ligne(axe,0),
FillStyle:=full, Color:=lightblue, Width:=Thicklines,
$L:=SortFacet(Parallelep(M(0,0,0), 3*vecI,3*vecJ,3*vecK),i),
Lp:=persp(L,distance),
Ligne(Lp,1)]


donne:

Dernier avantage: on peut continuer à faire tourner la scène comme avec l'autre projection

Ouais : c'est exactement le résultat que je voulais obtenir.

Malgré tout, le code reste plutot compliqué : il serait agréable d'en faire une macro DrawPersp par exemple qui permettrait de dessiner un solide en perspective.

A noter qu'on est toujours dans le sujet PolyedresII.mac : je trouve qu'il serait intéressant que ce mode de représentation soit disponible pour n'importe quel solide, convexe ou non!
Comme le dessin fait par ton élément graphique utilisateur est affiché grace a la commande Ligne, ca va vite poser problème dans les cas non convexes.

Y aurait moyen de généraliser tout ca?

Le code n'est pas si compliqué que cela! Le coup du SortFacet c'est ce que fait la macro DrawPolyNC. La différence entre les deux modes se résume à: avant le Proj3D on applique persp ou non? C'est cela que je vais modifier en interne. Ainsi on n'aura pas de code à changer mais seulement le mode utilisé par le biais d'une variable.

Ok! D'accord!!!

On attend cette nouveauté avec impatience...

Je viens de remarqué un petit défaut dan,s le fichier de macro PolyedresII.mac. Il s'agit d'un détail, mais je viens de le corrigé!

Le problème (si on peut dire ainsi) se situe dans la définition du petit rhombicuboctaèdre. J'avais oublié de séparer 2 types de faces carrés. Avec ma modification, on a bien une différentiation de ces 2 types de faces. Voici ce qu'on obtient :


Voici la dernière mise a jour du fichier en question : Télécharger PolyedresII.mac

Salut Alphonse,

Voilà, le nouveau PolyedresII.mac est chargé, il fera donc partie de la prochaine mise à jour.
A ce propos:

- je tarde un peu pour incorporer la perspective centrale, car certes j'avais dit qu'il suffisait de faire la projection en interne avant le Proj3D, mais c'était sans compter que cela change aussi le tri des facettes et entraîne donc une mise à jour de diverses commandes (et on des moindres) comme Build3D, DrawPoly, ...

- d'autre part je propose tant qu'à faire, d'ajouter en interne une matrice 3D de transformation qui serait appliquée avant la projection des points à l'écran (comme en 2d en fait). Elle permettrait par exemple d'adapter le graphique 3D à une boite par défaut (comme [-5,5]x[-5,5]x[-5,5]) ce qui évite à l'utilisateur d'avoir à bidouiller la fenêtre graphique. C'est ce que j'ai fait dans le fichier proglin3d par exemple (tu l'as testé au fait?), et c'est ce que je suis en train faire dans un nouveau fichier pour faire des courbes de niveau.

P.Fradin a écrit:d'autre part je propose tant qu'à faire, d'ajouter en interne une matrice 3D de transformation qui serait appliquée avant la projection des points à l'écran (comme en 2d en fait). Elle permettrait par exemple d'adapter le graphique 3D à une boite par défaut (comme [-5,5]x[-5,5]x[-5,5]) ce qui évite à l'utilisateur d'avoir à bidouiller la fenêtre graphique. C'est ce que j'ai fait dans le fichier proglin3d par exemple (tu l'as testé au fait?), et c'est ce que je suis en train faire dans un nouveau fichier pour faire des courbes de niveau.

Mmmmh... Je vois pas trop ce que tu veux dire!!

En même temps, j'ai pas eu le temps de regarder de près ton modèle de programmation linéaire en 3D. Je vais regarder ca de plus près...

Par exemple:

Avec les courbes de niveau j'ai le problème suivant: l'utilisateur entre par exemple comme fonction z=x^2*y avec x dans [0,6] et y dans [0,9], je veux que la fenetre 3D soit automatiquement calculée et correctement affichée sans que l'utilisateur ait à bidouiller sa fenêtre graphique, comment faire?

Et bien je calcule les points de la surface pour déterminer sa boite naturelle, [Xinf,Xsup]x[Yinf,Ysup]x[Zinf,Zsup], à l'aide d'une application affine (et donc d'une matrice 3D) je transforme cette boite en [-5,5]x[-5,5]x[-5,5]. Bien sûr il ne faut oublier de transformer chaque point du graphique 3D avec cette matrice avant de le projeter à l'écran, c'est qui est un peu embêtant, et ce ne serait plus un problème si cette matrice 3D était appliquée en interne, évidemment par défaut cette matrice serait la matrice unité.

Salut Alphonse,

Je crois qu'il y a un problème de définition avec le polyèdre J5, je n'ai pas encore eu le temps de regrder le code, car je planche sur la projection centrale en interne (pas aussi simple que cela!), et je suis tombé là-dessus:

Ok : je regarde ca de suite et je corrige tout ca...

---

C'est curieux!!!

J'ai vérifié toutes les face de la coupole pentagonale et elle sont correctement définies et orientées!!! D'autant que je m'étais déja penché sur cette macro a une époque ou la macro DrawPoly avait un problème (voir ici) donc je ne pense pas que le problème vienne de la macro J5.

En même temps, j'ai pas réussi a obtenir ton problème : tu aurais le code source?

Tu l'as dessiné avec la macro DrawPoly mode 3?

Salut Alponse,

Au temps pour moi! J'avais dessiné ce solide avec DawPolyNC, celle-ci classe les facettes sans éliminer celles qui sont cachées, et lorsque le centre de gravité de la grande facette est plus loin que celui de certaines facettes cachées, on a ce problème d'affichage.

Par contre avec DrawPoly pas de problème car les faces cachées sont éliminées.

Mes excuses pour avoir mis en doute ta macro Alphonse!

PS: au fait as-tu l'occasion de regarder les nouveaux fichiers (courbes de niveau, programmation linéaire)?

G regardé ca vite fait l'autre jour et j'arrivais pas a faire ce que je voulais...

Je vais regardé ca dans l'après midi et te faire part de mes premières impressions...

Alphonse Capriani a écrit:G regardé ca vite fait l'autre jour et j'arrivais pas a faire ce que je voulais...

C'est justement ce genre de retours (avec les détails quand même!) que j'aimerais avoir pour faire avancer la chose!

Du nouveau pour les polyèdres! (entre autres)

On m'a fait découvert par la liste de Syracuse l'existence d'un format u3d pour pdf, ce format est produit par exemple par le logiciel MeshLab, ce même logiciel prend en entrée le format .obj (entre autres), ce format est très simple (fichier texte en plus). J'ai exporté ainsi le grand dodécaèdre en obj, puis importé dans meshLab et exporté en u3d, puis inclut cet u3d dans un document pdf:

Code:


\documentclass[a4paper]{article}
\usepackage[3D]{movie15}
\usepackage[pdftex,pdfstartview = FitH]{hyperref}
\begin{document}
 \begin{center}
  \includemovie[
  label=Grand Dodécaèdre,
  poster,
  toolbar, %same as `controls'
  3Drender=Solid,
  3Dlights=Red,
  3Dbg=0.7 0.7 1,
  3Droo=18.413230070237102,
  ]{0.75\linewidth}{0.75\linewidth}{essai.u3d}
  %\movieref[3Dcalculate]{Grand Dodécaèdre}{Click here!}
\bigskip

Faites moi bouger à la souris!
\end{center}
\end{document}


Ce qui donne: demoU3d.pdf.

Attention: il faut Adobe Reader 8 ou plus.

Remarque: pour obtenir ce Grand Dodécaèdre, j'ai du corrigé deux faces dans PolyedreII.mac (faces 3 et 9), car elles étaient mal orientées, Alphonse va se faire tirer les oreilles!!! Il y a aussi un problème avec le petit dodécaèdre étoilé et je n'ai pas essayé d'autres polydres pour l'instant. Je pense qu'il faudrait régler ce problème, y a du boulot, mais y a peut-être moyen d'automatiser cela?

Wow : pas mal!!!

Je savais pas qu'on pouvait faire ce genre de truc avec Adobe Reader...

P.Fradin a écrit:Remarque: pour obtenir ce Grand Dodécaèdre, j'ai du corrigé deux faces dans PolyedreII.mac (faces 3 et 9), car elles étaient mal orientées, Alphonse va se faire tirer les oreilles!!! Il y a aussi un problème avec le petit dodécaèdre étoilé et je n'ai pas essayé d'autres polydres pour l'instant. Je pense qu'il faudrait régler ce problème, y a du boulot, mais y a peut-être moyen d'automatiser cela?

Tiens tiens!!! Je suis assez surpris car je me souviens avoir vérifier tout ca!!! En même temps, c'est bizarre cette histoire puisque en mettant une opacité positive pour les faces, on ne devrait pas avoir de problème! Le problème apparait en convertissant an format .obj?

Quoi qu'il en soit, je corrige ca tout de suite...

Alphonse Capriani a écrit:Wow : pas mal!!!

Je savais pas qu'on pouvait faire ce genre de truc avec Adobe Reader...

Je le sais depuis.... heu... hier soir.

Tiens tiens!!! Je suis assez surpris car je me souviens avoir vérifier tout ca!!! En même temps, c'est bizarre cette histoire puisque en mettant une opacité positive pour les faces, on ne devrait pas avoir de problème! Le problème apparait en convertissant an format .obj?

Quoi qu'il en soit, je corrige ca tout de suite...

J'ai exporté dans l'ordre d'énumération, j'ai donc les mêmes numéros de sommets dans le fichier obj que dans MakePoly, mais il y a aussi une donnée que je n'ai pas, c'est comment MeshLab gère les facettes (ceci dit j'ai eu le même problème avec un autre logiciel).

Je pense à un truc: pour un polyèdre (du fichier PolyedresII.mac) de centre O, toutes les facettes devraient avoir leur normale dirigée du côté opposé de O, non? Si oui on peut détecter automatiquement les facettes qui ne vont pas. Je vais essayé ça.

Te fatigues pas!!!

Je viens de vérifier les polyèdres de PolyedresII.mac et j'ai détecté 2 erreurs, a savoir celles que tu avais repéré. Voici le fichier PolyedresII.mac corrigé :

Télécharger PolyedresII.mac.

Il y avait bien un problème d'orientation sur deux faces de chacun de ces 2 polyèdres : en fait il s'agissait des memes faces : j'avais créée le petit dodécaèdre étoilé à partir du grand dodécaèdre en étoilant ses faces. Du coup la mauvaise orientation des faces du Grand dodécaèdre s'est répercuté sur l'orientation des faces du petit dodécaèdre étoilé...

Je vais quand même réorienter certaines faces de certains polyèdres en tenant compte de ta précédente remarque. Bien sur pour ceux dont certaines faces passent par le centre du solides, on ne peut rien faire...

Bon! J'ai reregarder mon fichier PolyedresII.mac en tenant compte de ta suggestion.

Au final, j'ai modifié 2 macro, à savoir le petit cubicubotaèdre et le petit rhombihexaèdre.

Voici la dernière mise à jour de mon fichier :

Télécharger PolyedresII.mac

P.Fradin a écrit:Alphonse va se faire tirer les oreilles!!!

S'il te plait : épargne moi!!! Je l'ai pas fait exprès...

Alphonse Capriani a écrit:Bon! J'ai reregarder mon fichier PolyedresII.mac en tenant compte de ta suggestion.

Au final, j'ai modifié 2 macro, à savoir le petit cubicubotaèdre et le petit rhombihexaèdre.

Voici la dernière mise à jour de mon fichier :

Télécharger PolyedresII.mac

P.Fradin a écrit:Alphonse va se faire tirer les oreilles!!!

S'il te plait : épargne moi!!! Je l'ai pas fait exprès...

OK, j'ai mis à jour, ceci le problème du petit dodécaèdre étoilé persiste mais cela ne vient plus de la macro, mais du logiciel MeshLab (et aussi Meshman), car ils traitent les facettes triangulaires uniquement, je viens de m'en rendre compte car voilà ce qu'ils m'affichent pour la première facette de ce polyèdre:



Autrement dit: interdit les facettes non convexes! Qu'y a t-il encore comme polyèdres à facettes non convexes? Tu aurais gardé les macros que tu as faites pour PolyedresI.mac?

Il y a juste le petit et le grand dodécaèdre étoilé qui ont des faces pentagrammiques. Sinon, il n'y en a pas d'autre.

OK,

Sinon, autre surprise de la journée essaie cette page (nécessite java): page

Précision: c'est une page que je viens de faire pour tester l'applet JMath3D qui lit des fichiers obj.

Personnellement, je préfère les animation sous Adobe Reader.

Par contre, si je ne me trompe pas les animations postées dans le post précédents sont plus pratiques si on veut les insérées dans une page web ou sur un forum. Donc c'est vrai que ca pourrait être très utile. Tu as réalisé ca comment?

Il serait possible de rajouté un bouton ou une option dans le modèle Animation.mod pour réaliser ce genre d'animation automatiquement?

P.Fradin a écrit:Tu aurais gardé les macros que tu as faites pour PolyedresI.mac?

Euh... Je crois pas!

Je vais quand même chercher : vu que je faisais régulièrement des sauvegarde de mon fichier quand je bossais la dessus, il me reste peut être un exemplaire planqué dans les profondeurs de mon disque dur...