Discussion :

[Invité]

Bonjour,

je continue ma découverte de Delphi pendant mes vacances scolaires et étudie le moteur 3D. J'aimerais réaliser une animation sur la mécanique newtonienne, histoire d'illustrer les récents événements à une classe de terminale : l'éclipse et la marée du siècle.

Mon scénario serait le suivant :

• Animation 1
  Mouvement des quelques planètes autour d'un Soleil (dans le plan de l'écliptique ou pas, enfin les 2). Mise en évidence des trajectoires coniques (y compris parabole et hyperbole) sur des astéroïdes. Evidemment, l'idéal serait de pouvoir manipuler les axes du plan de l'écliptique une fois l'animation des révolutions lancée. Il ne s'agit pas de construire un modèle avec équations. Le Soleil reste un foyer fixe. Les planètes sont placées sur des ellipses "automatiques". Je ne cherche pas dans cette animation à mettre en évidence l'interaction entre les planètes. Dommage, car c'est le calcul et la constatation d'une perturbation "inattendue" du mouvement observé d'une autre planète qui permit de découvrir Neptune. Cela fera l'objet d'une autre animation sur le raisonnement scientifique si j'ai le temps avant de quitter ma fonction.
• Animation 2
  On se consacre ensuite à un système à 3 : Soleil, Terre, Lune. Il faut mettre en évidence les rotations et évidemment les révolutions. La rotation de la Terre doit également être accompagnée de sa déformation en regard de la Lune, déformation grossie exagérément évidemment . Je ne sais pas s'il est concevable de différencier une surface liquide d'une surface solide sur la sphère "Terre" pour expliquer le phénomène des marées.

J'ai regardé quelques exemples fournis avec Delphi FMX 3D. Je n'image pas à ce stade si l'ensemble est faisable. J'avais réalisé, il y a plus de 20 ans, la première partie avec un Atari 1024 et du GFA basic... très simplement. Là avec FMX, la prise en main me semble compliquée (mais FMX est compliqué) et la documentation ne me permet pas de me faire idée de la faisabilité : j'ai vu quelques aspects sympathiques mais l'intégration de tous ces aspects (de ces "trucs tout prêt faits mais limités"... je voulais dire "démonstrateurs") en quelque chose de cohérent m'échappe totalement.

Comme le temps est précieux, j'aimerais bénéficier de votre expérience sur la question. Est-ce envisageable avec Delphi ? Evidemment, j'ai lancé une approche Qt 5 parallèlement et j'ai déjà une documentation fournie dont un livre très précieux sur le sujet... qui déjà me permet jusqu'à mon niveau d'études (non terminé) de ne pas détecter de point de blocage... J'aimerais bien en faire autant avec Delphi. C'est un aspect des choses qui m'énerve beaucoup avec ce dernier. Peut-on ou ne peut-on pas faire ? Il n'est pas normal que cela soit si difficile à envisager. Evidemment, ensuite on peut tomber sur des problèmes imprévus mais dans mon cas, pour l'instant en Delphi, je suis bien incapable d'avoir une "estimation". Heureusement, il y a ce forum !

[Paul TOTH]

La 3D sous FMX n'est pas plus compliqué qu'ailleurs, mais ça reste de la 3D

Je te propose comme entrée en matière les quelques clics suivants:

1) créer un projet multipériphérique 3D

2) placer 3 TSphere enfants l'une de l'autre, Soleil, Terre et Lune

3) placer 3 TLightMaterialSource, un pour chaque sphere

4) placer un source lumineuse de type "Point" au centre du soleil

5) Ajouter 2 TFloatAnimation, l'un sur le soleil, l'autre sur la terre

voici ce que donne la fiche:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
unit Unit1;
 
interface
 
uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms3D, FMX.Types3D, FMX.Forms, FMX.Graphics, 
  FMX.Dialogs, System.Math.Vectors, FMX.Ani, FMX.Controls3D,
  FMX.MaterialSources, FMX.Objects3D;
 
