[Index Software] Coin des développeurs :]

[Tugdual]

L'armée recrute, avec des postes à Rennes (35) :

• Comment l'armée veut séduire les prochains cybercombattants...

[Bubu]

Si vous voulez créer un jeu 3D, utilisez Unity 3D.
Ils ont tout intégré pour créer un jeu en quelque jours.
Même pour les jeux en réseau.

Bon il y a du boulot et des moyens pour optimiser les grandes cartes.
Notamment l'occlusion culling. C'est à vous que revient le taf !

[Bubu]

Un des premiers jeux 3D auquel j'ai joué est SuperMario64. (Sur Nintendo64).
Un joyau.
Bon la caméra buggait un peu, etc... Mais c'était tolérable.
Parfois on se retrouvait avec des vues en dehors du décor, etc ...
Mais ça a été une expérience géniale. J'ai adoré.

Une vraie aventure.

Le gros défaut, c'est que les textures n'étaient pas lissées.
Plus on s'approchait face à un mur, plus on voyait de gros pixels agrandis dégueulasses.
Pourtant la N64 était parfaitement capable de lisser les textures.
Mais ils ont choisi de ne pas lisser les textures. Car il y avait du monde là-dessous.
Et ils ont choisi d'être plus précis sur les personnages que sur les décors. Soit.

C'est mon jeu favori.

[Bubu]

J'ai également adoré le jeu :
Duke Nukem 3D.
Saviez vous que le moteur de ce jeu a été développé par un lycéen ?
Il a même dû traverser les états-unis pour expliquer aux développeurs de Duke Nukem comment utiliser son moteur !

[Radulphus]

J'ai également adoré le jeu :
Duke Nukem 3D.
Saviez vous que le moteur de ce jeu a été développé par un lycéen ?
Il a même dû traverser les états-unis pour expliquer aux développeurs de Duke Nukem comment utiliser son moteur !

Bonsoir ici !

Difficile de ne pas rebondir là-dessus, j'espère que ce n'est pas trop hors sujet du topic initial.

Je connaissais effectivement l'histoire du Build Engine (dans les grandes largeurs) et de son auteur Ken Silverman. Ce qui est le plus impressionnant je trouve, ce n'est pas seulement qu'il a conçu si tôt un moteur qui a servi à réaliser un jeu devenu légendaire, mais bien un moteur qui a été réutilisé par de nombreux jeux (dont deux autres sont devenus cultes aussi, Blood et Shadow Warrior ; Redneck Rampage et les autres sont plus confidentiels à mes yeux mais les chiffres me contredisent peut-être).

C'est aussi un FPS pour lequel énormément de maps amateurs ont été produites, malgré l'époque peu connectée, grâce à son éditeur très simple à prendre en main (enfin, pour un éditeur de maps de FPS). Le fait que ce ne soit pas de la 3D a dû aider grandement à garder l'éditeur simple par rapport à ce qui a pu se faire après.

