Demoscene.fr BBS

Articles et discussions techniques => Code => Topic started by: Patapom on 08 March 2014 à 14:55:49

Title: God Complex
Post by: Patapom on 08 March 2014 à 14:55:49
Hey!

Je fais un peu de pub rapide pour mon micro framework C++ DX11 qui s'appelle "God Complex": https://github.com/Patapom/GodComplex/wiki

C'était censé être une petit intro au départ, et puis ça a bien dérivé... ;D
Comme d'hab, je suis plus excité par des travaux de longue haleine comme développer une solution de GI qui fonctionne, que de réaliser des p'tits effets de démos, il est donc fort probable que rien ne sortira de tout ça si ce n'est des articles sur mon wiki perso, quand j'aurai le temps. Et p'têt des applications dans certains jeux, qui sait ? ;D

Bisous.
Title: Re : God Complex
Post by: phaazon on 09 March 2014 à 20:48:49
Code: [Select]
: m_pROOT( NULL )
:D

Sinon joli boulot :)
Title: Re : God Complex
Post by: maracuja on 12 March 2014 à 09:12:37
qu'est ce qu'une "solution de GI" ?
Title: Re : God Complex
Post by: flure on 12 March 2014 à 09:28:09
Maracuja : GI = Global Illumination, c'est le Graal du rendu temps réel :D
Title: Re : God Complex
Post by: phaazon on 13 March 2014 à 20:16:06
Je me demande souvent quelle approche est la meilleure en supposant que le hard nous le permette : la rastérisation, ou le raytracing? Autant le raytracing est super attirant pour modéliser des objets mathématiques ou des isosurfaces, autant pour rendre des objets random, c’est une autre paire de manche. En supposant toujours que le hard soit ok, ça implique forcément plusieurs choses : soit de tester tous les triangles à chaque itération (raymarching par exemple) – avec possibilité de kd-tree et ce que vous voulez, soit ça implique une voxélisation du modèle rendu.

Dans tous les cas, est-ce réellement plus élégant et implémentable qu’une bête rastérisation ?
Title: Re : God Complex
Post by: flure on 13 March 2014 à 20:21:57
Je pense qu'il faut faire un mix des deux : une voxellisation+raytracing pour calculer l'illumination, et ensuite rasteriser en utilisant les infos collectees. Enfin j'imagine que ca doit etre efficace...
Title: Re : God Complex
Post by: phaazon on 13 March 2014 à 20:23:47
Ouais ça pourrait le faire, mais les infos collectées, ça veut dire quoi ?
Title: Re : God Complex
Post by: flure on 13 March 2014 à 20:25:32
Je sais pas, ca doit etre possible de stocker ca dans des buffers ? Il risque surement d'y avoir un probleme de memoire cependant...
Title: Re : God Complex
Post by: phaazon on 13 March 2014 à 20:29:24
Ça s’assimilerait donc à du deferred raytracing :D Non mais je ne vois pas trop l’idée. Par contre, rastériser une première fois la géométrie dans 6 plans avec les 6 depthmap, puis lancer des rayons là dedans, ça me parle plus. En tout cas je suis toujours troublé par cette histoire de raytracing et de rastérisation.
Title: Re : God Complex
Post by: barti on 13 March 2014 à 22:14:45
l'idée pour faire du raytracing est de faire une rasterisation de triangles en zbuffer de barycentriques des triangles de la scène 3d avec index du triangle. ensuite la passe de raytracing lit la position relative de l'intersection avec le polygone dans le buffer temporaire ; cela évite tout le test d'intersection et interpoler 3 composantes en rasterisation est très rapide. bref, en tout cas, c'est le seul moyen de faire du raytracing temps réel.
pour faire une seconde passe de réflections, il suffit de faire un rendu dans un cubemap avec le même algo.

