# PIA

## Lot 1 - Rendu distant de terrain voxel

### Tâche 1.1 - Mise à jour du baking
La texture de la planète est générée aujourd’hui à partir seulement des résultats de la génération procédurale. Cependant, nous devons tenir compte également des modifications effectuées par les joueurs et les répercuter. Ces modifications sont potentiellement tridimentionnelles — grottes, surplombs — cependant nous devrons les représenter sur une carte en deux dimensions. Nous devrons trouver des compromis esthétiques et calculatoires dans cette étape de reprojection. Il conviendra dans cette tâche de synchroniser les modifications depuis le serveur. Cette synchronisation ne saurait se faire sans implémenter la capacité de générer ces textures dans le serveur en surcroît du client

### Tâche 1.2 - Baking des constructions statiques sur les planètes
Une distinction est faite au niveau du gameplay entre les constructions statiques comme les bâtiments et les constructions dynamiques comme les vaisseaux spatiaux. Les bâtiments suffisamment grands doivent être visibles depuis l’espace et peuvent être incorporés à la texture de terrain générée dans le lot 1.

## Lot 2 - Rendu distant de constructions voxel

Les constructions voxels peuvent être vues de très loin en raison de leur taille. Se pose la question de la génération de leur représentation à des niveaux de détail inférieurs au plus grand niveau de détail (LOD 0). Nous nous heurtons toujours au fait qu’elles sont dynamiquement modifiables à tout moment par les joueurs. Cela entraîne des complexités au niveau du rendu et au niveau de la synchronisation serveur des modifications.

### Tâche 2.1 - Génération automatique de mesh multi échelle
L’approche utilisée jusqu’à présent a été de simplifier la représentation voxel (Hermite data field). Mais les résultats ne sont pas toujours satisfaisants en termes de qualité graphique. Nous envisageons une nouvelle technique dans ce lot qui consisterait à simplifier les maillages des constructions dans leur intégralité et pas seulement. Les opérations effectuées seraient propagées dans les différents niveaux de détail sans effectuer de nouveau tous les calculs.

### Tâche 2.2 - Création de représentation par imposteur des constructions
La complexité des constructions — géométrie, variété de matières, éléments présents — ne permet qu'un niveau limité de simplification si l'on se limite à la topologie d'un maillage. Pour atteindre des niveaux de simplification mémoire et de réduction de coût d'affichage plus élevés la technologie des «imposteurs» est bien plus adaptée car elle ne nécessite qu'une image pour représenter l'intégralité de la construction. La génération de ces images sur notre serveur va nécessiter l'intégration d'un graphe de scène et d'un moteur de rendu primitif ainsi que des critères qui déclencheront la régénération des images.

## Lot 3 - Eclairage de scènes modifiables
Dans de nombreuses situations en jeu, un utilisateur peut avoir une scène avec plusieurs sources de lumière et de type différent. Afin d'allier performance et qualité visuelle, nous avons dû implémenter des schemas complexes pour le baking et le caching des lumières. Nous avons également inventé de nouveaux algorithmes à haute performance d'aggrégation d'information pour des techniques de rendu en temps réel. Ces étapes ont été réalisé en R&D mais l'implémentation au sein de la code base du jeu, étape non triviale, est encore à faire. Enfin, dans le but d'atteindre un rendu "photo-réaliste" nous devrons implémenter un mécanisme de propagation de la lumière dans la scène : l'illumination globale (GI).

In many situations during playing the game a user can have multiple lights of different types. To achieve good performance as well as visual quality we had to implement not only sophisticated schemas for baking and caching lights data, but also to invent new high performance algorithms for gathering information for real-time graphics techniques. In order to achieve an almost "real life" results we had to implement completly new mechanism of light propagation in the scene - global illumination.

### Tâche 3.1 - Baking dynamique de l’éclairage des constructions
Nous voulons donner la possibilité au joueur d’ajouter des sources de lumière à la scène. Ces lumières sont potentiellement mobiles pour le cas où elles seraient sur un vaisseau. Nous avons donc besoin d’une solution dynamique qui prenne en compte ces sources.

### Tâche 3.2 - Multiples instances de GI pour gérer les vaisseaux
Le problème principal des solutions actuelles d'illumination globale est la restriction à des scènes statiques. Cela n'est clairement pas suffisant pour un jeu et nous sommes en développement de deux approches distinctes.
* Illumination globale statique. Le mouvement d'un joueur n'est pas si rapide. La vitesse moyenne ne dépassant pas 50km/h. Dans ce scénario nous recalculons l'illumination globale en utilisant les techniques de Raytracing.
* Illumination globale dynamique pour les constructions de grande taille en déplaçement. Nous avons besoin de cet algorithme pour les objets créés par les joueurs pouvant se déplacer très rapidement dans l'espace. Pour ce faire nous faisons le baking de toute les informations de la lumière à l'interieur l'objet, dans le but de l'utiliser directement sans modifications.

