Reprise du message précédent :
Update :  
Les articles ont été remis à jours et sont disponibles sur mon site web:
 
premiers pas:
http://www.massal.net/article/raytrace/page1.html
éclairage spéculaire (blinn-phong), post processing et antialiasing:
http://www.massal.net/article/raytrace/page2.html
textures (Perlin noise, cubic environment mapping, bump mapping)
http://www.massal.net/article/raytrace/page3.html
Flou (depth of field), Fresnel, blobs (isosurfaces):
http://www.massal.net/article/raytrace/page4.html
HDR, loi de beer, aberration chromatique:
http://www.massal.net/article/raytrace/page5.html
Global ilumination, photon mapping:
http://www.massal.net/article/raytrace/page6.html  
 
Le code et les commentaires y sont plus récents. Vous pouvez continuer à utiliser ce topic pour les questions
et commentaires.
 
Voilà, si vous voulez l'historique du sujet, vous pouvez continuer à lire la suite.
Fin de l'Update  
 

 
A ma connaissance, il n'a pas de traduction française et n'a pas d'equivalents autre qu'en anglais.
 
C'est le cas de nombreux bouquins malheureusement et meme les auteurs français publient en anglais.

C'est dommage
 
J'ai trouvé ce livre :  
ici
 
L'auteur est un professeur en DUT informatique option Imagerie Numérique (c'est ce que je suits comme enseignement cette année)
Ce n'est pas spécifique au C, mais si les algo sont bien écrit, ca ne doit pas etre dur de les adapté en C, tout comme les cours que j'ai cette année en fait.
Mais je vais d'abord essayer de bien voir le contenu du livre, car si c'est la meme chose que ce que je fais en cours, ca vaut pas le coup de depenser 32€ =/

 
oui c'est peut-etre plus adapté aux eleves de DUT. je ne peux pas trop te dire, vu que je suis loin de connaitre tous les livres qui ont été écrits sur le sujet (et heureusement )

Tiens, par ailleurs, quelle est ta formation ? (au cas ou tu as suivis une filière scolaire dans l'informatique)
Je ne sais pas encore quoi faire apres le DUT, ya bien l'IUP mais le programme a l'air pire que le DUT (et vas y que je te remet une couche de droit, gestion, eco, lv2...)

 > Resume/CV

 
et ben quand je vois ca, je me dit que je ferais mieux d'aller me coucher :|

 
J'ai acheté ce bouquin et j'ai été assez déçu...Il y a un bon nombre de notions abordés en DUT option IN (Bezier, B-Spline, moteur software...). Malheureusement, la partie abordant le Raytracing est trop générale (à mon goût), d'autant que dans le cadre de mon projet tutoré je développe un moteur de rendu par lancer de rayons (sauf que l'on ne prend pas des objets mathématiquement parfaits, mais des objets polygonés de manière à pouvoir rendre n'importe quelle scène). Concernant le Raytracing, le meilleur bouquin est une compilation en anglais d'un certain nombre d'auteurs (dont l'auteur du précédent livre s'est inspiré pour son propre bouquin).
 
 

up parce que

Article interessant mais qui passe sous silence 2 points importants (qu'il aurait suffit d'évoquer):
a) sans structure d'acceleration (grille, octree, bvh, kdtree etc) on a vite une explosion combinatoire sur les bras.
b) les problèmes de stabilité numérique; par exemple aborder les ombres ou les reflexions sans parler des problèmes d'acnée (intersection avec soi meme) me semble un oubli facheu.

tu peux présenter en quelques lignes le principe des structures d'accélération ?

Le principe est simple: essayer de cloisonner les primitives ou objets afin d'éviter d'avoir à toutes/tous les tester pour intersection et autre (requete de visibilité etc).
 
