En fait avons nous eu le choix? On n'a pu suivre que l'évolution de nos simmus:  FS9 > FSX > P3D pour lesquels nous avons déjà investi BEAUCOUP (trop).
Repartir à zéro n'est pas au programme pour moi, à moins d'une réelle révolution!

ben oui mais quand on change de bagnole,de PC ,de matos de pêche, de téléphone, de matos de skis ....on rachète bien des trucs neufs ou d'occas.  pour aller avec notre '' nouvelle'' passion ...le matos de jeu -  simu c'est un peu pareil non ?

le vrais ''piège'' de  l'offre c'est  le marketing , le business , le smartphone à 1000€ qui fait guère mieux que celui à 300 ou 400  j'en sais qq. chose  je suis le premier à tomber dans le panneau même si je me calme

Ce qui compte c'est la passion de la chose ,l'envie aussi de posséder un truc esthétiquement beau qui correspond a un moment de ta vie , de tes envies ...de tes confrontations...de tes mauvais moments aussi...

après on s'en donne les moyens ou bien comme dit Magnum on fait le choix du stop, j’arrête les frais...


affaire de pépettes , d 'envie , d'age ,

et parce qu'on ne vit qu'une fois ( je crois ) 

heu je me suis peut être un  peu égaré  là ...

Dernière modification par androl2015 (19-12-2016 12:27:04)

Je partage l'avis de Magnum. Un "nouveau" simu en 64b que ce soit P3D ou DG FS va obliger à repasser à la caisse pour bon nombres d'addons (y en a qui vont en profiter pour s'en mettre plein les fouilles au passage genre pmdg, orbx, etc.) pour un apport qui au final va être négligeable (surtout la limitation de mémoire liée à l'appli 32b qui sautera).
Bref entre l'allégement du porte monnaie et la réinstallation du bouzin (pour peu que les scènes existantes soit réadaptées), la balance a plutôt tendance à pencher du côté de "ça tourne très bien et ça m'a couté suffisamment cher comme ça pour pas que j'aille voir ailleurs".

Dernière modification par Pilote95 (19-12-2016 16:15:08)

C'est sur que si on n'a pas d'OOM il n'y a aucune raison de passer à un P3D 64bits.

Les prochaines plateformes 64 bits (y compris XPlane) autoriseront un niveau de detail (pas seulement visuel) tres superieur a ce qui est possible sur FSX ou Prepar3D 3, le tout sans pour autant bouffer du CPU (si tant est que les moteurs graphiques soient adaptés).

Les deux ne sont pas reliés, ou très peu.

Daube a écrit:

Les prochaines plateformes 64 bits (y compris XPlane) autoriseront un niveau de detail (pas seulement visuel) tres superieur a ce qui est possible sur FSX ou Prepar3D 3, le tout sans pour autant bouffer du CPU (si tant est que les moteurs graphiques soient adaptés). En realite, lorsque des addons serieux apparaitront sur ces nouveaux simus, les simulateurs actuels vont paraitre bien fades

C'est deja un peu visible aujourd'hui d'ailleurs. Il suffit de se poser en helico au beau milieu de l'autogen urbain d'XPlane 11 pour avoir envie de pleurer lorsqu'on fait de meme dans FSX ou Prepar3D. Et tout ceci ne fera qu'empirer.

Il ne faut pas oublier que P3D comme DG FS sont basés sur le code de FSX avec toutes les limitations que ça impose qu'en bien même le code soit grandement retouché/optimisé. Ca tournera certainement un poil mieux, est-ce que ça justifie pour autant de repasser à la caisse ? Ça...

Pour l'autogen quand tu fais de l'ifr et tu passes la majorité de ton temps à 30 000+ft tu t'en balances un peu d'avoir un plein de trafic/batiments/jesaispasquoidautres. Il n'y a pas la limitation liée au VAS avec XP du fait de son archi 64b, cela étant dit je ne suis pas certain que les fps ne morfleraient pas avec l'équivalent qu'on peut utiliser sur P3D/FSX (active sky, rex, orbx, grosses scènes etc etc).

Après comme on dit chacun voit midi à sa porte...

Pilote95 a écrit:

Daube a écrit:

Les prochaines plateformes 64 bits (y compris XPlane) autoriseront un niveau de detail (pas seulement visuel) tres superieur a ce qui est possible sur FSX ou Prepar3D 3, le tout sans pour autant bouffer du CPU (si tant est que les moteurs graphiques soient adaptés). En realite, lorsque des addons serieux apparaitront sur ces nouveaux simus, les simulateurs actuels vont paraitre bien fades

C'est deja un peu visible aujourd'hui d'ailleurs. Il suffit de se poser en helico au beau milieu de l'autogen urbain d'XPlane 11 pour avoir envie de pleurer lorsqu'on fait de meme dans FSX ou Prepar3D. Et tout ceci ne fera qu'empirer.

Il ne faut pas oublier que P3D comme DG FS sont basés sur le code de FSX avec toutes les limitations que ça impose qu'en bien même le code soit grandement retouché/optimisé. Ca tournera certainement un poil mieux, est-ce que ça justifie pour autant de repasser à la caisse ? Ça...

Il y a des limitations mais pour la plupart on ne connais pas leur raison.
Certaines limitations sont aussi dues aux nombreuses restrictions imposees par le 32 bits et la quantite de memoire limitee, ce qui force a faire un code parfois plus complexe que necessaire. En programmation, l'economie a un cout non-negligeable en performances.
Ca ne veut pas dire que la conversion en 64 bits va, comme par magie, ameliorer les performances. Mais la conversion en 64 bits plus le nettoyage des economies couteuses et superflues pourraient grandement ameliorer les perfs, oui. Mais difficile de savoir ce que les devs vont vraiment faire ou pas.

Pour l'autogen quand tu fais de l'ifr et tu passes la majorité de ton temps à 30 000+ft tu t'en balances un peu d'avoir un plein de trafic/batiments/jesaispasquoidautres. Il n'y a pas la limitation liée au VAS avec XP du fait de son archi 64b, cela étant dit je ne suis pas certain que les fps ne morfleraient pas avec l'équivalent qu'on peut utiliser sur P3D/FSX (active sky, rex, orbx, grosses scènes etc etc).

Après comme on dit chacun voit midi à sa porte...

L'autogen c'etait un simple exemple parmis tant d'autres. Si tu avais lu tous les mots de mon message (mais bon, tu as du le survoler en IFR...), tu aurais peut-etre compris que je ne parlais pas seulement de qualité visuelle, mais de complexité en general, que ce soit pour les scenes, les avions, ou la simulation en elle-meme.

Avec un raisonnement comme le tiens, on continue de voler sur FS9.

Dernière modification par Daube (19-12-2016 17:46:37)

Daube a écrit:

L'autogen c'etait un simple exemple parmis tant d'autres. Si tu avais lu tous les mots de mon message (mais bon, tu as du le survoler en IFR...), tu aurais peut-etre compris que je ne parlais pas seulement de qualité visuelle, mais de complexité en general, que ce soit pour les scenes, les avions, ou la simulation en elle-meme.

Tu parles d'ifr je réponds sur le même exemple. Et je n'ai jamais parlé de qualité visuelle......

Daube a écrit:

Avec un raisonnement comme le tiens, on continue de voler sur FS9.

Pas la peine de prendre les gens de haut. Mon raisonnement vaut bien le tien...

Dernière modification par Pilote95 (19-12-2016 18:38:42)

Zangdaarr a écrit:

Le truc c'est que les gens ne cherchent pas à avoir de jolis graphiques. Ils cherchent à voir leur maison.
Et ça XPlane ne l'offre pas. Orbx oui. C'est leur métier.

?? La je ne suis pas. ORBX propose tres largement du landclass. Les textures sont adaptees, mais ca reste du generique. A l'opposee X-Plane, s'il utilise aussi une technique type landclass, base son autogen sur des donnees OSM, ce qui n'est pas le cas d'ORBX.

Donc tu as nettement plus de chances de trouver ta maison sous XP que sous ORBX...

Dernière modification par n666eo (19-12-2016 18:52:40)

Bonsoir,

En effet, il y a de quoi devenir une girouette ! quelle sera la tendance ?
Ne pas perdre de vue l'essentiel : se faire plaisir en réalisant des vols avec nos avions préférés et pour le moment mon FSX remplit bien sa tache, je ne vois pas réellement une plateforme se démarquer, prudence donc : "wait and see"

Guillaume

Zangdaarr a écrit:

Je n'ai absolument aucune idée de ce dont tu parles, voudrais tu développer un peu ?

