[Index Software] Coin des développeurs :]

[Tugdual]

Les premières ébauches publiques du travail sur WebAssembly 2.0 :

• ont été publiées...

[Tugdual]

Le langage de programmation C a 50 ans :

• et reste l'un des langages les plus plébiscités...

Extrait :

Successeur du langage de programmation B, C a été développé à l'origine aux Bell Labs par Dennis Ritchie entre 1972 et 1973 pour construire des utilitaires fonctionnant sous Unix. Il a été appliqué à la réimplémentation du noyau du système d'exploitation Unix. Au cours des années 1980, le C a progressivement gagné en popularité. Il est devenu l'un des langages de programmation les plus utilisés avec des compilateurs C disponibles pour presque toutes les architectures informatiques et tous les systèmes d'exploitation modernes. Le langage C est normalisé par l'ANSI depuis 1989 (ANSI C) et par l'Organisation internationale de normalisation (ISO).

[Bubu]

On doit beaucoup au langage C.
Sa syntaxe a inspiré la syntaxe de langages plus modernes.
Le C++( le C est compilable par un compilateur C++), le Java, le C#, et d'autres. Mêmes les langages de shaders (HLSL et GLSL) sont inspirés de sa syntaxe.

Je précise :
HLSL c'est pour high level shader language. C'est le langage pour Microsoft. (Pardon, pour DirectX)
GLSL c'est pour graphic librairy shader language. C'est le langage pour shader libre, Open GL.

Mais finalement, c'est la même syntaxe basée sur le C. A part 2 3 mots clés différents.

Par exemple, pour parler d'un vecteur de 4 réels :

On va dire float4
ou vector4.
Cela dépend du langage, mais ça veut rigoureusement dire la même chose.

[Bubu]

Pourquoi on utilise des vecteurs de 4 composantes en 3D ?
Car on pourrait se dire que 3 composantes (x, y et z) pourraient suffire.
C'est sans compter sur les coordonnées homogènes.
C'est fait automatiquement par les GPUs, pour la plupart des cas, mais il faut diviser les coordonnées par w, la quatrième coordonnée.
Pour les projections.
Pour les calculs d'ombres il faut faire la division soi-même.

Cette division, c'est le calcul qui fait que les objets rapetissent et se rapprochent du centre quand ils s'éloignent.

[lucius]

Je viens de tomber sur un article intéressant (mais sommaire et en anglais) pour l'accessibilité en open source pour les TDAH et les TSA.

• Accessibility in open source for people with ADHD, dyslexia, and Autism Spectrum Disorder

Plus un article sur la conception d'interface utilisateur (hélas en anglais)

• User Interface for People with Autism Spectrum Disorders

Voici quelques recommandations:

• Utilisez des graphiques simples
• Rechercher une navigation simple et claire
• N'utilisez pas de menus complexes
• Utilisez des indicateurs visuels pour les actions chronophages

Sur l'article de la conception, voici des recommandations:

PRESENTATION

Faire:
• Utilisez le contraste entre la police et l'arrière-plan.
• Utilisez des couleurs douces et douces.
• Assurez-vous que la zone de texte est clairement séparée du reste.
• Présenter le texte dans une seule colonne.
• Utilisez des graphiques simples.
• Utilisez des polices claires et sans empattement.

à éviter:
• N'utilisez pas de couleurs vives.
• N'utilisez pas d'images d'arrière-plan.
• Ne superposez pas les images transparentes et le texte.
• N'utilisez pas d'éléments contextuels et de distractions.
• Aucun élément ne doit trop ressortir.
• N'ont pas de défilement horizontal.

NAVIGATION ET CHARGEMENT DE PAGE

Faire:
• Efforcez-vous d'avoir une navigation simple et claire.
• Indiquez clairement sur chaque page où se trouve l'utilisateur.
• Prend en charge la navigation avec la souris ou le clavier.
• Autoriser l'utilisation des boutons du navigateur.
• Les pages doivent se charger rapidement.
• Utilisez des indicateurs visuels pour les actions chronophages.
• Avoir un bouton Aide.