La structure la plus efficace (géneralement et si on ne tient pas compte des temps de preparation de la structure elle meme) est le kd-tree; c'est une sorte de BSP ou les plans de coupe sont tjs alignés sur les axes (cf. la thèse de Havran, http://www.cgg.cvut.cz/~havran/phdthesis.html).

 
l'arbre octal paresseux fait également partie des structures efficaces
 
 

Je m'en tiens à Havran:
"Consecutively, we compare common heuristic ray shooting algorithms based on BSP trees, kd-trees, octrees, bounding volume hierarchies, uniform grids, and three types of hierarchical grids using a set of 30 scenes from Standard Procedural Database. We show that for this set of scenes the ray shooting algorithm based on the kd-tree is the winning candidate among all tested ray shooting algorithms."
 
J'ai, pour ma part, implémenté une bvh et un kdtree pour un lanceur de rayons coherents et je vois mal un octree se montrer plus efficace (du moins une fois l'épineu probleme de la construction du kdtree surmonté).

octree paresseux
 

Bon, levons l'ambiguité; un octree paresseux c'est un lazy octree (construction à la volée) ou un lose octree (à la thatcher)?
 
De toute façon en excluant les temps de constructions (comme indiqué dans le post original), le kdtree reste indétronable.

c'est un lazy, mais j'ai pas dit que c'etait le meilleur, juste qu'il est efficace egalement, je connais trop peu le kdtree pour en parler

Disons que je doute qu'un octree puisse tenir le choc, pas seulement parce que le partionnement est moins efficace mais aussi parce que le parcours est bcp moins efficace (beaucoup de branchements etc).
Et Havran le montre avec chiffres à l'appui.
 
Voilà par exemple ce que j'obtiens pour le happy buddah et son million de triangles, 2 loupiottes, ombres et sans meme lancer des rayons coherents.
http://ompf.org/ray/wip/20050130-10-2lights.jpg

 
ça a été évoqué en premiere page mais pas utilisé pour le rendu principal vu que ce n'est pas le point sur lequel je voulais insister.
Et surtout vu comment les gens ont des problèmes avec le code du début on va pas trop leur en mettre plein la tete.
 
Le photon mapping un peu plus loin dans la discussion utilise une implantation de base d'un kd tree ce qui est l'une des structures les plus sympas pour le spatial partitioning.
 

 
Ouaip, on ne peut pas tout aborder non plus
 
Et comme dit plus haut, c'est mon premier raytracer donc perfectionable (meme si je n'ai pas vraiment eu le loisir d'y consacrer quoi que ce soit depuis le dernier article).

Ah milles excuses si j'ai raté l'allusion au kdtree. Mea culpa, mea maxima culpa. Fromp! (bruit d'un livre s'écrasant sur mon front).
 
Je ne voulais surtout pas dénigrer un article, qui mériterait de ne pas etre caché au fin fond d'un forum

à UU (university of utah),
ils font des hierarchical bounding volumes
dès le troisième assignment :
http://www.cs.utah.edu/~bratkova/g [...] index.html  
et ils ne vont pas beaucoup plus loin (uniform grid en 4e).
 
Je pense que c'est un aspect du raytracing mais ce n'est pas ce qui m'interesse, afficher des millions de boules ou expliquer le photon mapping, la transparence et le HDR sans trop polluer le code.  
 
Le depth of field par exemple est leur dernier assignment et pas une note sur l'acnée (qui a mon avis est un plus gros problème sur des hardware qui font du shadow mapping que sur un calcul exact de réflexion sur une sphère).
 
Bref chacun voit midi à sa porte, le sujet est suffisamment vaste pour ne pas se satisfaire d'une source unique d'information.

 
Sauf qu'ils font leurs caculs sur des doubles et que leurs primitives sont des spheres: ils ont peu de chance de rencontrer des problemes de précision.
Par contre dès que l'on tente d'avoir un tant soit peu de rendement...
Enfin ce que j'en dis hein.

 
 
arf
 
 
je pense que je vais me décider à  acheter ce bouquin, par contre, j'arrive pour l'instant qu'à le trouver sur amazon.com