The main problem with current solutions with global illumination is that this technique is only applicable for static scenes. This is totally not enough for the game. We are in development of two different approaches:
* Static global illumination. Movement of the player is not that big, average speed is not more than 50 kilometers per hour. In this case, we regenerate the global illumination representation using Raytracing techniques.
* Dynamic global illumination for moving massive constructs. We need this extra step for player built objects, that can move very fast in Space. To solve this issue we are baking all the light information inside the object to use it directly without any other modifications.

### Tâche 3.3 - Pré-calculs sur le serveur et partage des informations précalculées
Nous avons rencontré le problème, au cours du dévelopement, de la limite de recalcul des informations pour chaque frame, en particulier lors du déplacement rapide de contructions de joueur. Une des solutions consiste au baking des informations à propos de cette construction et comment il réfléchit, diffuse et occlus la lumière. L'idée principale est de calculer la propagation de la lumière avec multiples rebonds en fonction des propriétées physique de la surface. Nous pourrons ensuite garder ces informations dans le serveur pour avoir un accès direct pour chaque joueur qui peut être près ou à l'interieur de l'objet. Cette idée basique est similaire au principe des light maps. En utilisant cette approche nous allons générer des rendus photoréalistes tout en conservant la fluidité de l'expérience de jeu par l'utilisation d'informations précalculé.

At some point we faced the problem, that not all information can be regenerated every frame, especially if we have fast moving player constructs. One of the solutions is to bake information about this construct and how it reflects, scatter and occlude light. The main idea is to calculate multibounce light propagation according to the surface physically based properties. Then we store this infomation on the server to have direct access for every player that can be near or inside of the appropriate object. This basic idea is very similar to light maps. Using this appraoch we will achive "real life" light visual results as well as very good performance due to usage of precalculated information.

## Lot 4 - Génération procédurale de planètes voxel réalistes

### Tâche 4.1 – Simulation de planètes
L'outil de simulation de planètes permet principalement de distribuer des biomes créés en amont selon des valeurs d'altitude, de température, et d'humidité. Ces valeurs sont générées grâce à une suite de modules simulant des effets physiques tels que la circulation de l'air, le volcanisme ou la tectonique. Nous explorons plusieurs pistes d'amélioration. D'une part, la diversification de ces modules. Nous envisageons la simulation de cours d'eau et de leurs érosions ou les phénomènes de désertification. D'autre part, un plus grand contrôle sur la disposition des biomes. Nous souhaitons pouvoir limiter l'ajout d'un biome à une région précise de la planète à l'aide de masques. Par exemple, un biome de banquise qui ne serait présent qu'aux pôles. Ceci nous permettrait de représenter des microclimats, ou simplement de différencier des environnements qui partageraient les mêmes caractéristiques physiques.

### Tâche 4.2 - Ambiances atmosphériques locales
Afin d'améliorer l'immersion et le réalisme des situations vécues par les joueurs, nous voudrions placer des ambiances atmosphériques locales. Cela peut être une simple brume de forêt mais aussi une tempête de sable dans le désert, ou un blizzard glaçant sur les étendues de neige. Ces micro-climats ne sont pas seulement des effets à afficher mais proposent de vraies difficultés. En effets, ils doivent être restreints à une zone locale mais être visibles par tous les joueurs à proximité. Un joueur voudra par exemple être capable de voir une tempête à quelques kilomètres afin de pouvoir l'éviter. Il faudra également que la transition entre l'exterieur et l'interieur des ambiances locales soit naturelle et la plus fluide possible. Des représentations multi-échelle devront être mises en place et des paramètres de rendu devrons être ainsi générés et utilisés suivant la position des joueurs.

### Tâche 4.3 - Gestion des étendues d’eau
Nous utilisons une représentation simplifiée de l’eau sur les planètes ayant des océans. Une sphère d’eau entoure la totalité de la planète. Cette solution simple permet d'avoir un rendu correct pour la version alpha mais implique de nombreuses limitations qui devront être dépassées par la suite. Par exemple, lorsqu'on creuse une galerie, à partir d'une certaine profondeur on trouvera toujours de l'eau : on ne peut pas avoir de grotte sèche sous le niveau de la mer. Cela pose des problème de gameplay et de rendu. En l'état actuel, il ne nous est pas possible de gérer d'autres types d'étendues d'eau tel que des lacs. En effet, c'est un problème complexe puisque tout le terrain est modifiable, y compris le fond d'un lac : comment modéliser et rendre l'eau avec un comportement réaliste lorsque de telles modifications sont réalisées et peuvent affecter de grandes quantité de liquide?

### Tâche 4.4 - Editeur et modules algorithmiques de génération procédurale
Les planètes sont décrites sous la forme de pipelines qui sont des compositions de blocs algorithmiques et de paramètres. Cette tâche va permettre d’obtenir des modules/blocs algorithmiques supplémentaires à composer lors de la génération procédurale (bruits, composition, seuillage, etc.). Un éditeur est développé pour aider à la constitution de ces pipelines et avoir un retour visuel rapide de la paramétrisation.