Lorsque tu developpes un programme, tu dois faire des choix de "balance" entre les perfs et la consommation memoire.
Je donne un exemple a la con, ensuite j'en donnerai un autre plus centre sur le monde de FS.

- Exemple 1
Je fais un programme qui doit traiter une tres grosse quantite de données, qui sont stockées soit dans un fichier, soit dans une base de donnees, on s'en fout. On parle de plusieurs gigas de données. Le programme doit lire les données, faire des trucs, des modifications ou n'importe quoi avec, et ensuite les sauvegarder quelque part (au meme endroit ou ailleurs, on s'en fout). La lecture et l'ecriture coutent tres cher (c'est lent), le traitement est super rapide.

Je pourrais juste lire toutes les données d'un coup, les traiter et les ecrire en une seule fois. Ce serait le moins cher en termes de temps. Sauf que j'ai pas assez de memoire pour faire ca, pour x raisons (32 bits, ou autres). Donc la seule alternative, c'est de lire les donnees petit à petit, de traiter chaque petit paquet et de le sauvegarder à chaque fois, puis nettoyer ma memoire pour avoir l'espace necessaire pour charger le prochain paquet à traiter. Dans cette optique, je consomme moins de memoire, mais je fais plusieurs lectures et ecritures, qui coutent tres cher. Resultat, mon programme ne plante pas, mais il tourne lentement. Si j'avais eu suffisamment de memoire, j'aurais pu tout faire d'un coup sans m'emmerder a ecrire un programme compliqué qui lit en plusieurs fois.

- Exemple 2
Dans FSX ou P3D, le moteur graphique doit charger le terrain et l'afficher à l'ecran.
On pourrait charger directement toutes les tuiles du terrain, jusqu'a une distance suffisante (c'est a dire, pas le globe tout entier), avec l'autogen et la texture directement a la bonne resolution. Mais en fait non, si on fait ca ca plante avec un bel OOM.

Alors, a la place, on charge seulement les tuiles super proches a la bonne resolution, et celles qui sont un peu plus loin a une resolution plus faible, puis encore plus loin avec une resolution encore plus faible etc... resultat, lorsqu'on vole, chaque tuile du terrain doit etre rechargee a une resolution plus precise plusieurs fois au fur et a mesure qu'on s'en approche. On investi un max de puissance CPU pour charger et recharger et re-re-recharger ces tuiles en permanence pendant le vol, tout ca pour ne pas saturer la memoire. Et ce processus est actuellement le seul et unique truc qui utilise tous les cores de ton CPU. Mais au moins, ca plante pas (enfin, pas trop...)

Si au lieu de recharger toutes les tuiles chaque fois tu tu parcours un kilometre on chargait directement les tuiles a la bonne resolution avec directement l'autogen dessus, on economiserait pas mal de puissance CPU. Mais en 32 bits, on aurait pas la place :)

Bon, la j'ai simplifié vachement, mais le principe est la.

Le truc c'est que les gens ne cherchent pas à avoir de jolis graphiques. Ils cherchent à voir leur maison.
Et ça XPlane ne l'offre pas. Orbx oui. C'est leur métier.

XPlane l'offre justement, avec son autogen par defaut construit à partir de donnees OSM.
Ce qui signifie entre autres qu'il est desormais parfaitement possible d'avoir sur XPlane une scene photorealiste a la FranceVFR  avec un autogen realiste a la Vogel ou 3DAutomation... mais sans les flouttages ou les plantages de FSX ou P3D :) (et avec des montagnes nettes :) )

Rebonjour à tous et spécialement à toi, ami Zangdaarr

Je continue de lire ce fil, avec la plus grande attention, et merci pour toutes ces informations techniques qui, au moins, ont le mérite de m'instruire ! Bon d'apprendre à tout âge, même quand la vieillesse est là !

En même temps, je me permets de revenir sur mon dernier post à ton intention, car je t'expliquais que ta réponse, liée à mes 2000 scènes montées : sans intérêt pour toi et '"à chacun sa came",  reposait sur un malentendu. Je résume ici, ce que je te dis plus longuement là-bas.

