Pourquoi certains jeux montrent-ils que les lumières brillent à travers les murs?

Dans certains jeux, je vois des lumières qui brillent à travers les murs, même si je règle la qualité vidéo à des niveaux élevés.

Quelques exemples de jeux auxquels j'ai joué récemment sont Borderlands 2 (explosions de missiles) et Call of Cthulhu (lanternes; le jeu utilise même Unreal Engine 4).

Est-ce un bug ou des raisons de performances?

Exemple Borderlands 2: https://youtu.be/9bV83qA6_mU?t=419 (quelques fois, mais rapidement)

Question bonus: dans ce dernier cas, existe-t-il un moyen d'utiliser à bon marché le lancer de rayons pour résoudre le problème? Je suppose que la RT coûteuse a définitivement résolu le problème, mais je me demande si elle peut également être utilisée sous une forme "bon marché" pour résoudre ce problème spécifique.

En développant la bonne réponse de TomTsagk, j'ai pensé que cela pourrait aider à décrire un peu plus pourquoi les jeux fonctionnent comme ça.

La lumière dans les jeux ne "voyage" pas vraiment de la source, à la surface, à la caméra, s'obstruant en cours de route.

Pour déterminer la luminosité de chaque pixel d'une surface en fonction d'une lumière donnée, nous utilisons (ou approximons) une formule mathématique qui utilise la direction opposée de la surface et la direction à partir de ce point de la surface vers la source de lumière. C'est tout, juste la direction dans laquelle il brille - nous ne jetons généralement pas de rayon pour vérifier si la lumière atteint réellement ce pixel, car le faire pour chaque pixel de l'écran et vérifier le rayon par rapport à toute la géométrie détaillée de la scène est généralement encore trop cher pour les jeux en temps réel.

Ainsi, par défaut, aucune lumière de jeu ne projette d'ombres. La direction vers une lumière reste la même, même s'il y a un shadowcaster, donc les calculs nous donnent la même valeur de luminosité.

Si nous voulons simuler des ombres, nous devons le faire séparément. Une méthode courante consiste à utiliser ce qu'on appelle une carte fantôme. Dans cette version, avant d'ombrer notre scène, nous rendons d'abord la scène du point de vue de chaque lumière, comme si cette lumière était une caméra, stockant la profondeur de chaque pixel qu'elle voit dans une texture hors écran.

Ensuite, lorsque nous ombrons la scène, nous pouvons comparer la distance mathématique de ce pixel de la source de lumière par rapport à la profondeur que nous avons enregistrée au pixel correspondant dans la carte d'ombre. Si la profondeur de la carte d'ombre est plus petite, cela signifie qu'il y a une autre surface entre ici et la lumière, et nous dessinons ce pixel dans l'ombre à la place.

Il y a beaucoup de techniques intéressantes pour rendre ces ombres basées sur une carte plus belles, avec moins d'artefacts / alias, mais je vais les passer en revue pour l'instant. Il suffit de dire qu'ils ne sont généralement pas gratuits non plus.

Parce que cela nécessite de restituer (jusqu'à) toute la scène à partir de la perspective de chaque lumière - jusqu'à six fois s'il s'agit d'une lumière ponctuelle qui brille dans toutes les directions {nord, sud, est, ouest, haut, bas}, et nous devons re -Rendre la carte fantôme chaque fois que quelque chose bouge, cela peut devenir très cher.

Ainsi, les jeux concentrent souvent leur budget de rendu sur les lumières les plus importantes de la scène - comme la lumière solaire directionnelle - pour s'assurer qu'elles ont de belles ombres. Les petites lumières de courte durée et mineures comme le flash d'une explosion sont souvent pardonnables si elles s'échappent un peu des occluseurs. Souvent, cela est plus agréable pour les joueurs qu'un accroc dans le framerate en raison d'une augmentation soudaine du coût de rendu de tout le rendu et du calcul de la carte d'ombre supplémentaire. Surtout s'il s'agit d'une scène d'action occupée où la fluidité importe plus que la perfection des pixels.

Pour faire court, cela se produit pour des raisons de performances.

Lorsqu'il y a une lumière sur l'écran, par défaut, elle brille sur tous les objets (obstrués ou non), donc le jeu devra faire des calculs supplémentaires pour voir quel objet est affecté par quoi.

C'est plus facile à résoudre sur les objets statiques en utilisant un éclairage statique et cuit, mais ce n'est pas la même chose sur les lumières dynamiques, comme les explosions comme vous l'avez noté.

Pour votre question bonus, ray tracing et cheap ne vont pas ensemble sur la même phrase. La seule raison pour laquelle le lancer de rayons n'a pas été intégré jusqu'à présent est la performance. En supposant que toutes les lumières utilisent le lancer de rayons, ce problème serait "résolu", mais au détriment des performances.