Discussion :

[Ti-R]

On peut toujours faire de l'approximation.
Cette technique est déjà utilisé dans le moteur Frosbite à partir de la version 2 (Battlefield 3 et +)
Cela fonctionnement bien pour certain type de lumière, mais c'est quand même "super limité".

La démo de Brigade 3 c'est 2 cartes NVIDIA à 1000€ la carte et c'est déjà hyper optimisé.

Et même si niveau code on améliore encore les performances, même si on fait 30% mieux (ce qui serait déjà énorme), et même en optimisant encore on arrive à faire 2 fois plus rapide niveau soft, il n'y a pas de miracle, cela va être 2 fois moins bruité et c'est "tout". Pour avoir un rendu complet cela nécessite forcément du hardware 100 à 1000x plus puissant. Le facteur d'échelle n'est pas le même.

Et d'ailleurs cela ne sert à rien d'avoir un moteur de folie sans avoir toutes les données pour nourrir le moteur. Donc faire des textures super détaillés, des meshs super détaillés (même si on fait de la tesselation dynamique, il faut quand même des tonnes de données super haute résolution au départ pour générer les textures). Et faut animer tout cela, donner de l’intelligence artificiel qui va aussi loin etc...

Le moteur 3D c'est presque juste un "détail" pour avoir un jeu complet.

Mirror Edge c'est énormément de pré-calculé et super bien fait.
Wolfenstein 3D c'est du raycasting, je n'ai rien contre la technique mais c'est vraiment une niche du raytracing et on ne peut pas vraiment mettre les 2 sur le même plan (comprendre le jeu de mot ).

[wax78]

Donc faire des textures super détaillés, des meshs super détaillés (même si on fait de la tesselation dynamique, il faut quand même des tonnes de données super haute résolution à départ pour générer les textures).

D'ou certains tentent le tout procédural. Textures ou meshs ne prennent presque "aucune" place, par contre le temps CPU (ou GPU) est impacté (forcement) evidement cela n'est pas "artist friendly".

[yahiko]

Et même si niveau code on améliore encore les performances, même si on fait 30% mieux (ce qui serait déjà énorme), et même en optimisant encore on arrive à faire 2 fois plus rapide niveau soft, il n'y a pas de miracle, cela va être 2 fois moins bruité et c'est "tout". Pour avoir un rendu complet cela nécessite forcément du hardware 100 à 1000x plus puissant. Le facteur d'échelle n'est pas le même.

Là, faudra quand même que tu apportes un minimum de preuve ou de source des chiffres que tu avances...
Par exemple la technique du Radiance Filtering telle que indiquée page précédente peut être une piste pour éliminer le bruit à un coût computationnel acceptable.

Je reste en tout cas intimement persuadé que l'ère du full raytracing en temps réel n'est plus si lointain.

[wax78]

Je pense aussi.

