[FSX] Textures au sol floues.

harlock73 · [↑]

ce qui m ennuie c'est que j'ai beau tout essayer j'ai toujours ce flou c 'est tres genant .

harlock73 · [↑]

salut
bon ca y est ca a l'air regler , jai appliquer les meme reglages que mick pour ma gtx 280 puis

[BufferPools]
PoolSize=10000000
TEXTURE_BANDWIDTH_MULT=40
UPPER_FRAMERATE_LIMIT=0
FIBER_FRAME_TIME_FRACTION=1.33
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=600
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=600

voila comme ca je n'ai plus de flou avec un zoom reduit a 0.70 en vue externe et parfait en vc avec ou sans zoom.

j'oscille entre 25,30fps avec des monter a 55 environs sans descendre sous les 25 .....=)
voila merci a tous .

Ptipilot · [↑]

harlock73 a écrit :

salut
bon ca y est ca a l'air regler , jai appliquer les meme reglages que mick pour ma gtx 280 puis
[BufferPools]
PoolSize=10000000
TEXTURE_BANDWIDTH_MULT=40
UPPER_FRAMERATE_LIMIT=0
FIBER_FRAME_TIME_FRACTION=1.33
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=600
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=600
voila comme ca je n'ai plus de flou avec un zoom reduit a 0.70 en vue externe et parfait en vc avec ou sans zoom.
j'oscille entre 25,30fps avec des monter a 55 environs sans descendre sous les 25 .....=)
voila merci a tous .

Je suis content pour toi, et je vois que les valeurs retenues rentrent plus dans les normes de bon sens...

Néanmoins, j'ai encore un peu de mal avec une de tes valeurs!...

Le FIBER_FRAME_TIME_FRACTION=1.33

J'ai repris les écrits de Phil sur le sujet et je te les ai traduit (Comme apparement, tu n'aimes pas la langue de Sheckspir...)

