J'ai lu ces divers posts mais ca n'explique en rien le delai a la mise a jour des dalles.

Bonjour Daube

Problème bien connu (trop connu ) avec lequel je me bats depuis une éternité.
Tellement de choses ont été dites, écrites, pour essayer d'y remédier. Mais tu les connais sûrement comme moi !
Il me semble toutefois (j'en suis même certain maintenant, du moins pour mes configurations) que trois points sont incontournables :
1) La puissance du processeur. C'est l'élément premier, et le plus important de tous. Mais j'ai le sentiment que ta configuration n'est pas en cause. Sauf à avoir réellement une "bête de course", ce problème de floutage revient et reviendra toujours, quels que soient les tweaks essayés et installés. Notre ami Filipo s'est longuement et excellemment expliqué avec moi là-dessus autrefois.
2) Un élément peut-être un peu moins connu (et en tous cas davantage discuté, mais je t'assure qu'il est évident pour moi) : la quantité de données indexées dans le fichier scenery.cfg. Je te précise bien que l'élément important n'est pas (du moins pour moi, je le répète) le nombre de scènes indexées (nombre d'entrées dans le fichier scenery.cfg), mais la quantité de données que le simulateur doit charger à l'ouverture de la session. Ainsi, j'ai pu déterminer empiriquement, qu'au delà de 200/250 GA de données chargées au lancement du soft, ce sont non seulement le temps de chargement initial qui est allongé (là-dessus, tout le monde est d'accord, je crois), mais aussi le temps de chargement des textures durant le vol. D'où un floutage nettement plus marqué, à réglages et scènes conservées strictement identiques par ailleurs, qu'avec moins de données chargées (= moins de scènes).
3) L'adjonction d'AGN augmente sensiblement le phénomène de floutage des scènes photoréalistes. J'ai pu maintes fois expérimenter la chose, en faisant des tests comparatifs grâce à la technique des scenery.cfg sectorisés. Et ici, je te/vous livre une remarque plus personnelle mais qui me semble pouvoir être un peu utile : j'utilise 2 PC avec FSX, dont l'un (qui me sert plutôt pour tester, ou/et qui m'est seulement disponible durant mes longs séjours en Bretagne, mon "gros" PC étant trop encombrant à déménager...)) est réellement une antiquité bourrine (mais en excellent état de marche : AMD Athlon 64 - Processor 3400+, 2,40GHZ avec 1,50 Ga de RAM - interdit de rigoler !!! ).
Eh bien, en volant très lentement (sur l'ULM par défaut de FSX, ou avec un hélico, ou mieux encore, en Zeppelin ! ), et sans aucune adjonction d'AGN, j'obtiens des conditions tout à fait satisfaisantes de vol en 1m pixel, et qui restent encore très exploitables en 0,50cm (+ 0,25cm pour certaines grandes villes). Or tout le monde sait ici que je suis un fanatique des scènes photoréalistes faites maison sous FS Earth Tiles, en résolution super-détaillée (que j'avoue nettement préférer au "merge" classique : résolution moindre + AGN, pour des raisons multiples que j'ai dites plusieurs fois ailleurs : en particulier le problème de surdimensionnement des arbres, signalé récemment par un autre ami simmeur, auquel je suis très sensible aussi. Un peu (beaucoup) aussi l'aspect "cartoon" des éléments du décor sur les villes. Mais c'est une question de goût, je sais...). Je fais toutefois une exception pour les seules zones aéroportuaires qui ne modifient pas sensiblement ce que je décris ici.
3) Lors de différents tests portant sur le LOD-RADIUS, qui est par défaut pour moi à 4.500.000, j'ai constaté, qu'en  montant à 6.500.000, j'obtenais certes une netteté du décor sur une zone plus étendue en avant de l'avion (encore que le phénomène ne m'apparaisse pas toujours très, très évident...). En revanche, j'ai noté plusieurs fois, et cette fois de façon très évidente, le phénomène que tu signales : chargement des textures sous l'avion devenu cette fois plus lent, et tendance plus marquée au floutage sur la zone proche, alors que la zone lointaine devenait (un peu) plus nette qu'avec un réglage à 4.500.000. La raison pour laquelle je suis revenu, pour finir, au réglage par défaut du LOD_RADIUS, - et cette fois sur mes 2 PC.
Voilà... Rien de très original dans tout ça,j je le sais parfaitement.
C'était juste pour comparer nos expériences et (peut-être) faire avancer un peu le schmilblick
Sous réserve de discussion et d'approfondissement...
Bien cordialement à toi et à tous.
Jean-Yves

Dernière modification par platoplotinus (19-02-2013 06:14:39)

Il parle de Landclass custom, pas de scènes photo...

Daube a écrit:

...
- Max_async_batch_jobs = 12 ou 16 je sais plus

Pourrais-tu expliciter ce paramètre stp ? Je ne crois pas l'avoir vu aupauravant... C'est la syntaxe exacte ?
Merci

Dernière modification par gpf (19-02-2013 14:26:20)

C172 a écrit:

Il parle de Landclass custom, pas de scènes photo...

et bien sa carte graphique il doit l'OC ou passer à une catégorie SUP ou en mettre deux en SLI  sa fréquence est basse

le problème est de vouloir plus avec le moins  ou alors se résigner par rapport à ce que l'on a et pas jouer dans l'empirique

à savoir que même avec de l'OC à 5 giga n'est pas une fin en soit  depuis 2006 on arrivait à jouer avec FSX à partir de 2coeurs  proc et des CG série8xxx gtx pour les + performantes à l'époque et déjà on tweakait avec le site de José Altuve  dans le .cfg

On a bien évolué en matériel et composant ,  la bête FSX est  un ogre financier  de part son architecture et écriture de l'époque ... P3D est un compromis , mais là c'est pareil la firme ne peut pas allez au delà de ses espérances pour passer aux DX supérieur du simulateur ..

il est sur qu'en TRANSPO à mach 2  FSX va assoir plus d'une machine performante actuel
j'ai fait l'essaie de DAUBE pousser quelques instant en Y  il est bien à noter que lors de la reconstruction suite à l'arret ou vois bien les plaques se reformer le lissage reprendre ses volumes et l'autogen réapparaitre même la texture de l'avion y passe
Pour moi quelques secondes 4/5 tout au plus  .sur ORBX .

voila pour mon retour avec mon PC et composants

Neptune

Pour ma part à moi, j'ai mis un Radius à 8.5, c'est nette sur quasiment tout l'écran.
Comparé à un Radius en 6.5, il y a un gain important. Sur les scènes photos les textures se chargent instantanément.
Par contre j'ai limité mes textures en 2048.
La carte graphique je pense joue pour beaucoup à ce niveau là.
Je serais curieux de voir le résultat avec une GTX680 et GO de mémoire et pousser le Radius à 10 ou 11.

Didier.

bizarrement avec mon vieux q9650 et ma 5850 j'étais plutôt content.

Mais en bidouillant quelque chose j'ai les dalles très proche de l'avion qui se chargent maintenant tres tard. (je dirais même que c'est plutôt le Mesh qui tarde a se loader).

Entre temps j'ai défragmenter avec O&O defrag en mode COMPLETE/Access. je me demande si ca n'a pas mis le Bronx dans FSX...

Rebonjour à tous

Je rebondis sur le post de Vegasparis, à la fois pour confirmer ce qu'il précise, et vous (re)poser une (deux) question(s).
Sur mon pc le plus puissant, évoqué plus haut (AMD Phenom(tm)IIX4 365 ; 3,42 GHZ, 3,25Go de RAM - Carte graphique : NVIDIA Ge Force GTX 460) - pas une réelle bête de course, mais pas trop mal quand même ! - je tourne le plus souvent en monoécran 21 pouces CRT, parfois couplé avec un 15 pouces pour affichage de la carte FSMovingMap, sous une résolution de 2048X1532X32 pour l'écran principal, et une résolution de 1024X768X32 pour l'écran auxiliaire. Et j'ai tenté l'expérience de monter le LOD_RADIUS à 8.500.000. Cette fois, la différence est vraiment spectaculaire, même par rapport au LOD_RADIUS=6.500.000, et sans effets pervers notoires à l'affichage. Aucun effet réellement négatif constaté, ni au niveau des FPS, ni au niveau du chargement des textures (à part un léger accroissement du temps de chargement, si le second écran est couplé, et parfois certaines mini saccades). Donc rien que de très normal, du moins en qui concerne l'affichage, et le déroulement général de la session.
Toutefois, comme je l'ai déjà signalé dans un post précédent, un problème se pose pour moi  si je cherche à réaliser une capture d'écran (effectuée avec la touche "V") : de façon un peu aléatoire, mais qui reste néanmoins très répétitive (et devenant quasiment constante si je décide de coupler les textures photorealistes avec des fichiers AGN), un message d'erreur s'affiche, m'indiquant que la capture d'écran n'a pas pu être effectuée.
Je précise qu'il s'agit d'une constatation certes purement "empirique" (pas d'explication technique à fournir), mais néanmoins parfaitement certaine, car le fait de revenir au LOD_RADIUS=6.500.000 fait disparaître le phénomène, sans aucune exception constatée. Et bien évidemment, c'est à l'identique (sans aucun problème constaté) si je reviens au LOD par défaut = 4.500.000. Une seule donnée constituant peut-être une piste pour comprendre : sous cette résolution et avec le LOD_RADIUS à 8.500.000, le poids de la capture d'écran, lorsqu'elle réussit, est de 15Mo... Ceci explique peut-être cela ?
Avez-vous de votre côté constaté un phénomène du même genre ? Et, éventuellement, avez-vous une explication précise à apporter ?
Merci d'avance pour vos réponses, ainsi que pour toutes les interventions constituant ce topic, toutes très éclairantes
Bien cordialement à tous.
Et bons vols de milieu de semaine.
Platoplotinus

Dernière modification par platoplotinus (20-02-2013 13:41:00)

Le LOD_RADIUS n'a strictement aucun effet sur la taille du fichier de la capture d'ecran.
C'est la resolution de ton ecran de jeu qui va determiner la taille de la capture.

Avec un CFG par defaut c'est encore pire. Gros delais parce que l'autogen n'est plus limite, gros artefacts parce que le BufferPools et le TBM ne sont plus adaptes, etc... D'une maniere generale, le comportement de FSX avec un CFG par defaut a toujours ete totallement catastrophique.

Re-re-bonjour à vous tous

Et d'abord toutes mes excuses, pour la faute de frappe (maintenant rectifiée...) : mon écran principal est un CRT de 21 pouces (déjà pas mal lourd à déménager à bout de bras... ), et non un 29 pouces...
Merci ensuite pour ta réponse JardY, et, pour la question que tu me poses, oui je suis sous WindowsXP.
J'ai Windows7 sur mon portable (où FSX fonctionne très bien). Mais c'est un écran 17 pouces (seulement), et donc pas de problèmes de ce côté là, ni d'ailleurs sur mon gros PC fixe, dès l'instant où je baisse la résolution, même avec le LOD_RADIUS maintenu à 8.500.000. Ce qui va dans le sens de ce que tu m'indiques Daube. Merci à toi aussi.
Ceci suggère en effet que le problème est lié à cette résolution extrême, et au poids de l'image quand on effectue la capture d'écran sous cette résolution. Mais la même résolution extrême conservée avec un LOD-RADIUS cette fois diminué supprime aussi l'effet de bloquage. Ce qui me conduit à penser que c'est en fait plutôt l'association des deux paramètres (résolution extrême + LOD_RADIUS à 8.500.000) qui produit le problème décrit.
Mais pas question pour moi de passer sous Windows7 sur le gros PC. Car j'ai aussi des logiciels plus anciens installés sur cette machine (et même un FS98 auquel j'aime bien revenir de temps en temps, pour la nostalgie... ! ) qui risqueraient, eux, de ne pas du tout apprécier la modernisation...
En tous cas, merci encore pour les précisions apportées, et la piste de solution indiquée.
Et bien cordialement à tous.
Platoplotinus.

Dernière modification par platoplotinus (20-02-2013 13:55:53)

Sur ma configuration ça va plus vite de sauvegarder puis de relancer le vol plutôt que de faire pause et attendre le chargement des textures floues. je trouve que ça montre qu'il y a un soucis quand même car pendant un pause, FS n'a en principe plus grand chose à faire et les 2 temps devrait être équivalents.

bon, ce n'est plus à prouver que :
1 - un moteur de simulation de vol comme FS à des tonnes de choses à faire entre chaque frame, et ça force l'admiration quand on y pense.
2 - celui de FS est loin d'être le meilleur dans le domaine de l'optimisation. Là c'est une histoire de pognon/délai pour faire le produit.