type
  TForm1 = class(TForm3D)
    Soleil: TSphere;
    Terre: TSphere;
    Lune: TSphere;
    SoleilMat: TLightMaterialSource;
    Light1: TLight;
    TerreMat: TLightMaterialSource;
    LuneMat: TLightMaterialSource;
    FloatAnimation1: TFloatAnimation;
    FloatAnimation2: TFloatAnimation;
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.fmx}
 
end.

et son DFM

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
 
object Form1: TForm1
  Left = 0
  Top = 0
  Caption = 'Form1'
  Color = xFE000000
  ClientHeight = 642
  ClientWidth = 1046
  FormFactor.Width = 320
  FormFactor.Height = 480
  FormFactor.Devices = [Desktop]
  DesignerMasterStyle = 0
  object Soleil: TSphere
    Width = 2.000000000000000000
    Height = 2.000000000000000000
    Depth = 2.000000000000000000
    MaterialSource = SoleilMat
    object Terre: TSphere
      Position.X = -10.000000000000000000
      Width = 1.000000000000000000
      Height = 1.000000000000000000
      Depth = 1.000000000000000000
      MaterialSource = TerreMat
      object Lune: TSphere
        Position.X = -2.000000000000000000
        Width = 0.500000000000000000
        Height = 0.500000000000000000
        Depth = 0.500000000000000000
        MaterialSource = LuneMat
      end
      object FloatAnimation2: TFloatAnimation
        Enabled = True
        Duration = 1.000000000000000000
        Loop = True
        PropertyName = 'RotationAngle.Y'
        StartValue = 0.000000000000000000
        StopValue = 360.000000000000000000
      end
    end
    object FloatAnimation1: TFloatAnimation
      Enabled = True
      Duration = 24.000000000000000000
      Loop = True
      PropertyName = 'RotationAngle.Y'
      StartValue = 0.000000000000000000
      StopValue = 360.000000000000000000
    end
  end
  object Light1: TLight
    Color = claWhite
    LightType = Point
    SpotCutOff = 180.000000000000000000
    RotationAngle.X = 356.795928955078100000
    RotationAngle.Y = 356.029602050781300000
    Width = 1.000000000000000000
    Height = 1.000000000000000000
    Depth = 1.000000000000000000
    Quanternion = 
      '(0.0279404129832983,0.0346279069781303,-0.000968477805145085,-0.' +
      '999009013175964)'
  end
  object SoleilMat: TLightMaterialSource
    Diffuse = claWhite
    Ambient = xFF202020
    Emissive = claYellow
    Specular = xFF606060
    Shininess = 30
    Left = 680
    Top = 64
  end
  object TerreMat: TLightMaterialSource
    Diffuse = claSlateblue
    Ambient = xFF202020
    Emissive = claNull
    Specular = xFF606060
    Shininess = 30
    Left = 512
    Top = 304
  end
  object LuneMat: TLightMaterialSource
    Diffuse = claWhite
    Ambient = xFF202020
    Emissive = claNull
    Specular = xFF606060
    Shininess = 30
    Left = 520
    Top = 312
  end
end

ensuite, il reste à lancer l'application


