Version imprimable
Bonjour,
Je vais probablement devoir réaliser un truc assez atypique en OpenGl/GLSL, et comme je débute, j'ai du mal à voir les possible problème.
J'aimerai faire du render to texture avec un pixel shader potentiellement _très_ gros, avec en entrée un gros nombre de texture (potentiellement des milliers).
Y a-t-il une limitation de la taille du pixel shader ? Du nombre de texture ?
Merki
Bonjour et bienvenue,
Pour le shader, il n'y a pas de limite de taille. Du moins pas que je sache.
Pour le nombre de textures, il y a une limite. Ou alors il ne faut utiliser la technique par défault pour récupéré les information des textures dans le shader.
Il se peut que ce que je viennent de dire paraisse compliqué. Si vous êtes nouveau en GLSL, je vous conseille le Orange Book.
Si vous êtes aussi nouveau en OpenGL, les red book ( ou le blue, je sais plus ) ne fera pas de mal.
Il y a une fonction pour récupéré le nombre de texture maximum dans OpenGL. ( Nombre qui peut dépendre de l'implémentation je crois ). La fonction est glGet(GLenum). Ou GLenum est une variable bien définie, qui permettra de récupéré la valeur que l'on veut ( nombre de textures max , nombre de lampes max ... )
Merci pour cette réponse. Je vais être plus précis sur mes besoins:
Je pense à coder un système de deep framebuffer pour Blender. L'idée est de faire un système qui permettrais de changer l'éclairage et éventuellement les matériaux, et d'avoir un retour visuel en temps réel (à comparer au temps de rendu "offline" qui peux durer plusieurs heures).
La technique de base consiste à faire un rendu offline, et stocker dans des caches (deep framebuffer), tout les éléments non dynamique (ie: qui ne varie pas en fonction de la lumière ou des matériaux), et de recalculer ensuite l'image finale sur GPU, en modifiant éventuellement les paramètres dynamique.
Plus d'info ici (anglais):
http://www.vidimce.org/publications/lpics/
http://people.csail.mit.edu/jrk/lightspeed/
Je vais parler ici que de la deuxième partie du processus, le re-calcul sur GPU.
Voilà comment je vois ça pour l'instant:
- en entrée du système, une série d'image qui représente les éléments fixe du rendu (nombre fini; 10 à 20 probablement; de la taille du rendu final)(couleur, z-buffer, normale, ...)
- en interne, un buffer par lampe dans la scène, voir plusieurs buffers par lampe (une lampe area peut être approximé en une série de lampe normale)
Pour le calcul de l'éclairage, il me faut donc soit un pixel shader unifié pour tout les type de lampes (mais j'y crois pas trop), soit un pixel shader par type de lampe. Ce shader doit pouvoir gérer en entrée les 10 à 20 textures, et un ou plusieurs buffers en sortie (disons 1-4).
- au final, un pixel shader capable de combiner tout les buffers intermédiaires des lampes (un nombre potentiellement infini -_-') pour calculer la pass éclairage.
- un dernier pixel shader qui va calculer l'image finale. Pour celui là, nombre restreint de texture en entrée, mais gros code, puisqu'il devra implémenter tout les type de shader offline de Blender.
Voilà comment je le vois pour l'instant, il y a probablement des trous dans mon raisonnement, je suis encore à la phase d'évaluation du problème. J'aimerai que vous me disiez si la partie openGl/GLSL est viable techniquement (j'en doute), et si vous avez une idée pour résoudre les problèmes éventuels.
Merci
Euh ... bonne chance :).
Je crois que je vais pas pouvoir aidé beaucoup, sachant que moi même je n'ai pas 'encore' travaillé beaucoup sur les shaders.
Par contre, je ne sais pas si votre technique va être plus rapide que ce que fait blender, mais je sais même pas comment il fait blender de toute façon :s
Dans OpenGL, nous sommes limiter à 8 lampes ( dans une implémentation classique ). Je suis pas archi sur, mais je pense qu'il y a un moyen de contourner cette limitation par les shaders. Problème c'est que les calculs des pixels des objets, dès qu'il commence à avoir beaucoup de lampe, c'est lent.
Il faudra un shader par type de lampe, ce sera plus simple.
Un shader pourra peut être reproduire la 'lampe area' ;)
C'est facile à faire ce genre de chose. tu fais un shader qui rend ta scène et qui au lien d'avoir une seul sortie (gl_fragColor) il en a plusieurs avec gl_FragData. Ce n'est pas compliqué et ça s'appelle du Multi Render Target ou MRTCitation:
Envoyé par Bat'O
Tu devras n'avoir qu'un seul shader pour ça, sinon ça me semble difficile. Ton shader devra prendre en entré toutes tes lumières et calculer une image dans un FBO représentant ta scène éclairée. Il aura aussi en entré tes buffers obtenus par MRT à l'étape précédente.Citation:
Envoyé par Bat'O
tes lumière peuvent êtres des billboard (défini par des textures), des textures 3D(ça me semble plus facile), les data de lumière envoyer au shader par buffer ...
renseigne toi.
Ou alors tu fais un rendu de ta scène avec une lumière dans un FBO ensuite tu fais un deuxième rendu de ta scène avec une autre lumière en utilisant le FBO contenant le rendu de la première dans ce même FBO et ainsi de suite .mais ça vas souffrir niveau perf: Perso je ne le ferais pas.
c'est quoi ça:roll:: shader offline de Blender.Citation:
Envoyé par Bat'O
sinon c'est fait à l'étape précédente. Comprends pas trop:aie:
tu devra aussi ajouter un shader, mais ce n'est pas obligatoire, qui ferai de l'anti aliasing. C'est lui qui rendra la scène final.Citation:
Envoyé par Bat'O
Ce que tu veux faire s'appelle une technique de rendu par deffered shading.
Ok, même si j'ai des éléments de réponses, je vais compléter un peu plus mes explications :p
Blender est une suite libre et gratuite d'animation, modélisation et rendu 3D (comme 3ds max, Maya, Houdini, ...).
Ce que je veux faire, c'est implémenter la technique du deep framebuffer dans Blender (directement dans son code source, donc). Cette technique permet de recalculer très rapidement des approximations des rendus offline (c'est à dire des rendus fait avec le moteur de rendu normal de Blender). Ça permet au artistes d'avoir un retour visuel très rapide sur des éléments comme le lightning ou les matériaux. Cette technique impose par contre que la géométrie de la scène reste fixe.
A l'étape finale du recalcul du rendu avec le GPU, la géométrie de la scène se résume à 2 triangles qui couvre toute la surface de l'image, grâce auquels on va faire calculer les pixel shaders. Pas de vertex shader, donc. Tout les calculs se font en image-space ! (au moins une grande partie, à priori, il est pas possible de faire des ombres en image space).
Pas de problème sur la question de la rapidité du système, Pixar arrive à obtenir plusieurs dizaine de fps, à comparer à un temps de rendu offline de plusieurs heures.
Pour vous aider à visualiser le processus, une petite image:
http://batmur.mine.nu/dawa/lpics.jpg
J'ai un peu triché sur cette image, le rendu final utilise aussi la pass d'occlusion ambiante, d'où l'ombre sous suzanne.
Comme proof of concept, j'ai fait un petit applet qui calcul l'éclairage d'une scène en image space. C'est très moche, lent, et incomplet, mais ça marche !
http://batmur.mine.nu/dawa/applet/
Syl_20:
À la première étape, la série d'image qui représente les éléments fixe du rendu, c'est le deep framebuffer en lui même. Il est fournis par le moteur de rendu de Blender, donc pas la peine de le calculer.
Shader offline: les shaders du moteur de rendu interne de Blender.
Ça vous éclaire ? :mrgreen:
c'est un bon début:ccool:Citation:
Envoyé par Bat'O
C'est déjà ça.Citation:
Envoyé par Bat'O
on n'a donc pas besoin de le rendre.
Je ne connais pas blender à par pour impoter/exporter des formats de fichiers 3D mais j'ai bien peur qu'il va falloir bidouiller des shaders à la main.Citation:
Envoyé par Bat'O
Ce que je vois c'est 1 premier shader qui écrit dans plusieur FBO en sortie:
1fbo avec la color map de ta scène
1 fbo avec les normals aux surfaces de chaque objet de ta scène
1 fbo avec les composantes spéculaires des matériaux
...
C'est une technique de deffered shading ou rendu différé en français. C'est une technique massivement utilisé dans le jeu STALKER
C'est pas la peine, cette partie va être fournie par le moteur de rendu de Blender. Ici, je devrais bidouiller le code de blender pour sortir les infos vers des buffers, pendant le calcul d'une image normale. Donc pas de shader. Là, je sais où je met les pieds, c'est cool =)Citation:
Envoyé par Syl_20
J'avoue, j'avais pas cherché ce qu'était le deferred rendering. Pour moi, c'était du rendu multi pass, mais en fait, ça ressemble beaucoup plus à ce que je veux faire ! Merci :ccool:Citation:
Envoyé par Syl_20
Blender qui s'occupe de ça , c'est déjà une grosse partie en moins à faireCitation:
Envoyé par Bat'O
En faisant des recherches tu devrais trouver beaucoup d'info.Citation:
Envoyé par Bat'O
Bonne continuation;)
Héhé, j'ai trouvé un bon os à ronger avec le mot clé "deferred rendering" !
J'ai trouvé une présentation du studio Guerilla Games à propos du deferred rendering, dans le je KillZone 2. Très instructif !
http://www.guerrilla-games.com/publi..._rsx_dev07.pdf
Il faut maintenant que je comprendre bien le processus, y compris par quelle magie ils arrivent à faire des shadow map en image space.
Stay tuned.
Les shadow maps ne peuvent pas etre faites en image space... Il faut absolument les recalculer des que la lumiere OU la geometrie bouge (vu qu'une shadow map est la profondeur de la scene du point de vu de ta lumiere...). Meme avec du deferred shading.
J'étais pas loin d'en tirer cette conclusions.
Donc, le programme de mes révisions:
- ombre shadow map "classique"
- ombre raytracée
Je commence à voir toutes les pièces du puzzle, c'est cool :)
Hello,
Un petit up pour vous dire que je lâche pas le morceau. J'ai commencé hier un prototype en C++/opengl. Pour l'instant, je peux charger des textures en png, texturer un quad fullscreen, et charger des shader glsl. :)
J'ai une question qui me trotte dans la tête, mais je trouve pas de réponse. Si j'ai bien compris le shader model 3.0 apporte entre autre une taille maximum pour les shader de 65k instructions. Mais est-ce que ce shader model est répandus aujourd'hui ? Même dans les chipset naze ? Si je code un truc basé la dessus, quel pourcentage de gens ne pourront pas l'utiliser ? Il y a d'autre limitation à connaitre ?