FlightGear - Création d'avions et autres / Creation of aircraft and other

Vous désirez aider à améliorer les avions de Hangar de Helijah, c'est ici que cela se passe / You would like to help improving aircraft from Helijah's hangar, this is where it happens

Vous n'êtes pas identifié(e).

#1 Re : Ici nous parlons modèles de vol et donc principalement de YASim ! » Voilà une question qu'elle est bonne ! » 2017-11-25 08:48:42

Salut,
Dans ma précédente intervention, je parlais de l'existence du" hstab" comme d'un doublon  de la "wing"...Suite au surf sur internet, il apparait que c'est une nécessité avec YASim pour l'animation d'une aile delta !
A ce sujet, a priori j'avais dévolu la fonction "profondeur" aux élevons intérieurs et laissé la fonction "roulis" aux élevons extérieurs...Un site internet explique que dans certaines réalisations les élevons de chaque demi-aile sont en deux parties pour des raisons entre autres de résistance mais que chaque ensemble des deux, droit ou gauche, est solidaire du mouvement commandé !
Le MIV qui a  été de son temps un engin entouré du secret militaire lié à sa mission de dissuasion nucléaire et de reconnaissance stratégique ne bénéficie pas de beaucoup de doc ! Je cherche à connaitre un écorché ou un descriptif de ses réservoirs internes...
PS : sur ton MIV les moteurs sont des 9K50 ! En fait c'était des 9K ! J'ai aussi constaté des différences entre unités de masse et de température !

#2 Re : Ici nous parlons modèles de vol et donc principalement de YASim ! » Voilà une question qu'elle est bonne ! » 2017-11-24 11:06:40