Il suffit déjà de voir certains moteur de rendus (cycle, Thea render, octane et j'en passe).
Certes tout est +- statique (ce qui est un problème aussi quand tout est dynamique et se déplace dans l'espace) donc ca facilite, mais pour des cas simple on est pas loin d'un certains "temps réel" avec un qualité correcte visuellement.

Évidement on pourra toujours faire en sorte de rajouter des raffinement qui mettront toujours a genoux les machines mais si on se limite a certains truc ca pourrait le faire.

[Dabou Master]

D'ou certains tentent le tout procédural. Textures ou meshs ne prennent presque "aucune" place, par contre le temps CPU (ou GPU) est impacté (forcement) evidement cela n'est pas "artist friendly".

Oula la faux ! ^^ (je dis ça gentiment parce que ça sonne super méchant dit comme ça)
Les meshes qu'on utilise dans le jeu vidéo actuel ne pèsent pas lourd à côté même de simples textures dès qu'elles ont une certaine résolution.
Par contre en effet avec un moteur comme celui-là (Brigade) il est vrai qu'il faudrait des modèles réellement plus détaillés, beaucoup plus détaillés pour trouver tout son intérêt et ça ça peut vite peser lourd. Mais bon le défaut dans cette théorie c'est qu'il faudrait probablement un plus gros multiplicateur que 1000 pour faire tourner une petite scène avec cinq personnages et le tout sans bruit ^^ (bien sûr si on continue de calculer tout de la même manière qu'aujourd'hui).
Pour l'instant c'est un simple moteur de rendu pré-calculé légèrement modifié dans son fonctionnement ce Brigade, Cycles (de Blender) n'est pas aussi rapide c'est clair et il est encore un peu jeune mais j'ai cru comprendre qu'Octane Render est aussi rapide (mais pas du tout orienté fps constant forcément) donc c'est un peu un faux progrès pour l'instant. Par contre je vois bien ce genre de technologie dans un jeu de stratégie (Anno) ou un jeu style caméra embarquée basé sur l'exploration et la découverte (le bruit pourrait éventuellement simuler une caméra de très mauvaise qualité et le grain s'occuperait de contribuer à une ambiance un peu sordide naturellement).
J'imagine que c'est la tesselation et les autres artifices comme ça qui vont prendre le relai mais je serais bien en peine de dire si ça prend de la place ou pas ça, quand on voit le poids des jeux aux technologies les plus récentes ça commence à faire peur.


Faut savoir aussi un truc, l'artiste n'est pas artist friendly ^^, on croit pas comme ça mais donnez-lui trop de libertés et il s'étouffe à avoir tenté de manger des polygones, ne sachant plus quoi en faire.

[wax78]

Oula la faux ! ^^ (je dis ça gentiment parce que ça sonne super méchant dit comme ça)
Les meshes qu'on utilise dans le jeu vidéo actuel ne pèsent pas lourd à côté même de simples textures dès qu'elles ont une certaine résolution.

Je ne le prends pas mal rassure toi. Mais je ne suis pas d'accord sur tout.

Un mesh généré proceduralement (ou simplement une texture générée procéduralement en temps réel ne prends pas de place juste du cpu. (Après rien n'interdit un pré calcul puis stockage du résultat, mais cela va prendre de la place). Regarde bien les exemple simpliste des truc genre ShaderToy :

0 données d'entrée (ou dans certains cas certaines petites texture) et les type te font des "mesh" (qui ne sont pas des mesh mais des fonction de distance estimée si je ne m'abuse que l'on combine ensemble pour arriver a un objet plus complexe) en te sortant un dauphin qui saute dans l'eau avec reflection, deplacement des vagues et bump mapping et j'en passe le tout avec des textures generée a la volée procéduralement. (ou alors une souris qui se promene dans un couloir (je ne trouve pas les liens maintenant zut)). Evidement la plupart utiliser un raytracer un peu biaisé qui donne moins bien que du pathtracing par exemple mais qui est déjà mieux que ce qu'on pourrait avoir maintenant avec toutes les astuce opengl/directx.

Par contre en effet avec un moteur comme celui-là (Brigade) il est vrai qu'il faudrait des modèles réellement plus détaillés, beaucoup plus détaillés pour trouver tout son intérêt et ça ça peut vite peser lourd. Mais bon le défaut dans cette théorie c'est qu'il faudrait probablement un plus gros multiplicateur que 1000 pour faire tourner une petite scène avec cinq personnages et le tout sans bruit ^^ (bien sûr si on continue de calculer tout de la même manière qu'aujourd'hui).

Ce n'est pas obligatoire d'avoir toujours plus détaillé, ou alors si, mais ca ne change rien, c'est ce que l'on fait depuis des années, entre wolfenstein 3D ou tout est plat et avec 2 polygones, et ce qu'on a maintenant (et comme tu le dis, si on rajoute un peu de tesselation etc ca devient "nickel".

Pour l'instant c'est un simple moteur de rendu pré-calculé légèrement modifié dans son fonctionnement ce Brigade, Cycles (de Blender) n'est pas aussi rapide c'est clair et il est encore un peu jeune mais j'ai cru comprendre qu'Octane Render est aussi rapide (mais pas du tout orienté fps constant forcément) donc c'est un peu un faux progrès pour l'instant. Par contre je vois bien ce genre de technologie dans un jeu de stratégie (Anno) ou un jeu style caméra embarquée basé sur l'exploration et la découverte (le bruit pourrait éventuellement simuler une caméra de très mauvaise qualité et le grain s'occuperait de contribuer à une ambiance un peu sordide naturellement).

Je suis d'accord qu'a l'heure actuelle il ne faut pas esperer avoir un jeu "First person shooter" genre crysis tout en raytracing... Par contre un simple jeu comme tu les décris ou un jeu de billard par exemple ca ca existe (pour en avoir fait l'experimentation avec Optix il y'a dejà quelques années). Après tu peux limiter certains effets, ou le sampling pour avoir plus laid mais plus rapide.

Faut savoir aussi un truc, l'artiste n'est pas artist friendly ^^, on croit pas comme ça mais donnez-lui trop de libertés et il s'étouffe à avoir tenté de manger des polygones, ne sachant plus quoi en faire.

Pas faux non plus. Mais ne demande pas un artiste qui ne sait pas coder de te pondre un shader avec des DE qui vont te dessiner une maison ou un canard ou dieu sait quoi... a moins qu'il soit artiste et développeur il préféra manger du polygone

[Ti-R]

Octane Render est basé sur brigade normal que c'est aussi rapide

La "radiance filtering" améliore bien les choses mais cela n'aide pas pour certaines parties, surtout pour tout ce qui est fin comme le spéculaire.

Tout le monde est basé sur la même "techno" GPU, donc les vitesses sont relativement proche.

Après je n'ai pas dit qu'on ne peut pas faire un mix de toutes les technos, c'est ce qui est d’ailleurs fait aujourd'hui dans tous les moteurs de jeux de haut niveau (unreal, unity, crysis).

Là, faudra quand même que tu apportes un minimum de preuve ou de source des chiffres que tu avances...
Par exemple la technique du Radiance Filtering telle que indiquée page précédente peut être une piste pour éliminer le bruit à un coût computationnel acceptable.

Je reste en tout cas intimement persuadé que l'ère du full raytracing en temps réel n'est plus si lointain.

Regarde juste les démos de Nvidia pour le rendu via leur bibliothèque OptiX/iray, "tout le monde" fait du rendu interactif, personne fait du full temps réel.

A regarder la vidéo, sur la voiture, je ne parle même pas d'un jeu, on est loin du temps réel et pourtant c'est un serveur avec 8 GPU (le iray VCA)

[wax78]

Ce qui me fait rire encore une fois, c'est la non distinction entre algo biaisé (rapide et moins beau) qui permet de faire ce que l'on voit avec Optix et les algo non biaisé (cycles, octane) ou le mix des 2 comme tu sembles l'indiqué... personne n'en a parlé jusque la il me semble et pourtant ca me semble la "base du problème" performances versus réalisme

[yahiko]

Merci pour la vidéo.

J'ai peut être tort, mais ça ne fait que me renforcer dans ma conviction que le full RT² (Real-Time Ray Traycing, une nouvelle dénomination que je devrais copyright ^^) c'est pour dans pas longtemps.

Le mec dit d'ailleurs que ce qui aurait nécessité des milliers d'ordinateurs il y a une dizaine d'années, n'en nécessite qu'une dizaine (certes costauds, mais tout de même).

[Invité]

Salut, pour le moment je fais le raytracing dans le shader comment ?

Comme ceci :

Je transforme les coordonnées monde des centres de mes lumières en coordonnées fenêtre et je les passe au shader, je passe également la normal map avec les normales et la hauteur de chaque fragments de la scène et je récupère le rayon entre le centre de la lumière et chaque fragments de la scène afin de calculer l'atténuation pour chaque fragments lumineux que je dessine sur une texture de rendu : la lightmap.

Ensuite je dessine la lightmap sur la scene en blend multiply.

L'avantage est que je peux dessiner n'importe quelles formes de lumière (étoiles, lunes, etc...) exactement comme ci c'était, un objet de la scène.

Je pense, à l'avenir, utiliser mon système de particules et mettre en œuvre la physique, comme présenté dans les démos-scènes :

[Ti-R]

On peut tout faire avec du raytracing, le but étant de faire des images réalistes et donc je parle toujours personnellement du non biaisé Optix/Iray inclus. On peut très bien faire un moteur beaucoup plus rapide si biaisé, mais je ne vois pas l'intérêt. Aujourd'hui on fait de plus en plus de shaders qui implémente des rendus physiques.

Pour parler de la vidéo, c'est 8 GPU en parallèle pour produire une image qui converge en quelques secondes et donc à peu près non bruité. Disons entre 5 et 10 secondes. Avec un calcul naïf, si on souhaite un jeu à 60 FPS, cela fais entre 300 et 600 fois plus rapide, et si on souhaite la même chose sur 1 seul GPU, on est à peu près entre 2400 et 4800 fois la puissance disponible sur une carte haut de gamme aujourd'hui.

[yahiko]

Et si on extrapole les progrès dans le rendu tels qu'énoncés par le présentateur, on peut espérer avoir quelque chose qui tienne la route dans une dizaine d'années.

[Ti-R]

Et si on extrapole les progrès dans le rendu tels qu'énoncés par le présentateur, on peut espérer avoir quelque chose qui tienne la route dans une dizaine d'années.

Peut être dur de dire, mais en tout cas le bientôt dans 10 ans, ce n’est pas pour de suite. C'est ce que je voulais signaler depuis le début, cela se fera peut-être un jour

10 ans en informatique c'est énorme, dur de dire/prédire ce qu'il y aura et ce qu'on aura inventé entre temps.

[yahiko]

Oui, tout est relatif évidemment... 2005 c'est sûr que c'était l'âge des cavernes

[Dabou Master]

Je ne le prends pas mal rassure toi.

Tant mieux ! Je trouve toujours que ça fait super prétentieux de le dire mais c'est tellement rare que je puisse le dire que je me jette dessus (et me casse les dents à 80% des cas ...). ^^

Un mesh généré proceduralement (ou simplement une texture générée procéduralement en temps réel ne prends pas de place juste du cpu. (Après rien n'interdit un pré calcul puis stockage du résultat, mais cela va prendre de la place). Regarde bien les exemple simpliste des truc genre ShaderToy (...)

Euh oui je ne parlais pas des meshes générés procéduralement, je parlais juste des modèles créés de façon traditionnelle en low-poly qui effectivement pèsent souvent moins lourd qu'une simple texture (qui n'est pas bien lourde non plus en général). Je ne savais même pas qu'il y avait des façons de générer un mesh de façon procédurale (enfin j'ai déjà vu des démos techniques de toute une scène créée par le code mais je sais pas du tout si c'est le même principe ou pas, je nage un peu et c'est loin du domaine artistique, on est plutôt dans l'Art du code ^^).

Ce n'est pas obligatoire d'avoir toujours plus détaillé, ou alors si, mais ca ne change rien, c'est ce que l'on fait depuis des années, entre wolfenstein 3D ou tout est plat et avec 2 polygones, et ce qu'on a maintenant (et comme tu le dis, si on rajoute un peu de tesselation etc ca devient "nickel".

Euh oui et non. Une question toute bête qui peut avancer les choses : as-tu déjà utilisé un moteur de rendu unbiased pour une scène 3D ?
Ce qui m'a choqué la première fois avec Cycles c'était le côté ultra réaliste de la matière, le cube était magnifique, c'était un fichu cube et pourtant il était superbe !
Puis alors je me suis amusé à mettre mes sculpts et à regarder comment ça rendait, c'était fabuleux, un vrai truc (difforme et moche peut-être !) sculpté dans la pierre, l'émerveillement de la nouveauté pour moi ^^.
Par contre je suis reparti sur mon modèle low-poly avec normal map etc. et là c'est le drame. Alors il y a une possibilité certaine que je ne maîtrise pas comment faire en sorte que les astuces du low poly rendent bien sur ce type de moteur mais dans tous les cas là où on peut carrément n'y voir que du feu sur un moteur classique, Cycles ne pardonne pas l'absence de relief "réel". Alors bien sûr la tesselation c'est du relief réel mais calculé après coup par une puce dédiée, donc je pense que là il n'y a aucun souci, par contre les normal maps sont presque à mettre à la trappe alors que c'est un truc absolument essentiel pour les moteurs classiques ("biased" j'imagine).
C'est donc en ça que je dis que là on n'a pas le choix il faut vraiment du détail, ou alors un style très épuré, un minecraft pourrait être vraiment magnifique avec un moteur de ce type sans se retrouver à crouler sous les polygones. Par contre si on veut un FPS à la crysis là il faudra du vrai relief partout pour avoir la même vraisemblance sur le plan des modèles (sans prendre en compte l'éclairage et tout le tintouin) et là c'est juste pas possible à moins qu'on trouve encore d'autres astuces ou que les astuces existantes s'améliorent.

Pas faux non plus. Mais ne demande pas un artiste qui ne sait pas coder de te pondre un shader avec des DE qui vont te dessiner une maison ou un canard ou dieu sait quoi... a moins qu'il soit artiste et développeur il préféra manger du polygone

Le gros problème c'est qu'un artiste doit savoir coder de nos jours . Bien sûr je me doute que c'est pas du tout aussi compliqué que de passer en bas niveau (on se limite à du très haut niveau style python que je sache) mais bon dans l'idéal faudrait que j'apprenne l'OSL et ça si j'ai bien compris il va falloir coder :'(. (Que tous les handicapés du code compatissent avec moi).
N'oublie pas qu'après la modélisation il y a l'unwrapping, le rigging, l'animation. Si les moteurs unbiased ne rendent pas aussi bien des textures illusoires que leurs prédécesseurs il se peut que la totalité de leur technologie ne soit jamais implémentée dans les jeux vidéo (c'est une simple hypothèse), la limite de polycount n'est pas qu'une question de puissance des machines mais aussi d'organisation de l'équipe artistique .


Sinon plus généralement, est-ce que vous êtes au courant que si les moteurs unbiased sont formidables en extérieur ils deviennent une calamité dans une pièce fermée avec peu de sources de lumières ? On peut en arriver à un multiplicateur supérieur à 10 pour le même rendu entre une scène extérieure et intérieure.
Du coup ça limitera forcément les types de jeux disponibles, ou alors il n'y aura que des hybrides biased/unbiased (ou d'autres inconnus).

[wax78]

Euh oui et non. Une question toute bête qui peut avancer les choses : as-tu déjà utilisé un moteur de rendu unbiased pour une scène 3D ?
Ce qui m'a choqué la première fois avec Cycles c'était le côté ultra réaliste de la matière, le cube était magnifique, c'était un fichu cube et pourtant il était superbe !

La liste est longue : maxwell, kerkythea, thea, cycle, octane, indigo, luxrender, ... tout ce que je pouvais tester je me suis amusé avec, j'en ai même écrit la dose (pas aussi performant ou aboutit hein on se comprend) dans différent environnement sur cpu et gpu et je me suis documenté un max pour bien comprendre ce qu'était réellement "les images de synthèse comme on disait dans le temps". Bien entendu ca inclus les biased aussi.

Cycles est pas mal c'est sure avec le systeme de node pour faire des materiaux délires et tout le tsointsoin, ca devient vraiment un "arme ultime" de la création.

Par contre je suis reparti sur mon modèle low-poly avec normal map etc. et là c'est le drame. Alors il y a une possibilité certaine que je ne maîtrise pas comment faire en sorte que les astuces du low poly rendent bien sur ce type de moteur mais dans tous les cas là où on peut carrément n'y voir que du feu sur un moteur classique, Cycles ne pardonne pas l'absence de relief "réel". Alors bien sûr la tesselation c'est du relief réel mais calculé après coup par une puce dédiée, donc je pense que là il n'y a aucun souci, par contre les normal maps sont presque à mettre à la trappe alors que c'est un truc absolument essentiel pour les moteurs classiques ("biased" j'imagine).

Trop low poly c'est sure que ca n'ira pas. Mais si tu arrives dans un moteur de jeu a un truc potable, tu arriveras forcement a faire mieux dans cycles (ou autres). Faut juste voir si tu fais bien ce qu'il faut pour.
La tesselation comme tu dit n'est pas du relief. C'est un subdivision des polygones bien particuliere qui ne change pas le relief. Pour changer le relief tu fais du "displacement".
Dans les moteur de rendus, l'equivalent de la tesselation pourrait être une simple subdivision. Ensuite tu pourrais appliquer sur le mesh un texture "displacement map" qui donnerait un relief supplementaire. Meme principe que les normal map, mais en plus gourmand et plus réaliste. Mais les 2 peuvent être combiné pour rajouter encore plus de détails.

Par exemple ici j'ai un plan subdivisé un peu (genre 32x32 noeuds), donc du très low poly.
Passé a la subdivision (pour passer a beaucoup de noeuds).
Passé dans un displacement (texture procédural genre fractale pour "terrain").
Avec en plus des normal map pour les fin details (la partie plus orangée montre l'effet de la normal map).
Et bien sure un shader pour calculer la couleur en fonction de l'altitude, la pente etc pour donner l'illusion.
D'ailleurs on voit sur la derniere image des polygones sur la droite...

N'oublie pas qu'après la modélisation il y a l'unwrapping, le rigging, l'animation.

Pas forcement toutes ces étapes, mais l'uv unwrapping ca c'est presque incontournable. Le reste ca devient du domaine de l'animation et des jeux.

Si les moteurs unbiased ne rendent pas aussi bien des textures illusoires que leurs prédécesseurs il se peut que la totalité de leur technologie ne soit jamais implémentée dans les jeux vidéo (c'est une simple hypothèse), la limite de polycount n'est pas qu'une question de puissance des machines mais aussi d'organisation de l'équipe artistique .

Les moteurs ne rendent pas les textures ou alors je ne te comprends pas. Je dis ça dans le sens ou ca rends un materiel et non une texture. Mais illusoire par contre j'avoue ne pas comprendre le sens.

C'est sure que pour le polycount, y'a des jeux excellent qui ne sont pas forcement laid, mais qui donne bien parce que le mélange est bon et que l'illusion est la.

Sinon plus généralement, est-ce que vous êtes au courant que si les moteurs unbiased sont formidables en extérieur ils deviennent une calamité dans une pièce fermée avec peu de sources de lumières ? On peut en arriver à un multiplicateur supérieur à 10 pour le même rendu entre une scène extérieure et intérieure.
Du coup ça limitera forcément les types de jeux disponibles, ou alors il n'y aura que des hybrides biased/unbiased (ou d'autres inconnus).

Comme tu le soulignes c'est bien un oui et non et comme tu le dis mais formulé différemment :

- Non dans le cas ou il y'a assez de sources de lumières "visibles facilement" ça reste correcte.
- Oui dans le cas d'un bunker à 2 étage (en sous sol) avec un petite ouverture vers l'extérieur qui fait que t'as une chance sur un milliard qu'un rayon de lumière arrive déjà au 1 étage, et le reste de chance comme au loto pour le 2 ème étage ou la camera se trouve

Il y'a bien entendu des hybrides rien ne l'interdit.

[Dabou Master]

La tesselation comme tu dit n'est pas du relief. C'est un subdivision des polygones bien particuliere qui ne change pas le relief. Pour changer le relief tu fais du "displacement".

Autant pour moi, pour le displacement je connais déjà le principe mais la tesselation reste la grande inconnue pour moi, le seul truc que j'en avais compris, sans aucune certitude, c'est une sorte de division par triangles (qui du coup n'a pas besoin d'appliquer la bête fonction uniforme catmull-clark qui est vite très coûteuse en termes de polygones) qui apportait du détail par endroits, là où c'était nécessaire. Là où c'est tordu c'est que je me suis basé sur la "fausse" appellation de "tesselation dynamique" qu'on donnait aux techniques apportées notamment par Sculptris avant son rachat par Pixologic (technique qu'on retrouve maintenant dans Blender sous le nom "dynamic topology" et qui existe aussi chez Zbrush bien sûr, pour les autres je ne sais pas). Si c'est pas clair ben ça partait sur une base forcément en triangles (une ico-sphere, par une uv-sphere) et ça divisait les faces sur lesquelles on travaillait sans encombrer le reste de la sculpture de subdivisions indésirables. On pouvait toujours avoir recours à une subdivision générale malgré tout dans Sculptris, et on avait une brosse pour rajouter de la définition (division localisée de triangles) ou pour en enlever sans que ça bouffe trop le détail.
Partant de là c'est tout ce que j'avais réussi à comprendre de la tesselation en sachant que c'était bancal dès le départ.
Enfin si t'as des liens ou documents sur le principe de la tesselation je suis preneur!

Pas forcement toutes ces étapes, mais l'uv unwrapping ca c'est presque incontournable. Le reste ca devient du domaine de l'animation et des jeux.

Comme ça parlait beaucoup de l'implémentation de ces technologies dans les moteurs de jeux j'ai effectivement abordé le sujet dans ce cadre-là. Sinon quel autre intérêt pour les autres domaines, je ne vois que du pré-calculé, mais je ne connais pas toutes les applications possibles desdites technologies.

Les moteurs ne rendent pas les textures ou alors je ne te comprends pas. Je dis ça dans le sens ou ca rends un materiel et non une texture. Mais illusoire par contre j'avoue ne pas comprendre le sens.

Euh oui euh je me suis dit que ça faisait un peu trop littéraire quand je l'ai écrit ^^. Les normal maps sont ce que j'appelle des textures illusoires (elles donnent l'illusion du relief en accrochant les ombres à la matière comme s'il y en avait). Je dis peut-être une énorme bêtise, et quand on n'est pas expert on a tendance à prendre des raccourcis où tout le monde se comprend même si on se plante tous, mais ce n'est pas le moteur qui va afficher la texture ? La texture est appliquée sur un matériau, matériau appliqué sur un modèle. La déformation de la texture sur le modèle (parce que c'est pas tout plat donc forcément c'est déformé) ainsi que le modèle en lui-même, tout ça n'est pas rendu par le moteur ? Non là c'est moi qui suis paumé, qu'est-ce qui est vrai qu'est-ce qui ne l'est pas ?

Comme tu le soulignes c'est bien un oui et non et comme tu le dis mais formulé différemment :

- Non dans le cas ou il y'a assez de sources de lumières "visibles facilement" ça reste correcte.
- Oui dans le cas d'un bunker à 2 étage (en sous sol) avec un petite ouverture vers l'extérieur qui fait que t'as une chance sur un milliard qu'un rayon de lumière arrive déjà au 1 étage, et le reste de chance comme au loto pour le 2 ème étage ou la camera se trouve

Hum, ben de ce que j'en ai vu, une pièce sombre, avec une faible source de lumière (ou même deux faibles) telle une lampe de chevet par exemple ou une petite fenêtre, ça transformait le moteur de rendu en une grosse usine à gaz. Bon après je l'avais cherché mais disons que dès que je ferme une scène et que je ne l'éclaire pas comme un sagouin, j'observe des chutes terribles de performances.
Du coup je me dis que si on veut faire un jeu style survival horror avec juste une lampe de poche, ça risque d'être super coton non ?

[Ti-R]

Pour répondre à la question initiale:

Le rendu au raytracing dans les jeux vidéo.

Le lancer de rayon non biaisé (unbiased raytracing) temps réel n'existe pas dans les jeux vidéo aujourd'hui et ne sera pas utilisé avant de nombreuses années à cause d'un problème de matériel pas encore adapté.

Le lancer de rayon non biaisé (unbiased raytracing) est surtout utilisé par les graphistes pour générer des textures utilisées ensuite en temps réel.

Le lancer de rayon biaisé (biased raytracing) est souvent utilisé pour ajouter certains effets particulier en temps réel (ombres, réflexions, calcul de lumières, semblant d’illumination globale etc.. voir mon post sur Unity et Frosbite comme exemples non exhaustif).

[yahiko]

Néanmoins, je pense qu'on devrait voir de plus en plus une généralisation du Ray Tracing en temps réel (dégradé avec des filtres pour alléger la charge) dans le rendu des JV.

[DonQuiche]

Au passage personne n'a parlé des avantages et inconvénients du raytracing pur (par opposition aux bidouilles des démos et à son usage restreint pour l'illumination globale qui va effectivement se généraliser pour le plus grand bien).

Car à puissance égale je ne vois pas pourquoi le rendu en raytracing pur serait supérieur à celui d'une rastérisation puisqu'il me semble que la rastérisation n'a finalement toujours été qu'une collection d'astuces pour aller plus vite que le raytracing. Si on avait dix fois plus de puissance on ne pourrait toujours pas faire de raytracing mais on pourrait déjà rastériser des cubemaps environnementales tous les N pixels et s'en servir comme modèle d'illumination globale indirecte en temps réel. Et à mon avis on aurait un résultat qui ressemblerait fichtrement au raytracing, si on omet les problèmes mineurs inhérents à nos techniques (transparence, diffraction, transluminescence, etc) qui nécessitent des bidouilles ad hoc.

J'ai l'impression que le seul vrai avantage du raytracing c'est la simplicité aux dépens des performances : plus besoin de toutes ces bidouilles. Et à l'heure où on revenu vingt ans en arrière dans la gestion de la transparence du fait du rendu différé, ça ne ferait pas de mal.

Non ?