Vous n'êtes pas identifié(e).
Futur nouvel inscrit, tu dois au préalable lire l'intégralité des 10 articles des règles, s'il te plaît. Tout nouveau compte qui ne respecte pas les règles sera supprimé par l'administration.
pour ceux que l'anglais rebute un peu voici ce que j'ai compris de l'utilisation des dds dans flightgear. Le thread sur la devel:
http://www.mail-archive.com/flightgear- … 31482.html
Les textures dans FG sont majoritairement au format .png, surtout pour des questions de place, mais cela possède un inconvénient: un temps de chargement-conversion, qui peut prendre beaucoup de temps sur certains avions (par exemple le f16 avec sa texture transparente qui prend dans les 20s chez moi pour se charger). FG prend le png, le convertit en un format qui plait à la carte graphique, et calcule les mipmaps, en utilisant un filtre rapide, et tout ça prend du temps.
L'utilisation du format dds au lieu de png permet de zapper la partie conversion et création de mipmaps, le dds est chargé directement dans la carte graphique tel quel, de même le dds contenant déjà les mipmaps (suivant les options demandées) le chargement est beaucoup plus rapide. le second avantage est que les mipmaps sont de meilleure qualité, par exemple pour une normal map, regardez les rivets ici:
http://flightgear.org/forums/viewtopic. … 47#p118547
l'inconvénient, c'est une question de taille, pour les tests que j'ai fait, les dds (avec mipmap) prennent 4x plus de place environ, et sans avoir eu le temps de trop faire d'essais, j'ai eu des problèmes avec des hélices qui n'étaient plus transparentes, un truc à voir avec les couches alpha...
les outils: je sais qu'il existe un plugin pour gimp pour creer du dds, mais j'ai utilisé les outils nvidia:
dispo en binaires pour windows, et en sources pour linux/mac et compilé sans soucis ici. A noter que ces outils peuvent utiliser Cuda, si vous avez une carte ad hoc.
ensuite, il faut flipper verticalement la texture avant de convertir, ce qui donne pour moi:
mogrify -flip blabla.png
nvcompress -bc3 blabla.png
mogrify -flip blabla.png
ou en une ligne traiter un avion complet (linux):
for i in `find . -name "*.png"`; do echo $i; convert -flip $i temp.png; nvcompress -bc3 temp.png ${i%.png}.dds; rm temp.png; echo; echo; done
(si des fois il y a des .jpg ou des.rgb, changer la ligne en fonction)
Il faut ensuite changer les extensions dans les .ac ou .xml...
la conversion prend du temps, et je comprend que le résultat soit meilleur que le résultat d'OSG.
j'ai testé ceci sur le F4N de dave et sur le Cub, en changeant les références dans les.ac, et ça marche plutot bien, le chargement des autres avion est plus rapide (y'avait un meeting de Cub, avec sa grosse texture il est long à charger), de même que le passage en vue externe la première fois. C'est pareil dans FGRun, un F4N en dds prend une seconde à charger, alors qu'il faut entre trois et 4 s sinon...
utilisation possible:
je pense surtout à ceux qui volent en formation, pour limiter le lag de chargement au maximum, il suffit de convertir toutes les textures de FG en dds il me semble que Thorsten propose un set de textures de nuages en dds pour des tests, par contre bon courage si il faut faire tous les avions...
Ma suggestion est de faire une copie de fgdata adaptée au vol en formation avec les nuages , voire le sol, voire tout le reste en dds , et un dossier aircraft vide. on utilise les options de dossier aircraft pour au choix charger le dossier Aircrafts normal (qui a été déplacé ailleurs), soit un dossier Aircrafts adapté à la PAF, ne possédant que les avions de la patrouille plus l'avion par défaut, textures en dds.
ok c'est du boulot, il faut un peu plus d'espace disque, mais si le résultat en vaut la peine...
voila, pour mes aventure en dds, j'ajoute que pour ceux qui compilent FG eux-même, que il est possible de faire en sorte que OSG utilise son cache, qui est désactivé pour le moment dans Simgear, ce qui donne des chargement de multiple textures moins gourmand en ram, enfin il me semble ,c'est ici:
http://www.mail-archive.com/flightgear- … 31572.html
il faut changer la ligne 56 de simgear/scene/model/SGPagedLOD.hxx pour remplacer: "CACHE_NONE" par: "CACHE_IMAGES" ou même: "CACHE_ALL"
ensuite recompiler sg + fg et donner votre avis...
jano
Hors ligne
La dernière fois que j'ai essayé les DDS dans FG j'en ai parlé avec Tim MOORE qui m'a affirmé que l'utilisation de mipmap n'avait aucun intérêt car FG utilise son propre système de mipmaping ce qui fait donc doublons avec celui des DDS. Par contre, j'ai testé des DDS sans mipmaping et cela fonctionne aussi. L'avantage, la réduction du poids des fichiers par rapport aux DDS classiques (sauf à utiliser des RGB compressés bien sur)
Solution, l'utilisation du plugin pour Gimp qui fonctionne très bien pour cela mais c'est très long et les avantages à l'utilisation d'un format très lourd à gérer n'est pas franchement une bonne idée à mon avis.
Le seul avantage reste la non compression des fichiers. Chargement plus rapide, mais occupation sur disque plus importante. Cela revient donc à utiliser le format RGB du début. Alors que faire. Régresser pour revenir à des fichiers non compressés plus lourds que les fichiers RGB (et oui avec le mipmaping, à résolution égale, le DDS sera plus lourd que le RGB) ou trouver un programmeur de génie pour optimiser au maximum la routine de décompression PNG (quitte à ne pas utiliser la libraire d'OSG pour cela). Ah autre solution aussi, réduire le nombre d'image utilisées par les avions.
Heu je viens de regarder, je comprend Jano ton soucis avec le F16. En effet sur mon fgdata GIT le F16 est en RGB compressé. Du coup ce n'est pas la décompression du PNG qui est en faute mais la décompression du RGB. Essais donc de convertir les RGB en PNG et dit nous ce que cela donne
La texture globale du F16 en RGB compressée fait 4 Mo. Non compessée elle fait 12 Mo (et oui c'est une 2048x2048). Solution la plus logique et la plus simple, proposer la même en PNG 1024x1024 par défaut et laisser la 2048x2048 en option. Tout le monde y trouvera son compte. Enfin moi, je dis cela, je ne dis rien hein !
Amicalement Emmanuel
Dernière modification par helijah (30/03/2011 20:25:36)
Pourrait-on affichier la texture en 2048×2048 sur son propre avion et en 1024×1024 sur les avions en MP par défaut, pour éviter le lag dès que quelqu'un arrive? Voire modifier la résolution en fonction de la distance? Ou commencer par charger l'image en basse résolution, puis charger la haute résolution en arrière-plan?
Dernière modification par guillaume (30/03/2011 22:41:32)
Debian GNU/Linux Sid
AMD Athlon II X2 250 / RAM 14 Go / nVidia GeForce GTX750
Hors ligne
Probablement, il serait possible de charger l'une ou l'autre des textures en fixant une condition sur le chemin du modèle dans l'arbre des propiétés.
xixi la PraLinZ
Hors ligne
le gain de toute facon serait minime,il ya dix peut etre que cela aurait eu un interet mais aujourd'hui meme les carte graphiques milieux de gamme fournissent une puissance de calcul acceptable.
concernant la compilation de openscenegraph avec differentes options de cachej'ai essayé et en fait je n'ai pas eu de resultat probant.
à vrai dire ce qui bouffe le plus dans fg ce sont les ai du traffic manager(qu'on peut desactiver facilement,on pourra alors apprecier un gain tres significatif),et ca ne vous empecheras pas de voir les autres "vrai joueurs".
Autrement niveau qualité les dds sont excellent.
Hors ligne
pour ceux que ça interesse, j'ai mis quelques avions en dds ici
à décompresser dans un dossier, et utilisez l'option --fg-aircraft= pour donner à fg le chemin ou les trouver, ou l'option des dossiers d'avions de fgrun.
si ce dossierest prioritaire les avions dds seront chargés.
un avantage: l'occupation en ram de FG est réduite (dans les 35M pour le dr400 par exemple), et le chargement est beaucoup plus fluide de même que le changement de livrée.
notez que celà s'applique aussi au textures de sol et aux nuages, qui sont dispos en dds dans les datas de fg, ils faut juste certaines options pour les utiliser.
jano
Hors ligne
Merci !
André. anciennement taureau89_9
Debian Testing Amd64. CM Sabertooth 990FX, FX8350, 32 Go Ram DDR3 1866 Mhz, GTX 1060 6Go, DD 2To Sata 3, THRUSTMASTER T.Flight StickX, FG 2020.4.0 Git.
Hors ligne
Merci jano.
Avec le Concorde en prime aujourd'hui.
Intel I7.7700k 4.2 GHz.CM:MSI Z270 Gaming pro.CG:ASUS GTX 3070 Tuff OC 8Go.Ram:32Go DDR4 GSKILL. 2*SSD 500G 1*M2 500G 1*M2 1T, 2*HDD 2*2T Seagate Baracuda.Alim:Corsair RM750X 80Plus Gold.Ventirad Be quiet pure rock.Boîtier Aérocool GT-S black édition.DVD Asus drw-24f1-mt. Wifi + Bluetooth gigabyte.Dual boot LinuxMint 20.3 Una /Windows10 FG2020.4.0
http://pattenflightgear.wifeo.com/
Hors ligne
ça va assez vite à faire, le script différencie les images (png ou rgb pour l'instant) à couches alpha pour leurs faire un traitement différent,
il me reste à trouver une façon automatique pour les normal maps, (avec une inversion de normale à faire )mais tant qu'elles ne sont pas trop répandues c'est faisable à la main...
si des fois vous voyez des erreurs graphiques non présentes sur le modèle des datas, dites le...
jano
Hors ligne
des nouvelles du front des dds...
c'est bon pour les normal maps, et le résultat ici est meilleur que l'original en .png:
le c172 version .png des datas:
le même c172, converti en .dds, on notera que les normal map sont beaucoup mieux rendues, alors que l'on a juste converti la texture. Un coup de fg qui a du mal à rendre bien les .png en normal map?
une image un peu dézoomée:
pour résumé:
- le chargement est plus rapide, surtout si on a créé des dds qui contiennent les mimaps, donc fg ne les recalcule pas si elles existent.
- l'occupation mémoire vive est moins importante.
- seul inconvénient, certains drivers ne supportent pas les .dds, mais quand ça marche, faut pas se priver.
je donnerai plus de détails pour ceux qui veulent le script bash utilisé pour la conversion, si vous voulez le faire chez vous, mais vu l'heure ce sera une autre fois .
jano
Hors ligne
mais vu l'heure ce sera une autre fois .
Pffff quelle déception ;-)
Magnifique.
FG git - GNU/Linux 64 bits - Quadcore i7500 2,7 GHz - RAM 8 Go + GTX940MX
Hors ligne
http://wiki.flightgear.org/Fr/convertir_un_avion_en_dds
libre à toi de commenter, tester, améliorer , ou de t'en inspirer pour nous fournir des scenery tout dds
jano
Hors ligne
Super mega génial ! Merci jano
OS: Linux Mint 17.1 | RAM: 12Go | GPU: GTX460SE | CPU: Intel I5 | FG: GIT
POIs: DR400-dauphin | FGCom | Jenkins | download_and_compile.sh
Hors ligne
une petite mise à jour, je viens de voir que nvcompress est dispo dans les dépot, (au moins en sid). donc plutot que de le compiler, il suffit d'installer nvtt (ainsi que le -dev) si des fois ça passe avec osg ..
jano
Hors ligne
update du script, qui est plus rapide, et remet à la bonne taille les texture qui ne sont pas en puissance de 2. le c172p se fait en 3 minutes.
le script : dds-conversion
(ou dans ma branche mp de flightgearr: scripts/tools/dds-conversion)
jano
Hors ligne