Connaitre l'éclairage d'un objet - Page 1

Bonjour tout le monde,

Je suis une buse en programmation graphique, alors excusez moi si les questions sont un peu stupides.

Bref, j'entrevois la possibilité que j'aie à développer une sorte de simulateur d'éclairage d'un objet, le but du jeu étant d'avoir un objet (complexe), et plusieurs sources de lumière, et de savoir précisément si telle ou telle surface, ou point d'une surface de l'objet est éclairée et si oui avec quelle intensité.
J'ai actuellement une solution maison qui est peu maintenable et surtout qui est décorrélée de la représentation graphique qui est faite par la suite. Tout cela est historique.

Il me semble logique d'unifier tout ça, puisqu'après tout c'est le boulot de la carte graphique de calculer tout ça, et ça sera fait sûrement avec plus de précision que ce que j'ai actuellement.

De plus, refaire ce moteur me permettrait de rajouter des réflexions et autres éclairages secondaires qui manquent actuellement.

J'entrevois donc plusieurs possibilités:

1- utiliser un moteur "standard", typiquement OpenGL, la question est alors: outre la représentation visuelle, est-il possible de récupérer des données d'illumination d'un polygone ? J'ai recherché sur le net et je n'ai rien trouvé de probant à ce sujet.
2- développer un moteur maison, basé sur la carte graphique.
3- pourquoi pas un raytracing 100% CPU ?

(cible: Win32, performance visée: 100Hz, faible complexité de la scène à représenter (une source de lumière principale, l'objet en question de quelques dizaines à quelques centaines de polygones, et un autre objet simple mais réfléchissant), mais à la différence d'un simple rendu graphique la totalité de l'objet doit être traitée et non uniquement la partie visible à l'utilisateur)

Ce qui orientera mon choix serait bien sûr la réponse à la première question, alors si vous avez des réponses à me donner ça serait super !

Merci d'avance

tu as jeté un oeil au "tuto" de sbibi pour bob ?

Hmmm merci pour le lien, je vais potasser ça.

(et n'hésites pas à demander à bob ses programmes intermédiaires s'il les a encore)

En fait je crois que la différence principale ici est que je cherche à avoir l'éclairage "dans l'absolu" sur mes surface, et non pas seulement à les afficher à l'écran... Je n'ai pas trouvé l'info en lisant en diagonale, je vais lire ça de façon plus appliquée quand j'aurais le temps.
D'ailleurs pour le coup je ne sais même pas si ça a un sens de parler d'éclairage "dans l'absolu" avec un moteur 3D. Je vais potasser tout ça avant de poser plus de questions

Hmmm ceci me semble adapté, mais il va falloir que je me rende compte si c'est viable ou pas. Ou s'il y a de meilleures alternatives.
http://en.wikipedia.org/wiki/Photon_mapping

j'aurais dit raytracing dans ton cas.

De quel niveau de précision as-tu besoin ? Les algos optimisés utilisés dans les jeux utilisent des astuces pour améliorer les perfs aux dépends de la précision mathématique.

C'est en effet une très bonne question, il faudrait que je reverse-ingénie l'algo actuel pour savoir la précision que j'ai en l'état... Mais je crois savoir que la précision est assez faible en l'état, justement à cause des perfs assez calamiteuse.

hum, effectivement le truc dont je parlais a bob c'est pas du tout ce que tu cherche.

je dirais que ca depend de:

1- quel type de lumiere? uniquement une source directionnelle ou ponctuelle sans surface ? ou des area-lights (ie: un ciel, une cubemap d'environnement HDR qui eclaire ta scene, bref une surface lumineuse quelconque)
2- quelle qualite d'eclairage? avec/sans ombres? illumination directe ou illumination globale? (ie: est-ce qu'il faut qu'une zone eclairee de ton objet reflechisse la lumiere et eclaire indirectement les zones de ton objet qui sont dans l'ombre?)

par exemple:

A- pour chaque vertex, dot-product entre la normale du vertex et la lumiere, et faire dot * light_intensity / (distance_from_vertex_to_light^2) -> t'as l'intensite lumineuse recue sur chaque vertex, que tu peux interpoler sur chaque triangle, et reutiliser pour des rendus en GL/DX. en gros tu precalcule le lighting par vertex sur toute la mesh, une fois par frame.

B- pareil qu'au dessus, mais par pixel: en gros tu deplie ton mesh sur une texture qui sera en fait une lightmap dynamique. tu fais le meme calcul qu'en A), mais pour chaque pixel de ta lightmap, et sur la carte graphique, pas sur le CPU. c'est assez simple a faire, et vu que c'est par pixel, tu peux avoir des ombres sans trop de problemes.
apres, si t'as besoin de recuperer les infos d'eclairage sur le CPU, tu peux toujours readback ta lightmap.

C- t'as besoin d'illumination globale, et la, oui, le photon-mapping peut etre une solution, mais c'est beaucoup plus casse couilles.

t'as besoin que ce soit de tres bonne qualite, voire "exact", ou tu t'en fous du moment que ca reste credible?
a mon avis le B est un bon compromis.

pour ce qui est des reflections, si ta surface reflechissante est planaire, c'est bidon a faire en rasterizing classique.

(je sais pas pour vous, mais moi j'ai le cerveau qui devient vachement réfléchissant quand j'essaye de comprendre un post de bear ^^)