Bref, c'était le moment nostalgie des laborieuses parties en réseau avec un null modem et de l'apprentissage sans le net des éditeurs du build engine et des fichiers de configuration du jeu (qui était totalement moddable). Je me demande d'ailleurs s'il existe des projets sérieux de porter ce moteur sur des technologies modernes (et si c'est pertinent, pour faire des jeux rétros modernes).

[Benoit]

Est-ce qu'il y a des gens qui pratiquent "Julia" ici ?

Je fais une overdose de python et j'aimerais tout migrer dessus.
Et puis utiliser des lettres unicode dans les noms de variables, aussi.

[Tugdual]

Désolé, je ne connais pas...

Et puis utiliser des lettres unicode dans les noms de variables, aussi.

Au fou !

[Benoit]

Mais euh...
Il y a de la Multiméthode.
Avec 376 versions de "*" rien que par défaut.
Sans compter celles qui n'utilisent même pas le symbole "*" :
x = 2ε₁ + 3ε₂

Il y a aussi des vrais raisons, enfin je crois, surtout avec les Gpu.

[Bubu]

Je ne sais pas.
Je ne connais que les langages dérivés de la syntaxe du C.
(C++, java, C# en cours d'apprentissage).
A l'école, j'avais appris le SmallTalk, mais j'ai tout oublié.

Bon courage Benoit.

[Bubu]

Concernant le language SmallTalk,
J'ai envie de pousser la gueulante.
De ruer dans les pancartes.
Bon.

D'abord, il faut bien le reconnaître, il y a un coté "fabuleux".
Tout, mais absolument tout, est objet. Même le code lui-même.
(C'est le seul language que j'ai connu ayant cette particularité, ou tout, absolument tout, est objet)
Il faut bien reconnaître que c'est hallucinant. (Au moins)

Les problèmes :
C'est un language assez peu efficace en performances, comparé à du Java par exemple.
Les développeurs SmallTalk dénigrent les autres languages. C'est un peu sectaire, il faut l'admettre.
Ce n'est pas une communauté, c'est carrément une secte.
Les programmes sont très lourds, car ils intègrent la machine virtuelle dans l'executable final.
La syntaxe est complètement loufoque.
Si on vient d'un terrain syntaxique dérivant du C, le code est incompréhensible.
Ils vivent en vas clos. Ils développent pour eux, et se font les émérites, les élitistes, du code.
Alors que c'est de la merde, et pitoyablement faible niveau performances, par rapport au Java par exemple. (Qui lui aussi utilise une machine (processeur) virtuelle)

Et je ne comprends même pas que cela soit enseigné en fac.

[edit]
En développant pour Android, j'ai été agréablement surpris de voir que Java est très puissant.
C'est pour un jeu 2D, mais j'utilise OpenGL, et je dois concéder que je ne fais pas la différence avec le C++.
Par contre si j'avais utilisé SmallTalk, je ne pourrais pas faire mieux qu'un Pendu !

[Tugdual]

Sur Developpez.com :

• Le C++ moderne « ne nous sauvera pas », car il est moins sécurisé que les nouveaux langages...

[Bubu]

On a l'impression dans les grands jeux 3D, qu'on nous présente une seule et immense scène 3D.

En fait il n'en est rien. La scène est fragmentée.
En secteurs, reliés par des portails.
Et c'est le travail des concepteurs de niveau de vous faire croire que c'est une unique scène.
Et c'est leur boulot, dans des scènes "en plein air", de créer des angles morts pour y parvenir.

Admettons que vous venez d'une scène en plein air, et que vous rentriez dans un bâtiment avec une fenêtre.
Par la fenêtre vous voyez le coté de la scène "plein air". En fait vous êtes devant un portail : Un quadrilatère sur lequel (seulement) est rendue la scène "plein air".
Car ce serait un réel gâchis en temps de tracer toute la scène extérieure si c'est pour la recouvrir par les murs intérieurs alors que seule la partie non occluse par la fenêtre est visible.
Cela est nécessaire pour des raisons d'optimisation. Faire un rendu de scène sur un petit rectangle (orienté) est énormément moins coûteux que de le faire sur tout l'écran.
Les secteurs sont reliés entre eux grâce aux portails. Et c'est comme ça que les niveaux sont construits, et permettent des maps 3D infinies (ou presque).

[EDIT]
Un autre aspect, et cela semble évident :
On ne gère pas les objets qui sont hors du champ de vue. Facile dit comme ça.
Sauf qu'en 3D, on fonctionne sur les volumes, là où la 2D fonctionne en surfaces.
On matérialise le volume du champ de vue (View frustum) et on énumère les objets qui sont dedans.
Et on ne trace que ceux-là.

C'est contre-intuitif, mais tracer un objet hors champ, même s'il ne contribue pas à l'image finale car hors du champ de vue, est coûteux pour rien puisque il n'est pas visible.
Le GPU va quand même énumérer ses facettes, calculer la position de chaque facette dans la scène pour se rendre compte in fine que chaque pixel de l'objet est en dehors de l'écran. Perte de temps.

Après imaginons une scène où il y a 100.000 objets qui la constituent. On ne peut pas vérifier pour chaque objet s'il est ou non dans le champ de vue.
Au lieu d'énumérer les objets dans une liste, on stocke les différents objets dans un arbre (arborescence) qui quadrille la scène en volumes imbriqués, chaque feuille (extrémité) contenant quelques objets. On regarde si une feuille de l'arbre est visible cad dans le (volume) champ de vue, et alors on trace les objets que cette feuille contient.
On appelle ça le partitionnement de l'espace. (Il y a les kd-trees, les octrees, les BSP pour les vielles applications)

Une autre difficulté, c'est de savoir si un objet est visible ou non. On regarde s'il est (même partiellement) dans le champ de vue (plus précisément dans le volume View frustum).
C'est une detection de collision 3D entre l'objet et le view frustum.
Pour cela on utilise des volumes englobants autour de chaque objet. (Calculer la pénétration facette par facette de chaque objet contre le view frustum serait beaucoup trop lourd).
Il y en a de 2 types, les boîtes englobantes (bounding boxes) et les sphères englobantes (bounding spheres). Un bon moteur graphique 3d doit gérer les deux, car selon l'objet, l'un peut-être plus précis et adapté que l'autre.
Donc c'est une approximation. Pour des cas critiques et marginaux, on peut quand même se retrouver à tracer un objet qui est pourtant hors champ.

C'est quoi la matérialisation physique du champ de vue en 3D (c'est quoi le view frustum ?)
C'est une pyramide couchée, avec le sommet tronqué par l'écran.
La face avant (sommet coupé), c'est votre écran. Représenté dans la scène 3D. (Parallèle à l'écran évidemment)
La face arrière, c'est le plan de profondeur maximale. (Car toute scène a une profondeur maximale). Parallèle à l'écran.
Les 4 autres faces relient ces 2 faces avant et arrière. Haut bas gauche droite.


