[FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

Ptipilot · [↑]

BiplanBonplan a écrit :

Pourquoi alors cette entrée existe-t-elle et change en fonction de nouveaux réglages ?... Une fantaisie comme ça des concepteurs / programmeurs de FSX ? Pour faire zoli...

Non, c'est juste une valeur calculée par un algorithme qui prend certains composants de ta machine (CPU, CGU,...).
Cette valeurs est comparée lors de la première installation à un tableau à 7 entrées (si mes souvenirs sont bons....) afin d'autocalibrer ton FSX la première fois.

La petite différence que tu as à chaque lancement sur une même machine est dû au différence de chargement de ta machine à un instant T.

Voili voilou...

BiplanBonplan · [↑]

Ptipilot a écrit :

BiplanBonplan a écrit :
Pourquoi alors cette entrée existe-t-elle et change en fonction de nouveaux réglages ?... Une fantaisie comme ça des concepteurs / programmeurs de FSX ? Pour faire zoli...
Non, c'est juste une valeur calculée par un algorithme qui prend certains composants de ta machine (CPU, CGU,...).
Cette valeurs est comparée lors de la première installation à un tableau à 7 entrées (si mes souvenirs sont bons....) afin d'autocalibrer ton FSX la première fois.
La petite différence que tu as à chaque lancement sur une même machine est dû au différence de chargement de ta machine à un instant T.
Voili voilou...

Merci de ta réponse. La question qui me vient alors à l'esprit : cette auto-calibration peut-elle alors impacter plus ou moins les performances dans FSX en meilleur comme en nettement moins bien ? Par exemple, est-ce qu'un nombre plus élevé correspond à un indice de meilleures performances dans FSX ?

Mais comme tu dis que ça ne sert à rien...

Merci encore.

Cordialement.

Dernière modification par BiplanBonplan (10-04-2013 20:46:14)

Ptipilot · [↑]

BiplanBonplan a écrit :

Mais comme tu dis que ça ne sert à rien...

Louis, si tu ne me crois pas, je t'invite à aller sur le blog de P.T. (le papa du produit...), il l'a expliqué de nombreuse fois...;)

BiplanBonplan · [↑]

Ptipilot a écrit :

BiplanBonplan a écrit :
Mais comme tu dis que ça ne sert à rien...
Louis, si tu ne me crois pas, je t'invite à aller sur le blog de P.T. (le papa du produit...), il l'a expliqué de nombreuse fois...;)

Messie je te crois en tant que le Jesus de ce présent fofo... pour désacraliser certains tweaks

Blague à part, si j'ai bien compris, cette ligne ne sert qu'en tant que "thermomètre" non pas comme ligne d'optimisation des perfs de ta config pour FSX. En gros, ce n'est pas un thermomètre qui fait élever ou baisser la fièvre...

Dernière modification par BiplanBonplan (10-04-2013 17:10:17)

NEPTUNE6P2V7 · [↑]

Ptipilot a écrit :