Ma question, relative au bloquage de FS2004, ne portait pas sur ce montage de 2089 scènes, qui lui, a tourné parfaitement. Elle portait sur les SEULES scènes de Bluesky. Et là, j'avais au plus une quarantaine d'entrées dans mon scenery.cfg. Mais sur ces scènes photoréalistes, le nombre de fichiers bmp (de 64kb chacun) dans les répertoires "Texture" devenait vite ahurissant : pour la seule Californie entière laissée active quant à toutes ses tuiles, des dizaines de milliers. Ce qui me contraignait à fractionner le chargement, et à ne jamais pouvoir voler sur la Californie entière. et encore moins sur la Californie couplée avec les scènes de Bluesky portant sur certains états limitrophes. Je continue de penser que la raison du bloquage (à 66% si mes souvenirs sont bons) tenait au nombre très grand de ces fichiers bmp dans les répertoires "Texture". Et je n'ai jamais pu résoudre ce problème qui, à mes yeux, a constitué alors la seule limitation réellement gênante, et imprévisible au départ, de FS2004.

Connais-tu toi-même ce problème, et as-tu une solution pour le contourner, à part désactiver, réactiver une partie du territoire survolé, ce qui n'est pas très immersif, puisqu'on est contraint de le survoler par tranches successives, avec pauses à chaque fois ?

Merci d'avance si tu acceptes de me dire ton opinion, même si c'est pour conclure qu'il n'y a rien à y faire, sauf accepter cette limitation, en vol VFR photoréaliste sur les Bluesky de FS2004 - et sur les scènes photoréalistes montées sur FS2004. Au moins je serai fixé, car je continue à pratiquer toujours FS2004, sur des scènes étendues réalisées avec FS Earth Tiles... en parallèle avec FSX, pour diverses raisons trop longues à écrire ici de nouveau.

En toute cordialité.

Platoplotinus

Jean-Yves

Dernière modification par platoplotinus (20-12-2016 06:48:22)

Zangdaarr a écrit:

Ce n'est pas vrai, tout dépend des scènes. Orbx utilise des avions pour faire du repérage et prendre des photos (ou du moins faisait, maintenant on a google maps, ils ont du réduire leurs coûts). Certaines de leurs scènes sont extrêmement précises et faites pour faire du véritable VFR.
3DA c'est juste de l'autogen.

Oula... La precision des scenes ORBX concerne le positionnement du landclass. Mais les textures sont generique, et donc les batiments (autogen) places dessus ne correspondent PAS DU TOUT a la realite. Si ce n'est qu'il y a bien un village la ou il y a un village dans la realite. Mais les rues, maisons, arbres, sont totalement faux.

A l'opposee, les scenes 3DA de France VFR utilisent une scene photo (par definition 100% conforme a la realite) avec un placement des batiments grace a une base OSM (qui repertorie le placement et l'emprise au sol des batiments dans la realite). Donc les batiments sont bel et bien la ou ils sont dans la realite, avec la bonne taille et la bonne orientation. LA, tu peux trouver ta maison, ton jardin, et meme ta bagnole garee devant...

Zangdaarr a écrit:

L'autogen ne fait pas une scène réaliste. Quand je dis voir sa maison, c'est évidement une exagération. Les scènes faites à la main offrent un terrain bien plus conforme à la réalité qu'un autogen qui n'est qu'un placement au hasard..

Encore une fois non. Un autogen sur base OSM n'est pas place au hasard. Celui d'ORBX l'est, puisque la base du placement des objet n'est un qu'un landclass. Sur XP11, la base du placement des objet est une base de donnees reelles, donc comme pour les scenes France VFR, tu peux y trouber ta maison.

Les limitations sont simples : ORBX utilise du generique, en ameliorant les landclass et leurs textures. La precision est suffisante pour du VFR, et ils peuvent couvrir de grandes surfaces a moindre cout de stockage. Il est cependant totalement impossible de retrouver sa maison, ni meme sa rue (sauf a habiter sur un grand axe).

France VFR utilise une base photo, et y place de l'autogen sur base OSM. Precision absolue, rue, maison, jardin, bagnole, chien, tout est la ! Mais le cout en stockage est enorme, et encore ils ne proposent qu'une saison...

De memoire, X-Plane utilise un landclasse plus "soft" - moins precis - mais des donnees OSM pour le placement des objets. Donc la "plaque" au sol ne correspond pas a la realite, tu n'y trouvera pas la forme du champ a la sortie du village... Mais tous les batiments sont places de facon conforme a la realite. Tu trouveras donc ta rue et ta maison sans probleme.

Dernière modification par n666eo (20-12-2016 08:27:43)