Remarques (Pour les puristes de l'anglais)
Je n'ai volontairement pas modifier l'ordonnancement des phases (Je suis resté en construction anglaise...)

Par contre, si j'ai fait une erreur de traduction, n'hésitez pas à me le dire car je ne suis malheureusement pas bilingue.=O

------------------------------------------
Posted: Friday, May 11, 2007 1:54 AM by Phil Taylor

So let’s start with the mysterious sounding FIBER_FRAME_TIME_FRACTION.
Donc, commençons avec le mystérieux FIBER_FRAME_TIME_FRACTION

Now we hope people don’t hurt themselves with settings that deeply affect the engine like this, because there is always the possibility of misuse. Usually that is outweighed by the value of being informed, and the great thing about the community is sometimes interesting questions do crop up out of people using these settings.
Maintenant, nous espérons que les personnes ne feront pas de mal avec les paramètres de ce genre qui affectent profondément le moteur, car il y a toujours la possibilité d'un emploi abusif. Habituellement qui est compensé par la valeur d'être informé, et la grande chose au sujet de la collectivité est parfois intéressant de faire surgir des questions de personnes utilisant ces paramètres.

Christian Buchner, author of TileProxy, recommended that Win64 users of TileProxy set FIBER_FRAME_TIME_FRACTION to 2.0 when the base value is .33. A lot of speculation about what that would be doing cropped up.
Christian Buchner, auteur de TileProxy, a recommandé que les utilisateurs Win64 de TileProxy ajustent le FIBER_FRAME_TIME_FRACTION à 2,0 quand la valeur de base est ,33. Beaucoup de spéculations concernant cela feraient leurs apparitions.

Here are 2 quotes from Adam (Adam Szofran, our resident terrain guru), verbatim:
Voici les 2 citations d'Adam, reproduit exactement:

FIBER_FRAME_TIME_FRACTION determines the maximum amount of time per frame that we will run fiber jobs on the primary thread. We measure how long it took to simulate and render and then multiply that time by FIBER_FRAME_TIME_FRACTION to determine how long to run the fibers.
For example, if it took 10 milliseconds to simulate and render and FIBER_FRAME_TIME_FRACTION was set to the default value of 0.33, then we would allow the fibers on the primary thread to run for up to 10 * 0.33 = 3.3 milliseconds. For fraction values of 1.0 and 2.0, the time given to fibers would be 10 milliseconds and 20 milliseconds, respectively.
FIBER_FRAME_TIME_FRACTION détermine la quantité maximum de temps par image que nous exécuterons les tâches de fibres (fiber jobs) sur le thread primaire. Nous mesurons combien de temps cela a pris à simuler et à interpréter et alors nous multiplierons ce temps par FIBER_FRAME_TIME_FRACTION pour déterminer sur combien de temps les tâches de fibres s'étendent.
Par exemple, si cela a pris 10 millisecondes afin de simuler et à interpréter et que FIBER_FRAME_TIME_FRACTION était réglé à la valeur par défaut de 0,33, alors nous accorderions les fibres sur le premier thread à s'étendre pour une durée maximum de 10 * 0,33 = 3,3 millisecondes.
Pour les ratios de valeurs de 1.0 et 2.0, le délai accordé aux fibres serait respectivement de 10 millisecondes et 20 millisecondes.

The operation of FIBER_FRAME_TIME_FRACTION on single core machines has not changed since RTM.
Le fonctionnement de FIBER_FRAME_TIME_FRACTION sur les machines simple-core n'a pas changé depuis la RTM.

On multi-core machines in SP1, we moved many fiber jobs off of the primary thread and onto secondary threads. Since FIBER_FRAME_TIME_FRACTION only affects scheduling of jobs on the primary thread, it will have less of an impact on the performance of Flight Sim on multi-core machines. In fact, we moved so many jobs off of the primary thread that there probably isn’t enough fiber work left to soak up the full time allowed by the default value of 0.33.
Sur des machines multi-core dans le SP1, nous avons éloigné un grand nombre de tâches de fibre du thread primaire et sur le thread secondaire. Puisque FIBER_FRAME_TIME_FRACTION ne touche que la planification des tâches sur le premier thread, il aura moins d'impact sur les performances de Flight Sim sur les machines multi-core. En fait, nous avons éloigné tellement de tâches du thread principal qu'il n'y a probablement pas assez de travail de tâches de fibres en attente pour absorber la totalité du temps autorisé par la valeur par défaut de 0,33.

Therefore, on multi-core machines, there’s very little reason to tweak the fraction because it really only impacts performance of single core machines.
Par conséquent, sur les machines multi-core, il y a très peu de raison de modifier le ratio parce qu'il impact seulement la performance des machines simple core.

and

Please emphasize the pointlessness of tweaking this value on multi-core machines.
Pour appuyer sur l'inutilité de modifier cette valeur sur les machines multi-core.

Further, setting it to values greater than the default value on single-core machines can increase frame rate volatility because it increases the amount of time we *might* allocate to fibers if there is adequate work waiting in the queue. When the queue is full, we’ll allocate the full amount of time to fibers but when the queue is empty, fibers get no time because there is no work to do. If the rate of new jobs entering the fiber queue is bursty and the full time allowed for fibers is large, then you can imagine how this would increase volatility.
En outre, le régler à des valeurs supérieures à la valeur par défaut sur des machines simple core peut augmenter la volatilité du taux d'image, car il augmente la quantité de temps que nous * pourrions * allouer aux tâches de fibres si il y a un travail suffisant en attente dans la file d'attente. Lorsque la file d'attente est pleine, nous allouerons la quantité maximale de temps aux taches de fibres, mais quand la file d'attente est vide, les tâches de fibres n'obtiennent aucune allocation de temps puisqu'il n'y a pas de travail à faire. Si le taux de nouvelles tâches entrant dans la file d'attente fibre est par rafale et que le temps autorisé pour des fibres est grand, alors vous pouvez imaginer comment cela accroîtrait la volatilité.

Remarque personnelle : La suivante est ma préférée!....

[large]If people feel like the fibers aren’t getting adequate resources, they would be better off leaving the fiber fraction alone and just lowering the frame rate limit slider, which helps divert more CPU time to primary thread fibers without increasing volatility.
Si les personnes se sentent d'humeur que les tâches de fibres ne reçoivent pas les ressources suffisantes, ils feraient mieux de foutre la paix au ratio de fibres et juste abaisser le curseur du taux d'image, lequel aidera à détourner plus de temps CPU vers le thread primaire fibre sans accroissement de la volatilité.[/large]

I'd take those words as golden.
Je prendrais ces mots comme or.

Dernière modification par Ptipilot (11-04-2012 15:31:18)

aldem · [↑]

confirmation par le programmeur de "Ground environnement X"...

http://forums1.avsim.net/index.php?s=892b55fbfc5123d46f60929c06309f28&showtopic=241915&st=50

harlock73 · [↑]

ah oui j'ai mis en fiber 0.10 et la c'est surprenant plus aucune textures ne chargent c'est deja charger

pventu · [↑]

Bonjour à tous, j'atterris sur cet excellent forum que je parcours en visiteur depuis quelques temps.

J'ai également fait un chemin de croix pas possible sur le net pour essayer d'éradiquer ces fichues textures floues. J'ai tout récemment upgradé ma config avec un proc. Intel quad 9650 + 4 Go de mémoire sans que le problème ne soit résolu (j'avais déjà une carte video Nvidia 8800 GTX).