NEPTUNE6P2V7 a écrit :
AMD phenom 1090T sur crossair IV Extreme le proc est OC 3.9
OS au repos 778 mo utilisé 2%/1% UC utilisé
Merci pour le retour,
Comme nous avons à peu près la même bête (J'ai un 1100T), c'est plus facile d'essayer de comprendre.
bien ouai le tiens de base 3.3 et le miens 3.2 sur 6 coeurs
La seule vrai différence d'utilisation entre nous, c'est au niveau DirectX. Je n'ai pas encore fait de test de cette variable sous Directx 10. Mais à mon sens, il ne devrait pas y avoir d’influence. Je dois le vérifier tout de même lorsque j'aurais le temps...
Je vois que tu overclockes. Est ce que tu utilises la fonction de Turboboost (OC dynamique sur 3 cores) ou bien tu fais un OC statique à la mimine sur tous les cores?...
Alors je passe par le Bios avec la mimine je clock la mem ainsi que la fréquence cpu à 3.6 giga c'est déjà super il faut dire que la CM au niveau BIOS c'est du billard, il suffit de renseigner les timing au lieu de les laisser sur auto, tu as toutes les fréquences sous la main .. Et y a plus qu'à
L'AISUITE II de Assus je ne l'utilise pas car il me colle une erreur quand je veux faire de l'OC via cette interface et toujours pas de réponse sur l'appli chez asus en vue de ma CM donc j'ai abandonné
Au démarrage après le BIOS j'ai activé les 6 coeurs car 4 étaient pris en compte au départ du premier lancement j'utilise donc les 6 Coeurs ensuite pour le Turbo Core je n'ai pas vérifié et j'ai pas de quoi le vérifier, pas penché dessus à vrai dire
donc c'est Brut de pomme ..

NEPTUNE6P2V7 a écrit :
l'utilisation des 6 coeurs est effective et oscille aux même niveaux
C'est cette phrase qui me turlupine, car ce n'est pas le fonctionnement normal de FSX.
Bien oui avec FSX les sinusoïdes tournent à la même fréquence et n'ai pas un coeur plus haut que l'autre comme je le disait L'UC est utilisée au maxi 80% avec FSX , B200, Anchorage PANC, ORBX_SAK, REX MTO + graphismes et FSC9.2
Normalement, tu dois avoir le core qui supporte ton thread principal (plus 3, 4 autres...) qui oscille entre 95 et 100 % et tes 5 autres jouant du YOYO (comme tu dis...=8).
Pourrais tu nous mettre une photo de la situation lorsque tout vas bien pour toi?...
Alors plus tard, car je dois maintenant préparer un vol avec les collègues
ce soir 21 heures
Image de Bélzébuth sur mon Forum je la trouve chouette pour l'event assez doué le GONZ
héhééé fait jour là bas

NEPTUNE6P2V7 a écrit :
avec le bazar MAX_ASYNC_BATCHING_JOBS
bien c'est cata
Là encore, cela étonne au niveau de ton ressenti..
Chez moi, je ne suis pas OC et mon proc tourne à 3.3 GHz.
Pour mes tests sur cette variable, je l'ai fait varier de 0 à 16 en prenant des mesures sur diverses situations.
Malheureusement, comme je le supposais, je n'ai rien pu en tirer de manière significative car je n'arrive pas, avec les outils dont je dispose, à isoler spécifiquement la partie qui m'interresse...
Je pense qu'il faudrait que je monte le SDK DirectX pour cela.;)
Pour l'instant, je l'ai fixée arbitrairement à 3.

BiplanBonplan · [↑]

Bonjour,

Un petit up par rapport au sujet de départ pour FSX en mode affichage DirectX 9 :

I Grâce à MAX_ASYNC_BATCHING_JOBS=2, j'avais pu enfin insérer cette ligne : UsePools=0

Puis d'après ce que j'ai lu, je comprends mieux les meilleurs perfs obtenues, d'après ce site : http://fsxtimes.wordpress.com/2011/09/05/fsx-cfg-bufferpools/

In addition, setting the value to “0" means that the system will completely use the video card memory as texture buffer. This could also bring significant improvements to FSX but may potentially induce artifacts or spikes occasionally.
Also note that this “0" setting is better performed when it is used in combination with:
[BufferPools]
PoolSize=0
ALLOW_SHADER_30=1

Traduction :

En plus, régler la valeur à 0 (pour PoolSize) signifie que le système utilisera complètement la mémoire de la carte vidéo en tant que tampon (buffer) pour les textures. Ceci pourrait apporter des améliorations significatives à FSX, mais pourrait potentiellement induire occasionnellement des artefacts ou des pointes (les fameuses lignes verticales entre ciel et terre... ).
Ainsi, notez que ce réglage est plus efficient quand il est utilisé avec la combinaison : ALLOW_SHADER_30=1

II J'ai donc essayé cette combinaison de réglages :

1) [JOBSCHEDULER]
AffinityMask=14

2) [BUFFERPOOLS]
UsePools=0

3) [GRAPHICS]
ALLOW_SHADER_30=1 ; pour la première utilisation de cette ligne, j'ai fait régénérer le cache des shaders (C:\Documents and Settings\(Nom d'utilisateur de votre session Windows)\AppData\Local\Microsoft\FSX)

4) [Display]
BLOOM_EFFECTS=0

5) [SCENERY]
MAX_ASYNC_BATCHING_JOBS=2

C'est carrément fabuleux en terme de qualité graphique ! Mais c'est par rapport à ma config : iE 2500K à 3.3 GHz et ma CG MSI GTX 560 Ti Twin Frozer.

Avec les réglages suivants :