à éviter:
• Utilisez des menus complexes.

INTERACTION

Faire:
• Conception pour la simplicité et peu d'éléments à l'écran.
• Essayez d'avoir une barre d'outils.
• Utilisez des boutons clairs et larges avec des icônes et du texte.
• Donnez de courtes instructions d'utilisation à chaque étape.

à éviter:
• Évitez l'interface encombrée.
• N'utilisez pas d'icônes multicolores.
• Évitez les boutons avec des icônes uniquement, sauf pour la plupart
gestes populaires. Par exemple, "retour".

PERSONNALISATION

Autoriser la personnalisation de :
• Type et taille de police.
• Interligne.
• Thèmes pour les couleurs d'arrière-plan et de premier plan du texte.

[MadShocker]

Quand mon énorme requête SQL :

• fonctionne du premier coup...

(même si je pense que le recours à une grosse requête SQL trahit un problème de conception quelque part, dans le MLD ou ailleurs...)

Celui-là est marrant aussi, mais c'est mal (on ne commite pas sans tester, en général l'ICE n'aime pas).

[Tugdual]

Pas mal...

[Bubu]

Pour la perspective 3D, on divise les coordonnées par z, la profondeur.
Pour un objet 3D, plus il est profond, et plus il est petit, se rapprochant du centre.
Il y a d'autres projections.
Dans ce cas, la matrice de projection met la coordonnée z dans la coordonnée w, entre 0 et 1, de manière logarithmique. C'est précis pour les profondeurs proches et moins pour les lointaines.
C'est cette version de la profondeur qui est stockée dans le z-buffer.
(Bien sûr, du point de vue de la caméra)

EDIT, pour parler des coordonnées homogènes.
C'est une extension des coordonnées cartésiennes.
Un point 2D comprend 3 composantes, et ce qui m'intéresse, c'est qu'il en faut 4 pour un point 3D.
Pourquoi ? Bah quoi ? C'est pour calculer les projections.
La dernière composante divise les autres.

La position 3D (4,2,8,2) est la même que (2,1,4,1). C'est pareil.

En 3D, les positions ont toujours 1 pour w à l'entrée du pipeline. C'est au niveau (final) de la projection que ça change.

Les vecteurs exprimés selon les coordonnées homogènes ont w, la dernière composante, à zéro.
On pourrait se dire que c'est impossible, à cause de la division par zéro.
En fait, c'est pour que les translations n'aient pas d'effet sur eux. Et surtout, ils ne sont jamais impliqués dans les projections (division par w).

