simulation numérique d'un voilier

[invite82ec7bc7]

Bonjour,

Je viens à vous pour des questions de conception qui devraient paraître ridiculement simples à certains d'entre vous.

Je m'essaye à la simulation numérique en 3D en C++ avec openGL(SFML gestion fenêtrage) et je souhaite réaliser une (petite) simulation de voilier, minimaliste mais aussi réaliste que possible tout de même dans la modélisation, qui pourrait s'affiner par la suite.

En guise de préambule, mes souvenirs de physique euclidienne remontent au lycée (no prépa, no ingé). donc mon niveau 3D (matrice, quaternion, torque, etc...) =0.
Dans la philosophie, je ne recherche pas la complétude des connaissances sur le sujet mais j'essaye de récupérer le strict nécessaire et suffisant sur les outils dont je pourrais avoir besoin pour atteindre l'objectif sus-cité.

J'ai déjà fait qqes choix :
-intégration par un solveur de type Runge-Kutta d'ordre 4 (standard).
-je compte simuler sur 5 DDL. Exit la gestion du frottement des vagues sur la carène (axe de roulis) pour l'instant.
et de manière générale je ne souhaite garder que les phénomènes physiques d'ordre 1 et 2 pour la simulation.
-centres d'efforts posés arbitrairement (pas de calculs de volumes en 3D pour le moment : carène, etc...)

Mes premières questions :
-faut-il conduire la simulation par les moments (linéaires et angulaires) ou bien rester sur position, orientation et accélération en valeurs primaires ?
sachant que accélérations et vitesses ne seront donc pas constantes...

-faut-il intégrer le mouvement linéaire et rotationnel de manière disjointe, à la manière d'un objet évoluant dans un espace libre ?

-comment déterminer un tenseur inertiel pour un voilier (quelle matrice?) ou bien, puis-je me permettre e prendre celui du cube (...et l'utiliser comme un scalaire pour commencer) ?

-comme je dois travailler avec des matrices pour opengl, j'aimerais autant que faire ce peut calculer la simulation à l'aide de matrices et des angles d'Euler uniquement (le gimbal lock ne me parait pas être un soucis dans ce cas de figure !).

Etant donné que je n'ai qu'un objet dynamique à calculer, je pense naïvement que cela n'aura que peu d'impacts sur les perfs de la simulation physique et par conséquent sur le framerate du render.
Sinon, je peux toujours utiliser les quaternions, mais j'aimerais éviter ce concept (trop mathématique pour moi dans l'immédiat...).

Je remercie d'avance tous ceux qui pourront m'apporter un éclairage et guider mes choix concernant ce simulateur.


-kermit69


PS : serait-ce opportun de passer par une simulation scilab (...je ne connais pas spécialement) en premier lieu, pour valider certaines options ?
-----

[invite82ec7bc7]

Je ne sais pas si cela intéresse du monde, je me réponds à moi-même...

J'ai réussi à trouver une approche qui me satisfait (par rapport à l'objectif) : c'est une bête décomposition de certaines forces pour la translation et des couples pour la rotation, dans un premier temps. Ce qui pilote le voilier à proprement parler, ce sont donc les angles vent apparent/voile et gouvernail/axe de déplacement.
Plus tard j'intégrerai un degré de précision supplémentaire dés que j'aurais réglé la prochaine question.

Et sinon, je fais bien différents essais via Scilab 5.4.2 sur la modélisation avant de passer ça en objets C++/opengl (exit les quaternions aussi !! ) et c'est nickel !


Donc, maintenant que j'ai quelque chose de très simple qui tient la route, je cherche à intégrer un "décor"... (qui ne soit pas que des textures .bmp )

En gros, je souhaite appliquer une "texture" marine mais qui soit ...

-soit une image plate appliquée sur une surface plane (avec un canal alpha), puis un fichier xml en parallèle décrivant des objets graphiques pour les traits de côtes, les phares, récifs, bouées cardinales, ... et gérer un minimum les marées (niveau de la mer) dans le décor.
Tout ça à créer à la main, via un éditeur spécifique à créer, donc qui risque de consommer pas mal de temps :/

-et/ou des objets vectoriels que je pourrais traduire en modèle opengl : je pense à récupérer (ou acheter?) une carte SHOM S-57 que je pourrais modifier puis intégrer dans mon programme et sur laquelle je récupèrerais les infos pertinentes. (courbe de niveau, etc...)
Comme il s'agit d'une bête simulation pour mon hobby personnel et non d'une aide à la navigation (interdit, contraintes légales fortes!), la mise à jour de la carte m'importe peu... par contre, je ne sais pas si cela est possible à faire, contrairement à la première solution.