[GRAPHICS]
//SHADER_CACHE_VERSION=1
ALLOW_SHADER_30=1 Indissociable de usepools=0
AC_SELF_SHADOW=0
AIRCRAFT_REFLECTIONS=1
AIRCRAFT_SHADOWS=0 à cause du traffic GAIT 2.07
COCKPIT_HIGH_LOD=1
D3D10=0
DAY_THRESHOLD=32768
EFFECTS_QUALITY=2
GROUND_SHADOWS=0
HIGHMEMFIX=1
IMAGE_QUALITY=0
LANDING_LIGHTS=1
NIGHT_THRESHOLD=4096
NUM_LIGHTS=8
See_Self=1
SHADER_CACHE_PRIMED_10=1693500674
SHADER_CACHE_PRIMED=1693500674
Text_Scroll=1
TEXTURE_MAX_LOAD=4096
TEXTURE_QUALITY=3
[Display]
RUNWAY_LIGHTS_SURFACE_SCALAR=1.0
RUNWAY_LIGHTS_VASI_SCALAR=0.8
RUNWAY_LIGHTS_APPROACH_SCALAR=0.9
RUNWAY_LIGHTS_STROBE_SCALAR=1.2
ActiveWindowTitleBackGroundColor=0,28,140,64
ActiveWindowTitleTextColor=255,255,255
BLOOM_EFFECTS=0
ChangeTime=4.000000
InfoBrakesEnable=True
InfoLowerLeftBackGroundColor=255,0,0,128
InfoLowerLeftTextColor=255,255,255
InfoLowerRightBackGroundColor=255,0,0,128
InfoLowerRightTextColor=255,255,255
InfoOverspeedEnable=True
InfoParkingBrakesEnable=True
InfoPauseEnable=True
InfoSlewEnable=True
InfoStallEnable=True
InfoUpperRightBackGroundColor=0,0,0,0
InfoUpperRightTextColor=255,0,0
NonActiveWindowTitleBackGroundColor=24,33,87,64
NonActiveWindowTitleTextColor=255,255,255
RUNWAY_LIGHTS_APPROACH_SCALAR=0.9
RUNWAY_LIGHTS_STROBE_SCALAR=1.2
RUNWAY_LIGHTS_SURFACE_SCALAR=1.0
RUNWAY_LIGHTS_VASI_SCALAR=0.8
SKINNED_ANIMATIONS=1
TEXTURE_BANDWIDTH_MULT=40
TextureMaxLoad=9
TransitionTime=4.000000
UPPER_FRAMERATE_LIMIT=30
WideViewAspect=True
[DISPLAY.Device.NVIDIA GeForce GTX 560 Ti .0]
Mode=1280x1024x32
Trilinear=1 en relation avec le taux de rafraîchissement de l'écran à 60Hz et VSync 1/2 refresh dans Nvidia Inspector
[TrafficManager]
AirlineDensity=59
GADensity=59 Impeccable avec GAIT 2.07 (c'est largement suffisant) tant pour avec ou sans ORBX
FreewayDensity=10
ShipsAndFerriesDensity=30
LeisureBoatsDensity=30
IFROnly=0
AIRPORT_SCENERY_DENSITY=3
[TERRAIN]
LOD_RADIUS=4.500000 Voir les commentaires plus bas
MESH_COMPLEXITY=100
MESH_RESOLUTION=23
TEXTURE_RESOLUTION=29
AUTOGEN_DENSITY=5
DETAIL_TEXTURE=1
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1700 Selon ORBX
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=2000 Selon ORBX
WATER_EFFECTS=6

J'ai essayé avec :
[TERRAIN]
LOD_RADIUS=6.500000 C'est carrément top ! Mais hélas sur certaines scènes comme Vancouver+ en combinaison avec PNW d'ORBX et FSDreamTeam, c'est un OOM. J'ai testé plusieurs fois et la scène est clean d'agn manquantes... En revenant à LOD_RADIUS=4.500000 pas d'OOM...

C'est expliqué ici : http://fsxtimes.wordpress.com/2011/08/03/fsx-cfg-lod_radius/#more-1927

visual quality – higher value = wider & clearer the coverage
frame-rate – higher value = lower frame-rate
stutter – higher value = more stutters
memory usage – higher value = more memory consumed (higher risk to OOM crash)
session load-up time – higher value = longer session load-up time

Même souci avec RTMM au départ de PANT (Anette Island) C'est dommage de ne pas pouvoir garder LOD_RADIUS=6.500000 ! Qui pourtant passe très bien avec les villes US Cities d'Aerosoft + les Airports de FSDreamTeam ou FlightBeamStudios ! J'ai même pris le F18 pour aller faire toute la zone de LA jusqu'à Frisco + KSFO ! Aucun OOM sur un vol fait d'un seul tenant ! Idem pour San Diego de Latin VFR...

Consolation avec la combinaison des réglages exposée ci-dessus, la différence visuelle entre LOD_RADIUS=4.500000 et LOD_RADIUS=6.500000 est très atténuée.

Donc, pour une config. similaire à la mienne, MAX_ASYNC_BATCHING_JOBS=2 permet pour le proc., de mieux répartir le charge de travail due aux textures autogénérées ; le proc. est ainsi "plus disponible" pour permettre l'utilisation de la mémoire de la CG pour la mise en tampon des textures avec Usepools=0 + ALLOW_SHADER_30=1. Ce qui se traduit par un énorme gain de qualité graphique. Sur tous les tests d'aujourd'hui, aucune dalle grisâtre avant le chargement de certaines textures, aucun clignotement des nuages REX (HD 4096) ! Et au sol, les textures sont nettes en permanence !

Je vous referai un petit up avec DirectX 10, car je vais le tester à nouveau avec la combinaison de réglages exposée plus haut et le LOD_RADIUS=6.500000.

Bons vols sur FSX

Louis.

Dernière modification par BiplanBonplan (12-04-2013 22:18:07)

Ptipilot · [↑]

Hé bien....
Les ingénieurs qui écrivent le MSDN n'ont qu'a bien se tenir...=WO
:a:a

NEPTUNE6P2V7 · [↑]

Salut Biplanbonplan

Alors pas de HIGHMEMFIX ? peut être ton soucis d'OOM fonctionne en DX 9 D3D 0

les PER_CELL immeubles et arbres sont un tweak ORBX conseillé dans leur PDF . et mange pas de pain

Neptune

Dernière modification par NEPTUNE6P2V7 (12-04-2013 09:37:30)

BiplanBonplan · [↑]

Ptipilot a écrit :

Hé bien....
Les ingénieurs qui écrivent le MSDN n'ont qu'a bien se tenir...=WO
:a:a

... Euh, disons simplement le plaisir de partager son expérience comme la plupart des membres de ce forum. Sans plus.

Merci du compliment

NEPTUNE6P2V7 a écrit :

Salut Biplanbonplan
Alors pas de HIGHMEMFIX ? peut être ton soucis d'OOM fonctionne en DX 9 D3D 0
les PER_CELL immeubles et arbres sont un tweak ORBX conseillé dans leur PDF . et mange pas de pain
Neptune

Salut,

1) Pour HIGHMEMFIX=1, voir la 11 ème ligne de la section [GRAPHICS]
OK, j'ai oublié de la surligner en rouge...