(Ça n'a pas de sens, la translation pour un vecteur géométrique. Le vecteur (2,3,4,0) n'est pas le même que (4,5,6,0), et je trouve que les coordonnées homogènes offrent une solution très élégante, en plus d'être performante, pour régler ce problème. La dernière ligne ou la dernière colonne des transformations selon la manière dont elles sont exprimées de manière matricielle sont annihilées par le facteur zéro du vecteur géométrique, et est simple (OpenGl : notation classique mathématique. Version de DirectX, les matrices sont transposées par rapport au standard mathématique). Du coup l'ordre de la multiplication des différentes matrices est inversé.
Personnellement, je suis plus à l'aise avec des matrices transposées, car l'ordre de multiplication suit l'ordre du pipeline : d'abord on met à l'échelle, ensuite on fait les rotations, et finalement les translations, qui permettent de positionner l'objet dans la scène. Ensuite, on change de repère, et on place la vue du point de vue de la caméra. Bien-sûr, après vient la projection pour les positions.

En 3D, il y a 2 concepts fondamentaux : les positions (des points simplement, appelés sommets), et les normales (vecteurs perpendiculaires aux surfaces).
Ils sont tous deux fournis par le logiciel de conception 3D (Blender, 3D Studio Max, Maya, etc... )
Les sommets (vertices au pluriel en anglais, vertex au singulier) sculptent l'objet 3D.
Les normales servent à savoir comment illuminer l'objet.
Tout cela est géré par les designers et leur(s) logiciel(s).
Après, c'est là que les développeurs interviennent, il faut bien en faire quelque chose de ces données.

Pour les vertices, c'est plutôt immédiat : l'objet est placé dans la scène. Et c'est fait dans le vertex shader : son rôle est de placer l'objet dans la scène du point de vue de la caméra, et de transformer les normales.
Pour les normales c'est différent : Et c'est fait dans le pixel shader (DirectX), ou autre nom, dans le fragment shader (OpenGl)
Chaque pixel a sa position par rapport aux lampes présentes. Via des calculs empiriques ou prouvés par l'optique (photoréalistes), on calcule son illumination et donc in fine, sa couleur.

Il y a beaucoup plus de pixels que de sommets, donc le plus couteux au niveau du GPU est le pixel shader. D'ailleurs beaucoup considèrent que le cout en performance des vertex shaders est négligeable.

Les normales ne sont pas investies dans tout le pipeline. Je radote un peu, mais les translations et les projections, ni même la vue selon la caméra, ne les concernent.
Il faut, en fonction des lampes présentes dans la scène, calculer la couleur du pixel concerné.

Ça pourrait paraître logique : l'éclairage d'une surface est le même quelque soit la position de la caméra. L'éclairage ne dépend que de la position de l'objet à illuminer et des lampes de la scène.
D'ailleurs les vertex shaders mêmes, ont deux matrices comme machines de guerre : la matrice complète pour les vertex, et une petite réservée aux normales, qui applique les changements de repère seulement.

[Bubu]

Il y a une technique révolutionnaire de rendu 3D, qui aujourd'hui est appliquée tout le temps pour la rastérisation : le deferred rendering. (Le rendu différé en français)
D'abord, on rend la profondeur de la scène. La z-pass. On stocke dans une texture la profondeur de chaque pixel de la scène.
Du coup à terme, on calcule seulement la couleur des pixels qui sont visibles.
Pour les objets opaques, on les affiche du plus proche au plus lointain, (en les triant). C'est pour qu'il y ait le plus d'échecs de profondeur (z fail, on rejette les pixels qui sont plus profonds que l'existant pixel dans le buffer) ) , et pour minimiser le coût en performance.
Ensuite, c'est en parallèle, tout est calculé en-même temps, on calcule la normal map et la color map. (Car on peut faire des rendus sur plusieurs textures en même temps)
La normal map contient la normale pour chaque pixel, et la color map contient la couleur brute de chaque pixel, sans calcul d'illumination (qui vient de la texture ou d'une couleur unie).
Finalement, on calcule l'image finale.(Tout est servi sur un plateau. On a le pixel visible, sa normale et sa couleur brute. On combine tout ça et c'est réglé. On obtient le pixel voulu)

https://fr.wikipedia.org/wiki/Deferred_Shading

[EDIT], le deferred rendering n'est utilisable que pour le rendu des surfaces opaques. Pour les surfaces transparentes, il faut d'autres algorithmes.
Pour la transparence, la technique la plus naïve est simplement de les trier en fonction de leur profondeur. On les affiche du plus profond au plus proche. (Par un tri).
La technique universelle c'est celle du OIT (order independent tranparency). Je ne peux pas en parler car je ne l'ai jamais implémenté.

[Bubu]

J'ai envie de parler du z-buffer.
C'est vrai que ce n'est pas nouveau, car il y a plus de 20 ans, ça existait déjà.
Sur les cartes accélératrices 3D. on ne parlait même pas de carte graphique.
Le z-buffer est un tableau de flottants compris entre zéro et 1, qui pour chaque image, stocke la profondeur des pixels de l'écran.
Même les premières cartes 3D le géraient.