### Tâche 4.5 – Optimisation des caractéristiques volumiques
Au-delà de la génération de carte d’altitude, nous souhaitons développer les caractéristiques volumiques comme par exemple des reliefs surplombants. Outre l’édition de terrain, notre technologie permet d’afficher des géométries plus riches qu’une simple carte d’altitude. Actuellement, pour des raisons de performance, le cœur de la génération résulte d’une carte d’altitude procédurale. Nous souhaitons y superposer des formes et caractéristiques volumiques pour casser l'apparence de simple carte d'altitude.

## Lot 5 – Graphe de scène côté serveur

Aujourd’hui le serveur gère les différents "constructs" (des instances indépendantes de notre moteur de voxels) comme des entités entièrement indépendantes, et leur position n’est qu’une simple coordonée en trois dimensions, qui est mise à jour sur simple demande du client. Ce client, lui, voit les constructs de manière beaucoup plus complexe : il en affiche entièrement la surface, afin de permettre à l’utilisateur de le voir en détail. Le client, ayant instancié les maillages des différents constructs, est capable de détecter leurs collisions, à l’aide du moteur de jeu, qui possède un moteur physique.

Le serveur n’ayant aucune de ces caractéristiques (ni instanciation du maillage des constructs, ni moteur physique), il n’est pas en mesure de déterminer si la mise à jour des coordonnées d’un construct ne le place pas au milieu d’une planète, ou à moitié à travers d’un autre vaisseau.

### Tâche 5.1 - Détection de collisions

Puisque la tâche 2.1 fera calculer au serveur les maillages des vaisseau, nous souhaitons utiliser ces données afin de permettre au serveur de déterminer les collisions entre vaisseau. Cela permet à la fois d’éviter la triche de la part de joueurs qui enverrait de mauvaises positions, et à terme de rajouter plus de comportements de gestion de jeu du côté du serveur.

### Tâche 5.2 - Lancé de rayons

Nous venons actuellement de mettre en place une première version de combats entre vaisseaux. Il fonctionne avec un tir touchant le vaisseau adversaire, et sur ce point d’impact nous appliquons une opération de dégats. Mais comment récupérer ce point d’impact ? Aujourd’hui c’est le client qui s’en occupe, puisque, comme expliqué plus haut, il a souvent déjà chargé toutes les informations nécessaires. Mais nous voulons pouvoir nous passer du client pour ce genre d’opérations. Nous voulons donc permettre au serveur de faire un lancé de rayon entre un point quelconque (le vaisseau attaquant) et une direction (vers le vaisseau adverse), pour déterminer exactement (avec plus ou moins de précision) où le point d’impact sera (vraisemblablement sur la coque du vaisseau). Nous allons pour cela nous servir des maillages des vaisseaux calculés avec la tâche 2.1.

### Tâche 5.3 - Gestion de la physique des vaisseaux

Comme expliqué plus haut, aujourd’hui c’est grâce au moteur de physique intégré dans le moteur de jeu du client que se déplacent les vaisseaux. Le serveur ne fait que recevoir les positions envoyées par les clients. Cela pose des problèmes potentiels de triche, et aussi des problèmes plus généraux : par exemple si un joueur contrôle un vaisseau qui avance se déconnecte, le vaisseau s’arrête, car il n’y a plus rien qui fait avancer le vaisseau. Nous souhaitons donc pouvoir mettre au moins une partie de la gestion de physique des vaisseaux côté serveur.

## Lot 6 – Tests en charge

### Tâche 6.1 – Métriques de performance

Les différents composants du serveurs sont testés individuellement grâce à des tests de charges automatisés. Des petites routines simples pouvant se connecter directement au différents composants du serveur pour pouvoir effectuer des opérations élémentaires (déplacement, visibilité, opérations voxel...) Des outils de mesures statistiques permettent de mesurer le poids en utilisation mémoire, temps processeur, charge réseau, temps de réponse... Le tout pour pouvoir s'assurer que toutes ces métriques progressent de manière linéaire face à la charge, repérer les goulots d'étranglement, et mesurer les régressions.

### Tâche 6.2 – Tests de charge automatisés par simulation de joueurs

Afin de permettre des tests de charges de nos serveurs, nous allons développer des outils de simulations de joueurs (appelés Bots). Ces outils dans leur version la plus complexe pourront émuler toute la complexité du comportement d'un vrai joueur, pilotés par des scripts permettant de donner aux bots à la fois un comportement individuel, mais aussi surtout des comportements coordonés entre eux pour s'approcher au plus près des conditions réelles d'exploitation et permettre d'anticiper au mieux les contraintes d'exploitation du jeu. Les Bots seront hébergés sur un cluster distant optimisé au maximum pour permettre d'en lancer un maximum en simultané.