2) Désormais, je peux me passer des tweaks sur les PER_CELL, en terme de Framerate, je n'ai pas de différences avec ou sans. Mais, tu as raison, à réessayer peut-être pour éviter les OOM sur certaines scènes avec LOD_RADIUS=6.5. Car j'ai pu tout de même voler pendant près de 2 heures sans ORBX en ayant aucun OOM. Même avec de l'ORBX natif, pas de souci ; mais dans la région de Vancouver, il y a Vancouver+ 3.0 et FSDreamTeam CYVR... J'en demande un peu trop !... En aillant rétabli le LOD_RADIUS=4.5 je n'avais plus du tout d'OOM sur cette même zone. Même souci avec RTTM puisque tu as ORBX, Tonguass Fjords et un peu de SAK maintenant. Mais sur SAK absolument aucun problème à 6.5

Merci de ce conseil judicieux, je vais retester avec et je ferai un petit up.

Je reviendrai après sur DirectX 10.

EDIT : pour les OOM, je pencherais pour le mélange de scènes de concepteurs différents, qui techniquement parlant interagissent parfois plus ou moins bien...

Dernière modification par BiplanBonplan (12-04-2013 12:16:48)

NEPTUNE6P2V7 · [↑]

Salut dans le Vancouver que j'ai pas

c'est suggestion, ils ont certainement mit une partie photo- réa dans leur scène et je sais pas s'il y aurait moyen de la désactiver car ORBX utilise déjà cette méthode et de plus retravaillée et cette superposition , pourrait à mon sens être un kill aux FPS du à la double lecture des fichiers superposés

Mais n'ayant pas la scène je peux pas allez plus loin
A mon avis tu peux faire des essais dans les .bgl scenery de CYVR ..!

voila j'ai trouvé en fait c'est des .bgl de ORBX qu'il faut mettre en .ORIG et non PAS la scène de FSdream TEAM