On remarquera que la terre et la lune sont correctement éclairés et ombrés (le saut dans l'animation est du au GIF, pas au programme), mais l'ombre de la lune ne s'affiche pas sur la terre...ce qui est totalement normale en matière de programmation 3D car la carte graphique calcule la couleur du pixel en fonction des paramètres donnés (vecteur normal, source de lumière, couleur) mais sans avoir connaissance des objets les uns vis à vis des autres.

Une des techniques utilisées est le Shadow Volume mais ça n'est pas proposé en standard par Delphi, ce qui se comprend je trouve.

ça me rappelle aussi un vieux programme Delphi 7 qui calculait en Raytracing (voir le code Turbo Pascal d'origine) le déplacement de sphères avec transparence et réflexion, tout cela dans un simple Bitmap sans accélération aucune...sur un PC moderne c'est presque fluide oh mais j'y pense, il faudrait que j'adapte le code pour exploiter le multicoeur !

(la qualité du rendu est dégradé par le format GIF)

[Invité]

Bonjour,

Merci Paul : C'est très intéressant.

De mon côté, j'ai travaillé sur une exemple de David Intersimone pour apprendre les bases.
L'exemple est en C++ Builder mais très facilement transposable en Delphi. Bon d'accord, c'est Mars et pas la Lune Je changerai demain !


L'animation donne ceci sous Windows : http://www.selzig.com/1504122000/xe7-1.avi. Bon, la résolution de cet avi est mauvaise. Pour ceux qui ont la fibre : http://www.selzig.com/1504122000/xe7-2.avi (150 Mo). Je n'ai pas le temps de le compresser.

Cerise sur le gâteau, cela fonctionne paraît-il sous iOS (que je ne possède pas). Pas eu le temps de tester sur mon mac mini... Mais comme une fois sur deux, je crains le pire. Ceci dit, je n'accable pas (encore) Delphi... Il va falloir que j'optimise les réglages de la cross-compilation si c'est faisable. Je me rappelle avoir pesté avec Androïd... de manière justifiée, non pas sur les capacités potentielles mais sur les réglages par défaut non vraiment fonctionnels à ce niveau et pas mis à jour dans la documentation... comme si c'était naturel, comme si cela relevait de la science infuse que j'ai évoquée dans l'article sur XE8. Bref quand le processeur est compatible, je n'ai rien trouvé de mieux et de plus efficace. Je regarderai demain ce qu'il en est avec Androïd... si j'arrive à le "re-régler".

Les sources pour Delphi XE7 sont ici ici.

J'ai modifié les sens et vitesses de rotation, les obliquités. Je regarderai demain s'il est possible de déformer les sphères. mais je ne vois pas comment inter-agir avec par exemple, une certaine géométrie (alignement) ou une position données. Je ne sais pas. Encore un doute... et surtout où chercher ? De même que sur votre démo, Paul, j'imagine mal comment faire varier la vitesse de révolution de la planète. Un mouvement régulier ne me convient pas. Ce ne serait vraiment pas pédagogique et vraiment loin de la réalité (2ème Loi de Kepler).

A demain donc et encore merci pour votre aide.

[ALWEBER]

Bonjour,

Si tu veux l'exemple en XE7, voici le résultat

[Invité]

Bonjour,

Jolie image, mais c'est plutôt la cinématique qui m'intéresse : trajectoire et vitesse des révolutions, , rotation des planètes.... Une petite vidéo ? Je saurai que c'est possible à faire... et c'est déjà un bon début.

[Paul TOTH]

J'ai modifié les sens et vitesses de rotation, les obliquités. Je regarderai demain s'il est possible de déformer les sphères. mais je ne vois pas comment inter-agir avec par exemple, une certaine géométrie (alignement) ou une position données. Je ne sais pas. Encore un doute... et surtout où chercher ? De même que sur votre démo, Paul, j'imagine mal comment faire varier la vitesse de révolution de la planète. Un mouvement régulier ne me convient pas. Ce ne serait vraiment pas pédagogique et vraiment loin de la réalité (2ème Loi de Kepler).

mon but n'était pas de faire une démonstration réaliste, mais que en quelques clics on obtient quelque chose sans doute un peu plus impressionnant que sous GFA Basic

Pour ce qui est de l'animation réaliste, il suffit de jouer sur Position.X (j'ai mis des valeurs au pif, -10 entre la Terre et le soleil, -2 entre la Lune et la Terre), il suffit de faire varier cette valeur pour changer la distance entre les corps célestes. Pour la rotation elle joue ici uniquement sur RotationAngle.Y qui est animée automatiquement par un TFloatAnimation de façon régulière sur 360°

maintenant rien ne t'empêche de calculer la position de la terre et de la lune en fonction du temps, j'imagine que ce n'est pas un problème pour toi Et de renseigner le RotationAngle.Y du soleil pour faire tourner la Terre (oui ce n'est pas le soleil qui est supposé tourner, mais c'est plus simple comme ça), et de faire tourner la lune avec le RotationAngle.Y de la terre.

Après si tu veux être plus rigoureux, tu ajoutes une TDummy au centre du soleil, tu places la Terre en tant qu'enfant de celui-ci et c'est ce Dummy qui fera touner la Terre et non plus le Soleil. TDummy sert uniquement à définir un point d'origine pour des transformations non centrées (la Sphere tourne autour de son centre, pour la faire tourner sur un point distant, on la place "dans" un TDummy à qui on application la rotation).

Pour déformer la Sphere il suffit de constater qu'elle n'est pas définie par un Rayon, mais par Width, Depth, et Height, il suffit de jouer sur ces dimensions pour la déformer à l'intérieur d'un parallélépipède rectangle. Et de lui appliquer une rotation (RotationAngle) pour respecter l'inclinaison de son axe et le tour est joué.

Tout cela me semble être des notions de 3D tout à fait élémentaires...

Que TDummy, par exemple, ne soit pas une évidence, c'est vrai, mais en VCL, TDataSource, TActionList, TImageList sont autant de classes qui n'ont pas d'évidence au départ, c'est en manipulant le framework qu'on en apprend les subtilités...et il y a des tas de tutoriaux pour expliquer tout cela..j'ai même fait une petite vidéo (amateur) sur FMX d'ailleurs

[Invité]

Bonjour Paul,

Merci pour les renseignements complémentaires. Cela rentre doucement... Relier (adapter) un modèle mathématique aux propriétés des objets ne me semble pas pour l'instant pouvoir être qualifié d'élémentaire à mon niveau de cheminement . C'est du chinois (voir pages > 34). Je pense qu'il contient l'essentiel qui me permettra de lier les maths à Delphi et à m'en sortir de manière quasi autonome. Le même en anglais, c'est où ?

Encore merci.

[ALWEBER]

Bonjour,

Jolie image, mais c'est plutôt la cinématique qui m'intéresse : trajectoire et vitesse des révolutions, , rotation des planètes.... Une petite vidéo ? Je saurai que c'est possible à faire... et c'est déjà un bon début.

Non c'est bien d'une animation dont je parle voir fichier ci-joint

[Invité]

Bonjour ALWEBER,

D'abord merci de votre confiance. La mise à disposition de votre travail va me permettre de réaliser une rétro-ingénierie. L'utilisation d'une unité pour les planètes me semble tout à fait intéressante. Je croise avec ce que m'a donné Paul, non pas pour améliorer votre code mais pour mieux comprendre et relier les maths aux propriétés des objets.

Vraiment merci. Je me sens redevable.

[Paul TOTH]

je ne dis pas que la 3D est simple, je dis simplement qu'elle n'est pas plus compliquée sous FMX qu'ailleurs

mais je fais de la 3D depuis fort longtemps, sous Turbo Pascal au départ, sous Delphi et même sous FlashPascal, du coup le passage à FMX c'est pas compliqué pour moi

[ALWEBER]

Bonjour ALWEBER,

D'abord merci de votre confiance. La mise à disposition de votre travail va me permettre de réaliser une rétro-ingénierie. L'utilisation d'une unité pour les planètes me semble tout à fait intéressante. Je croise avec ce que m'a donné Paul, non pas pour améliorer votre code mais pour mieux comprendre et relier les maths aux propriétés des objets.

Vraiment merci. Je me sens redevable.

Si vous avez des questions n'hésitez pas. J'ai d'autres exemples assez sympa. Ceci dit FMX autorise une approche différente et simplifiée de la 3D car beaucoup d'éléments que l'on devait développer sont aujourd'hui intégrés dans FMX

[Invité]

Bonjour,

Oui... j'ai encore des questions. J'abuse...

Sans code particulier, en utilisant des TSpheres et des TFloatAnimations, comment obtient-on une rotation de la Terre en 24 Unités alors que la Lune tourne autour de la première en 24*27U (en 27 jours) ? Et chance ! C'est également la durée d'une de ses rotations.

Avec les structures simples que j'utilise, la durée de rotation de la Terre devient la durée de révolution de la Lune.

Pour régler le problème, j'ai dû créer la TSphère pTerre sans satellite avec en sous-objet un TFloatAnimation (roTerre) (RotationAngle.Y) et une durée de 24U. Puis j'ai copié l'ensemble en pTerrePseudo, créer un satellite pLune, rebaptisé l'ancien roTerre en rvLune (durée de 30 et sens de rotation inverse pour bien visualiser) et me suis débrouillé pour rendre pTerrePseudo invisible (sans utiliser la propriété visible sinon la lune disparaît).

Le résultat est atteint... Mais je trouve cela tellement compliqué que je me demande s'il n'y a pas un autre moyen. De la même pour donner le même centre à mes révolutions (circulaires) et pour différencier ces dernières, j'ai dû créer plusieurs pSoleilPseudoX.

L'animation en avi : http://www.selzig.com/1504122000/xe14.avi

Parallèlement à partir de brides de documentation, j'ai commencé à extrapoler le pdf chinois pour procéder par le calcul. Je vais essayer de procéder ainsi. Je vois l'approche globale mais comme je le supposer, il faut un timer... ce qui signifie que les temps de calculs doivent être réduit au minimum. J'ai vu que votre timer était réglé à 100 ms qui incrémente le "jour" de 1. Je constate que l'application est fluide. Comme je ne dispose pas du source de l'unité uRotation2axes -ce qui me convient parfaitement- je suppose que vous avec utilisé le calcul matriciel. Mais même dans ces conditions, avec beaucoup d'objets et de rotations, l'utilisation des threads n'est-elle pas nécessaire pour garantir la fluidité de l'affichage ?

Si Paul lit ce message. Pour la déformation, quelque soit l'axe utilisé, elle est symétrique par rapport au centre de la sphère. Or la Terre ne se "soulève" que du côté Lune et pas de l'autre côté (aux antipodes)... Hum...

[Paul TOTH]

Bonjour,

Oui... j'ai encore des questions. J'abuse...

Sans code particulier, en utilisant des TSpheres et des TFloatAnimations, comment obtient-on une rotation de la Terre en 24 Unités alors que la Lune tourne autour de la première en 24*27U (en 27 jours) ? Et chance ! C'est également la durée d'une de ses rotations.

Avec les structures simples que j'utilise, la durée de rotation de la Terre devient la durée de révolution de la Lune.

Pour régler le problème, j'ai dû créer la TSphère pTerre sans satellite avec en sous-objet un TFloatAnimation (roTerre) (RotationAngle.Y) et une durée de 24U. Puis j'ai copié l'ensemble en pTerrePseudo, créer un satellite pLune, rebaptisé l'ancien roTerre en rvLune (durée de 30 et sens de rotation inverse pour bien visualiser) et me suis débrouillé pour rendre pTerrePseudo invisible (sans utiliser la propriété visible sinon la lune disparaît).

Le résultat est atteint... Mais je trouve cela tellement compliqué que je me demande s'il n'y a pas un autre moyen. De la même pour donner le même centre à mes révolutions (circulaires) et pour différencier ces dernières, j'ai dû créer plusieurs pSoleilPseudoX.

L'animation en avi : http://www.selzig.com/1504122000/xe14.avi

C'est expliqué plus haut dans mon message, il suffit d'utiliser un TDummy, il sert à ça.

Parallèlement à partir de brides de documentation, j'ai commencé à extrapoler le pdf chinois pour procéder par le calcul. Je vais essayer de procéder ainsi. Je vois l'approche globale mais comme je le supposer, il faut un timer... ce qui signifie que les temps de calculs doivent être réduit au minimum. J'ai vu que votre timer était réglé à 100 ms qui incrémente le "jour" de 1. Je constate que l'application est fluide. Comme je ne dispose pas du source de l'unité uRotation2axes -ce qui me convient parfaitement- je suppose que vous avec utilisé le calcul matriciel. Mais même dans ces conditions, avec beaucoup d'objets et de rotations, l'utilisation des threads n'est-elle pas nécessaire pour garantir la fluidité de l'affichage ?

le Timer ne me semble pas être une bonne option, il a une fréquence indépendante de l'affichage. Comme Delphi ne propose pas en standard de composant "Animation" qui ne soit pas lié à une propriété...ceci dit c'est facile à écrire....il suffit de créer un FloatAnimation lié à un objet quelconque et de traiter dans l'évènement OnProcess de l'animation la valeur de cette propriété.

exemple, 2 TCube l'un avec une RotationAngle.X de 0 à 100 et l'autre qui est affecté par cette valeur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
procedure TForm1.FloatAnimation1Process(Sender: TObject);
begin
  Cube2.RotationAngle.Y := Cube1.RotationAngle.X; // valeur qui passe de 0 à 100 en boucle
end;

L'avantage de cette approche est de permettre dans une seule "Animation" de fixer les valeurs de tous les objets sur une base commune. Quand on travaille sur plusieurs Animation il faut fixer la durée individuellement et si on veux accélérer l'ensemble il faut modifier toutes les durées; c'est peu pratique.

Si Paul lit ce message. Pour la déformation, quelque soit l'axe utilisé, elle est symétrique par rapport au centre de la sphère. Or la Terre ne se "soulève" que du côté Lune et pas de l'autre côté (aux antipodes)... Hum...

Ce n'est donc pas une Sphere TMesh permet d'affiche une forme quelconque, mais il faudra calculer les sommets et facettes qui la compose.

[ALWEBER]

Voilà un extrait du code que je t'ai envoyé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
  aDummy := TDummy.Create(PlaneteRef);
  aDummy.Parent := PlaneteRef;
  Planete := TSphere.Create(aDummy);
  Planete.Parent := aDummy;

Premier secret de fabrication :
Tu peux intercaler des dummies pour décomposer les opérations
Un dummy Terre qui tourne autour du dummy soleil en faisant varier la distance en fonction de l'angle
Une sphère Terre relative au dummy Terre
Un dummy Lune relatif au dummy Terre, Une Sphère Lune relative au dummy Lune et ainsi de suite.

Deuxième secret de fabrication :
Calculer la rotation de chaque objet uniquement sur la base de de deux rotations X et Y - Latitude et Longitude

C'est de cette manière que j'anime la marionnette que tu vois sur la vignette en dessous mon pseudo

[Paul TOTH]

en fait c'est une bête question de référentiel.

si la Terre et enfant d'un TDummy et que celui-ci tourne, la terre tourne avec lui, et ce mouvement ce combine avec la rotation de la Terre et celle du parent du TDummy...je peux fais tourner mon poignet sur lui même, mais aussi mon coude, et mon épaule, je peux en même temps faire pivoter mon bassin ou ma chaise. Un observateur extérieur verra mon poignet partir dans tous les sens alors que lui ne fait que tourner sur lui-même.

la position d'un enfant est également relative à son parent, mon poignet est au bout de mon avant bras, lui même au bout de mon bras, etc...donc Terre.Position donne la distance au point de rotation qui est le centre du TDummy parent (pour Dummy.RotationAngle)

[Invité]

Bonjour à tous deux...

Je vous remercie mais je ne comprends toujours pas l'utilisation du TDummy. Je ne désespère pas. Petite pause avec Delphi car Paul a raison. La mise en oeuvre n'est pas aisée pour un novice de la 3D. Les pré-requis manquent visiblement ce qui m'empêche de modéliser. Je n'ai pas réussi à mettre en oeuvre autrement la révolution de la Lune que par ma méthode que j'ai sophistiquée d'ailleurs. Cela me rappelle mon utilisation des styles... très personnelle aussi Donc probablement non viable à terme.

Je pars de la TSphère Soleil... et du "glissement" d'objets sur la Form en évitant les calculs et surtout l'utilisation de la propriété .Parent. Normalement la structure obtenue doit être cohérente à partir de cette pratique. Et j'espère en comprendre son fonctionnement Enfin, je suis parti de ce postulat.

La TSphère Terre doit exécuter 2 mouvements de rotation (au sens mathématique) : une révolution et une rotation (au sens astronomique). Evidemment la période des 2 n'est pas la même. Cela je n'y arrive pas, quelque soit les combinaisons Sphère/Dummy/FloatAnimation utilisée. J'arrive cependant avec la structure ci-dessous à obtenir une révolution "différenciée" de la Lune (de sens inverse pour bien visualiser). Par contre, impossible d'obtenir une rotation. La Lune est un mauvaise exemple parce que les périodes de rotation et de révolution sont égales à quelques décimales près.


Je résume donc les problèmes rencontrés et non résolus par l'orthodoxie:

1. Pour une TSphère : comment lui communiquer des mouvements de révolution et de rotation différenciés (avec par exemple des périodes et des sens différents) ?
2. Intégrer les calculs de positionnement dans chaque FloatAnimation est-il un concept viable notamment pour gérer la synchronisation de tous les mouvements ?
3. Le calcul est obligatoire pour toute autre mouvement qu'une rotation. Enfin me semble t-il. A confirmer mais je n'ai rien vu d'objet permettant autre chose.
4. Pourquoi dans la plupart des codes visités, le calcul matriciel est-il mis à l'écart alors qu'il devrait s'imposer. Est-ce lié au point 2 ?
5. Question complémentaire (et très peu importante) : les objets utilisés ne sont pas compatibles avec Androïd ? Il n'y a pas de plantage, mais les objets ne sont pas dessinés.

---

Demain, je passe à Qt (toujours sans abandonner Delphi) pour comparer, pour m'enrichir. Parallèlement, je viens de commander 2 livres américains sur OpenGL.

Donc petite pause sur le sujet. Et encore merci pour votre aide.

[Paul TOTH]

ce qu'il faut intégrer c'est cette notion de référentiel dont je parlais plus haut.

En VCL si je place un Button dans un Panel sa position Top,Left est relative à celle du Panel, c'est en fait une Translation du bouton relative au panel. Si j'applique une translation sur le panel, le bouton subit la même transformation.

Dans FMX3D on a la même logique mais en 3D, sur la rotation et la translation.

Si je place une Sphere en position(0,0,0) = centre de la fiche, que son enfant est en position(5,0,0), celui-ci subit une Translation de 5 sur l'axe des X.
Si maintenant de translate la Sphere, son enfant subit la même translation, c'est logique.

Mais c'est pareil pour la rotation. Un objet FMX tourne autour de son centre, donc quand elle tourne, la Sphere ne bouge pas, mais son enfant en position(5,0,0) décrit un révolution autour de son parent.

le problème dans ce cas c'est que la Sphere tourne en même temps que son enfant décrit sa révolution, si on veux séparer les deux mouvements il faut casser la relation parent/enfant...mais du coup plus de révolution.

Pour recréer la révolution, il suffit d'insérer un TDummy comme parent de l'enfant (appelons le Satellite)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
+TSphere position(0,0,0)
  +TDummy position(0,0,0)
    +TSatellite position(5,0,0)

je peux appliquer une rotation à TDummy pour que TSatellite décrive sa révolution. Et je peux aussi appliquer une Rotation à TSatellite pour qu'il tourne autour de son centre. J'obtiens alors bien un Révolution et une Rotation.

Et comme TDummy est enfant du TSphere, je peux faire tourner tout l'ensemble en appliquant une rotation à TSphere. Mais si je voulais que TSphere puisse tourner aussi, je devrais insérer un parent TDummy

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
+TDummy position(0,0,0)
  +TSphere position(0,0,0)
  +TDummy position(0,0,0)
    +TSatellite position(5,0,0)

avec ce montage je peux faire tourner l'ensemble (premier TDummy), la sphere sur elle même (sans faire bouger le reste), le Satelite autour de la Sphere (en réalité du second TDummy dont la position est confondue avec la sphère), et le Satellite sur lui-même.

TDummy s'affiche comme un cube dans l'IDE mais en réalité c'est un simple point dans l'espace qui sert de référence (comme la postion Top/Left du TPanel évoqué au début)

[Invité]

Bonjour,

Un petit passage par Delphi.

Grâce à mes lectures Qt OpenGL, par analogie (mais pas par mimétisme), j'ai réussi à résoudre ce petit problème. Vous trouverez ici un zip du source fonctionnel. Il s'agit d'une une construction totalement graphique par glissement des objets. Les seuls codes sont ceux des switches pour inverser les sens de rotations et révolutions.

En réalité, il faut dans un premier temps séparer le problème géométrie du problème POO des composants. Ensuite, il faut rendre compatible les solutions du problème géométrique (la couche graphique donc) et la nécessaire arborescence des composants POO (notamment leurs propriétés .parent) donc la gestion des héritages. C'est à cela que servent les TDummies. Deux approches différentes avec des logiques différentes qu'il faut faire coïncider en un lieu donné.

Une fois ceci compris, en effet, les possibilités sont nombreuses et je dois l'avouer la construction sur la Form est très rapide et sympathique sous Delphi. Cependant, si on peut rendre les mouvements de rotations/révolutions indépendants, il se pourrait qu'il y ait une dépendance entre les vitesses radiales... Il se peut que cela soit un effet d'optique mais c'est à vérifier.

Conclusion sur la problématique rencontrée et sa résolution

• Qt est moins "fun" mais j'ai déjà partiellement compris la partie mathématique attenante. Je sais m'écarter d'un angle de x° du plan de l'écliptique... Bref un paradis pour matheux. Je ne sais pas faire cela encore en Delphi... Je ne vois pas comment attacher le calcul matriciel aux TFloatAnimations puisqu'il semble que cela soit à ce niveau qu'il faille opérer.
• Toujours la même remarque : sans la doc Qt, je n'aurais pas pu m'en sortir. La science infuse me casse les pieds. Faire une petite démo où la Terre tourne autour du Soleil, cela en jette surtout en 5 clics... Mais cela n'apprend rien de ce qu'il est nécessaire de savoir pour faire un planetarium... et n'apprend même pas les concepts de base. Paul -que je remercie à nouveau ainsi qu'Alweber pour leur aide précieuse - fera remarquer qu'être novice en 3D est un handicap. Certes mais nécessairement on est novice à un moment. Et en Qt comme en Delphi, je suis un novice en 3D. Cependant Qt, sa documentation existante, donc ceux qui font des livres et des articles écrits comme des livres, me donnent une chance... que ne me donne pas Delphi !
  

  C'est carrément inabordable pour le commun des mortels[...]

  Je suppose que c'est une interprétation possible (probable ?) des récents propos de Jiji66 commentant la sortie de XE8.

PS : Evidemment j'ai pris des notes et me suis rédigé un article papier (à l'ancienne) , des fois que j'en aurais besoin ultérieurement. Mais je n'ai pas la volonté ni le temps de mettre cela au format du forum. Si quelqu'un veut prendre cette partie en charge... Mais je ne fais pas l'aumône. Mes méthodes désuètes n'ont peut-être aucun intérêt... J'ouvre une autre discussion sur le calcul.

