Journal de développement 17
Publié : mar. mars 06, 2007 4:06 pm
Comme promis, voilà donc la traduction attendue 
:
"Désolé pour le retard dans la parution de ce Carnet de Développement, malheureusement un certain nombre d'évènements se sont ligués pour retarder cette parution, le moindre n'étant pas le fait que mon PC a fondu, me mettant des bâtons dans les roues.
Heureusement nos intréprides développeurs n'ont pas rencontré de tel désastre et continuent de travailler à l'achèvement de Fighter Ops.
Quelques-uns des ajouts notables ce mois-ci proviennent de l'équipe graphique, avec l'achèvement des modèles du T-6 II et du T-38C. Je suis certain que vous tomberez d'accord sur le fait qu'ils sont absolument fantastiques! Le travail graphique se poursuit sur l'UH-60, le HH-60, le C-17, tout comme sur les aérodromes et les véhicules civils. Le travail se poursuit également sur les shaders tout comme sur les animations skeletal. *(NdT: même en français, il semble qu'on utilise le terme "animation skeletal". Si quelqu'un connaît un vrai équivalent dans notre belle langue, sait-on jamais?)
L'équipe des modèles de vol a bien progressé, les systèmes hydrauliques sont achevés, y compris les pannes détaillées ainsi que les variations de pression lors de rapides mouvements des commandes. Les systèmes liés à l'oxygène ont été également achevés ce mois-ci par l'équipe des modèles de vol. Le travail est actuellement en cours sur les systèmes de verrière ainsi que sur les projets propulseur et cellule toujours en train.
Notre équipe de codage a réalisé des progrès substantiels, avec l'achèvement de la première partie du moteur graphique DirectX, davantage de travail sur l'interface, un certain nombre de composants sont à présent complets dans la première et seconde itération, y compris le code de réseau, et les modules de son et de saisie. Le code du terrain est à présent bien entré dans sa seconde itération avec des outils permettant de visualiser de plus grandes surfaces de mesh de terrain à des fins de test. Tandis que j'écris ce texte le travail est en cours pour inclure à cet outil les données vectorielles pour les routes et d'autres choses du même ordre, et bientôt le texturage devrait s'y ajouter. Un travail détaillé de définition et de planification a été achevé en ce qui concerne le moteur météo dynamique. Le travail a déjà débuté pour ce qui est de rassembler tous ces composants pour le second prototype majeur qui marquera une étape assez importante sur le chemin vers les premières versions Alpha et Beta de Fighter Ops. La chasse aux bugs et l'affinement continuent pour le code des modèles de vol, qui devrait être prêt à être intégré très bientôt.
Babak, notre codeur en chef, a été assez aimable pour écrire un court texte sur quelques aspects du moteur de terrain:
Introduction
Dans un simulateur de vol qui vise à être riche et réaliste, le terrain signifie bien davantage que rendre le sol en utilisant des techniques de rendu 3D sophistiquées. En dehors de l'aspect visuel, le autres modules tels que la météo et l'IA sont grandement influencés par le moteur de terrain. Le fait que les données du terrain vont être utilisées par d'autres modules rend leur définition et leur implémentation très difficiles. Je m'explique. Afin de pouvoir rendre le terrain de façon efficace, il faudra que le contenu de ce terrain soit géré et stocké d'une certaine manière. Un autre module comme le moteur météo peut avoir besoin que les données du terrain soient structurées et stockées d'une manière différente. Ces deux méthodes préférables de gestion des données du terrain ne sont pas nécessairement compatibles et peuvent conduire à des contradictions. La solution évidente serait de créer une version séparée et complète des données de terrain pour chacun des modules qui en a besoin. La taille conséquente des données liées au terrain interdit de créer et stocker ces données en plus d'un exemplaire. La solution est donc de créer un format qui soit utilisable par tous les modules utilisant le contenu des données.
Contenus du Terrain
Que comportent donc les données de terrain dans Fighter Ops? A quoi correspond exactement le mot "terrain"? Dans Fighter Ops, le terrain est constitué des parties suivantes:
a) les donnée d'élévation
b) les textures de base
c) les données vectorielles
Les données d'élévation consistent en un large ensemble de mesures selon une grille uniforme appliquée à la surface terrestre. Chaque mesure est une altitude (par rapport au niveau de la mer). Cela se ramène à une matrice à deux dimensions de chiffres qui reproduit la surface de la Terre.
Les textures de base sont en fait les bitmaps primaires qui sont appliqués sur le terrain. La nature de ces textures est la même que celle d'une photographie de type JPEG, GIF, BMP ou tout autre format d'image habituel. Dans Fighter Ops, les textures de base ne sont pas de simples bitmaps préparés à l'avance qui sont appliqués sur le mesh terrain. Le processus de création et de rendu des textures de base est complexe.
Les données vectorielles sont une façon très pratique de décrire des données telles que les routes, les voies de chemin de fer et les points de repère. Une route droite, par exemple, est représentée par ses extrémités. Une route comportant des courbes et des virages est approximée par une série de lignes droites. Les avantages à utiliser un format vectoriel plutôt que des bitmaps primaires pour représenter ce type d'information sont la taille et la précision. Si l'on essaie de représenter et conserver une route en la dessinant sur un bitmap, seul un très faible pourcentage du bitmap sera utilisé et, en outre, lorsqu'on zoomera dessus, la route sera pixellisée très rapidement et sera inutilisable à des zooms importants. Qui plus est, si un format vectoriel est employé, seules les coordonnées des extrémités doivent être stockées et un programme affichant la route peut en faire le rendu pour n'importe quel niveau de zoom.
Plat ou sphérique?
Lorsque le terrain est créé, la solution habituelle est de rendre le terrain sur un plan plat, à la façon dont cela est fait dans la plupart des simulations de vol actuelles. Cette approche fonctionnera très bien si le jeu se concentre sur une région spécifique du globe ou un certain nombre de théâtre séparés. Toutes sortes de problèmes apparaissent lorsque l'on tente de modéliser un terrain très grand ou mondial. Voler ou visualiser le terrain à très haute altitude causera également forcément des problèmes et, enfin, simuler les trajectoires d'objets en orbite comme les satellites sera un cauchemar.
Créer une représentation plane d'un terrain mondial ne peut pas être fait de telle façon que chaque partie de ce terrain soit décrite avec précision. Si vous regardez une carte de la Terre typique, vous verrez que la précision de la carte décroît au fur et à mesure que vous vous éloignez de l'équateur pour vous rapprocher des pôles. Dans de telles cartes, l'Antarctique et l'Islande sont par exemple bien plus grands qu'ils ne le sont dans la réalité. Inversement, une carte créée pour une région polaire n'est seulement bonne que pour cette région, et sur une telle carte aller vers l'équateur va faire décroître la précision de manière significative. Si l'attention ne se porte toujours que sur une seule zone du globe, une projection plane peut être utilisée pour cette zone mais aussitôt que vous vous en éloignez la précision est drastiquement réduite. Dans le cas d'un vol très long, pour maintenir la précision la projection doit être modifiée tandis que l'appareil vole d'une zone à une autre. Ce manque de constance rendra un certain nombre de calculs difficiles à mener dans la simulation, sinon impossibles.
Une méthode alternative consiste à gérer le terrain mondial tel qu'il est en réalité: une sphère. Un terrain sphérique résoudra les problèmes de projection et nous soulagera d'avoir à créer de multiple projections pour différentes parties du terrain. Si nous représentons le terrain comme une sphère, nous pouvons toujours créer des projections planes autant que nécessaire pour des missions ou des campagnes locales. En outre, lorsque l'altitude s'accroît, la nature sphérique du terrain deviendra automatiquement visible sans qu'il soit nécessaire de remplacer le terrain original par quelque chose qui ait l'air réaliste pour cette altitude.
Nous avons adopté la représentation sphérique du terrain dans Fighter Ops. Cette méthode nous permet de simuler sans heurt des trajectoires sur de longues distances, à de hautes altitudes ou même en orbite avec facilité, et nous offre un terrain constant et précis à l'échelle mondiale."
:"Désolé pour le retard dans la parution de ce Carnet de Développement, malheureusement un certain nombre d'évènements se sont ligués pour retarder cette parution, le moindre n'étant pas le fait que mon PC a fondu, me mettant des bâtons dans les roues.
Heureusement nos intréprides développeurs n'ont pas rencontré de tel désastre et continuent de travailler à l'achèvement de Fighter Ops.
Quelques-uns des ajouts notables ce mois-ci proviennent de l'équipe graphique, avec l'achèvement des modèles du T-6 II et du T-38C. Je suis certain que vous tomberez d'accord sur le fait qu'ils sont absolument fantastiques! Le travail graphique se poursuit sur l'UH-60, le HH-60, le C-17, tout comme sur les aérodromes et les véhicules civils. Le travail se poursuit également sur les shaders tout comme sur les animations skeletal. *(NdT: même en français, il semble qu'on utilise le terme "animation skeletal". Si quelqu'un connaît un vrai équivalent dans notre belle langue, sait-on jamais?)
L'équipe des modèles de vol a bien progressé, les systèmes hydrauliques sont achevés, y compris les pannes détaillées ainsi que les variations de pression lors de rapides mouvements des commandes. Les systèmes liés à l'oxygène ont été également achevés ce mois-ci par l'équipe des modèles de vol. Le travail est actuellement en cours sur les systèmes de verrière ainsi que sur les projets propulseur et cellule toujours en train.
Notre équipe de codage a réalisé des progrès substantiels, avec l'achèvement de la première partie du moteur graphique DirectX, davantage de travail sur l'interface, un certain nombre de composants sont à présent complets dans la première et seconde itération, y compris le code de réseau, et les modules de son et de saisie. Le code du terrain est à présent bien entré dans sa seconde itération avec des outils permettant de visualiser de plus grandes surfaces de mesh de terrain à des fins de test. Tandis que j'écris ce texte le travail est en cours pour inclure à cet outil les données vectorielles pour les routes et d'autres choses du même ordre, et bientôt le texturage devrait s'y ajouter. Un travail détaillé de définition et de planification a été achevé en ce qui concerne le moteur météo dynamique. Le travail a déjà débuté pour ce qui est de rassembler tous ces composants pour le second prototype majeur qui marquera une étape assez importante sur le chemin vers les premières versions Alpha et Beta de Fighter Ops. La chasse aux bugs et l'affinement continuent pour le code des modèles de vol, qui devrait être prêt à être intégré très bientôt.
Babak, notre codeur en chef, a été assez aimable pour écrire un court texte sur quelques aspects du moteur de terrain:
Introduction
Dans un simulateur de vol qui vise à être riche et réaliste, le terrain signifie bien davantage que rendre le sol en utilisant des techniques de rendu 3D sophistiquées. En dehors de l'aspect visuel, le autres modules tels que la météo et l'IA sont grandement influencés par le moteur de terrain. Le fait que les données du terrain vont être utilisées par d'autres modules rend leur définition et leur implémentation très difficiles. Je m'explique. Afin de pouvoir rendre le terrain de façon efficace, il faudra que le contenu de ce terrain soit géré et stocké d'une certaine manière. Un autre module comme le moteur météo peut avoir besoin que les données du terrain soient structurées et stockées d'une manière différente. Ces deux méthodes préférables de gestion des données du terrain ne sont pas nécessairement compatibles et peuvent conduire à des contradictions. La solution évidente serait de créer une version séparée et complète des données de terrain pour chacun des modules qui en a besoin. La taille conséquente des données liées au terrain interdit de créer et stocker ces données en plus d'un exemplaire. La solution est donc de créer un format qui soit utilisable par tous les modules utilisant le contenu des données.
Contenus du Terrain
Que comportent donc les données de terrain dans Fighter Ops? A quoi correspond exactement le mot "terrain"? Dans Fighter Ops, le terrain est constitué des parties suivantes:
a) les donnée d'élévation
b) les textures de base
c) les données vectorielles
Les données d'élévation consistent en un large ensemble de mesures selon une grille uniforme appliquée à la surface terrestre. Chaque mesure est une altitude (par rapport au niveau de la mer). Cela se ramène à une matrice à deux dimensions de chiffres qui reproduit la surface de la Terre.
Les textures de base sont en fait les bitmaps primaires qui sont appliqués sur le terrain. La nature de ces textures est la même que celle d'une photographie de type JPEG, GIF, BMP ou tout autre format d'image habituel. Dans Fighter Ops, les textures de base ne sont pas de simples bitmaps préparés à l'avance qui sont appliqués sur le mesh terrain. Le processus de création et de rendu des textures de base est complexe.
Les données vectorielles sont une façon très pratique de décrire des données telles que les routes, les voies de chemin de fer et les points de repère. Une route droite, par exemple, est représentée par ses extrémités. Une route comportant des courbes et des virages est approximée par une série de lignes droites. Les avantages à utiliser un format vectoriel plutôt que des bitmaps primaires pour représenter ce type d'information sont la taille et la précision. Si l'on essaie de représenter et conserver une route en la dessinant sur un bitmap, seul un très faible pourcentage du bitmap sera utilisé et, en outre, lorsqu'on zoomera dessus, la route sera pixellisée très rapidement et sera inutilisable à des zooms importants. Qui plus est, si un format vectoriel est employé, seules les coordonnées des extrémités doivent être stockées et un programme affichant la route peut en faire le rendu pour n'importe quel niveau de zoom.
Plat ou sphérique?
Lorsque le terrain est créé, la solution habituelle est de rendre le terrain sur un plan plat, à la façon dont cela est fait dans la plupart des simulations de vol actuelles. Cette approche fonctionnera très bien si le jeu se concentre sur une région spécifique du globe ou un certain nombre de théâtre séparés. Toutes sortes de problèmes apparaissent lorsque l'on tente de modéliser un terrain très grand ou mondial. Voler ou visualiser le terrain à très haute altitude causera également forcément des problèmes et, enfin, simuler les trajectoires d'objets en orbite comme les satellites sera un cauchemar.
Créer une représentation plane d'un terrain mondial ne peut pas être fait de telle façon que chaque partie de ce terrain soit décrite avec précision. Si vous regardez une carte de la Terre typique, vous verrez que la précision de la carte décroît au fur et à mesure que vous vous éloignez de l'équateur pour vous rapprocher des pôles. Dans de telles cartes, l'Antarctique et l'Islande sont par exemple bien plus grands qu'ils ne le sont dans la réalité. Inversement, une carte créée pour une région polaire n'est seulement bonne que pour cette région, et sur une telle carte aller vers l'équateur va faire décroître la précision de manière significative. Si l'attention ne se porte toujours que sur une seule zone du globe, une projection plane peut être utilisée pour cette zone mais aussitôt que vous vous en éloignez la précision est drastiquement réduite. Dans le cas d'un vol très long, pour maintenir la précision la projection doit être modifiée tandis que l'appareil vole d'une zone à une autre. Ce manque de constance rendra un certain nombre de calculs difficiles à mener dans la simulation, sinon impossibles.
Une méthode alternative consiste à gérer le terrain mondial tel qu'il est en réalité: une sphère. Un terrain sphérique résoudra les problèmes de projection et nous soulagera d'avoir à créer de multiple projections pour différentes parties du terrain. Si nous représentons le terrain comme une sphère, nous pouvons toujours créer des projections planes autant que nécessaire pour des missions ou des campagnes locales. En outre, lorsque l'altitude s'accroît, la nature sphérique du terrain deviendra automatiquement visible sans qu'il soit nécessaire de remplacer le terrain original par quelque chose qui ait l'air réaliste pour cette altitude.
Nous avons adopté la représentation sphérique du terrain dans Fighter Ops. Cette méthode nous permet de simuler sans heurt des trajectoires sur de longues distances, à de hautes altitudes ou même en orbite avec facilité, et nous offre un terrain constant et précis à l'échelle mondiale."
, t'as pas encore les reflexes -> en news quand tu nous fais des trucs comme ça 
.
, je resterais avec mon lock on
)
)
! ! !