PS :
Ce qui permet d'utiliser des algorithmes simples pour détecter si un objet est ou non visible, c'est que le view frustum, une sphère ou un parallélépipède, sont tous des volumes convexes.
Et que les boîtes englobantes sont alignées sur les axes du repère de la scène. Que ce soit individuellement pour les objets, que pour le partitionnement de la scène.
En quelques produits scalaires et comparaisons, on sait si un objet, ou une partie de l'arbre qui partitionne la scène, est visible.
La contrepartie est qu'un volume englobant peut être dans le champ de vue sans que l'objet englobé le soit. False positive. Donc on le trace pour rien. D'où l'importance de bien choisir le type de volume englobant. Ça peut être automatisé. On calcule la boite englobante et la sphère englobante et on garde l'objet englobant qui a le volume le plus petit.

Imaginez un pont. Vu de dessus en 2D.
Largement rectangulaire, par exemple 10 m de largeur, 300 m de longueur.
On trace un cercle l'englobant. Le cercle est vide pour la majorité de la superficie du pont. Pas bien !
On trace un rectangle l'englobant. Là c'est plus fidèle à la superficie qu'il rempli.
Donc on choisira le rectangle comme englobant.

Maintenant imaginons une planète vue en 2D.
Un rectangle ou un carré, serait vide sur ses 4 coins.
Un cercle l'englobera parfaitement.
Donc on choisit le cercle comme englobant.

Comment on calcule un volume englobant ? C'est très simple, et c'est la même technique que l'on soit en 2 ou 3D.

Commençons par les boites englobantes alignées sur les axes.
Elles sont définies par 2 points seulement.
Le premier point est le minimum de toutes les positions des points de l'objet, et le second point, le maximum.
On énumère tous les points de l'objet, et on calcule le minimum et le maximum de leurs coordonnées.
A la fin, les minima définissent le premier point, et les maxima le deuxième.
Facile, non ?

