Vous n'êtes pas identifié(e).
Bonjour à tous,
Depuis plusieurs mois, je cherche à pouvoir profiter pleinement des incroyables scènes 3d automation FVFR.
Mon principal problème étant qu'au bout de qq minutes les textures sol ne chargent plus assez vite et je suis obligé de mettre en pause, parfois plusieurs minutes (!) pour en quelques sortes "rattraper le retard".
J'ai cherché dans beaucoup de directions sans grand résultats, je ne détaillerais pas ici, vous allez vous endormir .
A tel point que j'ai fini par admettre que ma config hardware n'est pas assez musclée, j'ai même commencé à lorgner sur l'overclocking, c'est vous dire...
Et puis en parcourant les forums ici et là je suis tombé sur le fameux FIBER_FRAME_TIME_FRACTION, rubrique [Main] du fsx.cfg.
D'après les explications trouvées sur Avsim, ce serait la portion de temps allouée au chargement des textures sol.
Si on considère que 1.0 est 100% du temps disponible pour le calcul complet d'une image (toutes opérations cumulées), la valeur par défaut de FIBER_FRAME_TIME_FRACTION est de 0.33, soit environ 33% du cycle complet. (c'est le cas si cette variable n'est pas déclarée dans le fsx.cfg).
Donc me voilà à augmenter le FIBER_FRAME_TIME_FRACTION jusqu'à 0.5 pour essayer de corriger mon problème, et là plus j'augmentais, pire c'était ! Encore plus de flou et beaucoup plus de saccades , l'inverse de ce que j'attendais. J'ai donc passé du temps à essayer beaucoup de valeurs, en utilisant à chaque fois la scène du havre, considérée comme "lourde", pour référence.
La meilleure valeur pour moi est à 0.1, et ça m'a changé ma vie fsx ! Mon problème de chargement de textures a (presque entièrement) disparu et j'ai trouvé une très bonne fluidité. Avec ma petite config, je tourne maintenant devant la ville du Havre à 30 fps (limité en externe) avec les 2 curseurs autogen à fond à droite !! Bien sur en mode VFR à ~100 noeuds (pas en mirage 2000)
Mon interprétation (ne demandez pas, je n'ai aucune preuve ) :
Le temps alloué par le FIBER_FRAME_TIME_FRACTION ne concerne que le transfert des textures depuis le moteur fsx vers la carte graphique. Tout le reste : temps d'accès disque, chargement dans le moteur, conversions, application du mesh, etc... n'est PAS exécuté dans ce laps de temps. Du coup, l'augmenter était contre productif pour moi, car c'est tout le reste des calculs qui était pénalisé, y compris les accès disque.
J'ai lu qq part que le codage fsx a commencé vers 2005. il est évident que le hardware a beaucoup changé depuis, a tel point que les codeurs ne pouvait pas l'imaginer. Le transfert de texture entre cpu et CG par un bus AGP n'a rien de commun avec ce qu'on a aujourd'hui.
Limite de la méthode : j'ai essayé de descendre sous 0.1 et j'ai retrouvé mes problèmes. j'en conclue donc que sous 0.1 la valeur n'est plus prise en compte et le 0.33 par défaut est appliqué. C'est bien dommage...
Afin que vous puissiez comparer, je vous donne un peu ma config (déjà dépassée) :
I5-750 à 2.66GHz non overclocké, NVidia GTX460, Win7 x64
FSX Acceleration, j'utilise DirectX10 avec les shaders de Steve en V3.2.2, limiteur 30fps dans NVidia Inspector (illimité fsx), textures mode "haute qualité" et 1/2 refresh rate VSync.
Voilà , à vous d'essayer J'ai enfin pu visiter l'Alsace 3D hier dans de bonnes conditions, un pur bonheur.
En espérant ne pas avoir réinventé l'eau tiède
Dernière modification par rolby (06-01-2013 11:25:56)
Hors ligne
Bonjour rolby,
Intéressant ton approche, personnellement, j'en avait tiré la conclusion inverse LOL, j'avais fait mes essaies sur une scène orbx dans la région de seattle, 0.4 me donnait des saccades, 0.3 c'est flou par moment, 0.11 FPS au planchet, mais au bout de 30 sec c'était tellement flou que je n'avais même plus d'autogen !!!
Donc, pour moi je laisse sur la valeur par défaut, mais je vais regarder de plus prêt les avis des autres simeurs.
Dominique.
Dernière modification par Nouls (30-12-2012 14:24:47)
I7 4790K 4Ghz - Gtx 970 - Gtx 1070 - 16Go Ram - W10 64 - Track-ir -Saitek : yoke, palonnier, radio & switch - P3D V4
Hors ligne
Hors ligne
j'utilise aussi ce setting et depuis que j'ai déplacé le répertoire texture, effets, ORBX et airplaine de mon FSX sur un SSD, j'ai une fluidité presque parfaite sans flou
Amat Victoria Curam
i7 14700k / Arctic Liquid Freezer III 420 / ASUS ROG STRIX Z790-E GAMING WIFI II / MSI 4080 Super GAMING X SLIM/ Trident Z5 7200 64Go / m.2 MP700 pro et 990 PRO / TM Warthog + TPR / Honeycomb Alpha&Bravo / mini FCU / TIR 5 / etc, etc, etc...
Hors ligne
Je précise aussi que j'ai supprimé [JOBSHEDULER] et son AffinityMask. Mes 4 coeurs sont toujours bien utilisés (toujours à fond ). Je crois que Win7x64 le gère bien tout seul.
Le but de l'affinity mask n'est pas de force FSX a utiliser les cores, car il le fait tres bien tout seul.
Le but, c'est d'empecher le moteur de jeu principal de FSX de tourner sur le core0 ou se trouvent egalement tous les processus de Windows.
En desactivant le core0 grace a l'affinity mask, FSX se retrouve generalement sur le core1, ou il n'y a rien, et du coup on gagne un peu de FPS.
Pour l'affinity mask, je vais refaire un essai avec 0.1. J'avais moi aussi fait des essais avec des valeurs plus grandes mais je ne voyais jamais aucun effet, a tel point que j'ai fini par croire que FSX ignorait totallement ce tweak...
Core i7 8700k, 32 Gb de RAM, NVidia GTX 1070-ti, Windows 10 64, Casque VR Pico 4
Hors ligne
Test non concluant. Le simu est plus fluide, mais les floutages sont trop importants.
Core i7 8700k, 32 Gb de RAM, NVidia GTX 1070-ti, Windows 10 64, Casque VR Pico 4
Hors ligne
Et a combien sont fixes tes tweaks du texture_bandwith_mult et swap_wait_timeout ?
Core i7 8700k, 32 Gb de RAM, NVidia GTX 1070-ti, Windows 10 64, Casque VR Pico 4
Hors ligne
Bonjour,
Un peu spéciale votre approche du FFTF: déjà mainte et mainte fois discuté, ce paramètre ne se règle "pas tout seul". Il dépend d'un certain nombre d'autres facteurs tel que: votre proc, le type de textures FSX utilisées, le TBM, le Bufferpools entre autres...... Impossible de se calquer sur un seul réglage ! Je vois vraiment pas comment il est possible de comparer des configs aussi variées.
Malgré tout merci pour feedback.
Cédric
Hors ligne
Bonjour,
Un peu spéciale votre approche du FFTF: déjà mainte et mainte fois discuté, ce paramètre ne se règle "pas tout seul". Il dépend d'un certain nombre d'autres facteurs tel que: votre proc, le type de textures FSX utilisées, le TBM, le Bufferpools entre autres...... Impossible de se calquer sur un seul réglage ! Je vois vraiment pas comment il est possible de comparer des configs aussi variées.
Malgré tout merci pour feedback.
Cédric
Je ne doute pas que ces réglages soient interdépendants et difficiles à interpréter. Toutefois, je constate un flou persistant, surtout avec FVFR, et je lis sur ce forum que quelqu'un un tweak qui a marché chez lui.
Empiriquement, j'essaye, si ça marche je garde si ça marche pas je fais marche arrière.
Là ça a marché, tant mieux, je ne m'explique pas pourquoi.
@Daube
pas de variable texture_bandwith_mult et SWAP_WAIT_TIMEOUT a été enlevé avec //
Hors ligne
@bandini : le but n'est pas de dire "tout le monde doit faire ce réglage". Comme le titre l'indique, c'est une réflexion que chacun peut (ou non) expérimenter. Chacun sait qu'aucune config n'est identique et que de (trop) nombreux paramètres sont interdépendants. Si déjà ça permet d'améliorer chez certains d'entre nous, c'est déjà bien non ?
Chez moi également, le problème concerne essentiellement les dernières scènes FVFR. J'aimerais d'ailleurs bien savoir pourquoi ? => mesh précis à 4.2 m ? Compression (et décompression obligatoire) des textures ?
Sur mes scènes FSET à 1m/pixel (non compressée) + autogen de domsimu et gropied, pas de soucis. Quelles différences ?
Pour info la variable "texture_bandwith_mult" n'est utilisée que si le frame rate est limité DANS fsx. Si UPPER_FRAMERATE_LIMIT=0, elle ne sert pas. La mécanique est bien expliquée sur Avsim par Jesus Alltuve (2010). En tout état de cause, ça ne participe qu'au calcul du débit maximum pour le chargement des textures.
Je ne connais pas SWAP_WAIT_TIMEOUT.
Hors ligne
@bandini : le but n'est pas de dire "tout le monde doit faire ce réglage". Comme le titre l'indique, c'est une réflexion que chacun peut (ou non) expérimenter. Chacun sait qu'aucune config n'est identique et que de (trop) nombreux paramètres sont interdépendants. Si déjà ça permet d'améliorer chez certains d'entre nous, c'est déjà bien non ?
Chez moi également, le problème concerne essentiellement les dernières scènes FVFR. J'aimerais d'ailleurs bien savoir pourquoi ? => mesh précis à 4.2 m ? Compression (et décompression obligatoire) des textures ?
Sur mes scènes FSET à 1m/pixel (non compressée) + autogen de domsimu et gropied, pas de soucis. Quelles différences ?Pour info la variable "texture_bandwith_mult" n'est utilisée que si le frame rate est limité DANS fsx. Si UPPER_FRAMERATE_LIMIT=0, elle ne sert pas. La mécanique est bien expliquée sur Avsim par Jesus Alltuve (2010). En tout état de cause, ça ne participe qu'au calcul du débit maximum pour le chargement des textures.
Je ne connais pas SWAP_WAIT_TIMEOUT.
Ok. Je vous laisse à ces considérations. Pour moi le FFTF=0.1 est un réglage optimal depuis longtemps. Je ne dispose pas de scènes FranceVFR, donc je ne peux rien dire à ce propos, il est vrai. Par ailleurs la limitation des fps en externe ne donne rien de bon chez moi: certes les frames sont "meilleurs" mais les saccades aussi augmentent.
Bon 31 Ã tous !
Cédric
Hors ligne
Pour clôturer le sujet (en ce qui me concerne) je suis passé sur Prepar3D 1.4.
C'est plus beau - couleur, contraste des textures -, mais surtout plus fluide avec ma petite config non OC.
Je peux enfin profiter du FVFR 3DA avec un LOD_RADIUS Ã 5.5, magnifique.
Par contre je suis très surpris de voir dans la doc officielle P3D des propositions de "tuning" issues d'Avsim et du travail de "Jesus".
Ces gens là (Lockeed Martin) sont censés disposer du code source, mais ne semblent pas savoir réellement l'effet de certains paramètres du prepar3d.cfg.
Toujours est-il que j'ai du ajouté entre autre le fameux high_mem_fix, tel que proposé dans la doc.
Bizarre, vous avez dit bizarre
[img align=C]http://rolby.free.fr/Exchange/Prepar3D.jpg[/img]
Dernière modification par rolby (06-01-2013 11:34:28)
Hors ligne
Bonjour,
Ben...je dois retourner à l'école... je croyais que c'était le système d'exploitation qui affectait les processeurs aux processus selon un algorithme de priorité! Un programme ne se contentant que de créer des process ou threads par différentes techniques. L'Affinity Mask étant un élément permettant d'informer le "dispatcher" du système d'exploitation des noyaux à utiliser en priorité mais sans exclusions! Je n'imaginais pas FSX gérant directement les unités de traitement (cores). Bon, c'est vrai que, ringard, j'ai plus souvent utilisé les "fork" et "pipe" qu'autre chose...l'age sans doute !
Cordialement,
JMC
Ps : Bien que mon affinity mask soit à 14, avec Occitania, à basse altitude, avec un lod radius exhubérant, et à l'approche d'Alès....les 4 cores sont utilisés même si, ailleurs, seuls sont utilisés les 1,2,et 3. Je n'ai pas activé l'hyperthreading.
Hors ligne