j'ai eu cette idée en 2001 ou 2002.
Title: Re : God Complex
Post by: Graindolium on 14 March 2014 à 00:51:24
barti c'est à peut près ce que je faisait dans mon raytraceur.
je tronquais les polygones en rectangle puis j'avais une map de 0 ou 1, , puis chaque face était sélectionné par une premier conditionnel  pour savoir si ont est dans le triangle ...
y a une façon de le faire puissant avec des précalcule de map  des conditionnements combinatoire genre nombre de possibilité de 50 faces par point ,  enfin je voulais faire une textmode et prendre mon pied avec de la belle 3D seulement manque de time et de bite pour ,   j'ai toujours utilisé mon moteur raster à chier où ont a pas de caméra

  intersection de face que j'avais tapé y a des 4 ans ou +,  j'aimerais refaire un raytraceur, un moteur simple (polygone/objet classique , lumière ombre, texture...) simple et bien structuré de sorte à être très puissant, intelligent en représentation, et faire un jeu avec, enfin soyons vaine
un chouette jeu d'arcade en 100*160  :D
Code: [Select]
poin interfac( Dro D , int S )
{
 //recherche du points d'intersection
 //Ix(AAt + BB) + Iy(AA1t + BB1) + Iz(AA2t + BB2) + R = 0
 
 float Tx1,Tx2,Tx3,Ty1,Ty2,Ty3,Tz1,Tz2,Tz3;
 //vec3 v1,v2,Vn;
 //float asx,bsx,csx,dsx;
 
 /*Fase[S].a = noV(Fase[S].a);
 Fase[S].b = noV(Fase[S].b);
 Fase[S].c = noV(Fase[S].c);*/
 
 Tx1 = Fase[S].a.x;//Les 3 points
 Ty1 = Fase[S].a.y;
 Tz1 = Fase[S].a.z;
 
 Tx2 = Fase[S].b.x;
 Ty2 = Fase[S].b.y;
 Tz2 = Fase[S].b.z;
 
 Tx3 = Fase[S].c.x;
 Ty3 = Fase[S].c.y;
 Tz3 = Fase[S].c.z;
 
 
 /*v1.x = Tx2 - Tx1;// les deux vecteurs
 v1.y = Ty2 - Ty1;
 v1.z = Tz2 - Tz1;
 
 v2.x = Tx3 - Tx1;
 v2.y = Ty3 - Ty1;
 v2.z = Tz3 - Tz1;
 
 asx = v1.y*v2.z - v1.z*v2.y;
 bsx = v1.z*v2.x - v1.x*v2.z;
 csx = v1.x*v2.y - v1.y*v2.x;
 dsx = -v1.y*v2.z*Tx1 -v1.z*v2.x*Ty1 -v1.x*v2.y*Tz1 +v1.y*v2.x*Tz1 +v1.z*v2.y*Tx1 +v1.x*v2.z*Ty1;
 
 Vn = asign( asx , bsx , csx );//normale
 Fase[S].n = Normalize(Vn);*/
 
 
 poin te;
 float IX,IY,IZ,RS,ti,de;
 float DIV,a,b,c,dw,ew,fw,gw,hw,iw,jw,kw,lw,xw,yw,zw;
 
 IX = Fase[S].n.x;//asx;
 IY = Fase[S].n.y;//bsx;
 IZ = Fase[S].n.z;//csx;
 RS = Fase[S].w;//dsx;
 
 de = IX*D.a + IY*D.c + IZ*D.e;
 
 if( de < 0 | de > 0 ){
 
  ti = ( - IX*D.b - IY*D.d - IZ*D.f - RS )/de;
 
  te.d = ti;
 
  if( ti >= 0 ){
   
   dw = Tx1;
   ew = Tx2;
   fw = Tx3;
   
   gw = Ty1;
   hw = Ty2;
   iw = Ty3;
   
   jw = Tz1;
   kw = Tz2;
   lw = Tz3;
   
   xw = D.a*ti+D.b;
   yw = D.c*ti+D.d;
   zw = D.e*ti+D.f;
   
   //solve( { ( a*d + b*e + c*f )/100 = x , ( a*g + b*h + c*i )/100 = y , ( a*j + b*k + c*l )/100 = z },{a,b,c} )
   DIV = dw*(iw*kw - hw*lw) + ew*(gw*lw - iw*jw) + fw*(hw*jw - gw*kw);
   a = 100*(zw*(fw*hw - ew*iw) + yw*(ew*lw - fw*kw) + xw*(iw*kw - hw*lw));
   a /= DIV;
   b = 100*(zw*(dw*iw - fw*gw) + yw*(fw*jw - dw*lw) + xw*(gw*lw - iw*jw));
   b /= DIV;
   c = 100*(zw*(ew*gw - dw*hw) + yw*(dw*kw - ew*jw) + xw*(hw*jw - gw*kw));
   c /= DIV;
   
   if ( a <= 100 && a >= 0 && b <= 100 && b >= 0 && c <= 100 && c >= 0 )
   { te.exist = 1; }else{ te.exist = 0; }
   
  }else{ te.exist = 0; }
  te.n = S;
  te.t = 1;//1 for a Face
 
 }
 else{
 
  te.exist = 0;
 
 }
 
 return te;
}