Puis, pour la gestion du courant marin et des marées, je pense utiliser un fichier plat xml contenant des coordonnées polaires sectorielles et horaires (sens et force de la marée). Une sorte de champ de forces.

La direction du vent réel restera fixée au démarrage (dans un premier temps). des événements clavier me permettent d'en changer le sens et la vitesse à volonté.

...Pour le lieu de ce décor, je pense me baser sur le golfe du Morbihan. Ainsi j'aurais suffisamment d'exemples différents d'objets à gérer au fur et à mesure.


Voilà, c'est tout pour aujourd'hui sur l'état de mes pistes d'investigation. Ceci n'est donc qu'un brouillon...


...Bien entendu, si quelqu'un a des propositions à faire valoir ici, qu'il ou elle n'hésite pas !


A bientôt pour la suite de la simulation

[CM63]

Bonjour,

exit les quaternions aussi !!

Là tu as tort, les meilleurs logiciels de simulation, notamment les jeux vidéo, utilisent les quaternions, cela entraîne moins d'erreurs numériques que les calculs matriciels pour les calculs de rotations-déplacement. Il n'est pas nécessaire d'entrer dans la théorie des quaternions, tu regardes juste les formules à utiliser, et personnellement je ne les trouve pas plus imbuvables que les formules matricielles (et si tu es aussi alergique aux matrices, ça va pas être facile ).

Bon courage pour ton entreprise

[CM63]

Autre chose : je ne saurais trop te conseiller d'utiliser un "moteur de jeu" plutôt qu'un langage de programmation généraliste, moi je fais de la simulation ferroviaire avec le moteur de jeu Jmonkey. L'avantage c'est que tu n'a plus qu'à créer tes objets que ce soit pour les décors, ou pour la partie "applicative" (pour toi: le bateau), après toutes les interactions avec les objets sont déjà programmées. Même la physique est programmée, en tout cas le contact entre corps non déformables, pour moi, cela me suffit. Pour toi , pour simuler les forces des voiles, la flotaison etc, peut-être qu'il faudra que tu ajoute de code, mais le plus gros est fait pour tout le reste: 3D, éclairages, objets lointains (qu'on ne voit plus au délà d'une certaine distance, cela décharge le moteur graphique), etc. Tu programmes en Java et il y a un super environnement de programmation, qui détecte les erreurs dès l'édition, un peu comme en VB.

Tu devrais essayer, a plus.

[A voir en vidéo sur Futura]

[invite82ec7bc7]

Hello,

Oui, je connais bien l'intérêt des quaternions qui sont sans doute utilisés universellement dans le monde professionnel du JV.