par
DAVE_YVR de AVSIM http://forum.avsim.net/topic/397650-cyvr-file-deletes/
Posted 22 January 2013 - 05:45 AM
Look in your ORBX\FTX_NA\FTX_NA_PNW05_SCENERY\scenery folder and find the 3 files that have CYVR in them.

Regardes dans ton Fichier ORBX\FTX_NA\FTX_NA_PNW05_SCENERY\scenery et tu trouves dedans 3 lignes qui sont nommées CYVR qu'il faut désactiver
et cela résout le problème d'OOM

Neptune

Nirgal76 · [↑]

Par contre, c'est dommage de baisser l'autogen à 3 (Normal ?) et d'enlever les tweaks.
ces tweaks servent justement à diminuer le nombre d'autogen en zones denses sans toucher aux zones moins denses. Alors qu'en baissant dans les réglages FSX, tu diminue leur nombre partout.

cf. un de mes post précédent sur le sujet :
http://www.pilote-virtuel.com/viewtopic … 04#p361504

Dernière modification par Nirgal76 (12-04-2013 12:29:57)

BiplanBonplan · [↑]

@Neptune et Nirgal76,

Merci les amis, je vais voir tout cela.

Neptune, à priori tu as bien formulé intuitivement le problème pour Vancouver. Pour RTTM, il faudrait que je fouille sur leur fofo... Le problème doit être certainement + ou - analogue à celui de Vancouver (?)...

Encore merci.

Je vous tiens au jus.

Dernière modification par BiplanBonplan (12-04-2013 12:31:26)

BiplanBonplan · [↑]

... Super ton post sur les Per_Cell, Nirgal76.

Thank you very much

Oui, l'Autogen à 3, c'est quand j'utilise une zone ORBX, sinon il est au maxi hors zone ORBX. J'utilise 2 profils de réglages pour FSX.cfg : un pour ORBX, un autre sans ORBX. Mais j'ai bien compris la démarche logique de ton post. Je vais (ré)essayer ça.

Cordialement.

Louis.

Dernière modification par BiplanBonplan (12-04-2013 12:38:21)

NEPTUNE6P2V7 · [↑]

BiplanBonplan a écrit :

@Neptune et Nirgal76,
Merci les amis, je vais voir tout cela.
Neptune, à priori tu as bien formulé intuitivement le problème pour Vancouver. Pour RTTM, il faudrait que je fouille sur leur fofo... Le problème doit être certainement + ou - analogue à celui de Vancouver (?)...
Encore merci.
Je vous tiens au jus.

j'espère que tu as mis les RTMM déclaré au dessus des ORBX NA comme la DER biblio de Xavier, moi j'ai tout et ça, tire pas sur les FPS ni d'OOM

Nadine alias Handie aussi les a tous les RTMM ... et jusqu' alors elle ne se plein pas sur ces OOM dans la région Tongas comme moi

Neptune

bizzy · [↑]

@ biplanbonplan

les textures HD de rex en situation d'overcast sa te mange pas la moitié de tes FPS ?

BiplanBonplan · [↑]

NEPTUNE6P2V7 a écrit :

voila j'ai trouvé en fait c'est des .bgl de ORBX qu'il faut mettre en .ORIG et non PAS la scène de FSdream TEAM
par
DAVE_YVR de AVSIM http://forum.avsim.net/topic/397650-cyvr-file-deletes/
Posted 22 January 2013 - 05:45 AM
Look in your ORBX\FTX_NA\FTX_NA_PNW05_SCENERY\scenery folder and find the 3 files that have CYVR in them.
Regardes dans ton Fichier ORBX\FTX_NA\FTX_NA_PNW05_SCENERY\scenery et tu trouves dedans 3 lignes qui sont nommées CYVR qu'il faut désactiver
et cela résout le problème d'OOM

Neptune

Merci. Je l'avais fait le jour même où j'avais installé CYVR. De tout façon, en ayant rétabli LOD_RADIUS=4.5 je n'ai plus d'OOM. En fait, je voudrais trouver le moyen de pouvoir conserver le lOD_RADIUS=6.5 (plus zoli) sans avoir d'OOM sur certaines scènes... Je ne rêve pas trop, car je pense, que c'est la puissance informatique qui est déjà un peu limite...

Je vais bien voir de toute façon.

NEPTUNE6P2V7 a écrit :