Quelque soit l'ordre d'affichage des objets (opaques), qui composent la scène, on obtient un rendu impeccable.
Si un pixel est plus profond que celui stocké dans le z-buffer, il est ignoré tout bêtement.
Et s'il est plus proche, plus petit, il remplace l'ancienne valeur.

C'est ce qui permet, par exemple, la précision au pixel près quand un personnage court dans de l'eau. Les intersections entre les jambes du personnage et l'eau sont précises au pixel près.

La scène visible du point de vue de la caméra au final après la projection, est dans un petit cube. [-1, +1] pour x et y, et [0,1] pour z, la profondeur pour DirectX, [-1, +1] pour z pour Opengl.
Le but de la projection, c'est de transformer le view frustum, qui est une pyramide tronquée et couchée (le premier plan est l'écran, le lointain est défini par la profondeur maximale), en un cube "unitaire".
C'est pour cela que dans ce cube, les objets lointains rapetissent et se rapprochent du centre. C'est ce que fait cette matrice de projection, utilisée pour la perspective.

Il y a d'autres matrices de projections. Comme la projection orthogonale, qui ne déforme pas les objets et est très utile pour calculer les ombres du soleil. (Lampe directionnelle)

[Jerold]

Très intéressant. J'ai fait pas mal de 3D sur 3dsmax d'abord, et maintenant sur du paramétrique comme catia ou solidworks pour le travail et occupation personnelle.
J'aime beaucoup être dans ce monde virtuel de créativité. Voir les objets apparaître au fur et à mesure qu'on les dessine.
J'ai fait aussi du calcul par méthode des éléments finis et autres simulations. Ainsi que du paramétrique conditionnel (sur catia pour les rouages avec les règles)
Par contre je ne maîtrise pas du tout les modules de calcul de rendus. Mais ce que vous dites me donne envie d'y regarder de plus près.
Je connais un peu les termes que vous employez car pour moi ce sont des réglages que je choisis empiriquement selon le rendu voulu quand, rarement, j'en lance un.

Sinon, j'ai fait un BTS info alors j'apprécie beaucoup le C ainsi que php mySQL même si j'ai beaucoup oublié.
J'aimerais me remettre au C et python, notamment pour faire un peu d'arduino. ^^ je sais c'est pas le top niveau, mais j'aime bien.

[Bubu]

J'avoue que je suis plutôt néophyte, mes compétences sont très ciblées.
C++ donc C, les langages de shaders, le Java. Un chouya de SQL.

