Discussion :

[skeud]

Dans le cas d'une lumière directionnelle pour simuler le soleil, tu n'as pas besoin. Car tu ne calcule pas le rayon de lumière en fonction de la position de la source, mais via le vecteur de direction directement. La hauteur permet de définir les surface éclairés, des surface qui ne le sont pas. C'est pourquoi la position de la lumière ne change rien, seule la hauteur et le vecteur de direction importe . Pour donner l'illusion d'un soleil qui se déplace (système jour/nuit), on fait varié le vecteur et la hauteur du spot:
pour la hauteur:
-100 ___ 0 _____ 100 _____ 0 ____ -100
____ nuit _ matin ___ aprem __ nuit ____

Ainsi que le vecteur de direction, on lui fait faire une rotation de 360° en fonction de l'axe de rotation du soleil .

[Invité]

Oui je fais comme skeud l'a dis : je simule le soleil en plaçant une lumière loin de la scene, je m'en sert pour générer les ombres, les lumières, j'en profite également pour générer la heightmap et la normal map. (Puisque comme le soleil est toujours pile au dessus de la caméra dans mon cas, je n'ai pas besoin de fournir la normal map avec les matériel, je ne fais juste que de définir les informations pour la calcul de la lumière spéculaire)

Je viens encore d'effectuer une correction pour que lors de la rotation de la caméra sur l'axe z, la vue du dessus (à la position du soleil) soit aussi rotationnée. (Sinon elle n'était pas bien positionnée. :/)

Bref cette technique me permet de dessiner n'importe quelle lumière comme si je dessinais un bête cube, ou encore une bête sphère.

Cette technique est beaucoup utilisée dans les logiciels comme blender par exemple.

[skeud]

Cette technique fonctionne lorsque tu n'as qu'une seule lumière, mais quid de plusieurs lumières?

Si tu ne définis pas tes normal map et heigh map dans le matériel, tu te retrouveras coincé lorsque tu voudras implémenté les spots de lumière :/.
De la même manière, ta lumière ambiante ne sera pas déplaçable, du coup le rendu de réalisme sera moins bien.

Le fait de placer tes map dans le matériel t'évite aussi de devoir les recalculer à chaque frame, donc gain de performance.

[Invité]

Cette technique fonctionne lorsque tu n'as qu'une seule lumière, mais quid de plusieurs lumières?

Le plus gros problème avec les pré-rendu c'est de savoir comment placer la caméra. si j'ai plusieurs lumières il suffira juste que je change la position de la caméra lors du rendu des lumières et lors de la génération des ombres et la matrice de projection qui me permet d'orienter les entités vers la lumière, les redimensionner et les translater pour le rendu des ombres.

Mais, il me semble que les normales pointent toujours vers le haut donc, les générer en plaçant la caméra là ou se trouve une lumière très haute (le soleil par exemple) me donnera la bonne heightmap et la bonne normal map sur la scene.

PS : il faut dire que ma caméra est fort avancée, je peux faire de la projection en perpesctive ou bien orhtographique, faire des rotations autour des axes x, y et z de la caméra combiner avec un lookat.
Ca me permet de placer la caméra ou je veux et faire des rendu de la scene à parti de là ou je le souhaite.

A condition bien sûr que les entités dessinés sur la texture de rendu, se trouvent bien pile au dessus de la caméra de base.

Mais pour cela il suffit de faire une translation du vecteur entre les deux caméras et une rotation sur l'axe z de la vue du dessus.

J'ai modifier le code source du moteur, désormais, même si je fais une rotation de la vue, les lumières et les ombres s'affichent correctement.

Chose qui ne se faisait pas avant.

[skeud]

Mais du coup tu re-génère tes map pour chaque objet, à chaque frame, ça doit être hyper gourmand en ressource :/. C'est peut-etre pour ça que tu n'as pas un FPS très élevé :/.

Les normal ne pointe pas toujours vers le haut, elle pointe vers la perpendiculaire de la tangente de la surface .

Le rendu, tu le fais en raycasting?

[Invité]

Mais du coup tu re-génère tes map pour chaque objet, à chaque frame, ça doit être hyper gourmand en ressource :/. C'est peut-etre pour ça que tu n'as pas un FPS très élevé :/.

J'ai testé, mais dès que j'utilise un shader mon FPS baisse déjà fortement (sans pour autant le faire à chaque frame), et oui je dois faire ça à chaque frame, mais je n'ai pas le choix si je veux vraiment faire de meilleurs rendus. :/

La tangeante à la surface, je la calcul aussi avec un shader, car quand je place la caméra juste au dessus de la caméra de base pour avoir la vue du dessus, je sauvegarde la position en z des fragments dans la texture, et je peux ensuite, récupérer la tangeante et la binomiale à l'aide de textureoffset qui me donne la position en z des fragments voisins.

Je ne génère pas les normal map par entités, je les génères sur toute la partie de la scène qui est élevé.

15 FPS (frame rate des dessins animé) ce n'est pas énorme mais tant que ça ne saccade pas je m'en fou, il existe un tas de techniques modernes pour pouvoir faire des rendus critiques au niveau des performances avec un FPS plus bas.

PS : je ne vais pas donné plus d'explications ici, je pense que le code source sur mon répertoire github en dis déjà beaucoup.

Il faut juste éviter de chuter en dessous de ça sinon..., là ça commence à se voir que ça saccade.

PS : Oui, c'est du raycast.

[skeud]

Pourquoi ne pas calculer dans ce cas la heigh map et normal map une seule fois puis la stocké, tu gagnerais énormément à faire ça :/ Car là, 15 FPS, c'est vraiment ultra hyper méga juste :/.

Un moteur graphique se doit de pouvoir tourner avec une scène simple à 60 FPS minimum. Et avec une scène compliqué, minimum 20-25 FPS, mais pas en dessous. L'oeil humain voyant les images à 24FPS, il faut pas descendre en dessous, sinon le changement de frame sera visible.

EDIT:

Du raycast, j'en ais beaucoup fait . Je pourrais te filer un coup de main sur pas mal de chose du coup .
En tout cas très bon choix, le raycasting permet d'avoir un rendu hyper propre par rapport aux autres moteurs. Par contre c'est beaucoup plus gourmands en ressources et en optimisation ^^.

[Invité]

Pourquoi ne pas calculer dans ce cas la height map et normal map une seule fois puis la stocké, tu gagnerais énormément à faire ça :/ Car là, 15 FPS, c'est vraiment ultra hyper méga juste :/.

Un moteur graphique se doit de pouvoir tourner avec une scène simple à 60 FPS minimum. Et avec une scène compliqué, minimum 20-25 FPS, mais pas en dessous. L'oeil humain voyant les images à 24FPS, il faut pas descendre en dessous, sinon le changement de frame sera visible.

Je suis conscients que j'ai encore quelques optimisations à faire pour les scènes plus compliquée.

Pour la normal map et la heightmap je pourrais en effet en générer une par entité, et la passé au matériel de l'entité, bref, je ferai ça dans les optimisations à venir.

Du raycast, j'en ais beaucoup fait . Je pourrais te filer un coup de main sur pas mal de chose du coup .

Ca, ça serait cool.

[skeud]

L'idéal serait que tu ouvres une discussion où l'on pourrait partager sur la manière de réaliser un moteur raycasting, je pourrais te donner mon avis de cette manière sans polluer ce thread .

Je te filerais pas de coup de main en programmation par contre (j'ai même pas le temps de m'occuper de mon projet perso pour l'instant ^^). Par contre, sur la manière logique de faire et sur l'analyse de bout de code, y a pas de soucis, je pourrais te filer un coup de main ^^.

[Invité]

Oui, juste pour la logique ça serait pas mal, au niveau du code ça, je peux me débrouillé.

Il faudrait que je puisse t'expliquer comment je fais là et si t'a des idées pour l'optimisation là je serai preneur.

Je sais pas peut être faire ça sur mon devblog car je vois mal comment expliquer cela sans shéma. :/

Bref je ferai un article là dessus.

[skeud]

Mieux vaut faire ça sur dvp, ça permettra d'avoir un fil de discussion très intéressante pour les personne voulant s'essayer à ce genre de programmation, ensuite rien ne t'empêche de copier les parties les plus intéressantes sur ton blog .

Mais perso, j'irais pas discuter de ça sur ton blog, ne serait-ce que pour avoir l'avis d'autres personnes sur DVP en même temps.

Je t'invite donc à ouvrir une discussion sur le forum pour m'expliquer les principes logiques de base que tu utilise, je te dirais ce que j'en pense, et comment (peut-etre) arrivé à optimiser le tout .

[Invité]

Ha mais attend!

Le raycasting oblige à lancer des rayons, moi, je ne veux pas lancer de rayons, je veux juste dessiner une sphere de lumière par exemple, et calculer l'atténuation en fonction de la distance entre le centre de la sphere et le fragment éclairé, avec la normale, la composante spéculaire, etc...

Je ne sais pas si on peut appeler ça du raycasting, je mets bien la vue au dessus pour avoir une vue en 2D comme expliqué sur wikipédia, mais au lieu de lancer un rayon, je dessine une sphere jaune.

Donc je met la vue au dessus pour générer la heightmap et la normal map, ensuite je dessine la sphere de lumière, et ce qui ne se trouve pas dans la sphere n'est pas éclairé, ce qui se trouve dans la sphère est +/- éclairé suivant la distance entre le centre de la sphère et le fragment.

Pour les lumières directionnelles je pensais à faire un cône avec une direction.

[skeud]

Je suis clairement pas sur que tu utilises les bonnes technique pour un moteur de rendu :/. Car j'ai jamais vu de moteur de rendu avec une histoire de sphère :/.

La lumière reflété par un objet dépend effectivement de la distance, mais aussi:
_ de la normal à la surface
_ l'angle incident du rayon sur l'objet.
_ La diffraction de la matière.
_ La réflexion de la matière.

Et pour la lumière, il n'y a pas d’histoire de sphère ou de cône, ça ne fera que augmenter le difficulté de faire comme ça, car tu manipuleras beaucoup plus de données, et les calculs seront beaucoup plus compliqué, ce qui entraînera une perte de performance.

Concernant l'affichage, tu utilise openGL du coup? Ou tu utilise un système de raycasting pour calculé la valeur de chaque pixel de ton écran?

[Invité]

Non, je fais comme ça en fait :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
 
const std::string perPixLightingFragmentShader =
                    "#version 130 \n"
                    "uniform sampler2D normalMap;"
                    "uniform sampler2D heightMap;"
                    "uniform vec3 resolution;"
                    "uniform vec4 lightColor;"
                    "uniform sampler2D lightMap;"
                    "uniform vec3 lightPos;"
                    "uniform vec3 radius;"
                    "uniform float maxM;"
                    "uniform float maxP;"
                    "in mat4 projMat;"
                    "void main () { "
                        "float far=gl_DepthRange.far;"
                        "float near=gl_DepthRange.near;"
                        "vec2 position =  vec2 (gl_FragCoord.x / resolution.x, gl_FragCoord.y / resolution.y);"
                        "vec4 bump = texture2D(normalMap, position);"
                        "vec4 specularInfos = texture2D(heightMap, position);"
                        "vec4 clipLightPos = projMat * vec4(0, 0, lightPos.z, 1);"
                        "vec3 sLightPos = vec3 (lightPos.x, resolution.y - lightPos.y, clipLightPos.z / clipLightPos.w);"
                        "vec3 pixPos = vec3 (gl_FragCoord.x, gl_FragCoord.y, bump.w);"
                        "vec4 lightMapColor = texture2D(lightMap, position);"
                        "vec3 viewPos = vec3(resolution.x * 0.5f, resolution.y * 0.5f, 1);"
                        "float z = (gl_FragCoord.w != 1.f) ? (inverse(projMat) * vec4(0, 0, 0, gl_FragCoord.w)).w : gl_FragCoord.z;"
                        "if (z >= bump.w) {"
                            "vec4 specularColor = vec4(0, 0, 0, 0);"
                            "vec3 vertexToLight = sLightPos - pixPos;"
                            "float attenuation = 1.0f;"
                            "vec3 a;"
                            "a.x = (radius.x != -1) ? 1.0f - (length(vertexToLight) / radius.x) : 1.0f;"
                            "a.y = (radius.y != -1) ? 1.0f - (length(vertexToLight) / radius.y) : 1.0f;"
                            "a.z = (radius.z != -1) ? 1.0f - (length(vertexToLight) / (radius.z / (far - near))) : 1.0f;"
                            "attenuation = (a.x + a.y + a.z) / 3;"
                            "vec3 pixToView = pixPos - viewPos;"
                            "float normalLength = sqrt(length(vertexToLight) * length(vertexToLight) -  dot(bump.xyz, vertexToLight) * dot(bump.xyz, vertexToLight));"
                            "vec3 lightReflect = vertexToLight + 2 * (bump.xyz * normalLength - vertexToLight);"
                            "float m = specularInfos.r * maxM;"
                            "float p = specularInfos.g * maxP;"
                            "float specularFactor = dot(pixToView, lightReflect);"
                            "specularFactor = pow (specularFactor, p);"
                            "if (specularFactor > 0) {"
                                "specularColor = vec4(lightColor.rgb, 1) * m * specularFactor;"
                            "}"
                            "if (bump.x != 0 || bump.y != 0 || bump.z != 0 && vertexToLight.z > 0.f) {"
                                "vec3 dirToLight = normalize(vertexToLight.xyz);"
                                "float nDotl = dot (dirToLight, bump.xyz);"
                                "attenuation *= nDotl;"
                            "}"
                            "gl_FragColor = vec4(lightColor.rgb, 1) * max(0.0f, attenuation);"
                        "} else {"
                            "gl_FragColor = lightMapColor;"
                        "}"

Mais tu vois là, pour l'instant, je dessine un cercle en 2D ou une sphere en 3D sur la texture de rendu, et je calcule la couleur en fonction de la normale du fragment et de sa composante spéculaire (je n'ai pas encore géré le reste), le but n'est de calculer la lumière que là ou c'est éclairé et je calcule l'atténuation en fonction du rayon de la sphère ou bien du cercle et de la distance entre le fragment de lumière et le centre du cercle.
Ainsi le shader n'est appelé que sur les fragments de la sphere de lumière et pas sur toute la scène.

Tu me suggérerais de faire comment ? De prendre le rayon entre le centre de la lumière et chaque fragment et de calculer l'atténuation comme ça ?

Il est vrai que je pourrais, ça me semblerais plus facile de faire comme ça.

Mais, c'est plus coûteux et ça n'utilise pas le principe du dereffered shading ça si ?

PS : Voici un tutoriel qui explique très bien le principe : http://mdeverdelhan.developpez.com/t...ght/tutoriel2/

[skeud]

Je ne comprends pas trop pourquoi tu utilises les fonctions de openGL pour les shader? Je croyais que tu codais ton moteur de rendu?
Ah moins que tu utilise openGL pour faire le rendu, dans ce cas je ne comprends pas pourquoi tu ne l'utilises pas pour ton moteur graphique en même temps?

Soit on recode tout, soit on utilise le moteur existant, si tu fait un mix des deux, tu vas te retrouver à avoir nombres de soucis de performances et de conception.

De plus, les shaders ne sont pas la pour calculer la lumière, mais pour modifier les propriété de l'objet en fonction d'un code. Donc on va modifier les propriété tel que:
_ La reflexion.
_ La refraction
_ La lumière
_ La position des sommets.
.....

Mais en aucun cas, on va décider de la quantité de lumière reçu ou prendre en compte la position d'une lumière, c'est le rôle du module de rendu de la lumière de s'en occuper.

De plus je ne pense pas que tu as découpé ton moteur graphique de la bonne manière si tu dois t'y prendre comme ça.

[Invité]

Hum, mon moteur graphique et mon moteur de rendu utilisent tout les deux openGL.
Comment tu fais pour calculer la lumière avec des lumières plus exotique comme par exemple des étoiles si tu ne décides pas de la quantités de lumière dans le shader avec une texture de prérendu ?

Tu est obligé de dessiner l'étoile et de calculer l'atténuation du fragment lumineux de l'étoile en fonction de la distance entre le centre de l'étoile et ce qui est éclairé. (Sans éclairé là entre les points de l'étoile)

Personnellement je ne trouve pas cela être une mauvaise idée de décidé de la quantité de lumière reçue dans le shader, n'oublie pas que ça dépend aussi de la transparence des fragments et ce genre de choses, l'eau ne sera pas éclairée comme on éclaire de la roche.

Ça ne dépend pas que de la réflexion, de la réfraction, etc...

Et c'est la même chose pour les ombres d'ailleurs.

Le fait de dessiner des lumières sur une texture de rendus (une texture à part donc) et de décidé de la quantité d'éclairage dans le shader offre beaucoup plus de possibilité je trouve.

Après je n'ai plus qu'à dessiné la texture de rendu sur la fenêtre et le tour est joué.

Je peux dessiner la scène en l'éclairant avec des lumières de n'importe quelle formes. (Cercle, Ellipses, Etoile etc... pour la 2D, Sphere, Ellipsoid, etc... pour la 3D)

PS : J'ai plusieurs moteur qui chacun effectue un prérendu sur une texture à l'aide d'un shader: le 1er pour le rendu de la lumière, le second pour la texture d'ombre, un troisième pour la heightmap, un quatrième pour la normalmap, et un cinquième pour le stencilbuffer.

Le moteur de rendu de la lumière utilise la texture de la heightmap et de la normalmap.
Le moteur de rendu des ombres utilise la texture du stencilbuffer.

J'ai également d'autre textures dans d'autres composants pour gérer la semi transparent avec le depthbuffer et le framebuffer.

Bref, je ne vais pas en dire de trop mes mon moteur de rendu est complexe et permet de faire pleins de choses, dessiner des étoiles sur une skybox, dessiner des particules sur les scènes 3D, (ainsi que des lumière et des ombres), etc...

Bref les lumières et les ombres sont générée sur un composant avec une vue 3D, et la ligtmap et la shadow map sur la fenêtre qui à une vue 2D.

[skeud]

Tu peux justement gérer l'éclairage grâce à la réfraction, c'est la quantité de lumière qui est retourner par ton material. Un material noir retournera pas de lumière par exemple, contrairement à un blanc.

Pour l'eau, dans ton shader, tu vas créer un plan, que tu vas déformer via le shader, en modifiant certaine arrête de ton plan et créant des sommets, ce qui donnera les vagues. L'interet de ce système c'est que c'est universel, tu n'aura pas besoin de faire un shader spécifique pour chaque lumière, chaque material.

Je te conseil vivement de regarder le tuto que tu m'as donné sur les shaders, il explique bien que ceux-ci sont fait pour altérer ton objet, et non pas faire des calcul de rendu.

Or avec ta solution, tu fais des calculs de rendu, ton shader ne devrait jamais avoir à faire ça. C'est ton module renderer qui doit s'en occupé. Celui-ci récupérera la normal, la réfraction, diffraction, réflexion de ton objet aux pixels demandé, ce qui lui permettra de calculer tout seul la lumière.
De plus les opérations des shader s'effectue directement sur la carte graphique, il faut donc pas faire de lancer de rayon dedans, comment tu feras lorsque tu voudra gérer la transparence, l'effet miroir, l'éblouissement? Crois moi, tu vas vite te retrouver bloquer si tu continues dans cette voie là. Et vaut mieux que tu change maintenant, plutot qu’après quand tu arriveras vraiment au bout du cul-de-sac ^^.

EDIT:

l'eau ne sera pas éclairée comme on éclaire de la roche

c'est faux, l'eau et la roche sont éclairé de la même manière, en revanche, ces deux matières renvoient la lumière différemment, c'est ce qui leur donne un aspect visuel différent.

Beaucoup de principe d'un moteur graphique sont vraiment basé sur la réalité, il suffit d'implémenter la réalité dans un moteur graphique pour avoir un rendu splendide. (bien sur on ne mettra pas autant de feature que dans la réalité ).

[Invité]

Mais ceci ne serait pas trop coûteux de récupérer le pixel dans la texture sans shader ?

Lire un pixel avec le CPU est une opération lente. :/

Bref, je ne vois pas du tout ou tu veux en venir. :/

[skeud]

Effectivement, le shader récupère la texture, mais il ne s'occupe pas de gérer l'éclairage .

Il va uniquement retourner les variable dont à besoin le moteur de rendu, à savoir:
_ La normale de ta surface (définis par la heigh map (plus communément appelé bump map) de l'objet, donc lecture de la heigh map par le shader)
_ La réflexion de ta surface (définis par le material, donc lecture du material depuis le shader).
_ La diffraction de ta surface (définis par la lightmap, donc lecture depuis le shader).
....

En gros tu peux utiliser une map pour chaque composante de la lumière, ce qui te permet de tout faire correctement .

De plus les shader ne doivent pas être codé dans ton moteur, c'est des fichiers qui sont lié à un objet de ta scène.
Normalement, tu dois avoir un fichier définissant ta scène, avec les objets.
Chaque objet se voit associé différente map et différent material.
Le shader est codé dans un fichier à part et ton moteur graphique doit le chargé et l'appliquer avant de dessiner ton objet.

La gestion de la luminosité est définis par les paramètre de tes lumières que tu rajoute dans le fichier de scène, ensuite openGL saura régler l'éclairage en fonction de la distante et du type de lumière.

Donc ce que tu fais n'est pas complètement faux, c'est juste que ton shader possède des traitements qui ne lui appartiennent pas .

C'est le principe KISS -> keep it stupid, simple.

Plus tu auras des traitement séparés, plus ton moteur sera performant et modulable, ce qui est très appréciable. La plupart des moteur graphiques fonctionnent de cette manière, car c'est la plus optimisée à l'heure actuelle .

Pour mieux comprendre:
OpenGL, lors du rendu de la scène, va récupéré les objets à afficher à l'écran. Pour chaque objet à afficher, il va récupéré la couleur à mettre dans le pixel correspondant à l'écran. Pour ça, il va trouvé l'objet à afficher, et le "pixel" de l'objet sur lequel le rayon pointe.
Une fois ce pixel trouvé, il va appliquer le shader, qui va s'occuper de modifier les propriété de l'objet pour ce pixel donné, à savoir:
_ Son emplacement dans l'espace
_ Sa normal
_ Et toute les propriété inhérente à la lumière (c'est le plus complexe)

Ensuite, une fois ces données récupéré (tu vois donc qu'il n'y a pas d'interaction avec les spot de ta scène pour l'instant), il va aller chercher tout les spot de ta scène, puis appliqué les formule correspondante:
_ SI un objet se trouve entre le pixel et la lumière, on passe à la suivante.
_ sinon, on calcule la lumière resultante depuis cette formule (à peu près, elle est beaucoup plus compliqué en vrai ^^):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CouleurFinale = (CouleurSpot&CouleurObjet)*diffraction*normal*distanceSpotObjet + CouleurReflexion*reflexion + CouleurTransparence*Transparence;

La couleur de reflexion est calculé en renvoyant un rayon depuis le pixel correspondant au scalaire du rayon de vue incident par la normal.
La couleur de transparence est calculé en renvoyant un rayon depuis le pixel correspondant au scalaire inversé du rayon de vue incident multiplié par l'indice optique de ta matière (ça correspond à la déviation des rayon de lumière).

Un super site qui explique le lancer de rayon

[Invité]

C'est joli sur le lien que tu m'a donné, je vais me baser sur ses formules pour la version future du moteur.

Je vais encore devoir créer une texture car ça fait pas mal d'informations là. ^^