j´ai donné un lien sur les pages précédentes.
Eclairage temps réel ( RTlighting): les textures sont décomposées en tuxels ( un pixel sur une texture) et les tuxels sont rassemblés en luxel.
ensuite le moteur calcule en permanence les valeurs RGB des tuxels de chaque luxel en fonctions des valeurs RGB, de la distance et la l´intensitée de toutes les sources de lumières: pour ce faire il trace une ligne directe entre la source et chaque luxel, si il y a un élément de propriétés solide qui passent entre le luxel et la source lumineuse, les tuxels de ce luxel se voient affectés une valeur RGB nulle : 0.0.0
avec plusieurs source de lumières ces valeurs RGB peuvent se voir plus ou moins modifier en fonction de la position des autres sources.
c´est prq un bug comme celui que j´ai montré sur l´image avec la porte dont les zones en bas à gauche sont éclairées est un bug de lightmap ( éclairage classique) comprendre ici que le calcul que j´ai détaillé avant n´est fait qu´une fois, avant même le chargement de la map :
la map est compilé par le dévellopeur qui lui donne des propriétés d´éclairage, et durant la compilation la lumière est établit avec tout les éléments FIXES. en fait, toutes les textures obtiennent durant cette compilation une valeur différentes pour chacun de ces luxels ( et donc tuxels) ces valeurs dépendent de la position des sources et des solides ( exactement comme pour le rtlighting, sauf que le rendu lightmap est meilleur mais fixe, donc en fait, il est moins bien . .. un paradox un peu complexe qui veut dire ici que le Lightmap est mieux que du RTLighting, car le lightmap est beaucoup détaillé et plus réaliste, les ombres sont beaucoup plus propres :
http://zombie.bhdnet.com/images/shot0127.jpg
sauf que si on se met devant les flammes, rien ne change.
Dynamic Lighting n´a aucun rapport ( ou presque) avec nos histoires de RTLighting et de Lightmap, ce n´est pas un principe d´éclairage du tout:
une DLight ( Dynamic Light) fonctionne de la façon suivante :
autour de la lumière, une sphére est créée, cette sphére peut se déformer de façon arbitraire et en temps réel.Tout les luxel se trouvant dans cette sphére se trouveront afféctés par le même principe que celui expliqué précédemment : leurs valeurs RGB seront modifiées en fonction des valeur RGB, de la distance de la source JUSQU´AUX BORDS de la sphère et de l´intensitée de la source. sauf que ici, les solides ne bloquent pas l´éclairage, c´est prq on remarque que dans Q3 par exemple, une grenade ou rocket passant ou explosant à l´étage supérieur éclairera le plafond de l´étage du dessous.
Far Cry fonctionne en LightMap, on le voit aux détails que j´ai donné précédement, mais ils ont inclus dans leur moteurs une technologie Stencil Buffer qui permet de creer des fausses ombres, en fait, certains éléments possédent la propriété de générer des ombres: un shader ( un ensemble de propriétés qui définissent comment sera traiter une surface ou un contenu par un moteur 3D) définit la forme de l´ombre qui devra être projetée en fonction de la position d´une DLight avec un Stencil Buffer.
Comme dans Far Cry et ses effets de lumières. rien n´est temps réel, tout est prévu.
Si un professionnel lit ces lignes qu´il sache que je n´ais volontairement pas approfondis les explications. des explications techniques demandant trop de temps et des connaissances de la part du lecteur. je ne suis déjà pas sur que tout le monde comprennent.
Merci à ceux qui ont lus jusqu´au bout.