j'espère que tu as mis les RTMM déclaré au dessus des ORBX NA comme la DER biblio de Xavier, moi j'ai tout et ça, tire pas sur les FPS ni d'OOM
Nadine alias Handie aussi les a tous les RTMM ... et jusqu' alors elle ne se plein pas sur ces OOM dans la région Tongas comme moi
Neptune

Je vois que nous faisons partie du club très fermé de tout ceux qui possèdent tout RTMM (fabuleux)! Bien sûr que c'est au-dessus de tout ce qui est d'OZx et d'ORBX :

RTMM
CIRP (que je n'active qu'en hiver)
OzX
ORBX

Mais, là encore aucun souci d'OOM si je reviens au LOD_RADIUS=4.5. donc j'en déduit dans les 2 cas (Vancouver et RTMM) que ce n'est pas un problème d'installation.

Je vais déjà voir en revenant sur le tweak ORBX des PER_CELL... Moins d'Autogen sur les 2 zones en question moins de mémoire qui sature...

bizzy a écrit :

@ biplanbonplan
les textures HD de rex en situation d'overcast sa te mange pas la moitié de tes FPS ?

Bonsoir Bizzy,

Incroyable mais vrai, REX n'a jamais sur ma config fait chuter les FPS, (même avec un orage violent avec un ciel complètement couvert) contrairement à tout ce que j'ai lu comme témoignages que je ne mets bien sûr pas en doute. Remarque : je limite le FPS à 30... Je verrai alors certainement une chute de FPS si je comparais en FPS illimité entre les différents résolution des nuages de REX. Sur du FSX natif avec UTX + GEX, en cambrousse je suis constant entre 29.9 et 30 FPS. ORBX en zone urbaine dense 16 à 22 FPS ; en cambrousse avec ORBX 29.9 à 30 FPS constant...

Je peux toujours tester avec des résolutions de nuages plus basses avec le LOD_RADIUS=6.5 peut-être que les OOM disparaîtront sur certaines zones... A voir.

Merci de ton message

Bons vols à vous tous.

Dernière modification par BiplanBonplan (12-04-2013 17:13:31)

BiplanBonplan · [↑]

Bonsoir,

Je pense avoir atteint un idéal de rendu graphique par rapport à ma config. du moins pour l'affichage en DirectX 9

J'ai appliqué à la lettre les conseils de Nirgal76, MERCI à lui, pour les "Per_Cell", ce qui me permet avec ORBX de mettre le curseur de densité de l'Autogen à fond à droite ! Sans perte de FPS !

Pour le LOD_RADIUS=4.5, j'ai (re)testé sur les zones à problèmes, aucun OOM. Par contre à 6.5, ça ne passe pas, car il faut bien l'admettre ma config ne le permet pas. Le 6.5 fonctionne quand même sur le FSX natif avec UTX + REX et l'écrasante majorité des scènes que j'ai installées.

Pour moi il est indéniable que ces 2 réglages :
[BUFFERPOOLS]
UsePools=0
[GRAPHICS]
ALLOW_SHADER_30=1 je confirme qu'à la première utilisation il faut faire régénérer le cache des shaders (C:\Documents and Settings\(Nom d'utilisateur de votre session Windows)\AppData\Local\Microsoft\FSX)
Apportent un modelé incroyable aux paysages survolés : perception des reliefs sous l'avion (hors montagne) plus accentuée même en haute altitude, magnifique contrastes des couleurs... A tel point que le LOD_RADIUS à 4.5 est plus que très acceptable ! Bien sûr le LOD_RADIUS=6.5 c'est sublime, notamment pour les lointains !
Et surtout aucune dalle noire qui précède le chargement des textures. Les textures restent nettes constamment en VFR. Tout en me permettant un traffic GAIT 2.07 à 59 % ! Ce qui soit dit en passant est largement suffisant sur ORBX !

J'ai mis ce post à jour en fonction de tout ce que je viens de vous exposer.

Maintenant, il ne este plus qu'à affiner tout cela avec l'Aperçu DirectX 10

Louis.

Dernière modification par BiplanBonplan (12-04-2013 22:45:39)

Daube · [↑]

Le LOD_RADIUS a 4.5 acceptable ? Je ne suis pas de cet avis.
Par contre, je crois que tu disais que tu utilisais les shaders alternatifs pour FSX c'est bien ca ? Ce serait eux qui impacteraient le rendu des montagnes distantes ?
Tu pourrais nous montrer ca avec un screenshots ? Avec un zoom de 0.70 hein, pas 0.50...

