Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Multi texture massif
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 ... )
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
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'
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
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 MRTEnvoyé 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.
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: shader offline de Blender.
sinon c'est fait à l'étape précédente. Comprends pas trop
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.
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:
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 ?
c'est un bon début
C'est déjà ça.
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.
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
Répondre avec citation
Partager