[Paul TOTH]

comme déjà expliqué, à ta place je remplacerais les différents FloatAnimation par un TProgressBar (par exemple) sur lequel je mettrais un seul TFloatAnimation pour faire varier sa propriété Value et sur l'événement OnProgress je calculerais les propriétés des Spheres.

en fixant l'animation la progressbar et l'animation pour un min = 0 et max = 1 on obtient ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
procedure TForm1.FloatAnimation1Process(Sender: TObject);
var
  Percent: Single;
begin
// % dans l'animation
  Percent := ProgressBar1.Value * FloatAnimation1.Duration;
 
// Remplace animMarsAutourSoleil
  dummMars.RotationAngle.Y  := +360 * Percent / 8;
 
// Remplace animTerreAutourSoleil
  dummTerre.RotationAngle.Y := -360 * Percent / 20;
//
  etc...
end;

Et là tu es libre d'affecter des valeurs qui ne sont pas linéaires en fonction du temps et de modifier Position.X pour que le révolution soit elliptique et non circulaire, juste un peu de Math, mais j'ai cru comprendre que c'était plus ton dada que la 3D => quel est la distance de la terre au soleil (sphTerre.Position.X) et son angle de rotation (dummTerre.Rotation.Y) en fonction du temps ?

autre avantage, en faisant varier uniquement FloatAnimation1.Duration, tu peux accélérer ou ralentir toute l'animation en une seule fois.

NB: Delphi fera lui le calcule matricielle (LocalMatrix et AbsoluteMatrix), mais ce n'est qu'un outil mathématique, ça n'empêche pas de devoir faire les calculs indiqués plus haut. Sous OpenGL on peut appliquer directement une matrice de transformation globale - que l'on calcule soit-même - à chaque objet, avec Delphi on se contente d'en donner les composantes (rotations, translations, échelle) et Delphi fait le calcule pour nous.