Vous n'êtes pas identifié.
Pages: 1
En faisant le ménage dans mes archives j'ai retrouvé le vieux document qui explique les différences prévues par Microsoft entre une librairie 'Globale' destinée donc à un usage global, usage mondial ou régional, et ce que certains désignent comme 'Locale' pour une librairie ne concernant qu'une scène.
L'original:
When compiling a scenery .bgl file for Microsoft Flight Simulator, the compiler examines each entry that positions an object and places some code in the file header that defines the geographic coverage of the placement items. In this way, Flightsim needs only examine the file header to determine whether there is anything in the file relevant to the current position of the user aircraft. This, in turn, reduces processing overhead because unneeded (relative to the user aircraft position) objects and positioning data is not loaded. The file is considered geo-locked to its coverage area
But, there’s also a “downside” to this scheme. If the file contains any objects that might be useful outside the area to which it is geolocked, those objects are not accessible. Further, library object .bgls (which contain only object model data but no positioning data) are not geo-locked by the compiler. Hence, objects in such files are always loaded, whether or not they are needed. To address this latter situation, Microsoft geo-locked some of the stock libraries (e.g., Scenery\Orlando.bgl) when developing Flight Simulator. But, this capability is not supported by the released compilers.
La traduction:
En compilant un scenery .bgl le fichier pour le Microsoft Flight Simulator, le compilateur examine chaque entrée qui place un objet et écrit un certain code dans l'en-tête de fichier qui définit la couverture géographique des données de placement. De cette façon, les simulateurs n'examinent que l'en-tête de fichier pour déterminer s'il y a quoi que ce soit dans le fichier concernant la position actuelle de l'avion d'utilisateur. Ceci réduit le traitement préalable parce que si inutiles (par rapport à la position d'avion d'utilisateur) les objets et les positionnements de données ne sont pas chargés. Le fichier est considéré geo-fermé à sa zone de couverture.
Mais, il y a aussi un inconvénient à ce marquage. Si le fichier contient des objets qui pourraient être utiles à l'extérieur de la zone à laquelle il est geo-fermé, ces objets ne sont alors pas accessibles. Donc, l'objet d'une library.bgl (qui contient seulement des données de modèles d'objets, mais aucune donnée de positionnement) n'est pas geo-fermé par le compilateur. Par conséquent, les objets dans de tels fichiers sont toujours chargés, qu'ils soient nécessaires ou non. Pour gérer cette dernière situation, Microsoft a geo-fermé certaines des bibliothèques de stock (par exemple, le Paysage\Orlando.bgl) en développant le Simulateur de vol. Mais, cette possibilité n'est pas fournie par les compilateurs distribués.
A une époque, j'avais signalé sur ce forum que lorsque les objets d'une libraire de scène accompagnée de son ou ses fichiers BGLs de placement d'objets, ces objets étaient chargés au lancement du simulateur dans la VAS et y restaient en permanence et qu'alors, en cas d'un grand nombre déclaré de scènes comportant des librairies, un dépassement de la capacité de la VAS était possible au cours du vol. Certains s'étaient montrés très sceptiques. Mais, si Microsoft a bien distingué deux types de librairies lors de la création du simulateur, il l'a fait en distinguant par l'écriture des fichiers BGL celles qui auront une orientation globale de celles qui en auront une locale. Mais malheureusement ne fournit pas l'outil de compilation permettant de faire la distinction directement.
Donc, pour permettre une bonne gestion de la VAS, chargement dès l'entrée dans le rayon de visibilité et déchargement des objets dès leur sortie du rayon, la seule solution pour la création de librairie unique d'objets scéniques propres à une scène unique est donc de travailler lors de la création de la scène avec des objets simples positionnés géographiquement à l'aide de l'outil choisi par le créateur et d'introduire dans le fichier BGL de l'objet compilé ses données géographiques (Latitude, Longitude, orientation, échelle et éventuellement Altitude).
Pour cela, le ou les BGLs de placement associés à ces objets, fichiers totalement inefficaces en utilisation pour l'optimisation de la VAS, deviennent utiles en les transformant en fichiers XML (par bgl2xml par exemple) de façon à pouvoir en extraire aisément les dîtes données de placement par objet et de les inclure ensuite dans le BGL de chaque objet à l'aide d'un outil externe (MCX par exemple), les fichiers de placement devenus inutiles sont effacés.
Cette méthode est très importante pour nos simulateurs versions 32bits et surtout pour Prepar3D qui propose une gestion optimisée de la VAS à l'avancement.
EDIT:
J'ai trouvé un outil qui verrouille ou déverrouille les librairies: http://stuff4fs.com/newpage.asp?Folder=Geolock
L'auteur a repris le texte d'origine et y a rajouté Prepar3D pour tenir compte de l'actualité.
L'outil permet d'inscrire une zone géographique dans l'entête du fichier librairie locale ou permet de l'enlever si la librairie devient globale,les fichiers de placement sont obligatoires dans les deux cas. Pas testé.
Des discussions sur FSDeveloper, il suffit de faire une recherche portant sur 'Geolock'.
Il existe donc deux méthodes pour sauvegarder la VAS,
si les objets de la scène sont peu nombreux:
chaque BGL objet est géo-référencé mais un grand nombre d'objets peut augmenter le temps de chargement initial du simulateur.
si les objets de la scène sont nombreux:
créer une librairie avec fichier de placement et utiliser Geolock pour définir une zone géographique dans laquelle les objets de la librairie seront affichables.
Les créateurs distributeurs de scènes (pro ou pas) n'ont plus d'excuses pour nous encombrer la VAS.
Pour ceux qui veulent placer un ou des objets avec MCX:
Dernière modification par bede40 (10-05-2017 13:45:22)
Hors ligne
Un seule chose à dire: à épingler de suite !
Ah oui encore une chose: Merci
Hors ligne
Merci pour ce rafraichissement.
+1 pour l'épingle
Hors ligne
Salut, Bernard tu avais fait la démo, il y a quelques temps déjà, avec des photos
Même si tu appuis tes dire avec les textes de CROMOUE .
Patou
Dernière modification par NEPTUNE6P2V7 (10-05-2017 09:54:39)
Hors ligne
Bonjour,
Souvent je me sens tout petit, comme un apprenti sorcier qui joue avec des ingrédients qu'il ne maîtrise pas.... Merci Bernard, à présent j'en suis sûr!
En rentrant de (petites) vacances je vais re-relire tes conseils et peut-être arriverais-je à transformer mes scènes les plus lourdes pour qu'elles soeint plus digestes!
Chapeau bas!
amitiés, Pascal.
Hors ligne
Merci beaucoup Bernard !
Hors ligne
MERCI Bernard,
Je vais tester cela illico dans Grostenquin ...
Ma librairie, qui ne comporte que des bâtiments, compte tout de même 43 objets différents pour 104 objets placés ... et ce n'est pas terminé !
Bons vols.
Patrick
Dernière modification par PatDeBarr (10-05-2017 19:43:38)
Hors ligne
Merci pour cette découverte et le message !
Hors ligne
Pages: 1