[Index Software] Coin des développeurs :]

[Bubu]

Je crois qu'il y a une différences entre les développeurs (Plus des informaticiens)
Et les autres qui font des maths appliquées. (Plus des mathématiciens)

La formation n'est pas la même.

Quand on est informaticien, on a conscience du bas-niveau, de ce qui se passe concrètement sur les processeurs.
Quand on est mathématicien utilisant les ordinateurs, on en a que faire (et même pas conscience) de ce qui se passe réellement.
C'est beaucoup plus haut-niveau.

Ce sont deux domaines différents.

Après il n'y a aucun jugement de valeur, et je crois que les deux pourraient s'entraider mutuellement.

Mais il faut quand-même reconnaître, au bout d'un moment, que l'objectif n'est pas le même.

[EDIT]
Point de vue de l'informaticien des années 80 qui veut faire des rotations :
On crée une table d'entiers 8 bits d'autant de valeurs qu'il le faut.
Cosinus de zéro (*128)
Cosinus de 10 (*128)
Cosinus de 20 etc. (*128)
On fait tout le tour.
Le Sinus c'est la même table sauf qu'elle est décalée de 90°. (Pi / 2)

Ensuite on calcule les rotations : (On multiplie tout et à la fin, on divise par 128)
Et on se retrouve avec des jolis sprites qui tournent.

Dans Super Mario Bros, les barres de feu qui tournent utilisent cette idée. Donc ça date ...

Maintenant, c'est plus simple, on calcule le cosinus et le sinus directement sur des flottants ....

[Benoit]

Je n'ai pas assez de recul, mais je pense que le même type d'analyse peut se faire aujourd'hui sur les capacités d'une machine à (par exemple) résoudre certains problèmes dans le cadre de tâches plus importantes type "vraie IA décisionnelle" (dont elles sont heureusemnt toujours incapables).
Bref un peu là même chose, une question de savoir faire et de connaissance des capacités de la plateforme, même s'il y a un glissement du hard au hard+soft (éventuellement disputable si on fait rentrer en jeu les questions de GPU).

[Bubu]

Ça dépend de ce que l'on demande aux GPUs :
Ils travaillent avec des vecteurs et des matrices (sous forme de palettes)
Mais de dimensions respectives 4 et 4x4.
Pour les matheux, il y a des APIs qui permettent de travailler avec des vecteurs et matrices de tailles quelconques.

Dans le cas du calcul matriciel, ce n'est pas une simple amélioration en rapidité : une explosion ! Un autre ordre de grandeur carrément.