Pour les sphères, c'est un peu différent.
D'abord il faut déterminer son centre. Facile on calcule la moyenne de tous les points de l'objet.
Ensuite on calcule le maximum des distances entre le centre et chaque point de l'objet. C'est le rayon de la sphère.
Une petite parenthèse. En fait on calcule et compare les carrés des distances. Car la racine carré est une opération coûteuse.
C'est seulement à la fin, quand on a la distance carrée maximale, qu'on applique juste une fois la racine carrée, pour avoir le rayon de la sphère.
(La relation d'ordre entre (deux valeurs réelles positives de) la fonction identité et la fonction carrée est la même. La comparaison de deux valeurs au carré et la comparaison de deux valeurs telles quelles sont en bijection. On obtient la même valeur de la comparaison. Si une valeur au carré est plus grande qu'une autre valeur au carré, la valeur telle quelle de la première sera aussi plus grande que la deuxième telle quelle. Donc on est sûr que même si on compare les distances carrées au lieu des distances telles quelles, cela revient à la comparaison des distances telles quelles. Mais vu qu'on s’intéresse à la distance telle quelle, on applique la racine carrée sur la distance finale au carrée, donc maximale, obtenue.)
A ne pas confondre avec la comparaison de la fonction carrée avec l'identité. Sur [0,1], la fonction carrée est inférieure ou égale à l'identité, mais supérieure ensuite jusqu'à l'infini.
Je ne parle ici que des valeurs positives ou nulles. Sur l'intervalle IR+
Les informaticiens n'ont pas les mêmes prérogatives que les mathématiciens. Les informaticiens associent un coût aux différentes opérations mathématiques. En temps de calcul et en mémoire. Tant qu'on peut, quand on est informaticien, on raisonne dans ce cas développé, par les carrés des distances. C'est seulement si nécessaire que l'on appliquera la racine carré. Pour les mathématiciens, c'est juste un signe, pour les développeurs, c'est une opération qui demande une vingtaine de cycles horloges du CPU.
Et les développeurs sont des radins.


(Après, pour un objet donné, pour savoir lequel des deux volumes englobants est le meilleur, il suffit de comparer leurs volumes.
Pour la boîte : on multiplie hauteur, largeur et profondeur.
Pour la sphère, 4 * Pi/3 * rayon^3.
Et on choisit le volume englobant ayant le plus petit volume)

Tous ces calculs sont faits en avance. Pas en temps réel. Lors du chargement de la map, voire encore avant, lors de la conception des niveaux (et enregistrés dans la map).
Une autre difficulté, c'est que c'est parfait pour les objets statiques, mais inadapté pour les objets animés, en mouvement.
En général on gère les objets dynamiques individuellement, on ne les intègre pas dans le partitionnement de la scène.
Dans une scène, l'essentiel affiché est constitué d'objets statiques. Même s'il y qu'une dizaine d'objets dynamiques dans la scène, c'est moins coûteux de les gérer un par un que de les intégrer dans la structure qui partitionne la scène.

Il y a un troisième système pour éliminer le plus d'objects possibles qui ne contribuent pas à la scène, c'est l'ambient occlusion.
Et c'est de deux formes.

Le premier c'est de voir si l'objet qu'on a rendu à l'image précédente a contribué à la scène. (S'il a été complètement masqué par des objets, on ne le trace plus).
Ça a un défaut très visible, si on a un faible nombre d'images par secondes, car son affichage différé, décalé d'une frame se verra.
Par exemple on a un personnage caché par une colonne. Dès que l'on se décale on devrait le voir car n'étant plus caché. Et bien on verra une frame vide, sans le personnage, avant de le voir apparaître d'un coup. Cette technique est gérée en grande partie par le GPU, qui détermine le nombre de pixels visibles de l'objet, et qui renvoit après coup ce résultat au CPU. Le résultat est reçu par le CPU à la fin du rendu de frame, d'où le décalage d'une frame pour le rendu de la prochaine frame.

L'autre technique est géométrique. Assez sensiblement proche de la technique de partitionnement de la scène en secteurs reliés par des portails. C'est géré entièrement par le CPU.
On définit deux types d'objets : les occulters, et les occulted. (C'est en anglais En gros il y'a les objets qui masquent certains objets de la scène et ceux qui sont masqués par d'autres objets de la scène.) On ne trace pas un objet qui est derrière un autre s'il est couvert par l'objet devant lui.

Si vous utilisez un moteur 3d tout fait, ces outils sont déjà programmés et disponibles. Nul besoin de les créer, il suffit de les utiliser.
Même en ne faisant que les utiliser si vous êtes concepteur de niveau, ce n'est pas si simple.

[EDIT]
Il y a encore une optimisation, la plus simple, et entièrement gérée par le GPU, qui permet de ne pas tracer les facettes orientées vers l'arrière. On économise environ 50% de temps de tracé d'un objet.
Les facettes ont un sens en 3D. D'un coté elles sont visibles et de l'autre non.
C'est fait en calculant la composante z (profondeur) de la normale de la surface. Si elle est négative, on ne trace pas la facette. (composante z du produit vectoriel de 2 vecteurs de la face)
Seulement, il faut s'assurer que l'objet est convexe, sinon il peut y avoir des "trous".
Par exemple, dans le premier Assassin's Creed, la capuche du héro n'est pas affichée quand on la voit de l'intérieur.(Quand on regarde le personnage sur le coté). Dans cette situation, il faut faire des doubles faces. Mêmes positions, mais orientées à l'inverse.

Yppisétou !

[Bubu]

Juste anecdotique.
J'ai fait un tout petit moteur de jeu. Pour la 3D.
Avec ses propres shaders, et une gestion complète de la transparence.
J'y avais intégré pas mal de choses, dont le normal mapping, la refraction, les ombres en couleurs (provenant d'objets transparents).
Les skins meshes (objets animés) avec un système qui pouvait gérer les foules. (Instancing).