Bonjour,
Merci pour ta réponse : c'est ce que je recherchais ! Donc c'est le FDM qui gère le positionnement de l'aéronef relativement au sol de FG.
Sauf que dans la masse des connaissances à absorber et à ESSAYER de maîtriser entre le logiciel de modélisation (Blender), un logiciel de dessin (Paint pour le moment, GIMP un jour prochain...), le logiciel de simulation FG, la programmation des animations en .xml et pour le moment présent le logiciel de FDM, je peux dire que effectivement Paris ne s'est pas fait en un jour !
Donc dans ma découverte pas à pas de cet ensemble, je progresse par itérations successives à chaque niveau et cela, bien que j'y sois assidu me prend un temps certain ! Ceci dit je suis admiratif du travail fourni par les uns et les autres...
Problème du truc en général c'est la documentation principalement en anglo-américain qui n'est pas ma langue d'origine...et de ses traductions imparfaites ! Bref avec les facilités de la traduction en ligne, on peut avancer aujourd'hui plus facilement qu'hier ! Reste que pour traduire faut être un zeste linguiste et en matière d'aéronautique un peu d'expertise ne nuit pas pour rendre un document intelligible.
Ceci dit mes modèles ne  volent pas mal sur la base du F86 avec Yasim et du F105 avec JSBSim, car les avions que je modélise surtout pour en gérer l'animation des trains d'atterrissage sont des avions très semblables car de la même époque, un Sabre n'est pas bien différent d'un Ouragan, Mystère IV ou SMB2 et un F105 n'est pas bien différent d'un F1...
Bref j'étais à finaliser un Mirage IV A et P chacun ayant son FDM  particulier JSBSim et YASim et j'ai approfondi pour le moment  le FDM YASim sur la base du tien...
La doc wiki française mérite une petite maj et j'ai donc pris la doc wiki US qui introduit quelques corrections et explique l'installation de l'addon de lecture du fichier YASim.xml par Blender !
En soi c'est une découverte interessante...
J'ai remarqué que la symétrie de la "wing" n'est pas top !
En ce qui concerne ton fichier je ne comprends pas l'existence d'un "hstab" décrit comme la"wing" et de "weight" (pilotes et radar que j'ai remplacé par un ASMP) décrits comme des ballasts !
J'ai décrit un bec qui n'apparait pas physiquement...
Et pour finir quand je lance une session d'essai de ma description perso du FDM,  FG plante !!!!! Donc en perspective, grosse séquence de recherche et d'essais pour trouver le hic !
PS : j'ai bien pris garde de lire le  FDM.xml par Firefox qui me donne toutes les corrections syntaxiques.
A+

#3 Ici nous parlons modèles de vol et donc principalement de YASim ! » Voilà une question qu'elle est bonne ! » 2017-10-29 09:45:54

S-KIMO
Réponses : 4

Bonjour à tous,
Pour intégrer mes modèles dans FG j'utilise deux packs que j'adapte sans comprendre toutes les subtilités du .xml :
- le F-86F avec YASim de Detlef Faber
- le F-105D avec JSBSim de David Culp
J'ai réalisé un Vautour II N que j'ai intégré avec chacun des packs et je mets ici en évidence mon problème :
171029110304168265.png
171029110408537335.png
Ci-dessus mon modèle avec le pack du F-86 et YASim : le modèle  (et tous mes modèles réalisés avec ce pack) penche à gauche ! Initialement c'est ce programme qui m' a fait régler l'altitude du modèle donc le train arrière tangente la piste...
171029110500911171.png
171029110551942709.png
Ci-dessus mon modèle avec le pack du F-105 : le modèle est bien horizontal...mais les pneus ne sont pas au contact de la piste !

Que faut-il en penser  selon vous ?

En post scriptum le déclencheur de cette question : avec AC3D je pose mon modéle Vautour II N dans FG et j'évalue la correction à appliquer pour remonter les trains à la tangente de ma piste préférée LFMH 18...
Sous Blender 2.79, je cale le curseur à 0,0,0 et procède aux rotations (le dessin choisi nécessite une rotation de 5,8 degrés pour amener les trains à l'horizontale) et à la translation en Z...Je récupère mes références et les code dans les fichiers .xml du pack choisi...
En fin de soirée, tout baigne : le modèle manoeuvre ses surfaces de vol, ses trains, trappes et verrières comme je le rêvais et je peux aller dormir content !
Au matin suivant, je me rends compte que les roues des trains au décollage ont un mouvement lapidaire et que des parties du modèle sont maintenant décalées  !!!!
171029113336599498.png
Je refais donc tout le processus en ayant soin de conservé un exemplaire de mon code initial.
Il y a eu là un truc qui m'échappe...
Pour être précis, initialement je remontais mon modèle de 70 cm et après correction ce n'est plus que  de 30 cm ! En comparant les coordonnées Z des deux versions c'est 38,163 cm...
En bref, ce n'est pas un détail !

#4 Re : Ici nous parlons des applications externes en rapport avec FG. » Affichage des textures dans FG » 2017-08-28 06:36:06

Merci de ta réponse. Je connais depuis quelques temps tes deux tutos qui m'ont aidé à défricher le domaine de modélisation des avions mais Blender 2.78 a beaucoup évolué ne serait ce que l'interface depuis 2.6 ou 2.4 qui avaient fait l'objet de documentations traduites en français. Chaque fois qu'un logiciel évolue, je n'ai pas de prévention à l'actualisé à la dernière version ce qui est absolument le but recherché par ses auteurs mais en phase de finalisation cela comprend souvent des évolutions magistrales. On parle déjà de Blender 2.8 qui précédera surement une version 3.0 définitive et une release 2.79 est dispo sur le site...

#5 Re : Ici nous parlons des applications externes en rapport avec FG. » Affichage des modèles dans FG » 2017-08-28 06:26:52

Oui, surement au plan général ! Mais j'ai déjà constater que le xml n'est pas un langage qui pousse à la rigueur sémantique comme pouvait l'être les premiers langages tel  Fortran : ainsi, xml convertit facilement un chemin avec un autre ! Je m'explique : si je fais un dossier copie eh bien xml interprête la recherche des dossiers subalternes ou les fichiers non pas dans ce dossier copie mais garde le chemin du fichier mère selon un algorithme je dirais tolérant à la syntaxe défaillante ! Pour cela c'est simple (enfin si on veut le voir ainsi)  il faut configurer le fichier copie de manière éloignée dans l'arborescence de son fichier mère comme par exemple le mettre sur le bureau !!!
Je ne sais pas si je me fais comprendre !

#6 Re : Ici nous parlerons de Blender. » BLENDER 2.78c » 2017-08-28 06:14:11

Salut,
Le staff Blender a intégré un programme de manipulation d'image pour surpassé GIMP ou autres logiciels utilisés précédemment ce qui est une bonne idée.
J'ai voulu m'y frotter en m'aidant de la doc en anglais dont une traduction en ligne est devenue possible ce qui est une aussi bonne idée.
Mais j'ai la nette impression que pour tout informaticien se pose le problème de documenter son logiciel et que là on a mis la charrue avant les boeufs tellement cela frôle l'intuitif...C'est du genre boite à outils multiples et bonne chance pour la suite ! Du coup, ne retrouvant pas la logique de progression vers le but recherché, j'ai documenté ce que j'ai pu réaliser disons basiquement à savoir gribouiller des couleurs sur les faces du cube d'origine : en gros, c'est possible en 15 clics !
Par contre il y a foison de menus et d'options desquels je ne saisis pas l'action...faute de mentions documentaires !
Bref je continue le débroussaillage...
A +

#7 Ici nous parlerons de Blender. » BLENDER 2.78c » 2017-08-26 07:50:53

S-KIMO
Réponses : 2

Salut t'à toutes z'et t'à tous !
Qui s'est donné la peine (l'immense peine ?) de lire le manuel (pas l'Emmanuel !) afférent ?
C'est un truc super balèze...si c'était structuré pour permettre un apprentissage au sens progression dans la connaissance de l'outil mais en fait c'est un fouillis sans nom où les liens créés ne permettent pas cette logique documentaire...Bref donnez un coup d'oeil à la version française (se commande par un menu déroulant en bas à gauche de la page d'accueil) et plus particulièrement à la partie peinture et sculpture qui m'intéresse fort car j'essaie d'en capter la substantifique moelle pour enfin réaliser une livrée sans passer par GIMP qui en lui-même est un monument ou Paint !
Dans ce chapitre pré structuré mais en dehors de la réalité du logiciel, sans parler ici d'une quelconque approche intuitive, il est impossible de retrouvé un rapport direct et simple entre l'écrit du manuel et l'affichage du logiciel...
En fait c'est dommage, je me suis paluché l'aide contributive à cette oeuvre (une organisation parfaitement cartésienne au sens américain du terme !) des fois que...mais je vais faire ma doc de mon coté !

#8 Ici nous parlons des applications externes en rapport avec FG. » Affichage des textures dans FG » 2017-08-17 08:55:57

S-KIMO
Réponses : 2

Salut tà toutes zet tà tous !
Puisque j'y suis, autre problème !
Je n'ai pas une maîtrise formidable des livrées donc je fais une peinture totale de mes modèles pour jauger l'effet...
J'associe un material disons"Aluminium" des zincs et une texture disons "Peinture" monochrome ou "Camouflage" (avec 2 tons)...
Par exemple tout ce qui est noir comme un pneu est "Pneu" en material et "Pneu" en texture et sur ces petits éléments l'affichage noir existe bien. Pour ce qui est de la presque totalité du modèle et de ses surfaces de commande de vol la texture "Peinture" ou "Camouflage"  ne s'affiche pas !
Où se situe le problème selon vous ? Merci de vos avis

#9 Ici nous parlons des applications externes en rapport avec FG. » Affichage des modèles dans FG » 2017-08-17 08:46:26

S-KIMO
Réponses : 3

Salut tà toutes zet tà tous !
Donc dans mon élan et ayant acquis une certaine aptitude avec Bender 278c à modéliser, je me fais le Mirage F1 et son train d'atterrissage spécifique à la cinématique dite du salut militaire ! Faute de détails c'est difficile à mettre au point mais c'est assez réaliste : enfin j'en suis content !
Pour faire court je décline les fichiers sous F1CT et là arrive un moment où plus rien ne va !
Sans entrer dans les détails passés j'ai donc renommer mon .ac converti avec ac3d car particulièrement tolérant en "indefini" ! et le pb s'est estompé...j'ai à nouveau eu le zinc en seuil de piste !

J'ai dans l'idée de faire les deux versions "F1CT" et "F1CR" qui ne changent que par la position d'un des canons et par l'emport d'un pod laser ou caméras !
Je copie donc mon fichier "F1CT"  et le renomme "F1CR"et boum les problèmes recommencent ! Donc je renomme chacun de façon complétement différente soit l'un "Tactique" et l'autre "Reconnaissance" ! résultat ça affiche de nouveau !

Mais car il y a un mais quand je cherche sur FG la version "Reconnaissance" elle n'apparait pas dans la liste de mon fichier "Hangar"!
J'ai donc installé la dernière version 2017.2.1 et pas d'amélioration : je précise que tous les fichiers reprennent Tactique qui s'affiche et Reconnaissance qui ne s'affiche pas dans la dénomination des divers fichiers et images !
Pour confirmer que le .ac de "Reconnaissance" est conforme je l'ai susbstitué à "Tactique.ac" dans le fichier "Tactique" qui s'affiche et il apparait correctement !!!
Qu'en pensez-vous ?

#10 Re : Le forum est en mutation, on en parle ici. » Perte du Forum depuis 3 jours..... » 2017-07-26 13:34:33

Te revoili !
Je suis bien content qu'il existe des ressources FG et consorts (Blender, xml,...) hors le site dit officiel français où l'on ne traite que de problèmes liés à l'informatique et spécifiquement au truc à l'enseigne du pingouin qui marche à en juger le feu de dieu, j'ai nommé Linux !
Bonne route à ton oeuvre.

#11 Re : Le Hangar contient bien des avions à finir :) » Le 2000 » 2016-04-24 13:00:55

Bonjour,
Où trouver la dernière version de l'avion ?
Merci

#12 Re : Le Hangar contient bien des avions à finir :) » Le 2000 » 2015-10-28 17:13:51

Seuil 33 LFMI mission Kilo 17 h Zoulou :
151028061348197874.png
...le train est sur les jantes !
15102806205335142.png
...la tuyère s'est réduite,
15102806180112732.png
...la PC est déclenchée !

Beau ! Bravo !

http://www.airforce-technology.com/proj … rage3.html : un lien avec des photos des emports !

#13 Re : Le Hangar contient bien des avions à finir :) » Le 2000 » 2015-10-24 13:02:51

Bonjour,
Au sujet des volets de la tuyère, je suis d'accord sur leur mobilité mais je pensais intuitivement qu'au sol, au décollage,  ils réduisaient la section (comme on fait en pinçant un tuyau d'arrosage pour qu'il "pisse" fort et loin !) pour passer l'éjection des gaz  en mode chalumeau et arracher la bête du plancher des vaches...alors qu'en vol, ils s'ouvrent pour éviter de brûler ! Mais c'est peut-être une ânerie ce que je dit ?
Il semble que tout cela soit régulé par un calculateur...mais je n'ai pas trouvé confirmation de mon intuition en ce qui concerne le quand et le comment...
https://fr.wikipedia.org/wiki/Snecma_M53
Au sujet de la flamme de PC et de ses anneaux pulsés bleutés (je connais bien cet effet pour avoir bossé 14 ans sur une BAN, dans la tour face à la piste et au Mont Ventoux !), j'ai essayé la 3.6RC mais au contraire elle ne faisait pas fonctionner le F14B avec une bonne visu de l'effet de son mode PC (qui est peut-être bien différent par conception de celui du M2000) donc j'ai réinstallé la 3.4 et la version1.2.2 du Tomcat !

#14 Re : Le Hangar contient bien des avions à finir :) » Le 2000 » 2015-10-23 07:48:54

Salut,
J'ai installé le pack du 21 ! Il est beau cet avion ! Je ne  comprends pas tout dans vos problèmes de programmation mais cet avion est assez stable pour être manié à la souris, il me semble qu'il y a un temps de réaction pour sortir de cette position relativement à d'autres modèles typiquement "bûche" volante !
Ce qui est impressionnant à voir ce sont les becs qui s'actionnent de façon très "réaliste" (voir la réalité est réservé à qques initiés invités sur biplace !)
Et je trouve super ses livrées avec le détail des multiples trappes d'accès.
Au sujet de la PC, est-ce que les volets de tuyère sont animés ? Est-ce que la flamme de la PC ne doit pas être plus longue ? Est-ce qu'il est possible de la rendre encore plus "réaliste" en simulant les ondes de compression ?
Bonne suite à vous c'est du beau travail et cet avion bien de chez nous mérite une place dans FG.

#15 Re : Ici nous parlerons de Blender. » Pourquoi Blender » 2015-10-20 16:16:15

Et pourquoi pas !
Hello, c'est encore moi !
De mon surf sur internet, j'ai saisi qu'on crée les modèles avec un modeleur puis qu'on les exporte dans un autre environnement pour l'usage prévu !
Pour mettre en perspective notre "bijou" sous un de ces aérodrommes dont Flightgear à le secret il faut lui donner une extension en .ac alors que Blender nous fabrique l'objet sous . blend !
J'ai saisi aussi que Blender (je suis au top des versions avec la 2.76 RC, enfin je crois les choses allant si vite...) manque de l'extension (add-on) qui va d'un coup de baguette magique faire le truc en Nasal (sniff)...De mes lectures et avec les aides fournies sur différents sites dédiés j'ai récupéré par téléchargement des fichiers qui contiennent ces petits programmes et les ai installés dans le dossier qui va bien de Blender...
Ayant constaté que le zinc le plus répandu de la planète ne figurait pas dans les petits papiers de FG, j'ai récupéré 2 dossiers et dans mon intention de me bricoler "mon" modèle j'ai employé la fonction "Importer" de Blender avec chacun des add_on installés. Donc l'affaire se fait mais le résultat n'est pas identique :
151020061046849387.png
151020061225450826.png

Lors de ce dernier chargement un panneau éphémère rempli d'infos apparait !
Pour ce qui est de la fonction "Exporter" "mon" modèle ? Nada, sauf aussi un panneau éphémère...
Pourtant, j'ai fait "A" pour tout sélectionner de la visu choisie puis choisi le fichier d'implantation en lieu et place de l'original ci-dessus en renommant bien "mon" fichier" au nom de celui-ci.

Suite une série d'essais j'enrichis mon exposé pour vous éviter de perdre du temps à m'expliquer ces essais !
Ainsi au départ, j'ai sous FG un dossier téléchargé que j'ai recopié et renommer (oui je garde l'original en place) pour le fagociter au niveau de son "avion".ac dans Model. Résultat avec l'add-on 1 (spécial FG qui va mieux que l'autre) je charge au démarrage de FG l'avion original du dossier original alors que le menu apparemment les distingue. Pour en avoir le coeur net, je contrôle que la date d'implantation est correcte, ce qui est le cas...C'est l'occasion aussi de constater que les dossiers originaux sont protégés contre l'inscription, il faut donc faire une copie ! Question pour les informaticiens, pourquoi sous l'apparence de concerner le dossier idoine (celui qui a été renommé), le logiciel lance l'avion original du dossier original qui a un nom différent ? C'est pas la chose qui risque de se passer en mécanique ça !
Je voulais m'éviter une manip mais devant la nécessité je supprime donc ce dossier original et renomme à son nom "mon" dossier copié et là FG n'affiche que les autres "machin".ac du dossier à savoir un tableau de bord seul sur la KSFO 28R !
Ma conclusion mon cher Watson c'est "Elémentaire, quelque chose ne fonctionne pas, of course !"


Une idée sur la chose ?
Merci d'avance  pour le diagnostic.

#16 Re : Ici nous parlerons de Blender. » Un exemple de 3D qu'il n'est pas bon de garder :) » 2015-10-19 16:44:31

Bonjour Emmanuel,
Oui, je comprends que le logiciel n'envisage pas le traitement par un algorithme particulier de certains cas de figure possibles des imbrications volumiques dans ses boucles de conditions  booléennes ! Au minimum, la "maille" d'un mesh n'est déjà pas identique à celle d'un autre mesh et comme le logiciel procède lui-même par itération, son pas de calcul ne risque pas de "tomber juste" !
Est-ce qu'à ce sujet, pour les opérations booléennes les meshes ne sont pas alors subdivisés puis reconstitués comme l'original ce qui fait qu'on retrouve tous les vertices intermédiaires en visu fil de fer mais qu'ils ne sont pas réutilisés par exemple par les modes de visualisation qui créent des masques ?

#17 Re : Ici nous parlerons de Blender. » Un exemple de 3D qu'il n'est pas bon de garder :) » 2015-10-19 14:40:24

Bonjour,
Au hasard Baltazar, je relis ce post et c'est le plus proche de ma dernière expérience où j'ai passé un temps fou de retraité forcément occupé à rien d'autre, à m'escrimer sur des faces, arêtes et vertices parasitant "mon" 737MAX post booléen et surtout les hublots en nombre imposant. Quelque part ou non , y a-il une méthode ? (ou alors Blender étant ce qu'il est, je dois faire avec). J'ai remarqué sans vouloir poussé une thèse qu'arrive un moment où le nettoyage un à un des parasites (surtout ne pas grouper les intrus sinon c'est le fiasco et même si c'est énervant je n'évanouis que les arêtes et laisse tous les vertices car ce sont eux les éléments originaux dont on a besoin pour reprendre le facettage) qui se passe bien, à savoir qu'effectivement l'intrus peut être supprimé ou dissous (sans trop savoir lequel fait quoi de différent de l'autre) sans évanouir une face, puis laquelle chose se produit alors effectivement : il ne reste quà faire un Ctrl + Z. Cependant, certaines fois, c'est le joliciel qui m'envoie un message genre "Ne pas toucher, frontière ", la face ne s'évanouissant pas ! Y a-t-il des arêtes et vertices réellement parasites par rapport aux éléments d'origine ou bien le logiciel reconstitue-t-il la définition des faces tant qu'il a le minimum d' éléments nécessaires ? Une chose n'est pas claire pour moi, y-a-t-il dans la logique de Blender un post -traitement sous un mode donné comme le laisse entendre Didier qui farait apparaitre des trucs dont on n'a rien fait pour les avoir ?

En ce qui concerne les booléennes, et maintenant je me contente du résultat sans plus chercher à comprendre le concept, j'ai remarqué qu'un mesh cylindrique (c'est ma méthode de faire des aéronefs avec un max de ceux-ci dont je maîtrise facilement la déformation) après une booléenne subit un dommage (il faudrait que je retente l'expérience pour être didactique) et j'ai alors des génératrices  parasites  mais aussi des génératrices d'origine qui se rejoignent ! Je sais détruire les parasites visuellement car sans illusion d'optique elles vont d'une extrémité d'originale à l'extrémité opposée de la plus proche, en bref Blender dessine des "Z" sur la paroi pseudo-cylindrique !
151019054551540204.png
Quand je les dézingue, arrive un moment, à la fin du nettoyage, où deux originales se rejoignent sur la face sectionnelle...Un vertice a donc migrer vers un autre !

Dans le même ordre d'idée j'ai remarqué que le sinistre s'étend en périphérie du mesh et en limitant le mesh à un volume fermé réduit aux seules surfaces nécessaires les parasites ont concerné un autre mesh !
Mais c'est peut-être "accidentel"...

Le temps de faire mon essai didactique, je me suis rendu compte que dans le cas précis de ce winglet double,  j'avais 2 options dans sa conception et que le plus sûr est de ne pas faire trop tôt la fusion des meshes pour pouvoir continuer à utiliser les booléennes sans trop de dégâts (ici faire un feu de position dans le winglet supérieur qui par sélection s'est révélé être distinct de l'aile d'origine qui forme le winglet inférieur, ce qui n'était pas le cas sur mon modèle) :
151019065434460127.png

#18 Re : Ici nous parlerons de Blender. » Des effets désagréables de rendus » 2015-10-18 08:32:17

Hello,
Non, Didier je n'utilise pas de fonctions super chic ! Ce que l'on voit sur le modèle c'est les liserés orange de la sélection globale...
Je ne suis pas à ce niveau de connaissances des ressources de Blender ! Mais ta remarque me montre que j'ai une ligne diagonale sur le spoiler intérieur (en fait le fond de son logement) que je n'avais pas voulu ! Il y a des choses comme celles-ci qui apparaissent à un moment donné et qu'il me semble n'avoir pas été voulues...Quand on créé il faut sans cesse prendre du recul pour évaluer ce qui se produit en réalité et dans ce sens coloré par matériau me permet de mieux mettre en évidence des parasites ce qui est typique des fonctions booléennes !
Je connais le truc qui existait sur Catia et qui permettait de définir des contours et des volumes sans trous avant de procéder à des opérations booléennes. D'après ce que tu dis Blender a cela ? Je vais chercher !
Par contre, oui je smoothe (enfin moi je reste français car j'ai la conversion de Blender dans ma langue maternelle qui est aussi ma langue paternelle !) en fait c'est Ombrage/Adoucir et c'est pas beau ! Ici j'ai intégré les bidules genre antennes dans mon fuselage et quand je tire le drap y a des plis :
151017073117492331.png

Est-ce que quand je mettrai une texture UV cela va être caché ou bien faut-il que je ne joigne pas certaines entités à d'autres ?

Par la force des choses mon fuselage étant dissymétrique (les portes avant ne sont pas alignées) je ne l'ai pas coupé à l'axe puis fait en miroir. Je suis obligé de garder la voilure non jointe qui elle est en miroir pour gérer des évolutions sinon elles n'apparaissent pas en miroir : c'est le cas des feux en bout d'aile !

Est-ce que le modèle final doit-être compacté  c'est à dire n'être qu'une unique entité  (excepté les organes mobiles) ? Au mieux actuellement, je me concentre pour réaliser qu'une peau de l'avion (bonjour le booléen Blender !) alors que je pourrais ne pas réaliser les intersections des meshes.

Pour ce qui est des normales anormales je gère la chose en visuel car Blender savamment en change l'aspect en les assombrissant ! C'est un minimum pour utiliser les fantasques fonctions booléennes de Blender que j'ai systématiquement utilisées ici : gros boulot de nettoyage à faire...

Pour le moment je suis en train de bricoler les surfaces de commande de vol pour les affiner car je les ai découpées dans le profil d'aile qui est trop épais : c'est difficile à évaluer sur les plans ou photos et en réalité sur un zinc du réel ce sont plutôt des bouts de tôle qu'il faut intégrer artistiquement dans un bord de fuite plutôt épais car il se relie au fuselage par un karman dont la plupart du temps on n'apprécie pas précisément le volume !
J'ai fait cet essai de 737MAX à partir de documents plus ou moins cohérents trouvés sur internet (en fait l'engin en est au stade de fabrication du 1er de série et rien de bien précis n'existe en plans) et finalement j'ai réussi faute de docs à dépasser ma propension à vouloir faire des choses exactes (vieux réflexe professionnel !). Ce que je veux tenter c'est de faire de l'animation des parties mobiles puis de mettre le projet dans FG pour le voir évoluer. J'essayerai d'utiliser plutôt JSBSim qui est supporté par un site dédié mais enfin j'en suis pas encore là...

A+

#19 Re : Ici nous parlerons de Blender. » Des effets désagréables de rendus » 2015-10-17 07:45:18

Salut les pros !
Je greffe ici ma question...
J'essaie de mener au bout une tentative de réalisation d'un modèle par Blender avec l'intention de le configurer sous FG...juste pour voir et comprendre l'ensemble du processus.
Je me suis longtemps attardé à réaliser divers modèles pour "apprendre" Blender et maintenant j'en suis à vouloir donner à la chose dessinée un aspect lisse !
Quels outils Blender dois-je employer ? Et à quel stade de la conception ?
151017095804754480.png
Merci à vous.
PS : en filigrane, vous discernerez que ma question n'est pas innocente, j'ai essayé des choses mais ça donne des résultats hummm... déduction : y a surement un truc à faire !

#20 Re : Ici nous parlons modèles de vol et donc principalement de YASim ! » Les traductions des pages de Gary NEELY (Buckaroo) » 2015-08-17 08:34:31

Bonjour,
J'ai traduit la prose de Buckaroo sous AOO 4.1.1.
Pour cela j'ai fondu tous les chapitres un fois passés à la moulinette de Google en un seul tenant ce qui m'a permis de faire des corrections en masse donc de nommer les choses de façon systématique et homogène...
Je te les propose pour insertion ici par voie d'email !
Je n'ai pas compris un paragraphe, du moins une explication sur la prise au vent, qui me parait a priori erronée (j'en ai commencé la discussion par ailleurs) et j'ai aussi relevé un copié collé erroné !
Je pense avoir repris sa pensée sans erreur grossière mais une relecture approfondie au sens des pensées "simulo-aéro-informatiques" s'impose...
Qu'en penses-tu ?
A+

#21 Re : Tutoriaux » Création du dossier de base d'un avion :Tupolev Tu-444 » 2015-07-22 07:31:17

Salut Didier,
Je m'intéresse à la partie logicielle de FG maintenant et je découvre le XML ! J'ai synthétisé ton tuto et je me rends compte qu'il serait bon que tu expliques que les fichiers XML du dossier de base servent à donner entre autres (?) des infos sur les pages du lanceur du simu avec un écran d'illustration.
Merci.

#23 Re : Tutoriaux » Eclipse 550 tuto N°1 : Modeling the outside body » 2015-04-01 21:27:42

Salut Didier,
Suite mon annonce de repartir de zéro et ton retour, je suis d'accord sur l'incertitude du booléen de Blender ! ce n'est pas bien grave mais autant le dire.
Donc il est important avec Blender d'évoluer avec méthode et en particulier de trouver un système de sauvegarde de la modélisation acquise car il y a des choix sans retour !
Il faut donc rester clairvoyant sur ce qu'on veut faire, bien analyser les données du problèmes et imaginer la méthode à suivre.
En fin de compte je suis arrivé à tout faire en booléen aujourd'hui sans trop savoir si Différence ou Intersection convenait c'est le résultat qui décidait...
Ainsi j'ai systématiquement créé ce que j'appelle des outils pour perforer la peau du fuselage ? Pour cela je convertis en Objet par copie (Maj +D) ou  'Séparer/Sélection" (P) les éléments  nécessaires pour obtenir des sections droites. Je rectifie si nécessaire ces éléments en éliminant les doublons (W) et en les ramenant dans un plan( Sx, Sy ou Sz), je crée une face (F) avec la section droite sélectionnée qu'ensuite j'extrude : le volume est fermé et c'est ce que recommande le manuel.
J'applique le booléen : ça fonctionne, ou l'objet de référence disparait et là je change d'opérateur ou j'ai un message "Ne peut effectuer l'opération booléenne" et là je pars à la recherche du défaut.
Pour la sélection, je passe en mode d'affichage solide qui fait que seuls les éléments visibles sont sélectionnés. Pourtant une arête manquait qui devait motiver le message. Je me rappelle que dans ma vie professionnelle, CATIA avait des fonctions de contrôle comme savoir si un périmètre ou un volume était bien fermé...Des réminiscences !
Dans le cas de l'Eclipse je vais conservé le fuselage en entier (pas de symétrie miroir) du fait que les ouvertures sont dissymétriques : demi- porte avec hublot. J'ai réalisé les ouvertures en axe xx et le pare-brise en zz : il faut faire un outil droit par symétrie du gauche (Ctrl + Mx) après copie (Maj +D) : c'est pas forcément gagné !
Bien ramené les cdg sur les géométries...
Enfin je n'ai pas fait de nettoyage des arêtes qui sont invisibles en réalité hors du mode d'affichage fil de fer mais qui servent au drapé ! Du coup je n'ai pas de bizarreries dans le facettage.
150401113622934106.png
Je suis assez content du résultat mais restons modeste !
A+

#24 Re : Tutoriaux » Eclipse 550 tuto N°1 : Modeling the outside body » 2015-04-01 09:01:37

Salut à tous,
Donc en désespoir de cause, j'ai repris la modélisation de l'Eclipse !
Je reviens donc sur ma correction et de façon affirmative c'est la fonction booléenne "Différence" qui convient, ainsi que les essais successifs sur des mesh de base tendent à nous le montrer, pour définir la jonction d'une aile sur un fuselage en créant l'intersection d'un mesh spécifique avec le dit fuselage ! Dans le cas "Intersection" c'est radical le fuselage disparait !
A bientôt sur nos lignes.

#25 Re : Tutoriaux » Eclipse 550 tuto N°1 : Modeling the outside body » 2015-03-30 12:37:32

Hello,
Suite et fin des essais : ci joint le résultat pour lever le blocage fenêtre du cockpit.
Donc après voir conserver un profil de l'outil précédent, fait W pour éliminer les doublons (inutile) puis Sx pour mettre coplanaires tous les vertices et ar^êtes  (ce qui n'était pas le cas réellement mais une projection vue en bout c'est une projection ?) créer une face et fait son extrusion en x mais sans traverser le fuselage de gauche à droite, je fais d'abord Différence (ma marotte ces temps derniers)
mini_1503300240117763.png
et hop plus de fuselage puis je reviens à Intersection d'où un résultat :
mini_150330024348118492.png
mini_150330024458912663.png
mini_150330024606974244.png
mini_150330024647647899.png
mini_150330024756188388.png
Vue de coté à la base du profil   :
mini_150330024943605145.png
Vue de dessus pour un profil résultant décalé :
mini_150330025115746022.png

Reste à faire de même  de l'autre coté et le pare-brise...
Donc se convaincre que Intersection est bien l'opération booléenne qui fonctionne pour réaliser une intersection...

Pied de page des forums

Propulsé par FluxBB 1.4.8