(http://graindolium.paradisia.net/APyxel/mystic_cat.png)
Title: Re : Re : God Complex
Post by: Patapom on 14 March 2014 à 14:46:12
Je me demande souvent quelle approche est la meilleure en supposant que le hard nous le permette : la rastérisation, ou le raytracing? Autant le raytracing est super attirant pour modéliser des objets mathématiques ou des isosurfaces, autant pour rendre des objets random, c’est une autre paire de manche. En supposant toujours que le hard soit ok, ça implique forcément plusieurs choses : soit de tester tous les triangles à chaque itération (raymarching par exemple) – avec possibilité de kd-tree et ce que vous voulez, soit ça implique une voxélisation du modèle rendu.

Dans tous les cas, est-ce réellement plus élégant et implémentable qu’une bête rastérisation ?
Honnêtement, j'pense que dans 10 ans on a ça sur toutes les bécanes grand public et qu'il faut oublier les triangles : http://raytracey.blogspot.fr/2013/10/brigade-3.html (http://raytracey.blogspot.fr/2013/10/brigade-3.html)
Title: Re : God Complex
Post by: ponce on 14 March 2014 à 16:00:40
Carmack est assez reservé sur la question du raytracing.

http://arstechnica.com/gadgets/2013/01/shedding-some-realistic-light-on-imaginations-real-time-ray-tracing-card/?comments=1&post=23723213#comment-23723213 (http://arstechnica.com/gadgets/2013/01/shedding-some-realistic-light-on-imaginations-real-time-ray-tracing-card/?comments=1&post=23723213#comment-23723213)
Title: Re : God Complex
Post by: Patapom on 14 March 2014 à 16:24:51
Ouais 'fin Carmack il est un peu resté dans les années 90, il a jamais écrit un compute shader de sa vie le type. Vu qu'on s'oriente vers du massivement parallèle tous azimuts, je peux garantir que ces "milliards de rayons" on va les atteindre très très vite !
Et puis l'importance sampling c'est pas pour les chiens : si tu samples pas ta BRDF comme un pied t'es pas obligé d'envoyer des "milliards de rayons"... ;D
Title: Re : God Complex
Post by: MsK` on 15 March 2014 à 10:53:58
Je trouve quand même plus intelligentes les solutions qui rasterisent les premiers rayons et raytracent les rayons secondaires. Smash fait ça actuellement en voxélisant la scène à chaque frame pour avoir une représentation basse résolution de la scène mais facile à raytracer. Ca permet pas de faire ce que fait brigade mais ça permet d'avoir un résultat noise-free en temps réel.
Title: Re : God Complex
Post by: Patapom on 15 March 2014 à 12:53:25
Bah c'est pas le first hit qui cause du noise mais la BRDF du matos.
Tu peux faire ce que tu dis et continuer à avoir du noise si tu samples mal ta BRDF, genre manque de pot PAF ! 1 fois sur 100 pixels tu tombes sur un pic de spéculaire bien velu. Rasteriser d'abord ne te sauvera pas.

Le truc de Smash y a que de la spéculaire idéale, de la réfraction et un peu de diffuse, y a pas de modèle de BDRF très compliqué c'est pour ça que y a pas de noise : tu samples juste dans la direction du rayon réfléchi point barre. Par contre si tu veux commencer à faire du glossy, là t'es dans la merde...
Title: Re : God Complex
Post by: ponce on 15 March 2014 à 13:56:41
Ouais 'fin Carmack il est un peu resté dans les années 90, il a jamais écrit un compute shader de sa vie le type. Vu qu'on s'oriente vers du massivement parallèle tous azimuts, je peux garantir que ces "milliards de rayons" on va les atteindre très très vite !
Et puis l'importance sampling c'est pas pour les chiens : si tu samples pas ta BRDF comme un pied t'es pas obligé d'envoyer des "milliards de rayons"... ;D
C'est vrai que même sur le CPU ça devient pleins de core + instructions qui agissent sur pleins de valeurs de manière identique. Les AVX-512 seront introduites bientôt et j'ai du mal à concevoir quoi faire avec 2kb de registres.
Title: Re : Re : God Complex
Post by: Patapom on 15 March 2014 à 14:25:00
C'est vrai que même sur le CPU ça devient pleins de core + instructions qui agissent sur pleins de valeurs de manière identique. Les AVX-512 seront introduites bientôt et j'ai du mal à concevoir quoi faire avec 2kb de registres.
J'ai rien spécialement contre Carmack, il est doué pour certaines choses (algos, idées, technique) mais ça fait 1 an que je bosse avec l'idTech 5 et j'aurais quelques griefs à lui formuler. Notamment au niveau des outils et de l'expérience utilisateur : c'est zéro ! Que du code legacy de merde qu'on est en train de complètement dégager, ça prend un temps fou vous avez pas idée !

Pour donner un ordre d'idée : l'autre jour en allant farfouiller dans le dossier des icônes de GUI je suis tombé sur une BMP (déjà !) avec le logo 3DFX ! ;D
Title: Re : God Complex
Post by: maracuja on 15 March 2014 à 17:22:53
Maracuja : GI = Global Illumination, c'est le Graal du rendu temps réel :D
Merci Flure :)
Title: Re : God Complex
Post by: barti on 15 March 2014 à 17:58:39
patapom:
tu entends quoi par du code "legacy" ?
le compute shader permet de calculer l'intersection avec des meshes ?
tu peux executer un compute shader avec des links vers des vertexbuffers ?

Title: Re : God Complex
Post by: Patapom on 15 March 2014 à 20:12:34
Code legacy: du code que tu traînes depuis 20 ans, que tu patches pour que ça continue à fonctionner... Cf. Windows avec Win32 alors qu'on en est au WPF, Autodesk qui peuvent pas changer leur framework complètement parce qu'il faut que les trucs de 2001 soient toujours supportés, etc.

Avec les compute shaders tu fais un peu ce que tu veux en fait. Faut voir ça comme du C mais exécuté par le GPU. Tu accèdes à peu près à tous les buffers en read/write, t'as des memory barriers pour synchroniser tes threads, de la mémoire partagée par chaque groupe de threads, c'est vraiment du massivement parallèle (pour donner un ordre d'idée t'as p'têt 16 cores dans ta machine, mais ta carte graphique en a plusieurs milliers même s'ils ne sont pas vraiment comparables).

En tout cas, rien ne t'empêche d'envoyer un buffer qui décrit la géométrie de ta scène, tes matériaux, tes lampes, tes structures d'optim de scène genre octree, BVH, etc. et dire que chaque thread se charge de ray-tracer un rayon...

En fait, les rasterizers et tous les shaders (vertex, hull, domain, geometry, pixel) ne sont grosso-modo plus qu'un cas particulier d'utilisation des compute shaders qui en sont la version généraliste.
'fin pas encore tout à fait, la carte graphique a quand même des fonctionnalités hardware vraiment dédiées à des tâches relatives aux graphics comme l'interpolation et la rasterization de triangles, la tesselation, la gestion optimisée de la mémoire pour les textures, etc. donc ça peut et doit encore s'appeler "carte graphique" parce que ces éléments-là existent. Et les compute shaders sont encore relativement séparés des autres shaders sur certains hardware genre PS4. Mais je pense pas prendre trop de risque en disant que ça devrait plus tarder que tout ce bazar soit unifié...

A priori, on s'oriente vers des milliers (millions ?) de petits cores, moins puissants que des cores CPU, mais plus dédiés aux calculs parallèles. Faut voir ça comme des fourmis qui finissent par construire un truc de maboul alors qu'à la base elles sont un peu connes. ;D

Ce qui est cool avec ce schéma c'est surtout que tu peux ajouter autant de cartes que tu le souhaites et en théorie tu multiplies à chaque fois ta puissance de calcul...
Title: Re : God Complex
Post by: phaazon on 16 March 2014 à 13:51:43
Du coup, dans un futur plus ou moins proche, on peut s’attendre à une disparition des techno du genre OpenGL et DirectX pour une invasion massive de CUDA / OpenCL / whatever permet de faire du massivement parallèle quoi.
Title: Re : God Complex
Post by: Patapom on 16 March 2014 à 15:30:56
Bah ça disparaîtra pas non, j'pense pas. On aura toujours besoin de "helpers" pour créer/structurer/optimiser les buffers de données (textures ou non), accélérer/séquencer/cacher les appels et les transferts CPU<=>GPU, etc.
Par contre les cartes graphiques risquent de se transformer plus en "cartes de calcul", les accélérations graphiques n'étant qu'un aspect particulier de calculs parallélisables...

En code, on avance toujours vers la généralisation d'un pattern spécifique, là c'est pareil : on est parti du rendu spécifique de triangles, on en arrive au problème générique, à la quintessence, qui consiste à penser le problème comme une simple liste de pixels à remplir avec une couleur, quasiment indépendamment les uns des autres, donc des tâches hautement parallélisables.

Pareil pour le ray-tracing, si on assigne plusieurs rayons par pixel et que chaque thread se charge d'un rayon, on arrive à rendre sa scène aussi bien que si ça avait été rendu par des triangles.

L'intérêt du ray/path-tracing c'est aussi que TOUS les studios pros (film/pub) et une grande majorité des publications scientifiques depuis 1980 se sont concentrées sur l'optimisation et l'amélioration de ce type de rendu (bidiriectional path tracing, variance reduction, importance sampling, irradiance caching, final gather, photons mapping, etc.). C'est seulement récemment où les jeux vidéo et les applis temps-réel commencent à rivaliser au niveau de qualité des prods précalc des studios, mais je pense que ça va pas durer : on va arriver au point où c'est moins intéressant de rendre des triangles (trop de contraintes) et où on va gentiment faire la transition vers le path-tracing et s'approprier toutes les techniques que les studios/chercheurs/renderers pro emploient depuis des dizaines d'années...

Pour les constructeurs de cartes, je pense que c'est leur "big picture" du moment. Quelle sera la suite ? Dur dur d'imaginer le futur ! ;D
Title: Re : God Complex
Post by: MsK` on 16 March 2014 à 18:21:32
Ouais enfin tous tous... Renderman a du raytracing que depuis Cars hein et les scènes étaient globalement rasteriées et c'était seulement les parties qui en avaient besoin qui pouvaient utiliser du raytracing...
http://www.levork.org/raytracingforcars.pdf (http://www.levork.org/raytracingforcars.pdf)
Title: Re : God Complex
Post by: Patapom on 16 March 2014 à 18:26:41
Je reviens sur God Complex un instant parce que j'ai enfin fini cette saleté de Sponza atrium avec ma technique d'indirect lighting :
(sans texture parce que ma machine à la maison est à genou et ça pète si je mets les textures ;D )

(http://i.imgur.com/5weDLLA.png)

C'est pas méga précis mais ça fait le job. Dans le coin en bas à droite j'ai inséré ce que ça rendrait s'il n'y avait que l'éclairage direct.
Ca tourne à 200 FPS sur ma GeForce 680 GTX, mais bon c'est surtout parce que la scène est lourde, la technique en elle-même bouffe pas tant que ça...
Title: Re : God Complex
Post by: MsK` on 16 March 2014 à 18:46:01
Y'a des lampes derrière les rideaux ? parce que je comprends pas pourquoi le plafond est éclairé, y compris dans la scène avec uniquement l'éclairage direct.
Title: Re : God Complex
Post by: Patapom on 16 March 2014 à 19:10:51
Oui y a une lampe dynamique qui se balade... ;D
Title: Re : God Complex
Post by: MsK` on 17 March 2014 à 12:50:10
Ce qui répond à la question deux : c'est dynamique ? :D
Mais il est ou le code en fait ? Pas réussi à le trouver... C'est la solution dont tu - il me semble - parlait y'a quelques années ? des probes un peu partout avec des coeffs SH...

edit:
mwahahaha, sympa le code en UTF-8
double   SH::ComputeSHWindowedSinc( int l, int m, double _θ, double _ϕ, int _Order )
:)
Title: Re : God Complex
Post by: phaazon on 18 March 2014 à 09:48:31
Je faisais ça aussi dans mes sources, mais je n’arrive plus à faire fonctionner la touche compose depuis que je suis passé à debian (ça marchait très bien sous archlinux) :(
Title: Re : Re : God Complex
Post by: Patapom on 19 March 2014 à 08:59:38
Ce qui répond à la question deux : c'est dynamique ? :D
Mais il est ou le code en fait ? Pas réussi à le trouver... C'est la solution dont tu - il me semble - parlait y'a quelques années ? des probes un peu partout avec des coeffs SH...

edit:
mwahahaha, sympa le code en UTF-8
double   SH::ComputeSHWindowedSinc( int l, int m, double _θ, double _ϕ, int _Order )
:)
Le code il est dans Effects/GlobalIllumination2, le 1 c'était un essai raté que j'ai conservé au cas où mais je vais le dégager du coup...
Par contre ça marche pas du premier coup y a de la conversion de textures à faire d'abord car je ne file que les PNGs sinon c'est trop lourd sur GIT.
Et puis je me suis perçu que j'ai oublié de générer les mips dans le convertisseur.
Et puis il faut aussi compiler le projet Tools/ControlPanelGlobalIllum et le lancer en parallèle de l'exe pour contrôler la démo (soleil, ciel, animation, debug, etc.)

Et si tu veux changer de scène bah y a pas mal de milliards d'opérations à faire pour construire les probes et les précalculer. Du coup oui c'est avec des probes et des SH.
Ca gère lampes statiques et dynamiques, les area lights dynamiques sur le décor statique et (bientôt) sur les objets dynamiques. Et je vais même rajouter le p'tit bonus : lumière sur des objets dynamiques qui se reflètent sur les objets statiques (et dynamiques du coup).

Bref... Encore du boulot, trouver les bugs, etc.
Title: Re : God Complex
Post by: ponce on 19 March 2014 à 17:14:08
Comme pour confirmer les dires de Patapom sur le ray-tracing, PowerVR annonce une unité d'accélération de ray-tracing en cablé nommé "RTU" comme Ray Tracing Unit => http://blog.imgtec.com/powervr-developers/powervr-gr6500-ray-tracing (http://blog.imgtec.com/powervr-developers/powervr-gr6500-ray-tracing)

S j'ai bien compris l'accès à cette accelération se fait avec "OpenRL".
Title: Re : God Complex
Post by: MsK` on 20 March 2014 à 09:00:01
Et c'est une solution hybride :P
Ne pas tracer le premier rayon, c'est pas énorme, mais c'est toujours ça de pris...