Lorsque vous avez une lumière statique (non mobile) dans un jeu, vous avez deux options pour rendre cette lumière. Vous pouvez le rendre comme une lumière dynamique. c'est-à-dire alimentez-le par le pipeline de shader qui calculera son effet sur tout ce qui l'entoure, chaque image, en allant à l'écran. C'est évidemment assez cher. Ou encore, un éditeur peut faire entrer la lumière dans la scène.
Ce que j'ai toujours pensé de la cuisson était peut-être une version plus simple: l'éditeur prend simplement les textures de tout ce qui entoure la lumière, calcule l'effet de la lumière sur ces textures (les éclaircit, peut-être même, les ombres, etc.) et les enregistre en tant que textures de remplacement à utiliser. Ainsi, toutes les textures autour de la "lumière" ont l'air d'être éclairées, mais au moment de l'exécution, il n'y a pas de lumière du point de vue du calcul; c'est une illusion d'optique, essentiellement.
L'unité, cependant, semble générer une lightmap . Ceci est similaire à la notion ci-dessus, mais l'éclairage cuit est conservé séparément au lieu de modifier la texture sous-jacente, et je suppose qu'un shader fusionne les deux au moment de l'exécution. Cela aurait l’avantage de conserver l’avantage des textures en mosaïque (c’est-à-dire une faible utilisation de la mémoire), car elles ne laisseraient pas la lumière pénétrer à l'intérieur, elles pourraient donc rester en mosaïque et le shader serait très léger, en particulier par rapport au traitement de l'image. léger comme dynamique.
Une lumière doit évidemment être statique pour que cela fonctionne; c'est-à-dire que vous ne pouvez pas le déplacer pendant le jeu, car la lumière a été introduite dans les textures. De plus, aucun objet dynamique dans la pièce (tel que le personnage du joueur) n'aura la lumière qui brille dessus, il doit donc exister une sorte d'exception, dans laquelle la lumière est rendue pour les objets dynamiques mais n'est pas (re) rendue le le paysage statique.