Mais aujourd'hui je suis moins enthousiaste à ce propos. J'aurais utilisé un moteur tout fait, j'aurais gagné 5 ans et la possibilité de publier ce jeu de course automobile.

Je me la joue,
Mais je n'ai jamais vu de moteurs graphiques gérer les ombres engendrées par les surfaces transparentes !

[Bubu]

Pour ceux qui s'intéressent à la 3D, et pour comprendre ce que fait le GPU, je propose de faire soi-même un programme qui trace une scène 3D. Il faut faire un détour par les matrices et les coordonnées homogènes, mais sinon c'est abordable dès la terminale scientifique.
Ce que font les Gpus, c'est transformer un triangle en surface à remplir (énumérer les pixels sur l'écran correspondants aux 3 points géométriques de ce triangle. On appelle ça la rasterization en anglais). Projeter une image appelée texture (et si on peut la lisser en plus grâce à une interpolation bilinéaire, déjà, c'est le top mais c'est beaucoup plus coûteux), sur ce triangle. Gérer les triangles qui sont coupés par l'écran. (Ils peuvent devenir des trapèzes divisés en deux triangles. D'ailleurs je me rends compte que je n'avais pas géré tous les cas . Par exemple si un triangle équilatéral ou proche, centré, est tronqué par les bords de l'écran, c'est encore plus compliqué, 4 triangles ou encore plus .... ). Introduire la notion de shaders. "J'ai un pixel à coloriser selon les paramètres donnés. Comment faire ?"
On peut également implémenter un z buffer (parfois appelé depth buffer). Il stocke la profondeur de chaque pixel tracé, sur tout l'écran. C'est un tableau de flottants qui a la même résolution que l'écran. Si jamais pour une frame on veut tracer un pixel qui est plus profond que l'actuel, le tracé de ce pixel est annulé.
Idéal pour les surfaces opaques. Et pour rendre les surfaces transparentes sur fond opaque. Par contre inutile pour gérer les surfaces transparentes entre elles (à la base).
(Le z buffer est entièrement géré par le GPU. Il suffit de le paramétrer.)

C'est très instructif et permet de mieux comprendre le fonctionnement des Gpu, et permet de mieux les programmer.

Évidemment il ne faut pas s'attendre à du temps réel. Mais à une belle image toutes les x secondes au lieu d'une centaine par seconde . D'où l'existence des gpu.

[elpanacho]

J'avais fait il y a quelques année des tuto pour avoir la base des moteur 3d (en C++).

Refaire tout soit même pour comprendre comment chaque element marche est tres instructif, mais difficile de faire mieux que des équipes de plusieurs personne qui travaillent a temps plein pendant plusieurs année, du coup je me suis mis a Unity.

Je ne sais pas si tu connais cette chaîne YouTube :