le prends pas mal, on voit clairement que tu touches grave ta bille (je comprends ce qui touche juste le côté physique de l'éclairage), c'est juste que j'ai carrément pas le niveau pour comprendre ce qui peut se passer au niveau hw et logiciel derrière tout ça ^^

bah le but c'est pas de comparer nos bites et savoir qui touche sa bille ou pas, c'est que ca soit comprehensible
donc bon ca fail un peu quand meme...
Xim> si c'est pas clair je detaille

En fait plus j'y pense et plus je me dis qu'il faudra vraiment séparer la fonctionnalité de calcul d'éclairage et celle d'affichage. Pour cette dernière j'utiliserai probablement un rendu "standard" si bien expliqué dans l'autre topic, et pour la partie éclairage quelque chose de différent.

Donc, pour répondre aux questions bearesques, et puisqu'au final c'est un projet perso je vais être plus précis:

J'ai une seule source de lumière réelle assimilé directionnelle (hum, le Soleil), une sphère irrégulièrement réfléchissante (hum, la Terre), une autre qui n'est là que pour faire joli donc on s'en fout à part pour les éclipses (appelons-la Lune), et un satellite.

Le satellite n'a que ses panneaux solaires qui sont considérés comme réfléchissants dans le degré de précision que je recherche (et pour répondre à la question: du coup, ils sont plans par sections).

J'ai besoin de gérer les ombres en effet.

Le but de la partie "éclairage" est de savoir pour chaque surface du satellite la puissance reçue (ce qui correspond à l'éclairage, si je sais calculer l'un je saurais calculer l'autre).

L'information importante pour moi que je lis dans ta réponse est que je peux "readback [ma] lightmap"

Ceci dit, je suis dans le cas "C" car j'ai besoin de l'illumination globale, mais comme je n'ai qu'une source de lumière directe je pense que le photon-mapping, quitte à faire des approximation ou à paramétrer sa précision doit être jouable.

Ensuite pour le rendu visuel, de toute façon il faut tricher sur la taille du satellite et sur son illumination (pour le rendre visible en fait ) je ne peux pas utiliser directement la résultat d'avant sans traitement donc une petite surcouche de traitement et ça devrait se faire.


Bon, maintenant il faut surtout que je trouve le courage de m'y mettre


(cross: c'est clair dans les grandes lignes, je ne comprends pas tous les termes techniques mais je comprends l'algo global, et comme j'en suis à ce stade ça me va )

j'ai un train a prendre, j'aurai pas le net ce weekend, je te repondrai lundi si personne d'autre a repondu d'ici la.
mais vu les enormes differences d'echelle entre une planete et un satellite artificiel, amha, le photon mapping, tu vas bien te faire chier, et ca va soit:
- avoir une qualite d'eclairage de merde, pas assez de photons
- avoir une qualite d'eclairage suffisante, mais ramer A MORT, un truc de dingue

pourquoi as-tu besoin de l'illumination globale ? tu veux calculer la puissance recue par les reflections sur la planete en fonction de son albedo? ou sur les autres parties du satellite?

parceque sinon, tu rends une cubemap du point de vue du satellite, et tu peux t'en servir comme source de lumiere multidirectionnelle (cherche HDRI rendering)

y a un truc assez chouette que tu peux faire avec ca d'ailleurs, c'est que si t'as la courbe de reponse de ton panneau solaire suivant l'incidence de ta lumiere, tu peux utiliser ca comme le profil d'un kernel de blur symmetrique (encore plein de buzzwords mais bon, la pas le temps d'expliquer plus clairement), pour blurrer ta cubemap, ce qui te permet d'avoir l'intensite recue pour chaque panneau en indexant la cubemap avec la normale du plan du panneau.

par contre si tu veux prendre en compte les interreflections dans le satellite lui-meme, tu peux pas faire comme ca.

Oui en effet l'albedo de la Terre est pris en compte. En fait l'éclairage sert à plusieurs choses :

a- savoir la puissance lumineuse reçue sur les panneaux solaires
b- illuminer différents capteurs (là du tout ou rien suffit, mais il est important de savoir s'ils sont dans l'ombre d'un élément du satellite, ou au contraire il peuvent être éclairés par la réflexion du soleil sur un élément réfléchissant - et je viens de me rendre compte que du coup c'est encore plus la merde car il faut connaître l'angle d'incidence ))
c- établir un modèle thermique mais ça en fait je m'en balance grave.

En effet, c'est ainsi que je calcule déjà l'éclairage du panneau, mais je veux surtout gagner en fidélité et précision sur l'éclairage (et plus particulièrement l'ombrage) du satellite.

Le truc c'est qu'actuellement rien n'est unifié, un module calcule dans son coin l'éclairage sur les panneaux solaires, un autre déduit pour chaque capteur s'il est éclairé ou non, etc, et j'aimerais faire un truc plus générique et flexible. J'ai donc pensé aux similitudes évidentes avec un moteur graphique. Sans parler du fait qu'actuellement tout est fait avec un langage peu optimisé, et sur CPU.

Sinon, je pense que pour simplifier les calculs on peut tricher avec l'albedo, mais ce n'est pas évident car la Terre n'est pas vue du tout de la même taille en orbite basse ou en orbite géostationnaire.

Peut-être que je vais d'abord me concentrer sur un rendu du tout pour avoir quelque chose de visible qui me donnera du courage et ensuite je me concentrerai sur les autres problématiques quitte à tout devoir refaire

Merci pour les réponses en tout cas et bon weekend !