bonne nouvelle, j'ai trouvé le livre à la biblio de mon école (si, si, cet endroit sert, c'est fou...)

topic de ouf

voé et ca mérite bien un pti up histoire de voir si ya pas des niouz.

Nope plus le temps de bosser là dessus désolé.
 
Peut-etre un jour un cleanup et je mettrais ça sur ma page web mais ça reste hypothétique.
 
Il y a de bons articles sur le raytracing sur flipcode pour ceux que ça intéresse de pousser ça un peu plus loin:
http://www.flipcode.com/articles/a [...] ce01.shtml
 
Un copain a écrit un raytracer/pathtracer pour le fun et il est bien meilleur que le mien
http://people.cs.uct.ac.za/~snirenst/SSRT/

ok.
en tout cas bravo, c'est marrant de voir a quoi ressemblent les "trip" des gens sortis de polytechnique ^^
(et je ne parle même pas de l'N7)

 
et le rapport c'est.. ?

 
 
la choucroute

Salut
 
Il y a quelques temps, j'ai commencé à faire un ray-tracer avec C#. Je me suis pas mal amusé avec C# et j'ai fais quelques images sympa, mais j'ai envie de refaire mon ray-tracer et en profité pour passé à C++.
 
Mais avant de commencé, je voulais éclaircir quelques points, étant donnée que je ne suis pas un gourou de C++. Existe-t-il un moyen de créer des listes de tailles variable (le nombre d'objets par scene ou encore de polygones par objets pouvant varier par exemple)? Existe-t-il des librairie pour lire/écrire plusieurs format d'image ?
 
J'ai plein d'autres question, mais je pense que je les poserai plus tard.

 
Oui et par définition une liste est de taille variable. Enfin je ne suis pas sûr de bien comprendre ta question ?
le C++ est tout à fait capable de faire des conteneurs de taille variable, tu peux les faire
toi-meme (exo d'algorithmique) ou bien utiliser les conteneurs de la STL (vector, list, deque, map, set.. et j'en passe).
 

 
Oui. J'ai choisi le TGA dans cet exemple parce que ça ne nécessite aucune librairie spéciale, vu que le format est super simple. Mais pour les autres formats plus compliqués il y a  
 
Par exemple pour png :  
http://www.libpng.org/pub/png/libpng.html
pour jpeg:
http://www.ijg.org/
 
et Google est ton ami.

je dirais meme limite devIL qui fait tout. Seulement jcrois que son api est opengl-like, stadire laide

Hello
 
j'ai essayé de comprendre la partie blob, c'est vraiment pas clair
je comprend en gros qu'il transforme la sphère du blob en 10 sous sphères, puisqu'il approxime le potentiel par une fonction du 2e degré
mais une fois dans le code, je suis perdu!
 
merciiiii

Oui j'ai fait l'erreur de vouloir optimiser un peu (sinon c'est encore dix fois
plus lent que ce que c'est là) donc c'est du coup plus très clair.
 
Bon.. je ne pense pas que
cette méthode soit expliquée nulle part ailleurs mais ne desesperez
pas, j'essaie de mettre en ordre cette suite de posts
désordonées et je posterai des articles remis en formes
avec des explications (un peu) plus claires.
Enfin comme j'ai un vrai boulot en parallèle, ça mettra le temps
qu'il faudra . Pour l'instant ça avance avec la vitesse
de l'escargot (et le code qui est tout pourrave aussi..).

Bon je vais peut etre dire une betise
mais ou peut on trouver la dernière version en source?
 
l

Oui elle manque aussi, ça arrive!
 
Si vous vous ennuyez vous pouvez aller là bas:
http://graphics.ucsd.edu/papers/
 
c'est beaucoup plus intéressant qu'ici

Je vais quand meme poser mes ptit questions alors :-)
Pour le bumpmapping, pas de problème ca modifie le vecteur normal,la seule adaption que j'ai du faire c'est de trouver une fréquence qui donne bien a l'écran.
Cependant, avec la réflection j'ai plein de pixels parasites qui apparaissent, sauf si j'enlève la récursivité des rayons. Il ne faut pas lisser la bump map?
 
Pour le HDR, quel est l'algorithme qui permet de repasser en format float dans le range [0-1]? (tonemapping) Apparemment la fonction rgbe2float ne le fait pas
j'ai trouvé un site qui explique qu'il faut faire: 1-exp(-lumière*exposition): http://freespace.virgin.net/hugo.e [...] posure.htm
oui mais lumière peut etre négatif, ce qui fait foirer le résultat!

qu'est-ce que tu entends par pixels parasite ? acnée (interférence avec la précision finie des flottants) ? points rouges dans une scène en noir et blanc ?
Bref, si tu ne peux pas expliquer mieux, un screenshot ça marche aussi. Tu as essayé d'activer l'antialiasing ou ton problème n'est pas un problème d'aliasing ?
 
L'algo qui permet de passer en float dans range  
est expliqué à la page 1:
http://forum.hardware.fr/hardwaref [...] tm#t478889
 
C'est la meme fonction que Hugo Elias. Certains appareils photos numériques utilisent une courbe sigmoide (en forme de S) ainsi que certains renderers de synthèse. Il y a quelques justifications physiques (en fait la justification est principalement statistique, la function logistique représente la croissance d'une population dans un environnement restreint).
 
RGBE2Float ne s'occupe pas de tonemapping parce que ça a lieu tout à la fin du processus de rendu.  
 
Quant à la lumière négative, si ça arrive c'est un bug :
tu ne peux pas obtenir un nombre négatif en n'ajoutant que des nombres positifs. (et si tu as un nombre négatif dans tes données initiales c'est une "operator error" ).