J'avais bien entendu essayé toutes les modifs habituellement suggérées du fsx.cfg (TEXTURE_BANDWIDTH_MULT et autres FIBER_FRAME_TIME_FRACTION...) sans résultat probant.

Une amélioration significative est apparue via un paramètre assez peu cité sur le net et paramétré ainsi par défaut :

[TERRAIN]
LOD_RADIUS=4.500000

Ce paramètre définit apparemment le rayon dans lequel les textures sont préchargées (et donc nettes ?). Je l'ai positionné à 9.500000 suite à quoi, après un temps de chargement plus long au démarrage de FSX, mes textures sont nettes (Zoom à 0.50). Je n'ai rien modifié d'autre dans le fsx.cfg d'origin. Cela dit, je n'ai sans doute pas encore été victime des éventuels effet collatéraux liés à l'ajustement de ce paramètre.

Attention, plus on augmente la valeur de ce paramètre plus on consomme de mémoire. J'ai essayé à 15.00000, la mémoire explose et fsx émet un message avant sa fermeture. Il convient également de neutraliser l'autogen consommateur de mémoire.

Deux copies d'écran (portion de vallée de Champagny photoréaliste réalisée avec FSearthTiles)

Avant :

Après :

Patrick

Dernière modification par pventu (05-04-2009 16:08:38)

harlock73 · [↑]

ca a l'air de le faire quelqu'un a tester ??
chez moi ca change rien pour ainsi dire.

Dernière modification par harlock73 (05-04-2009 19:42:15)

Ptipilot · [↑]

pventu a écrit :

Ce paramètre définit apparemment le rayon dans lequel les textures sont préchargées (et donc nettes ?). Je l'ai positionné à 9.500000 suite à quoi, après un temps de chargement plus long au démarrage de FSX, mes textures sont nettes (Zoom à 0.50).

Tes photos ne sont pas significatives, car elles sont prises de haut et sans éléments qui chargent le CPU et le GPU (autogènes...).

Les concepteurs du produit ont limité l'interface graphique de paramétrage de cette variable aux valeur suivantes :

[TERRAIN]
LOD_RADIUS=x
Rayon des détails du terrain
2.500000 = Petit
3.500000 = Moyen
4.500000 = Large

Il y a peut être une raison ???????????.......................=S

Dans FS, tous les réglages sont des [large]compromis[/large], puisqu'ils s'interfèrent les uns avec les autres !....=)

Dernière modification par Ptipilot (06-04-2009 09:09:31)

pventu · [↑]

Çà c'est clair qu'il s'agit de compromis. Je cherche à obtenir une netteté maximale des scènes photoréalistes bien évidemment au détriment d'autres paramètres sur lesquels je suis prêt à faire des concessions. Je constate une différence significative avec ce paramètre LOD_RADIUS réglé à 9.5 ou 8.5 ce qui dans mon cas particulier et de mon point de vue constitue un progrès par rapport à ma quête. Mais je n'ai sans doute pas encore été confronté aux effets collatéraux sur d'autres paramètres.

Patrick

Ptipilot · [↑]

pventu a écrit :

Çà c'est clair qu'il s'agit de compromis. Je cherche à obtenir une netteté maximale des scènes photoréalistes bien évidemment au détriment d'autres paramètres sur lesquels je suis prêt à faire des concessions. Je constate une différence significative avec ce paramètre LOD_RADIUS réglé à 9.5 ou 8.5 ce qui dans mon cas particulier et de mon point de vue constitue un progrès par rapport à ma quête. Mais je n'ai sans doute pas encore été confronté aux effets collatéraux sur d'autres paramètres.
Patrick

Patrick,

je te renvoi à la conclusion de Phil Taylor contenue dans le .pdf des blurries:

If this is the type of blurry you experience, it’s not some flaw in SP1, but the result of the combination of all the choices we have made, and the way the math and hardware work. So stop worrying about this type of blurry and enjoy the flying!

pventu · [↑]

Le mieux étant l'ennemi du bien, tu as raison Ptipilot, je vais peut-être finalement me mettre à voler plutôt que de passer 90% de mon temps au tuning et 10% au vol !

Patrick

Benmars · [↑]

J'arrive après la guerre, je sais ...

Daube a écrit :