Leur principal avantage (y'en a plusieurs mais bon...), celui pour lequel à la base il est utilisé en prog 3D, et d'éviter de devoir gérer le gimbal lock des angles d'Euler.
Donc dans une simulation de voilier (pas avion ou objet en rotation libre...) je vois pas comment je pourrais me trouver réellement confronté à cette situation dimensionnelle.

Ensuite, autre gros sujet, les pb de perfs (nombre d'opérations comparé du calcul par quaternion par rapport au calcul par matrices de rotations) il n'y en a donc pas vraiment car je ne gère qu'un seul objet mobile à chaque boucle (...pour l'instant il est vrai) et aussi surtout, pas de contrainte de latence réseau non plus à gérer donc la simu physique ne devrait pas me prendre plus d'un framerate d'affichage (fixé arbitrairement pour l'instant à 1/60s)

Voilà, c'est pour cela que j'ai écarté les quaternions et aussi parce que en effet, ça me parle pas trop, conceptuellement

Sinon les matrices, plus facile à appréhender, me font pas spécialement peur et comme c'est ce qu'utilise aussi OpenGL, ça me va bien.

A+
-kermit

[CM63]

Quelques éléments d'info supplémentaires:
- pour la force de vent: ce serait un champ de force : possible dans Jmonkey,
- pour la poussée d'archimède, tenant compte de la gîte éventuelle du bateau, etc, il faut juste faire un calcul des forces sur les facettes immergées: possible dans Jmonkey, il faut le rajouter à ta routine d'update,
- courant marin : champ de force, idem,
- c'est pour le calcul des forces sur les voiles que c'est plus compliqué, mais on va dire il ne te resterait plus que cela à résoudre, je suppose que tu veux représenter les mouvements des voiles?

A plus

[invite82ec7bc7]

re, CM63

"après toutes les interactions avec les objets sont déjà programmées"
...oui, ça peut être très utile, je veux bien te croire
je crois qu'en C++ il y a Bullet qui est pas mal, si je me souviens bien.

Bon je fais ça aussi dans un but didactique, donc tout faire moi-même (j'ai même poussé le vice jusqu'à refaire une classe Vecteur3 ! ) ne me dérange pas spécialement.
Toujours pour apprendre, je comptais bien gérer les éclairages et les effets moi-même directement en openGL.

Pour l'EDI je m'en suis fait un "à la papa" : MinGW+ gVim + project + tout un tas de compléments bien utiles


"je suppose que tu veux représenter les mouvements des voiles?"
tout à fait , mais ce sera simplissime : en gros il y aura (pour l'instant) deux états : la voile qui fasseye au vent et la voile qui prend le vent. La déformation "réelle" de la voile, ie. le déplacement du centre d'effort, me parait accessoire à gérer pour un début.

Bon, là je galère sur la conception d'un décor car à priori, je n'ai rien trouvé aujourd'hui d'utilisable facilement... même les cartes raster (images scannées) sont difficiles à se procurer, mais je désespère pas ! Au pire, je les ferais moi-même. Et puis il y a aussi une partie SIG à gérer avec le système de coordonnées (WGS84 ou mercator, etc...) qu'il faudra retranscrire... bref pas mal de boulot à défricher de ce coté désormais avant de retourner peaufiner un peu la simulation physique.

A+
-kermit

[CM63]

Re,

Bullet existe aussi dans Jmonkey, je me suis fait la main avec en faisant un tobogan avec une boule qui tombe, guidée par des barres. Ca marche pas mal.

Il faut dire que ce que j'apprécie avec Jmonkey c'est :
- travailler en Java plutôt que C++, pour moi (l'informaticien en retraite) Java c'est du C++ assaini, tous les avantages et pas les inconvénients,
- portable sous Linux (je ne suis plus sous Windows depuis l'arrêt de XP),
- et donc l'environnement de developement, vraiment super,
- tu peux créer tes objets 3D avec d'autre logiciels tels que Blender et ensuite les importer dans Jmonkey

Pour l’acquisition de la 3D du terrain, là je n'ai pas d'expérience, surtout s'il s'agit de fonds sous-marins , en ferroviaire les spécialiste utilisent un logiciel , j'ai oublié le nom, pour tout ce qui concerne le territoire français (mais au dessus du niveau de la mer). je vais regarder, je posterai le nom.

A plus.

[invite82ec7bc7]

J'ai commencé la prog (à l'époque scolaire...) avec du java aussi... vraiment idéal comme langage pour débuter il est vrai.
Je n'en fais plus (de java ni de programmation autre que loisir)
Maintenant pour les avantages comparé du java vs. c++, je laisse cela à d'autres plus expérimentés que moi.
Mais somme toute, de ce que j'en sais, tes arguments sont tout à fait recevables

"objets 3D avec d'autre logiciels tels que Blender"
Oui, pareil ! le modèle de bateau et ses composantes sera fait dans Blender. Il exporte un .obj tout à fait exploitable.


Par contre, il me semble que tu dois aussi avoir une problématique de report de coordonnées pour ta simulation de train ??
ou c'est peut être aussi géré via un module de l'EDI ?


En tout cas, merci beaucoup pour tes apports !


-Kermit

[CM63]

Qu'entends-tu exactement par report de coordonnées? Si tu veux parler des différents repères de coordonnées: globaux ou locaux, eh bien on utilise des routines de transformation qui admettent comme argument les angles d'Euler, et non pas des quaternions (on peut aussi si on maitrise) et c'est relativement facile. En fait il existe des objets Transformation, qui représentent des rotations-similitudes-déplacements, que l'on peut cloner et composer entre elles. Je ne sais pas si je réponds à ta question.

[invite82ec7bc7]

En effet, tu décris une façon de positionner les objets en 3D... ^^

Le système de projection en 3D que tu mentionnes (Eye (écran) vers global vers local) avec translation puis des matrices de rotation (...et donc le mécanisme push/pop) sera bien utilisé pour construire et visualiser une scène. C'est le fonctionnement d'openGL en fait.

Le repère global de la simulation, je peux lui donner un positionnement arbitraire, somme toute, alors que les fonds de carte sont géolocalisés avec des coordonnées géographiques en latitude/longitude selon différentes méthodes de projection pour passer de la terre à la carte (en fonction de la situation sur terre, ou autre).

cf. http://fr.wikipedia.org/wiki/Projection_cartographique
(regarde à WGS84, Lambert93, Mercator)

C'est la matière première des Systèmes d'Information Géographiques (cf. consortium OpenGis, PostGis)

Forcément, je ne connais pas non plus très bien le sujet, juste que quand on traite de positionnement sur Terre, tôt ou tard, on est confronté à cette problématique, mais j'ai pas encore trop fouillé le sujet pour savoir comment le rendre.

Je pense que tu as pareil dans les trains, et je serais curieux de savoir comment tu gères tes objets en réseau d'une carte à l'autre pour pouvoir t'en passer ?
(...dans l'optique où tu souhaites bien coller à la réalité terrain pour construire ta scène.)

[CM63]

Re,

Oui, je vois que tu en connais plus que moi sur les données cartographiques et d'altitude. Pour la simulation ferroviaire nous avons des utilitaires qui nous permettent de transformer ces infos en objet du monde de la simulation, appelé "Terrain". En fait on dispose alors d'un terrain illimité, défini par des parcelles, qui se chargent en mémoire ou se déchargent selon que l'on s'en approche ou qu'on s'en éloigne. Tu as toujours en mémoire la parcelle où tu es , plus les parcelles voisines. Encore un truc que tu n'aurais pas besoin de programmer.
Avec ça il y a des gens qui ont des km de voie ferrées, reproduction des différentes réseaux ferrées du monde.*

A plus.

[invite82ec7bc7]

"nous avons des utilitaires qui nous permettent de transformer ces infos en objet"
...veinard

Le fait de mémoriser la zone actuelle et de charger uniquement en plus les zones contigües, c'est pas non plus le plus dur.

Je n'ai pas encore envisagé le niveau de zoom (ex. 1/25000ième) pour le placage de la carte (uniquement en vue de dessus)
Ni des vues d'ailleurs... la caméra "embarquée" sur le mobile devra bien avoir un aperçu des reliefs les plus proches, mais du coup la texture sera sans doute très simple (du vert...) avec qqes objets genre balise ou phare ou maison (pour les azimuts et la tenue d'un cap).
Potentiellement ce sera pourtant la même source d'information. Enfin, dans l'idéal...

Bonne soirée !

-Kermit

[invite82ec7bc7]

Pour ceux que les modèles numériques terrestres (MNT) peuvent intéresser, je viens de trouver un projet très intéressant pour mon simulateur :

http://www.shom.fr/les-activites/pro...que-terre-mer/

...Litto3D, en partenariat IGN & SHOM, qui date quand même de 2005 mais que je ne connaissais pas. Il y a l'air d'y avoir pas mal de choses de faites désormais, et certaines (plusieurs) gratuites !!
Par contre, pas moyen de mettre la main sur le golfe, alors que c'est le "démonstrateur", bref...

Donc j'ai "commandé" des dalles numériques gratuites du Finistère que je vais essayer intégrer comme mesh dans Blender puis réexporter en .obj : ce sera mon modèle de décor.
Il est fort possible que pour ce faire je doive passer par un script de transformation à l'import dans Blender...

En tout cas, en ce qui concerne la partie purement géographique visuelle, ça a l'air d'être une très jolie promesse de support !
C'est quand même chouette les MNT dans un simulateur.

Restera à gérer les autres objets maritimes d'une autre manière, sans doute plus plate (xml...), via un éditeur dédié (je risque encore de pas y couper...)
Va falloir que je prenne l'habitude de me dire que j'ai besoin d'un éditeur différent pour chaque projet :/

A+
-Kermit

[CM63]

Bonjour,

Oui ça a l'air intéressant. Mais n'oublie pas que les terrains , dans les jeux vidéo en tout cas, ne sont pas stockés comme des géométrie 3D quelconques, ils ont un type particulier Terrain. En gros : il définissent un carré d'une certaine longueur réelle, divisé en 1024 carrés (par exemple), et à chacun de ces petits carrés est associé:
- une couleur,
- une information d'altitude.
Cela permet de mailler des grandes surfaces à la grosse, c'est suffisant quand on ne voit pas les surfaces de trop près, ça irait bien pour tes fonds sous-marins.
Après on peut toujours rajouter des objets 3D normaux pour le détail du décor: Blender.
Mais pour éditer les fichiers Terrains, je ne pense pas qu'on puisse le faire à partir de Blender, c'est pour cela que je parlais d'utilitaire. Je vais regarder le site que tu a cité pour voir s'il y a plus d'infos.

A plus.

[CM63]

Ben déjà si je clique dans "Grand public", c'est circulez, y'a rien à voir