(J'étais en cursus Math-Info, donc j'avais autant de cours de Maths que d'Info. Résultat : rien )

L'essentiel de ce que j'ai appris en informatique, c'était en autodidacte, depuis que je suis enfant. (Quand on est passionné on ne compte pas)

[Bubu]

Les ordinateurs ne mentent jamais.
Si on n'a pas le résultat voulu, c'est toujours de notre faute.

Car ce sont des machines, elles ne font qu'exécuter le code qu'on leur demande d'exécuter. Et elles ne se trompent jamais.
Si elles faisaient une bouillie calculatoire, cela restera venant d'un mauvais code.

[Bubu]

Pour revenir sur la 3D, du point de vue des développeurs :

Il y a eu très rapidement un consensus sur le fait que le CPU, de part son architecture, était impotent et pas assez puissant pour générer des images 3D de qualité en temps réel. D'où les GPUs.

Les GPUs sont des monstres de calcul. Mais ça ne suffira jamais. Quelque soit leur puissance, on en voudra toujours plus. D'où le fait que les développeurs dans ce domaine sont des névrosés de la performance.
Les performances pour les algorithmes sont cruciaux dans le domaine de l'image 3D en temps réel.
L'optimisation est une préoccupation maladive dans ce cas.

Je voulais parler du culling. Enfin des cullings car il y en a 2.
Le but c'est de traiter seulement ce qui est visible, selon le point de vue de la caméra. Pour n'afficher que le strict nécessaire de la scène complète.

Le plus simple géré d'ailleurs par le GPU, est le back face culling.
Les surfaces ont un coté visible, et sont invisibles de l'autre coté.
Pour cela on calcule la normale mathématique du triangle. On n'utilise pas la normale utilisée pour l'illumination, car chaque sommet a sa propre normale interpolée pour calculer la normale de chaque pixel du triangle. On calcule juste la coordonnée z du produit vectoriel de la facette. Si elle est positive, cela veut dire qu'elle est dirigée vers le fond, donc on ne l'affiche pas.

Un autre, beaucoup plus compliqué, c'est le frustum culling : on ignore les objets qui sont hors champ. Pour cela le GPU n'aide pas. Ça se calcule via un code à créer et exécuté sur le CPU.
Comme je l'ai dit, la partie visible de la scène est contenue dans un volume appelé le view frustum. Si un objet est strictement en dehors de ce volume (pyramide tronquée couchée), on ne le traite pas.
Pour calculer l'intersection du frustum avec chaque objet, on utilise des volumes englobants pour représenter les objets à tester car ce serait impossible au niveau performance de prendre en compte l'objet tel quel.
Il y a 3 types de volumes englobants : les AABB (des boites alignées sur les axes car c'est vite calculé), les sphères englobantes (le plus simple), et les OBB (des boites non alignées sur les axes, jamais utilisées car trop couteuses à calculer).
Donc il faut des algorithmes qui calculent si oui ou non le volume englobant de chaque objet intersecte le volume du frustum.
Si il y a intersection entre les deux, on affiche l'objet. Sinon on l'ignore. Mais il peut y avoir des faux positifs : vu que les volumes englobants sont par définition plus grands que les objets qui sont à l'intérieur, on peut parfois gérer un objet qui pourtant est hors champ. Le volume englobant de l' objet peut être dans le champ de vision, sans que l'objet le soit. Mais c'est peu probable statistiquement, mais c'est possible.

L'idéal c'est de gérer les AABB et les sphères englobantes en fonction de la forme de l'objet. Des exemples :
Pour une voiture ou un personnage humanoïde ou un pont ou un bâtiment, le volume englobant le plus précis est la boite alignée sur les axes (AABB).
Pour un objet à peu près sphérique comme un ballon, la sphère englobante est plus précise.

Le calcul d'une AABB est simple : on collecte tous les maxima et minima de tous les sommets de l'objet sur les 3 axes. Elles sont définies seulement par 2 points : un point qui contient tous les minima et l'autre tous les maxima. Par contre la détection d'intersection de volumes est plus compliquée, sans être couteuse.
Pour les sphères englobantes, on fait la moyenne de tous les sommets de l'objet: le centre de la sphère. Ensuite pour déterminer son rayon, on énumère tous les points de l'objet et on stocke la distance maximale entre les sommets et le centre. L'utilisation ensuite est très simple.

En général, les AABB sont plus précises. (Pour mon petit moteur, je n'utilisais que des AABB).

Toujours en rapport avec le frustum culling : dans une vaste scène contenant des milliers d'objets, on ne peut pas tester chaque objet individuellement.
On utilise des arborescences hiérarchiques, qui contiennent les objets de la scène. En gros la scène est contenue dans des cubes, un peu comme les poupées russes.
On teste la visibilité des cubes de cette structure d'abord. De manière récursive, on en déduit quels petits cubes finaux sont visibles. Et on traite les objets qu'ils contiennent comme je l'ai décris plus haut.
Les structures de partitionnement sont les octrees et aussi les kd-trees. Mais ce n'est pas adapté pour les objets qui changent de position. (Animés). Pour les objets animés, on se passe de cette solution, on les teste individuellement.

[Quelqu'un]

Bonjour,
Est-ce que quelqu'un qui connait le Python pourrait m'aider un peu sur un programme que je dois réaliser ?
Je pense que j'essaie de faire trop compliqué... Du coup je bloque.
Merci.