Pour ma part le LOD_RADIUS a 6.5 est un minimum pour les scènes "normalles", mais sur les scènes de FranceVFR par exemple, je pousse ce parametre a 8.5 sans soucis. J'ai 6 Go de RAM dans mon ordi et j'ai configure le fichier d'echange de Windows a une taille fixe de 2 Go.

En revanche, sur les scènes OrbX le LOD_RADIUS a 8.5 est un peu trop gourmand, surtout lorsque la meteo commence a etre chargee... Dans ces conditions, la valeur de 6.5 offre une meilleure balance entre rendu distant et fluidite chez moi.

Pour finir, les tweaks ..._PER_CELL sont connus depuis des annees. Ca me surprend que tu ne les aies jamais utilises jusqu'à maintenant ? Super utiles, notemment sur OrbX. A noter que pour les buildings, meme une valeur tres basse comme 400 ou 600 donne déjà un rendu sympathique. Pour les arbres, vu la densite des forets dans PNW, il ne faut pas descendre trop bas. 1500 c'est une bonne base pour les tests.

axis360 · [↑]

Pour ma part le LOD_RADIUS a 6.5 est un minimum pour les scènes "normalles"

C'est quoi les scènes normales pour toi ? J'utilise GEX UTX et j'ai essayé de mettre le LOD RADIUS à 6.5 et je ne vois pas de différence au sol ça devrait être plus net à 6.5 que 4.5 ? enfin la j'arrête pas de changer je met toujours au même endroit et franchement je vois pas différence c'est bizarre

Daube · [↑]

Pour les textures du sol, avec des textures génériques tu verras tres peu de différences. Surtout si tu voles en régions plates.

En revanche si tu passes aux régions montagneuses, la difference visuelle de niveau de detail de la forme des montagne a moyenne distance est flagrante: les montagnes sont moins lissees, leurs reliefs sont plus precis qu'avant.