Sur un Dual core, l'affinity mask ne sert a rien.
On s'en sert sur un quad core pour dire a FSX d'eviter le core qui est utilise par Windows, et donc de ne tourner que sur les trois autres cores. Sur un Dual core, tu ne veux SURTOUT PAS que FSX ne tourne sur un seul core n'est-ce pas ;)
Donc effaces immediatement la ligne de l'affinity mask.

Je ne suis absolument pas d'accord avec cette affirmation.
L'affinity mask permet aussi de faire tourner tous les cores, en particulier avec un dual core pour éviter que l'un bosse pendant que l'autre glande.
Donc, que ce soit pour mon ex E6550 ou mon E8500 maintenant,
- sans : 1 core à 100% en permanence, l'autre glande, avec le 6550 très difficile de sortir de fsx et d'y revenir (pc qui mouline un temps fou avant de donner la main)
- avec : les 2 bossent ensemble, à des % plus raisonnables.
Copies d'écran à l'appui si besoin.

Conclusion :
[JOBSCHEDULER]
AffinityMask=3
indispensable pour un Dual Core. Tu remarqueras que cette valeur oblige à l'utilisation des 2 cores.

Dernière modification par Benmars (25-04-2009 17:03:38)

Daube · [↑]

Benmars a écrit :

J'arrive après la guerre, je sais ...
Daube a écrit :
Sur un Dual core, l'affinity mask ne sert a rien.
On s'en sert sur un quad core pour dire a FSX d'eviter le core qui est utilise par Windows, et donc de ne tourner que sur les trois autres cores. Sur un Dual core, tu ne veux SURTOUT PAS que FSX ne tourne sur un seul core n'est-ce pas
Donc effaces immediatement la ligne de l'affinity mask.
Je ne suis absolument pas d'accord avec cette affirmation.
L'affinity mask permet aussi de faire tourner tous les cores, en particulier avec un dual core pour éviter que l'un bosse pendant que l'autre glande.
Donc, que ce soit pour mon ex E6550 ou mon E8500 maintenant,
- sans : 1 core à 100% en permanence, l'autre glande, avec le 6550 très difficile de sortir de fsx et d'y revenir (pc qui mouline un temps fou avant de donner la main)
- avec : les 2 bossent ensemble, à des % plus raisonnables.
Copies d'écran à l'appui si besoin.
Conclusion :
[JOBSCHEDULER]
AffinityMask=3
indispensable pour un Dual Core. Tu remarqueras que cette valeur oblige à l'utilisation des 2 cores.

Avec le SP2, il n'y a pas de cores qui glandent.
L'affinity mask n'est pas utilise pour forcer un core a travailler, mais plutot pour l'en empecher. Le but principal etant d'empecher FSX de tourner sur le core 0, qui est deja occupe par Windows et ses process.
Il ne faut pas regarder les cores a l'arret mais en vol, pendant que l'on avance (donc pas en pause ni en transposition).
Si on ne place pas d'affinity mask, tous les cores seront utilises, en tous cas avec le SP2. C'est sense etre le cas avec le SP1 egalement.
Sur mon Q6600, je n'ai pas d'affinity mask, et a partir du moment ou mon avion est en mouvement, tous les 4 cores travaillent pratiquement a 100%.

#51 [↑][↓] 02-04-2009 11:51:02

Re : [FSX] Textures au sol floues.

#52 [↑][↓] 02-04-2009 23:36:15

Re : [FSX] Textures au sol floues.

#53 [↑][↓] 03-04-2009 16:27:50

Re : [FSX] Textures au sol floues.

#54 [↑][↓] 03-04-2009 17:41:07

Re : [FSX] Textures au sol floues.

#55 [↑][↓] 03-04-2009 19:15:32

Re : [FSX] Textures au sol floues.

#56 [↑][↓] 04-04-2009 15:26:21

Re : [FSX] Textures au sol floues.

#57 [↑][↓] 05-04-2009 19:34:20

Re : [FSX] Textures au sol floues.

#58 [↑][↓] 06-04-2009 08:59:53

Re : [FSX] Textures au sol floues.

#59 [↑][↓] 06-04-2009 21:10:40

Re : [FSX] Textures au sol floues.

#60 [↑][↓] 07-04-2009 07:33:53

Re : [FSX] Textures au sol floues.

#61 [↑][↓] 07-04-2009 19:27:23

Re : [FSX] Textures au sol floues.

#62 [↑][↓] 25-04-2009 17:01:55

Re : [FSX] Textures au sol floues.

#63 [↑][↓] 25-04-2009 20:45:15

Re : [FSX] Textures au sol floues.

Pied de page des forums