je poste 2 images avec le bump mapping dès que je trouve un server web
 
En fait j'ai plein de petits points avec la couleur saturée (sur une sphère rouge, ca fait des points rouges saturés, idem pour le vert etc.. jusqu'a former des taches
ca augmente si j'augmente la perturbation
ca disparait si j'enleve la récursivité
le reste du bump apparait normalement
 
j'ai pas programmé d'antialiasing.
 
RGBE2Float c'est normal qu'il fournisse des float de 0 a 1e32  mais presque toujours sur les extremes ?

Update :  
Les articles ont été remis à jours et sont disponibles sur mon site web:
 
premiers pas:
http://www.massal.net/article/raytrace/page1.html
éclairage spéculaire (blinn-phong), post processing et antialiasing:
http://www.massal.net/article/raytrace/page2.html
textures (Perlin noise, cubic environment mapping, bump mapping)
http://www.massal.net/article/raytrace/page3.html
Flou (depth of field), Fresnel, blobs (isosurfaces):
http://www.massal.net/article/raytrace/page4.html
HDR, loi de beer, aberration chromatique:
http://www.massal.net/article/raytrace/page5.html
Global ilumination, photon mapping:
http://www.massal.net/article/raytrace/page6.html  
 
Le code et les commentaires y sont plus récents. Vous pouvez continuer à utiliser ce topic pour les questions
et commentaires.
 
Voilà, si vous voulez l'historique du sujet, vous pouvez continuer à lire la suite.
Fin de l'Update  
 

Ils commencent à mettre des limitations mais pour un one image posting c'est pas mal:
http://www.imageshack.us/
 

 
Peut-etre que tu as perturbé tellement que les normales pointent à l'envers
ou dans des endroits impossibles. L'inconvénient de cette méthode c'est que rien n'interdit
de passer des arguments pas du tout plausibles/possibles physiquement.
 

 
Comprends pas la question ??

bump mapping:

 
Lorsqu'on lit une image hdr, les flottant fournit pour rgb sont compris entre 0 et environ 1e32, mais surtout vers 0 ou surtout 1e24 a 1e32
c'est etrange