Et c'est encore plus flagrant avec des textures photorealistes, dont les flouttages distants sont bien visibles sur les montagnes lorsqu'on utilise un LOD_RADIUS a 4.5. Encore plus flagrant si on utilises un zoom entre 0.70x (mon zoom en cockpit virtuel) ou plus, genre 1.0x (vue exterieure de l'avion). Avec un LOD_RADIUS plus important, les zones lointaines sont plus detaillees, les meshs plus precis, les textures plus nettes.

Par "scènes normalles", je voulais simplement dire "pas OrbX".
Les textures et scènes OrbX sont ce qu'il y a de plus lourd dans le monde de FSX. Les scènes photorealistes de France VFR, meme lorsqu'on ajoute de l'autogen par-dessus, sont beaucoup plus legeres, moins gourmandes, et chargent beaucoup plus vite. C'est également le cas avec les dernieres scènes de France VR avec la technologie 3DAutomation.

axis360 · [↑]

D'accord c'est bien ce qui me semblait c'est beaucoup orienté sur Orbx mais oui moi en effet j'utilise que GEX et UTX et en effet sur du génériques pas de différence merci de la précision.

Dernière modification par axis360 (13-04-2013 00:35:28)

Daube · [↑]

Non non, t'as pas compris ce que j'ai ecrit.
Meme sur du generique, il y AURA une difference FLAGRANTE. Mais tout dependra de la region survolee.
Sur une region plate, le genre de plaines interminables a perte de vue, pour voir la difference il faudra zoomer un peu.
Quelqu'un qui survole une telle region avec un zoom 0.50 dans le VC (comme moi il y a quelques mois encore), ne verras pas la difference.
La meme personne volant depuis le VC avec un zoom a 0.70 verra bien la difference.
La meme personne volant en vue exterieure avec un zoom a 1.0x verra parfaitement la difference.

Et pour ce qui est des régions montagneuses, surtout si on a un bon mesh, alors meme avec un zoom a 0.50 la difference sautera aux yeux.

axis360 · [↑]

ah oui d'accord alors moi je vol en 2D zoom 0.40
et je fais très peu voir jamais de vue exterieure donc peut être pour ça

BiplanBonplan · [↑]

Daube a écrit :

Le LOD_RADIUS a 4.5 acceptable ? Je ne suis pas de cet avis.
Pour ma part le LOD_RADIUS a 6.5 est un minimum pour les scènes "normalles", mais sur les scènes de FranceVFR par exemple, je pousse ce parametre a 8.5 sans soucis. J'ai 6 Go de RAM dans mon ordi et j'ai configure le fichier d'echange de Windows a une taille fixe de 2 Go.
En revanche, sur les scènes OrbX le LOD_RADIUS a 8.5 est un peu trop gourmand, surtout lorsque la meteo commence a etre chargee... Dans ces conditions, la valeur de 6.5 offre une meilleure balance entre rendu distant et fluidite chez moi.
Pour finir, les tweaks ..._PER_CELL sont connus depuis des annees. Ca me surprend que tu ne les aies jamais utilises jusqu'à maintenant ? Super utiles, notemment sur OrbX. A noter que pour les buildings, meme une valeur tres basse comme 400 ou 600 donne déjà un rendu sympathique. Pour les arbres, vu la densite des forets dans PNW, il ne faut pas descendre trop bas. 1500 c'est une bonne base pour les tests.

... Voici ce que j'ai écrit dans mon dernier post de la soirée :

Pour le LOD_RADIUS=4.5, j'ai (re)testé sur les zones à problèmes, aucun OOM. Par contre à 6.5, ça ne passe pas, car il faut bien l'admettre ma config ne le permet pas. Le 6.5 fonctionne quand même sur le FSX natif avec UTX + REX et l'écrasante majorité des scènes que j'ai installées.

C'est pourtant très clair...

De plus dans FSX.cfg LOD_RADIUS=4.500000 est la valeur par défaut. Honnêtement avec l'optimisation de mon FSX.cfg, je ne vois pratiquement pas de différence entre un LOD_RADIUS=4.500000 et un LOD_RADIUS=6.500000

Si tu as une configuration qui te permet un LOD_RADIUS jusqu'à 8.500000... sans OOM quelque soit la scène survolée, ma foi, j'en suis ravi pour toi.

Daube · [↑]

En 2D avec un zoom 0.40 ???
Ah ok, tu utilises un multi-ecran avec des instruments deportes (voir meme un vrai cockpit externe?) alors ?

Personnellement, ca doit faire environs 10 ans que j'ai plus touche le moindre panel 2D pour piloter
(je parle de cockpit 2D, pas des panels annexes pour commander certaines fonctions, comme un load manager ou les panel de dommages moteurs, evidemment). Mais je ne vole que sur un seul ecran 16/10, j'ai pas de cockpit externe, pas la place, pas assez d'ecrans, pas l'interet, etc...

Quoi qu'il en soit, avec un zoom aussi faible, effectivement tu ne dois pas trop voir les flouttages des textures distantes et les lissages des reliefs distants. Par contre, pour le pilotage ca doit etre coton non ? Déjà qu'en zoom 0.50 je voyais les trucs arriver au dernier moment (la distortion du zoom fausse la perception des distances et des vitesses de rapprochement...), alors en 0.40...

#76 [↑][↓] 10-04-2013 14:53:43

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#77 [↑][↓] 10-04-2013 14:59:08

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#78 [↑][↓] 10-04-2013 15:03:20

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#79 [↑][↓] 10-04-2013 15:09:31

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#80 [↑][↓] 10-04-2013 19:45:29

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#81 [↑][↓] 11-04-2013 22:25:28

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#82 [↑][↓] 12-04-2013 08:11:23

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#83 [↑][↓] 12-04-2013 09:34:18

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#84 [↑][↓] 12-04-2013 12:05:13

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#85 [↑][↓] 12-04-2013 12:22:13

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#86 [↑][↓] 12-04-2013 12:26:26

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#87 [↑][↓] 12-04-2013 12:31:04

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#88 [↑][↓] 12-04-2013 12:35:14

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#89 [↑][↓] 12-04-2013 13:26:02

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#90 [↑][↓] 12-04-2013 15:50:45

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#91 [↑][↓] 12-04-2013 17:03:32

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#92 [↑][↓] 12-04-2013 22:41:20

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#93 [↑][↓] 12-04-2013 23:39:22

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#94 [↑][↓] 13-04-2013 00:15:18

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#95 [↑][↓] 13-04-2013 00:21:41

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#96 [↑][↓] 13-04-2013 00:32:23

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#97 [↑][↓] 13-04-2013 00:36:52

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#98 [↑][↓] 13-04-2013 00:43:22

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#99 [↑][↓] 13-04-2013 00:55:32

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

#100 [↑][↓] 13-04-2013 00:57:53

Re : [FSX]Améliorations possibles grâce à MAX_ASYNC_BATCHING_JOBS...

Pied de page des forums