En infographie, les vertex shaders profitent de cette explosion en performance. (Il n'y a que des opérations matricielles).
Pour les fragments (pixels) shaders c'est plus délicat. Comme déjà dit, il faut veiller à la synchronisation des unités de calcul, favoriser la cohérence (des tests). Eviter les tests le plus possible.

Bovino ergo sum !
Ça devrait être la devise des GPUs !

Si les tests sont synchrones (globaux), aucun problème. (Toutes les unités exécutent la même suite d'instructions)
Mais dès qu'on tournicote au niveau des tests (que c'est fébrile et que le résultat du test change tout le temps), il faut s'attendre à une énorme chute des performances.

Après ce n'est pas si compliqué:
Il faut gérer le cas le plus compliqué, et annuler les calculs dans les autres cas. A grand coups de 0.0 !

Il faut bien comprendre que les unités d'un GPU exécutent toutes le même programme.
Si on attend le résultat d'une unité, on freeze.
Plus aucune unité au travail, sauf celle que l'on attend.

Une unité qui a une suite d'instruction extrêmement lourde suite à un branchement bloquera les autres unités jusqu'à ce qu'elle ait finie !

Et on se retrouve d'un coup à une image par seconde au lieu de 60.

[guillaume]

Je crois qu'il y a une différences entre les développeurs (Plus des informaticiens)
Et les autres qui font des maths appliquées. (Plus des mathématiciens)

J'aime bien les profs de maths qui expliquent que l'informatique, ce sont des maths.
Avec le même raisonnement mais en modifiant légèrement les paramètres initiaux, on arrive à comparer l'informatique au latin.

Du point de vue linguistique, les mathématiques utilisent un langage descriptif quand l'informatique utilise un langage performatif ;
Pendant que le mathématicien énonce, l'informaticien ordonne.
Et souvent, certes, on lui dit "fais moi ce calcul". Sauf que tu as raison quand tu dis qu'on doit, en informatique, prendre en compte comment le calcul sera fait.
Exemple sur l'assembleur des premiers processeurs, la comparaison entre deux entiers est super longue, alors que la comparaison par rapport à 0 est courte.
Donc pour faire une boucle, tu ne part pas de 1 pour calculer le 1er terme pour arriver à N pour le Nième terme, mais tu pars de N-1 et tu décrémentes à chaque itération.
De même en SQL, si tu COMMIT dans une boucle ou en sortie de boucle, le SGBD ne va pas réagir pareil. Et pourtant, il s'est passé la même chose.
Et pour finir, un truc du genre forkbomb de base, tapé dans un shell root, du point de vue purement mathématique, il ne se passe strictement rien. Mais ce n'est pas l'impression qui se dégagera de ton retour d'expérience.

C'est pour ça que le gentil dév qui veut pousser son machin direct en production parce que "chez moi ça fonctionne" se fera toujours bouler direct.

[Bubu]

J'imagine que vous connaissez tous Maple !
C'est un logiciel de calcul formel.
Très puissant !
(j'étais en Licence Math-Info et on avait des cours dessus)
La TI-92 utilisait le calcul formel aussi, mais à un bien moindre niveau.

[Bubu]

Pour voir à quoi peut bien ressembler un shader.
C'est en HLSL (DirectX)

Ce shader génère des shadow maps en cascade avec gestion de la couleur.
A utiliser dans une deuxième passe pour tracer la scène avec des ombres colorées (pour les objets transparents, alpha != 1.0)

Code : Tout sélectionner

#ifndef CSMDEPTH_FX
#define CSMDEPTH_FX

#include "VS_INPUT.fx"

#define CSM_MAXSPLITS	8

//--------------------------------------------------------------------------------------
// Sampler states
//--------------------------------------------------------------------------------------
SamplerState samDiffuse
{
    Filter=MIN_MAG_MIP_LINEAR;
    AddressU=Wrap;
    AddressV=Wrap;
};

//--------------------------------------------------------------------------------------
// Constant buffers
//--------------------------------------------------------------------------------------
cbuffer rarely
{
	uint				g_nbSplits;
};

cbuffer everyFrame
{
	row_major matrix	g_CSM_VP[CSM_MAXSPLITS];
};

cbuffer everySubset
{
	row_major matrix	g_mWorld;
	float4				g_vDiffuseColor;
	float2				g_vDeltaUV;
	uint				g_iDiffuseMapEnableAlphaTestEnable;
	uint				g_mask;
	int					g_iFrameIndex;
};

//--------------------------------------------------------------------------------------
// Global variables
//--------------------------------------------------------------------------------------
Texture2D g_DiffuseMap;
Texture2DArray g_DiffuseMapArray;

//--------------------------------------------------------------------------------------
// Geometry shader input structures
//--------------------------------------------------------------------------------------

struct GS_INPUT_CSM
{
	float4 vPos		: SV_POSITION;
	float2 vTexUV	: TEXCOORD0;
};

struct GS_INPUT_CSM_INST
{
	float4 vPos		: SV_POSITION;
	float2 vTexUV	: TEXCOORD0;
	uint csmMask	: TEXCOORD1;
    int iFrameIndex	: FRAMEINDEX0;
};

//--------------------------------------------------------------------------------------
// Geometry shader output structure
//--------------------------------------------------------------------------------------
struct GS_OUTPUT
{  
	float4 vPos		: SV_POSITION;
	float2 vTexUV	: TEXCOORD0;
    int iFrameIndex	: FRAMEINDEX1;
	uint iRT		: SV_RenderTargetArrayIndex;  
}; 

//--------------------------------------------------------------------------------------
// Vertex shaders
//--------------------------------------------------------------------------------------
GS_INPUT_CSM VS_CSM(VS_INPUT input)
{
	GS_INPUT_CSM output;
	output.vPos=mul(float4(input.vPosition,1),g_mWorld);
	output.vTexUV=input.vUV.xy;
	return output;
}

GS_INPUT_CSM_INST VS_CSM_INST(VS_INPUT_INST input)
{
	GS_INPUT_CSM_INST output;
	output.vPos=mul(float4(input.vPosition,1),input.vWorldMatrix);
	output.vTexUV=input.vUV.xy+input.vDuvDE.xy;
	output.csmMask=input.csmMask;
	output.iFrameIndex=input.vFrameIndices.x;
	return output;
}

//--------------------------------------------------------------------------------------
// Pixel shader
//--------------------------------------------------------------------------------------
float4 PS_CSM(GS_OUTPUT input) : SV_Target
{
	float4 diffuse;

	[branch]
	if (g_iDiffuseMapEnableAlphaTestEnable)
	{
		[flatten]
		if (input.iFrameIndex==-1)
			diffuse=g_DiffuseMap.Sample(samDiffuse,input.vTexUV);
		else
			diffuse=g_DiffuseMapArray.Sample(samDiffuse,float3(input.vTexUV,input.iFrameIndex));
		
		clip(0.5f-(g_iDiffuseMapEnableAlphaTestEnable==2 && diffuse.a<0.5f));
	}
		
	return float4(0.0f,0.0f,0.0f,0.0f);
}

float4 PS_CSM_TRANS(GS_OUTPUT input) : SV_Target
{
	float4 diffuse;

	[branch]
	if (g_iDiffuseMapEnableAlphaTestEnable)
	{
		[flatten]
		if (g_iFrameIndex==-1)
			diffuse=g_DiffuseMap.Sample(samDiffuse,input.vTexUV+g_vDeltaUV);
		else
			diffuse=g_DiffuseMapArray.Sample(samDiffuse,float3(input.vTexUV+g_vDeltaUV,g_iFrameIndex));
		
		clip(0.5f-(g_iDiffuseMapEnableAlphaTestEnable==2 && diffuse.a<0.5f));
		diffuse.a=g_vDiffuseColor.a;
	}
	else
		diffuse=g_vDiffuseColor;
		
	return diffuse;
}

//--------------------------------------------------------------------------------------
// Geometry shaders
//--------------------------------------------------------------------------------------
[maxvertexcount (CSM_MAXSPLITS*3)]  
void GS_CSM(triangle GS_INPUT_CSM input[3],inout TriangleStream<GS_OUTPUT> output)  
{
	[unroll (CSM_MAXSPLITS)]
	for(uint i=0;i<g_nbSplits;i++)  
	{
		if (g_mask & 1<<i)
		{
			GS_OUTPUT o;
			o.iRT=i;
			[unroll (3)]  
			for(int j=0;j<3;j++)  
			{   
				o.vPos=mul(input[j].vPos,g_CSM_VP[i]);
				o.vTexUV=input[j].vTexUV;
				o.iFrameIndex=-1;  
				output.Append(o);  
			}   
			output.RestartStrip();
		}
	}  
}

[maxvertexcount (CSM_MAXSPLITS*3)]  
void GS_CSM_INST(triangle GS_INPUT_CSM_INST input[3],inout TriangleStream<GS_OUTPUT> output)  
{
	[unroll (CSM_MAXSPLITS)]
	for(uint i=0;i<g_nbSplits;i++)  
	{
		if (input[0].csmMask & 1<<i)
		{
			GS_OUTPUT o;
			o.iRT=i;
			[unroll (3)]  
			for(int j=0;j<3;j++)  
			{   
				o.vPos=mul(input[j].vPos,g_CSM_VP[i]);
				o.vTexUV=input[j].vTexUV; 
				o.iFrameIndex=input[j].iFrameIndex;
				output.Append(o);  
			}   
			output.RestartStrip();
		}
	}  
}

//--------------------------------------------------------------------------------------
// Techniques
//--------------------------------------------------------------------------------------
technique10 CSM
{
    pass P0
    {
        SetVertexShader(CompileShader(vs_4_0,VS_CSM_INST()));
		SetGeometryShader(CompileShader(gs_4_0,GS_CSM_INST()));
        SetPixelShader(CompileShader(ps_4_0,PS_CSM()));
    }
}

technique10 CSM_TRANS
{
    pass P0
    {
        SetVertexShader(CompileShader(vs_4_0,VS_CSM()));
		SetGeometryShader(CompileShader(gs_4_0,GS_CSM()));
        SetPixelShader(CompileShader(ps_4_0,PS_CSM_TRANS()));
    }
}

float4 main() : SV_Position
{
	return 0;
}

#endif

[Bubu]

Suite : pour éviter les gros pixels d'ombres dégeulasses (excusez le mot, mais il est juste).
On applique un flou gaussien.
On utilise la cloche de Gauss en deux dimensions pour pondérer la valeur des pixels des shadow maps.
Si à la base la résolution des shadow maps est suffisante, ça suffit.

(Sinon on applique 2 passes pour le flou, une 3x3 ensuite une 9x9, toujours en utilisant la distribution gaussienne.
Mais ça rend les ombres moches.)

Le flou gaussien, au delà d'"arrondir les angles", donne une impression de pénombre. Mais c'est complètement faux. C'est juste visuellement acceptable.

[guillaume]

Le flou gaussien, au delà d'"arrondir les angles", donne une impression de pénombre. Mais c'est complètement faux. C'est juste visuellement acceptable.

Je n'ai pas compris cette ligne. Surtout le "c'est complètement faux", qui m'intrigue :
- C'est quoi ce "c' " qui est faux ?
- En quoi cela consiste le fait d'être faux quand il s'agit de ce "c' " dont j'ignore la nature ?

Désolé si je suis pénible, ce n'est pas pour le plaisir de l'être mais pour le plaisir de comprendre.
(je te connais juste assez pour supposer que si tu éprouves le besoin d'exposer ça ici, ça ne te gênerait pas trop de développer.
Ceci dit, je suppose également que tu ne veux pas tuer tout le monde en développant trop dans les détails.)

[Bubu]

Le flou Gaussien , dans ce cas, donne l'impression de pénombre.
Mais c'est faux. La pénombre est beaucoup plus compliquée que ça.

Dans les jeux, on s'en moque.
Mais dans les films, on ne s'en moque pas.

[guillaume]

Le flou gaussien, au delà d'"arrondir les angles", donne une impression de pénombre. Mais c'est complètement faux.

Le flou Gaussien , dans ce cas, donne l'impression de pénombre. Mais c'est faux.

J'adore quand tu développes, ça donne de la profondeur à tes explications

Bon, alors en fait, dans les jeux, on ne s'en moque pas, mais ça serait trop cher.
En gros, pour un film, on rentre les calculs, ça compile, ça donne un fichier d'export qu'on se contente de lire.
Dans un jeu, il faut tout calculer en temps réel. Donc calculer toutes les lumières indirectes en temps réel pour un rendu photo réaliste sur des paysages grandeur nature, ça n'est pas possible. Du coup, on triche en utilisant le système cognitif du spectateur qui fait la correction tout seul.

Si mes infos sont bonnes, le premier film entièrement en images de synthèse est "Final Fantasy : Spirit Within" et a nécessité quelques mois de calcul pour du 24 images par secondes, là où on attend du 60 images par secondes pour les jeux, calculés en temps réel.

[Bubu]

Dans les jeux il y a 3 sources de lumière :
Ponctuelle, définie par une position dans l'espace. (une ampoule)
Directionnelle, définie par un vecteur (le soleil)
Conique, définie par une position et 2 angles. (lampe torche)

Théoriquement ça ne gènère pas de pénombre.

Il faut que les lampes soient des surfaces pour quelles génèrent une pénombre.

Quand je dis que dans les jeux on s'en moque, je veux dire que c'est surtout impossible, d'un point de vue réaliste.
On lisse les ombres soit avec PCF (percentage close filter) ou un flou gaussien.
Ça permet 2 choses :
Eviter que les pixels de la shadow map soient visibles.
D'avoir des coutours plus flous.

Mais c'est juste pour que ce soit plus joli, pas plus réaliste.

La seule solution pour avoir des ombres superbes, avec pénombre et gérer des surfaces lumineuses correctement, c'est avec le lancer de rayon.

On est aux prémices du lancer de rayon temps réel, mais je pense qu'on va bien devoir attendre une dizaine d'années pour que ce soit effectivement utilisé dans les jeux.

Désolé pour ma tautologie qui ne servait à rien ...

[EDIT]
Bon, je n'ai pas envie d'insister, mais quand même
Comment calcule-t-on l'éclairage d'un pixel ?
On prend sa normale (le cas échéant la normale de la surface), et on fait un produit scalaire avec le vecteur (normalisé évidemment) de la lumière. C'est le cosinus de l'angle entre la normale et le vecteur de lumière.
Dans les shaders, c'est fait en quelques caractères. (Il faut ajouter un signe - quelque part cependant )
Si les deux vecteurs sont parallèles, le pixel est allumé au maximum.
S'ils sont perpendiculaires, il n'y a aucun éclairage, le pixel est seulement éclairé par la lumière ambiente.

Pour la brillance, c'est plus compliqué.
Perso, j'utilise Blinn-Phong.
En gros on utilise des puissances hautes de ce produit scalaire en prenant en compte également l'angle de vue.
Ce n'est pas si difficile, mais c'est empirique.
C'est joli, mais complètement faux d'un point de vue réaliste.
https://en.wikipedia.org/wiki/Blinn%E2% ... ding_model

[Bubu]

Savez-vous pourquoi ont été inventées les cartes accélératrices 3D ? (Avant les cartes graphiques les intégrants ? D'aujourd'hui)
Parce qu'il y avait un gouffre entre ce que proposait le calcul 3D sur CPU par rapport à ce qui était exigé au niveau performances.

J'ai fait un projet entièrement exécuté par CPU il y a quelque années. Un labyrinthe. On pouvait se balader dedans.
A des années lumières de ce qui est possible si on utilise un GPU. Mais ça a été une bonne école.

Les GPUs :
Ils ont des milliers d'unités de calcul, chacune assignée à une zone de l'écran.
Depuis longtemps maintenant, ils sont programmables (les premiers GPUs n'étaient pas programmables, on les paramétrait c'est tout. On parle de pipeline fixe.) Maintenant les GPUs sont programmables. Via les shaders. Il y a même des langages haut niveau, voire des diagrammes pour les construire sur les logiciels comme 3D Studio Max.

[Bubu]

Savez-vous que tous les logiciels peuvent-être hackés ?
Avec beaucoup de persévérance, on trouve les tests qui confirment que la version du logiciel a bien été payée.
En désassemblant notamment. On prend l’exécutable et on le transforme en assembleur.
Et il suffit d'écraser les vérifications. Ce programme est valide si la licence est bonne .... Et on écrase ce test par vrai.
Il y a des obstacles cependant même à ce niveau. Notamment en Java, on peut obfusquer le code. Le rendre illisible même après désassemblage.

Pour les domaines de haute sécurité comme les sites bancaires c'est infiniment plus compliqué. Et heureusement pour nous.

Je ne m’intéresse qu'aux jeux.
Et dans les jeux on s'en fout, car les hackers s'acharneront d'autant plus sur un programme bien protégé. C'est un challenge pour eux.

Je crypte le code et l' obfusque, et le rend non exécutable si la source du téléchargement n'est pas la mienne. (Google Play Store)

Mais tout bon hacker pourra le hacker, mais vu que c'est ultra-ultra-minoritaire, je préfère les laisser faire.

[Manichéenne]

Pour les domaines de haute sécurité comme les sites bancaires c'est infiniment plus compliqué. Et heureusement pour nous.

Il y a des gens qui continuent de croire que quand ça concerne la finance c'est sécurisé, même après l'affaire Kerviel ?

[Bubu]

Pour les domaines de haute sécurité comme les sites bancaires c'est infiniment plus compliqué. Et heureusement pour nous.

Il y a des gens qui continuent de croire que quand ça concerne la finance c'est sécurisé, même après l'affaire Kerviel ?

Kerviel n'est pas hacker à ce que je sache !
C'est un enculé. Définition du Grand Larousse : Qui préfère qu'on la lui mette par derrière plutôt que par l'avant. (Excusez mon latin)
A moins que j'ai zappé un épisode ?