Parfois builder un projet C++ peut prendre du temps... beaucoup de temps! Chez e-on software attendre 30mins pour un build est une habitude quotidienne... pour les développeurs Windows! Sous Mac automatiquement make -j12 sur les octocores donnent au build multithread tout son sens!
Grâce à Arnaud [Calvin1602] Masserann le build Windows à pris un bon coup de boost! Automatiquement, Visual Studio 8 est capable de paralléliser le build des projets qui n'ont pas dépendance entre eux. Malheureusement, c'est un cas assez limité, mais heureusement, il y a /MPx!
/MPx est une option à ajouter à la ligne de commande de compilation d'un projet Visual Studio 8 et qui lance autant d'instances de 'cl' qu'indiquer par la commande /MPx (/MP8 pour 8 instances par exemple). J'ai effectué quelques tests sur mon Q6600 + 2Go de RAM tournant sous Windows XP 32.
Quake 4 SDK 1.3 (default): 35s Quake 4 SDK 1.3 (/MP2): 25s Quake 4 SDK 1.3 (/MP4): 20s Quake 4 SDK 1.3 (/MP8): 21s
Irrlicht 1.4 (default): 43s Irrlicht 1.4 (/MP4): 14s Irrlicht 1.4 (/MP8): 14s
Xerces lib 2.8 (default): 71s Xerces lib 2.8 (/MP4): 26s Xerces lib 2.8 (/MP8): 27s
Le gain est donc vraiment significatif même si assez variable suivant les projets. J'ai noté une utilisation assez importante de mémoire, les 2 Go sont par loin d'y passer, je pense que sur une machine équipée de Vista et utilisé de manière plus vaste que seulement build un projet, les 4 Go de RAM ne feront pas de mal.
JeGX d'oZone3D.net m'a offert la possibilité d'avoir un forum sur son site pour pouvoir discuter des activités de mon site. Un grand merci à lui !
J'espère que vous appréciez de partager votre feedback sur ce forum. Un post est disponible à propos de la réflexion sur les GPUs que j'ai commencé avec MatRem.
La réflexion sur les GPUs que j'avais commencé il y a quelques temps à pris une tout autre envergure notamment grâce à la participation de Mathieu [MatRem] Roumillac que je remercie pour son esprit critique et sa rigueur en terme de modélisation UML.
Nous avons créé de nombreux diagrammes pour montrer différent aspect, point de vue du GPU. Les résultats ne nous conviennent pas encore tout à fait mais voici deux diagrammes issus de cette réflexion qui à n'en pas douter, continuera à s'enrichir.
Ces diagrammes ont très probablement certains manquent et nous n'avons pas hésiter à ajouter nos suppositions. Ils sont donc à lire avec un oeil critique et non pas comme des vérités strictes. Bien entendu, tout commentaire est bien venu, d’ailleurs ces diagramme en aurait bien besoin … Cela viendrait avec le temps.
J'ai tout récemment mise à jour mon environnement de développment, en intégrant TortoiseSVN à Visual Studio !
Ceci est possible grâce au menu "external tools" dans "Tools" et l'utilisation de TortoiseSVN en ligne de commande.
Update tous les fichiers de la solution: /command:update /path:"$(SolutionDir)" /notempfile /closeonend Commit tous les fichiers de la solution: /command:commit /path:"$(SolutionDir)" /notempfile /closeonend Diff sur le fichier actif: /command:diff /path:"$(ItemPath)" /notempfile /closeonend Log des commits sur le fichier actif: /command:log /path:"$(ItemPath)" /notempfile /closeonend
Suite à ma réflexion du design de Küken et pour présenter "OpenGL" chez e-on software je me suis lancé dans la création d'un diagramme d'activité UML représentant les traitements et les flux de données qui gravitent dans d'une carte graphique.
J'ai finalement obtenu le diagramme suivant. Trouver le bon type de diagramme UML qui pourrait représenter ceci fut déjà une grande étape mais il est clair que ce diagramme seul n'est pas suffisant pour donner une bonne appréciation des contraintes liés à la programmation GPU, pour monter d’où l’on vient et où l’on se dirige.
N'hésiter pas à m'envoyer un commentaire sur ce diagram ou sur vos idées pour réprésenter le GPU.
Après 2 années passées chez e-on software à bosser sur Vue, je me dis qu'il est temps de trouver un nouveau défi !
Je recherche donc un nouveau boulot, je ne limite pas mes recherches à la France mais au monde. Je n'ai pas de recherche spécifique au delà d'être lié à la 3D, l'essentiel est ce que l'offre pourrait m'apporter et comment je pourrais mettre en oeuvre mon expérience, mes connaissances et mes idées.
Une nouvelle version de GLM est disponible à present sous license MIT. La documentation a été largement complété et de nombreux bugs ont été corrigé.
Depuis maintenant un moment, j'ai commencé à travailler sur un nouveau "moteur 3D" entièrement orienté shader avec un terme la vocation d'être massivement multithreadé.
Soyons honnête, le projet est vraiment à son commencement. Pour la première release, j'ai simplement prévu d'intégrer un renderer OpenGL 2 mais il manque encore bien des fonctionnalités.
Le G-Tut Pack a été mis à jour avec trois nouveaux samples. Un premier propose une méthode de rendu dans un vertex buffer. Le second donne un exemple de vertex texturing et enfin le troisième évoque l'alpha to coverage, c'est à dire la possibilité d'antialiaser une texture qui contient des texels non visible. L'alpha test pour le multisampling en somme.
Dans une news du 11/01/2006, deux ans presque jour pour jour, j'évoquais mon passage à Visual Studio 8 au travers d'un benchmark mettant en œuvre GCC 3.2, GCC 3.4, Visual C++ 7.1 et Visual C++ 8.0. les résultats étaient alors peu flatteur pour Visual C++ 8.0. Visual C++ 7.1 caracolait alors en tête suivit de près par GCC 3.4, Visual Studio 8.0 étant largement en retrait. Ces tests avaient été effectués sur mon raytracer avec un Athlon XP 2800+.
Aujourd'hui, j'entame ma migration vers Visual C++ 9.0 bien que Visual C++ 8.0 soit toujours mon IDE de référence tout simplement car tous les outils (DevPartner, VTune) ne sont pas encore près pour Visual Studio 2008. Le test est maintenant réalisé sur un Core 2 Q6600 ce qui laisse l'opportunité d'activer les optimisations SSE2 ainsi que la compilation en 64bits.
Ce test montre que globalement les performances n'ont pas évolué depuis Visual C++ 7.1 si l'on s'arrête sur le mode 32 bits et sans optimisation SSE. L'utilisation des optimisations SSE permet de gagner environ 20% de performances. Passer en 64 bits permet de gagner encore environ 10% de performances. Selon ce test Visual C++ 8.0 SP1 est pour le moment le plus efficace particulièrement en 64bits.
Le schéma suivant donne le temps en seconde pour la génération d'une image avec mon raytracer.
Un nouveau sample est disponible sur le sujet des mipmaps. Biais, génération et personnalisation de mipmaps, niveau de base, etc...
Il semblerait que je sois dans une formidable dynamique de mise à jour de vieux trucs... Cette fois c'est au tour de la liste des GPUs de subir un lifting ! Elle inclut à présent tous les derniers GPUs jusqu'au GeForce 8800 GTS 512.
J'ai commencé une nouvelle série de samples OpenGL. Depuis la dernière mise à jours du G-Tut-Pack le 05/11/2004 j'ai tenté bien des approches qui non pas données grand chose de convienquant au final...
Avec cette nouvelle série de sample pour OpenGL, 24 samples sont déjà disponible ! Cette version vise à la présentation de l'API d'OpenGL 2 dans une approche entièrement orienté programmation GPU avec GLSL.
Les exemples utilisent GLEW, GLM et SDL mais tout est inclut dans chaque archive, il ne reste qu'à lancer le sample ou le compiler avec Visual Studio 2005. Ils sont disponibles sous de manière unitaire mais également regroupé dans une archive.
GLM continu a évolution avec des mise à jours régulières principalement pour corriger des bugs mais aussi en ajoutant de nouvelles extensions. La version 0.7 est en cours de développement mais est encore qu'à ses débuts.
J'ai passé un peu de temps à me remettre à l'assembleur x86 ces derniers temps. J'y ai trouvé beaucoup de plaisir ! La pile des registres flottants, les 10 instructions indifférentes juste pour la soustraction, les instructions SSE... ahhh :)
Ma principale motivation était d'étudier l'apporte que pourrait apporter les instructions SSE à GLM. Bien qu’elles permettent d'exécuter jusqu'à 4 opérations à la fois, leurs utilisations introduisent les latences. Dans l'état actuel, il est difficile d'espérer un gain, d'autant qu'il faut permettre au compilateur de réaliser ses optimisations et écrire un code au moins aussi efficace que celui du compilateur. Bref, il me reste beaucoup encore à faire.
J'ai regroupé les résultats de cette activité dans une archive que je mets à votre disposition. Il y a également du code que j'ai trouvé sur le net. C’est vraiment brute et rien d’utilisable pour un projet. Cependant, c’est une bonne base de code pour observer le fonctionnement de différentes fonctionnalités de l’assembleur.
Le travail réalisé sur GLM 0.6.0 concerne exclusivement les extensions le leur mécanisme.
Une extension GLSL sur le GPU est utilisé de telle manière quelle semble s'intégrer au langage. Ceci est possible car le programmeur indique de manière explicite qui souhaite utiliser une extension spécifique. Il venait a utilisé deux extensions différentes définissant la même fonction, le même type alors il aurait des collisions d'espace de nom.
GLM 0.6.0 reprend ce mécanisme pour intégrer les extensions GLM à la bibliothèque core à la demande de l'utilisateur.
Beaucoup d'extensions ont été ajouté. GLM 0.5.1 contenait 44 extensions implémenté, GLM 0.6.1 en contient 58 dont de nombreuses anciennes améliorées. Nombres flottant à demi-précision, vecteur et matrice de taille N, unsigned int, opération bit à bit, quaternion, opération sur les matrices, splines, etc.
Nous recherchons activement de nouveaux passionnés pour enrichir notre équipe de dev !
Un master of C++ Un master of OpenGL Un master of Math Un master of plug-in for 3DS, Maya, XSI, etc... Un master of PHP and web stuff
Expérience pro non nécessaire, stage possible, expérience amateur très recommandé !
Pour plus d'infos pas besoin de faire des petits ronds : criccio {at} e-onsoftware {dot} com. Vous pouvez également me joindre au 01 43 14 28 15, demandez Christophe.
Pour les masters of C++ et/ou OpenGL, la procédure est généralement la suite : Je vous appele pour un entretien téléphonique, si je suis enchanté par l'échange, je le dirais sinon je le dirais aussi. Quelques part se glissera aussi l'envoi d'un portfolio pour que je puisse observer le code que vous avez écris. Enfin, vous serez reçu chez e-on software pour faire plus ample connaissance. :) Pour les autres master of, ca sera pareil mais avec quelqu'un d'autre.
De retour du Siggraph et de mes vacances, au boulot j'ai eu l'heureuse surprise de découvrir mon nouvel espace de travail, que vous pouvez observer sur les screenshots suivant. L'original fait 3520*1200 ... Je veux le même genre à la maison ! Ceci sera complété dans la semaine par un Core 2 Quad Q6600 sur lequel je vais mettre une GeForce 8 GTS 320 et une Radeon X1950 pro. A quoi bon avoir un GeForce et un Radeon sur un même PC alors que l'on ne peut pas faire du SLI/Crossfire entre les deux ? Tout simplement programmer et tester sur les deux principaux constructeurs aux quotidiens pour faciliter ce fastidieux voyage entre le comportement des drivers de l'un ou de l'autre. Je veux pareil à la maison !
Concernant mes développements personnelles, la version 0.6 de GLM avance bien avec tout un tas de nouvelles fonctionnalités, un nouveau système de nommage et d'espace de nom plus conforme au usage les extensions de GLSL, même si c'est manière est contraire aux conventions qui avaient étés définit par l'ARB. Le système de configuration est également beaucoup plus simple et moins soumit à d’éventuels problèmes de collisions. Cette version corrige également les problèmes avec Visual Studio 2005 SP1.
J'envisageais un système de 'plug-in' facilitant l'interopérabilité avec d'autres bibliothèques notamment DirectX 9, DirectX 10, WildMagic 4 et NVSG 3 pour les premiers testent. Celui ci sera probablement reporté pour la version 0.7. Autre piste pour l'avenir, une interprétation des fonctionnalités de GLSL au niveau des textures, peut-être suivant l'approche de GLSL 1.2 mais peut-être aussi suivant l'approche de la version de GLSL accompagnant OpenGL 3. J'ai relevé que ce type d'accès trouvait finalement place dans certains de mes projets du coté CPU. Cependant ceci n'est pas encore planifié. (0.8 / jamais ?)
Le compte rendu de la BOF d'OpenGL est commencé, j'espère le terminer rapidement.
Je vous propose la première release d'un nouveau micro projet nommé "Stuff" qui a pour but de proposer des outils génériques basés sur les convensions de la STL et de Boost. Ce projet est d'ailleurs dépendent de Boost.
Principale et même unique fonctionnalité de cette version, ce que j'ai appelé le "async_ptr". Il s'agit en fait d'une sort de boost::shared_ptr dont l'on peut partager une donnée, entre plusieurs pointeurs, qui n'est pas encore alloué. Cet outil peut-être très utile dans le cas du multithread pour effectuer des allocations asynchrones. J'ai pour objectif d'en écrire un tutorial mais ce n'est pas encore pour tout de suite, notamment parce que d'autres tâches m'attende, comme le Siggraph 2007 !
En effet, je pars samedi à San Diego pour le Siggraph 2007. J'ai prévu des journées de conférences bien chargées ! Je tâcherais de rédiger un petit compte rendu à mon retour.
Un nouvel article est disponible. Il traite de certains aspects liés au mot clé 'const' en C++.
Une nouvelle version de GLM est disponible depuis quelques jours. Elle apporte le support des swizzles operators et surtout celui des features de GLSL 1.2.
Cette annonce tardive précède celle d'une mise à jour qui corrige quelques bugs dont quelqu'uns d'important sur les swizzles operators.
Le tutorial sur les VBOs est à présent disponible sur oZone3D.net, en français et en anglais. Il est accompagné d'un exemple plus élaboré permettant d'observer l'impact des VBOs sur les performances.
Je vous invite également à visiter le site de Cyril Crassin qui dispose d'un contenu très intéressant !
Le GeForce 8800 est annoncé et les tests sont formels : c'est de loin la nouvelle meilleure carte graphique du monde ! Ce en tout point, performance, qualité du rendu et fonctionnalités. Ok, mais niveau programmation qu'est ce que cela donne ?
Pour répondre à cette question, je vous propose un document sur le sujet, traitant plus spécifiquement de la programmation OpenGL du GeForce 8800. Bien sûr, il y a les geometry shaders sous OpenGL mais cette carte nous réserve également tout un tas de nouvelles gâteries.
Cette révision intègre un nouveau test dans le but de détailler d'avantage les tableaux entrelacés.
Dans un registre tout à fait différent, c'est avec plaisir que je vous annonce que mes activités amateurs reprennent et G-Truc Creation recevra aussi à nouveau des mises à jours régulières dès que j'aurai une connexion Internet stable.
L'article sur les extensions OpenGL a subit une petite mise à jour dont beaucoup de corrections.
Une nouvelle série d'exemples OpenGL est disponible. Ils utilisent GLEW, SDL et GLM.
En ce moment même, Boston accueil le Siggraph 2006, évènement qui a servi pour la publication des spécifications d'OpenGL 2.1.
OpenGL 2.1 intègre 4 extensions : GL_ARB_half_float_pixel pour le chargement de bitmaps codés avec des nombres flottants sur 16 bits, GL_ARB_texture_float pour le stockage dans la mémoire de la carte graphique de textures utilisant des nombres flottants à simple (32 bits) ou demi précision (16 bits), GL_ARB_color_buffer_float pour un stockage avec des nombres flottants 16 ou 32 bits des tampons chromatiques et GL_ARB_pixel_buffer_object pour une manipulation plus efficace des pixels.
Le support des nombres flottants pour les textures et les color buffers permet la réalisation des rendus basés sur le High Dynamics Range ou encore des rendus de flou comme Sebh nous l'a présenté sur le forum de Game-Lab.
Les pixel buffer objects (PBOs) utilise l'API des vertex buffer objects en ajoutant deux nouvelles cibles pour l'écriture et la lecture de pixels. L'utilisation la plus courante est le readback asynchrone du framebuffer pour le rendu sur texture. Une seconde utilisation est le rendu sur vertex array où des données traitées par les pixel pipelines sont renvoyés aux vertex pipelines et enfin les PBOs permettent le texture streaming pour un download des textures plus rapide.
Les GeForce 6/7 et les Radeon X1*** sont des cartes OpenGL 2.1, toutes ces fonctionnalités sont disponibles depuis longtemps chez nVidia, chez ATI encore un peu de patiences niveau drivers.
Dernière nouveauté de taille, la version 1.2 de l'OpenGL Shading Language (GLSL). Elle apporte beaucoup de modification qui rapproche GLSL du C++ au niveau du typage ainsi que le support de matrices non carrés (eg : mat4x3, mat2x3).
Enfin, notons qu'un SDK pour OpenGL 2.1 sera distribué avant la fin 2006 et qu'OpenGL 3.0 est sur les rails pour 2007 avec une refonte importe de l'API.
Pendant de nombreuses années l'ARB d'OpenGL publiait une sorte de résumé des réunions principales (Les meetings notes) qui incluaient les votes d'extensions, l'avancement du travail sur de nouvelles fonctionnalités et les idées pour l'avenir. Malheureusement, voici bientôt trois ans que la publication des comptes rendus a été arrêtée.
De nombreux changements, dont la mort de Silicon Graphics et le développement d'OpenGL ES, semble donner un nouveau souffle à OpenGL, preuve en est avec la publication de la première newsletter officiel sur OpenGL sous la houlette de Jon Leech, précédemment l'auteur des meeting notes. Cette newsletter est trimestriel, comme les meetings notes, mais présentée dans une forme nettement plus accessible.
Nous apprenons qu'il est maintenant officiel qu'OpenGL passe dans les mains du Kronos Group et comme je le disais dans une news précédente, c'est une bonne chose pour dynamiser le développement d'OpenGL. Ceci permettra une fusion entre OpenGL ES et OpenGL, peut-être jusqu'aux contextes OpenGL (EGL à la place de AGL, WGL et GLX). Il est d'ailleurs ironique de constater que ce qui a permit la portabilité d'OpenGL soit aujourd'hui totalement décrier par les développeurs cependant si EGL venait à remplacer les autres APIs de contextes OpenGL, je pense que nous en serions tous ravies. De plus, ce que de nombreux nouveaux développeurs cherchaient en vain, probablement du fait d'un parallèle avec DirectX, devrait arriver. En effet, un SDK officiel pour OpenGL pourrait voir le jour.
Cette newsletter nous parle du développement d'OpenGL avec une nouvelle fonction pour les textures look up (ARB_shader_texture_lod) sous GLSL, de l'extension ARB_sync pour la synchronisation CPU/GPU notamment avec plusieurs contextes OpenGL et enfin du nouveau model d'objets OpenGL.
Très bon numéro, vivement le prochain :).
PS : Voici bien longtemps que G-Truc Creation n'avait pas étés mise à jour, espérons que des jours plus amateurs arrivent prochainement.
Le tutorial et les exemples sur les Vertex Buffer objects d'OpenGL ont étés mise à jour. Correction d'erreurs d'orthographe et j'espère correction des crashs au démarrage qui affectait certains utilisateurs. Si vous rencontrez encore des problèmes, n'hésitez pas à me contacter.
J'ai terminé hier un cycle majeur de ma vie : Mon parcours scolaire ! J'avoue que c'est avec le plus grand soulagement que je franchie ce capte. La suite passe évidemment par le vrai début de mon parcours professionnel qui commencera par un stage en vue d'une embauche pour E-On Software. Leurs productions très impressionnantes, d'ailleurs elle participe au Siggraph 2006, c'est pourquoi j'ai bien l'intention de parcourir un bon de chemin avec elle. Je commence le 12 juin, jour de mon anniversaire, que demander de mieux comme cadeau ? :)
Pour ce qui est de mon parcours amateur je n'ai pas l'intention de m'arrêter ici. Je suis un amateur et je ne perds pas une occasion de le rappeler. Cependant, il est évident que ce profond changement de vie influera sur mon emploi du temps mais dans quelle mesure, j'avoue n'en avoir aucune idée, je me contenterai de faire au mieux.
Quels sont mes projets amateurs pour l'avenir ? Il a tout d'abord GLM qui est un petit projet mais dont le concept me plait vraiment beaucoup. Dans les nouvelles features, il y aura prochainement le support des swizzles operators puis des matrices de tailles N ainsi que de nouvelles possibilités pour le traitement des espaces couleurs. J'aimerai également ajouter des fonctionnalités comme les sparses matrices, la LU decomposition, etc. dans le but de créer un intégrateur implicite pour la résolution des équations de mouvements pour le cas d'une cloth simulation. Cependant, ce ne sera pas avant un moment par contre j'ai d'autres ambitions pour ce projet tel que la création de plug-in pour PhysX, DirectX, donc le but est de faciliter l'intégration de GLM. Pour en terminer avec GLM, j'envisage d'implémenter des extensions en GLSL.
Sinon, à moyen terme je souhaiterai sortie un benchmark open source pour les tests de CPUs et de compilateurs puis plus tard de GPUs. Cette idée mais venu lors de la réalisation de tests entre différents compilateurs avec mon RayTracer. Mon idée est de regrouper un bon nombre de mes programmes, souvent non disponible, dans un tout. Ce benchmark comprendrai alors de nombreux tests liés au rendu de graphiques ou a la programmation de jeux : Raytracing, cloth simulation, création de géométrie de terrain, image processing, skeleton animation, etc. Ce projet de nomme pour le moment Trucmark.
Pour ce qui est de diffusion de connaissances, j'annonçais mon intention de réaliser un nouveau pack de samples il y q quelques temps déjà. Malheureusement, rien n'a été publié. Je sais que ce type de contenu est très appréciez et c'est d'ailleurs ce qui a attiré les premiers visiteurs sur ce site. Cependant, ce n'est pas le plus amusant à programmer et ma ligne éditorial ne me convient plus. Bref, toutes mes excuses pour ses illusions. Pour ce qui est des articles, je souhaites continuer dans la lancé actuelle.
Un nouveau magazine nommé Game Development Magazin est disponible. L'initiative est courageuse et mérite donc notre soutien. Pour la qualité du contenu, je n'ai pas aucune idée, j'investis dès que je rentre en France.
JeGX est un amateur de programmation graphiques depuis de nombreuses années mais aussi le webmaster de oZone3D.net, le site qui, à mon avis, diffuse le plus de connaissance depuis près d'un an.
C'est également le créateur d'Hyperion, un demo-system qui a notamment une vocation pédagogique mais qui surtout repose sur une architecture particulièrement moderne basé sur LUA et XML.
C'est pour mon plus grand plaisir que JeGX a répondu à mon invitation pour une interview.
Une mise à jour de GLM est disponible. Elle ajoute seulement des exemples d'utilisation avec OpenGL. Ils sont disponible avec GCC, MinGW, VC7.1 et VC8.0.
Cette nouvelle version introduit les premières fonctionnalités de GLSL 1.2 via extensions et directement dans le core pour la partie concernant les constructeurs. De plus, diverse extensions ont été ajouté ou mise à jours. Enfin, il n'est plus nécessaire d'inclure windows.h avant glm.h quand windows.h est nécessaire.
Dans une interview donné à Gamer Within, John Carmack présent le MegaTexturing, méthode qui sera utilisée par Enemy Territory: Quake Wars (ETQW) pour le rendu de terrain.
N'ayons pas peur des mots, John Carmack en fait de tonnes sur cette solution qu'il dit plus révolutionnaire que le normal mapping introduit par Doom3. L'E3, qui se déroule actuellement, explique peut-être son engommant démesurer. Elle est sans nul doute intéressante mais voyons ce qui se cache sous ce nom très commercial.
Le méga texturing semble être une sérieuse optimisation du texture splatting dont le principe est d'utiliser un certain nombre de tiles répéter sur le terrain. Cette méthode augmente virtuellement la résolution de la texture du terrain ce qui augmente la qualité du rendu visuel.
Pour le texture splatting classique, le coût en mémoire vidéo est ainsi bien plus faible mais le rendu nécessite une passe par tile divisé par le nombre d'unités de textures de la carte graphique (au mieux). L'optimisation est très complexe et très variable suivant les cartes. Selon mes tests, le texture splatting utilisant 5 tiles est jusqu'à 4.5 fois plus lent que le texture strechting (une grosse texture étirée sur le terrain) de résolution réel équivalent à la résolution virtuelle du texture splatting. (Voir l'image ci-dessous)
La méthode de John Carmack semble améliorer le texture splatting en utilisant seulement une texture avec tous les tiles intégrés. Cette solution peut réduire le nombre de passes à une seule mais le fragment shader pour sera plus long et le nombre d'attributs envoyés au GPU plus grand. Chaque tile, pouvant nécessiter un attribut pour ses coordonnées de textures. Nous pouvons également imaginer un pattern de shaders dédiés à une application pour lequel il ne sera pas nécessaire d'envoyer des coordonnées de textures supplémentaires. Enfin, un problème se pose au niveau du filtrage des textures sur les bordures. Si tous les tiles sont juxtaposés, le filtrage risque de provoquer des bugs d'affichages en mélangeant la couleur de texels n'appartenant pas au tile.
Cette méthode est prometteuse notamment pour le rendu de terrain de très haute résolution. Là où la quantité de mémoire vidéo nous empêchera d'avoir une texture de 32768*32768, le MegaTexturing répondra présent de manière plus rapide que le texture splatting traditionnel. A mon avis, il est possible de l'implémenter pour un investissement temps raisonnable, le plus ennuyeux étant la création des ressources notamment l'alpha map qui pour être vraiment réusite demande un éditeur dédié.
Enfin, John Carmack nous informe que l'implémentation utilisé par ETQW nécessite une carte actuelle mais qu'elle pourrait s'appliquer au bonne veille 3DFX. Dans l'absolue, je suis d'accord mais dans la pratique il n'y a pas API qui le permet, il faudra probablement passer par un fragment shader, c'est à dire que la technique nécessiterait au moins une Ge-Force 5200 ou une Radeon 9500 voir un GeForce 3 / Radeon 7000.
Remarque : Le soft de test n'est pas disponible pour le moment, si vous êtes vraiment intéressé, contactez moi.
Intel a dévoilé le nom commercial de sa nouvelle génération de processeur x86 connue sous le nom de code Conroe. Pas de Pentium 5 en vue, il s'agira du Core 2. C'est un processeur bi-core, dépourvu d'instructions 64 bits et composé de 14 pipelines contre 30 pour le Pentium 4.
A son introduction, il sera cadencé entre 1.83 GHz et 2.66 GHz, mais il écrasera sans problème le Pentium 4 principalement dans les applications multithreadé grâce à une architecture à très bon rendement. Les 3.8 GHz du Pentium 4 sont utilisés, dans des proportions non négligeables, à l'attente du vidage des pipelines en cas d'erreurs de prédiction. De plus, la version bi-core du Pentium 4, dites 'D', est vraiment déplorable.
La désignation Core a déjà été utilisée pour les processeurs nom de code Yonah héritiers de l'architecture P6 utilisé par le Pentium 2, Pentium 3 et Pentium M. Il est principalement utilisé sur les portables et les Mac Intel. Le Core 2 est lui aussi un héritier du P6 et ne reprends du Pentium 4 que son bus Quad Pump (Tout comme le Core Duo et les derniers Pentium M). C'est surtout le vrai nouveau représentant d'Intel pour les ordinateurs de bureau.
Je suis personnellement liée à un Dothan 1.5 GHz (prédécesseur du Yonah) sur mon portable et les performances sont vraiment bonnes, parfois supérieur à mon Athlon XP 2.083 GHz. Le Core 2 s'annonce comme un excellent cru, AMD a du souci à ce faire. Selon les premiers tests, un Core 2 à 2.6 GHz bat un Athlon 64 FX 2.6 GHz sur presque tous les sentiers.
Mon point de vue à ce jour est le suivant: Oubliez définitivement le Pentium 4, achetez des Athlon 64 pour jouer, des Athlon X2 pour programmer et pour demain tout dépendra du positionnement au niveau du prix d'AMD par rapport à Intel car l'Athlon X2 et le Core 2 sont tout deux de bons processeurs.
Un nouvel article sur les Vertex Buffer Objects est disponible. Il se veut particulièrement complet.
Il est accompagné d'une série d'exemples présentant les fonctionnalités abordées ainsi qu'une utilisation conjointe avec GLSL et Cg.
Orange est un framework pour la création de jeux et d'applications graphiques.
Scene graph Gestionnaire d'erreurs et logger (Dont un log XML) Gestionnaire de ressources avec lecture depuis des archives au format 7z Gestionnaire d'objects par composants Détection des fuites de mémoire. Gestionnaire de langues Ensemble de patterns (Singleton, factory, tree, smart pointer...) Outils mathématique (Intégration de GLM)
Le projet est décomposé en plusieurs packages. Ceci est le package principal, nommé core, qui est totalement indépendant de la plateforme. D'autres packages, qui existent mais ne sont pas encore disponible, permettent de gérer le son, le temps, les threads, la fenêtre, etc... Ces packages plug-in sont eux dépendant de la plateforme mais s'efforce de proposer une interface indépendante. Des exemples présentent la plus part de fonctionnalités du framework.
Orange est distribué sous licence LGPL.
Ceci constituât la 100ème news de G-Truc Creation. :).
Je réalise actuellement une cloth simulation. Voici quelques screenshots :
GLM 0.3.2 corrige deux bugs importants. Le premier bug provient de la définition de l'opérateur de division des mat4 et imat4 et le second est une erreur dans l'accès aux composantes des vecteurs par (s t p q).
Pour la suite, la version 0.4 complètera les opérateurs des matrices et des vecteurs et apportera des fonctionnalités de GLSL 1.2. Tout d'abord, la clarification sur les conversions sera intégrée. De plus, les matrices 4 par 3 et l'"outer product" seront disponibles sous forme d'extensions. La fonction "transpose" est déjà disponible sous forme d'extension.
La version 0.5 intègrera les nouvelles fonctionnalités de GLSL 1.2 dans le core de GLM.
La version 0.6 supportera les swizzles opérateurs en lecture et écriture. (cad: vec3 v1(1.0, 2.0, 3.0); vec3 v2 = v1.xxx; v1.zyx = v;).
Game-Lab réouvre ses portes. Ce site propose l'une des plus belle collection de tutoriaux sur la création et la modification de jeux vidéo. Pour l'occasion, l'article sur le smart pointer a été publié sur Game-Lab.
Un nouvel article un disponible. Il présent le concept des smart pointer, un outil indispensable pour une résolution robuste des problemes de gestions de la mémoire.
Cette mise à jour apporte le support de GCC 4.0 sous MacOS X et le support GCC 4.0 et 4.1 sous Linux.
Lors de la GDC 2006, s'est déroulé une journée de tutoriaux sur OpenGL comme chaque année. Une partie de cette journée a été consacré à OpenGL 2.1 et l'avenir d'OpenGL, elle nous est relayée par Dave Astle sur GameDev.net et je vous relaye à mon tout avec quelques compléments.
On nous apprend tout d'abord qu'OpenGL charge de propriétaire, pour passer dans les mains du Khronos Group. Ceci était attendu, voir espéré, suite aux mauvaises nouvelles du coté de SGI, actuel propriétaire d'OpenGL, qui pourrait déposé le bilan cette année.
Pour ce qui est d'OpenGL 2.1, ARB_pixel_buffer_object et EXT_texture_sRGB viennent compléter le core d'OpenGL.
ARB_pixel_buffer_object reprend l'API des vertex buffer object (ARB_vertex_buffer_object) pour charger des pixels en mémoire. Cette fonctionnalité est disponible à partir des Radeon de première génération et des GeForce2 mx.
Pour EXT_texture_sRGB, le format sRGB représente un système de couleurs non linéaire standardisé par l'International Electrotechnical Commission (IEC) sous la référence IEC 61966-2-1. Concrètement, pour une couleur sur 8 bits avec une texture usuelle, les 8 bits de données sont convertis dans un interval [0, 1] de manière linéaire. Avec un système de couleur sRGB se n'est plus le cas, les texels subissent une correction équivalente à du gamma 2.2. Le screenshot ci-dessous illustre le procédé. Ce format est disponible chez nVidia pour les GeForce FX et supérieur depuis les drivers 80.
Intégré à OpenGL avec la version 2.0 par la promotion de ARB_texture_float, les textures flottantes subissent une modification mineure. Si la carte ne supporte pas les textures flottantes, OpenGL retourne maintenant une erreur au lieu de tenter une conversion en entier.
Deux nouvelles extensions sont prévues. La première, ARB_framebuffer_object est la promotion de EXT_framebuffer_object, EXT_framebuffer_multisample et EXT_framebuffer_blit qui décrivent la notion de framebuffer object introduit récemment et qui a conquit les développeurs OpenGL. Les framebuffer objects sont particulièrement utiles et efficaces pour le rendu sur texture. Ils viennent remplacer l'immonde WGL_ARB_pbuffer mais ne sont disponible qu'à partir du GeForce FX et de Radeon 9500. La seconde est nommée ARB_synch_object et apporte des perspectives très intéressante au niveau de la synchronisation entre le CPU et le GPU. Jusqu'à présent, seuls deux mécanismes permettent de gérer cette synchronisation, glFinish et glFlush. glFlush force les commandes émises précédemment à commencer leur exécution et glFinish force l'achèvement de toutes les commandes OpenGL. Cette extension permet de forcer l'achèvement d'une partie du code. Par exemple, lors de l'upload des vertrices, cette extension permet de s'assurer que les données ont bien été envoyées dans la mémoire de la carte graphique avant de les modifier. Cette extension est basée sur NV_fence, disponible pour toutes les cartes nVidia depuis le GeForce 256.
Enfin dernière évolution: GLSL 1.2. Pas de geometry shaders (nommés primitive shaders pour OpenGL) pour le moment, mais on pouvait s'y attendre du fait du processus de développement d'OpenGL basé sur la promotion. Il faudra attendre l'arrivé des extensions propriétaires qui seront disponible en même temps que les cartes. Au niveau des changements, il y a tout d'abord la possibilité d'accéder à un mipmap spécifique. Un nouveau qualificatif nommé "centroid" nous permettra de contrôler un texel lorsqu'il n'est pas couvert par un fragment ce qui pourrait être utile pour des tâches de filtrage ou éventuellement pour l'occlusion culling. Il est également état d'un nouvel attribut pour les fragments shaders lors de l'utilisation des points sprites basé sur un attribut déjà existant sous OpenGL ES. Je n'ai malheureusement pas trouvé cet attribut dans les spécifications de GLSL ES.
Au niveau du langage lui-même, GLSL devient plus souple au niveau des conversions. Il était avant impossible d'appeler la fonction void exemple(float parameter) ainsi exemple(1) car 1 est un entier. Avec GLSL 1.2, la conversion sera automatiquement faite. Ce mécanisme fonctionne avec toutes les types primitifs ce qui inclut vec3, ivec2, mat4 par exemple mais le nombre de composantes doit correspondre. ivec3 peut-être convertie en vec3 par exemple mais pas en ivec4. Les tableaux disposent également de nouvelles possibilités au niveau des comparaisons ou de l'affectation qui seront direct si les tableaux ont la même taille. GLSL 1.2 supportera les matrices non carrés et deux nouvelles fonctions : transpose() et outerProduct(). Enfin pour utiliser GLSL 1.2, il faudra utiliser #version 120.
OpenGL 2.1 sera annoncé au SIGGRAPH 2006.
De plus, de nombreuses informations sur les sujets de réflexions de l'ARB ont étés présentés notamment sur OpenGL 3.0 qui devrait être divisé en deux profiles. Un premier reprend OpenGL tel que nous le connaissons et un deuxième apportera une vague de changement pour créer OpenGL LM (Lean and Mean), une version agressive d'OpenGL prévu pour concurrencer Direct3D sur le secteur des jeux. OpenGL est un API très souple voir trop souple ce qui limite les optimisations et complexifier l'implémentation. OpenGL LM retirera toutes les parties d'OpenGL qui ne sont pas directement implémenté dans les cartes graphiques. Concrètement et dans l'état du projet, OpenGL LM ne supporterait que les VBOs pour le transfère de la géométrie. Un nouvel objet serait créé pour la gestion de tous les états. Le fixe pipeline disparaîtrait et le model objet d'OpenGL devrait charger. Ainsi, à la place des unsigned int pour les noms d'objets nous utiliserions des GLobject qui ne seraient rien d'autres que des void*. Toutes les nouveautés d'OpenGL LM devraient voir le jour sous forme d'extensions dans un premier temps. Voici qui est intéressant, OpenGL LM reprend le principe de DirectX 10 d'une API simplifiée mais sans layer, le tout en laissant OpenGL backward compatible.
Une update de la bibliothèque de fenêtrage est disponible. Elle apporche le support de Visual C++ 6.0 et 8.0 et améliore le support de MinGW pour l'édition WGL.
Voici une première évolution de G-Truc Creation depuis sa version 4 avec l'arrivé d'un flux RSS 2.0. Pour l'occasion, la dernière version des sources du site a été uploadé.
Ozone3D demeure très actif avec la publication d'une nouvelle version d'Hyperion ainsi que de nouveaux tutoriaux.
Un tutorial sur l'éclairage basé sur Phong est disponible, il aborde notamment les spots lights avec pénombre.
Un autre tutorial aborde le format 3DO de ATI pour la compression de normalmaps. En effet, il n'est pas recommandé d'utiliser un format S3TC pour la compression de normalmaps car ce format est destructif ce qui entraîne une dénormalisation des normales.
ATI a donc introduit la compression ATI2N avec les cartes X*00, présenté par Ozone3D, puis le format ATI1N avec la série X1*00. Espérons que nVidia entre dans la danse et que cette technologie se banalise à la manière du S3TC.
Les fabricants ne se lassent décidément pas de sortir de "nouvelles" cartes graphiques toujours plus puissantes.
Le GeForce 7600 GT vient prendre la relève de l'excellent GeForce 6600 GT avec une bonne progression au niveau des performances. Quand au GeForce 7900 GTX, le plus haut de gamme de nVidia, il ne améliore que très peu les performances du GeForce 7800 GTX 512.
Technologiquement nVidia reste légèrement en retrait par rapport à ATI notamment sur le point des formats de texture à nombre flottant utilisé pour le rendu HDR. Pour les performances Radeon X1900 et GeForce 7900 se valent cependant l'architechture du Radeon X1900 dispose d'un net avantage pour les branchements dynamiques c'est pourquoi je lui accordes l'avantage. Pour le milieu de gamme, ATI ne semble pas en mesure de lutter contre le GeForce 7600 GT.
A mon sens, ce qui ressort de ce nouveau chip c'est avant tout une bonne stratégie commerciale. Habituellement, ATI et nVidia ajoutent 10-20% de transistors pour chaque nouvelle génération de chips. Avec l'amélioration du procédé de gravure la taille du chip reste relativement stable. Pour cette génération, nVidia n'a pas ajouté de transistors mais en a retiré tout en passant d'un procédé en 110 nanomètres à un procédé en 90 nanomètres. Conclusion,le GeForce 7900 fait 2/3 de la taille du GeForce 7800 et le GeForce 7600 est plus petit que le GeForce 6600. En conséquence, la nouvelle génération chauffe moins et devrait coûter moins chère à nVidia car le coût d'un chip est directement proportionnel à sa taille.
Pour les nouvelles technologies, il faudra attendre la prochaine génération qui supportera Direct3D 10 dont notamment les geometry shaders et les shaders unifiés...
Un nouveau volume de la série des Game Programming Gems est disponible au Royaume Uni. Il sera disponible le 8 mars au Etats Unis et le 30 mars en France.
Espérons que ce volume soit aussi riche que le précédent !
Je viens de mettre à jour la bibliothèque de debuging. Elle dispose de plusieurs améliorations tel qu'un auto-flush des loggers ce qui peut être utile en cas de crash du programme.
J'ai également ajouté un logger XML comme je l'annonçais précédemment. Pour éviter une dépendance absolue avec TinyXML, le parseur XML utilisé, la bibliothèque est propose en deux versions, la première sans le parseur XML et la deuxième avec.
Le projet intègre un exemple de transformation XSLT du log d'exemple, ce résultat est également disponible via le lien ci-dessous. Cette transformation est réalité avec Xalan.
La bibliothèque et les exemples ont étés compilés et testés sous VC6.0, VC7.1, VC8.0, MinGW 3.2, MinGW 3.3 et MinGW 3.4.
Un nouvel article est disponible. Il traite des precompiled headers, un outil pour diminuer le temps de compilation d'un projet avec GCC (>= 3.4) et Visual C++ (>= 6.0). Cette technique est notamment utilisé dans les SDKs de Doom3 et Quake4 avec des résults ... intéressant !
Une nouvelle version de GLM est disponible. Elle améliore la conformité avec GLSL notamment au niveau de la création et conversion d'objets. De nouvelles extensions ont étés ajoutés. Ainsi GLM permet la gestion des nombres flottants à doubles précisions et démi précisions. De plus, plusieurs extensions ont étés développés pour améliorer mes performances des fonctions exponentielles et trigonométriques au détriment d'une précision légèrement réduite. Enfin une documentation Doxygen a été ajouté.
Le raytracer a été mise à jour et le tout a été testé sous GCC 3.2.3, GCC 3.4.2, Visual C++ 7.1 et Visual C++ 8.0.
Un nouveau projet est disponible. Il s'agit d'une bibliothèque destinée à faciliter la phase de debuging lors du developpement d'un projet.
Pour cela, trois outils sont intégrés. Premièrement, un système de log dans des fichiers textes, dans la console, dans Visual C++ ou enfin dans un message box. Deuxièmement, il est possible de déterminer s'il y a des fuites de mémoires et même de les quantifier. Enfin, pour aider à la recherche des fuites, il est possible de traquer les fuites sur des instances de classes. Un exemple inclut, montre tous les utilisations de cette bibliothèque.
Je vous invite à decouvrir ce projet surtout si vous n'utilisez pas d'outils tel que Boundchecker. Une update est prévue, elle intégrera un logger XML avec transformation en XHTML via XSLT.
Dans un tout autre registre, je reviens de quelques jours de visites à Londre, des photos sont disponibles.
Comme vous pouvez le voir une toute nouvelle version de G-Truc Creation est disponible. Elle utilise toujours massivement XML, XSLT et CSS et grâce à l'utilisation de XML pour la précédente version, j'ai récupéré tous les données de la version 3.
Le nouveau design à été tous spécialement étudier pour piquer un peu moins vos yeux, l'occasion de vous conseillez à nouveau d'utiliser un navigateur respectant les standards tel FireFox ou Opera. Internet Explorer (même la version 7 beta 2) reste une horreur.
Au niveau des nouvelles parties, j'ai commencé un listing des GPUs donc le but est de présenter les performances. Si vous souhaitez connaitre les features d'une carte graphique, repportez vous plutôt à GL View, un soft ultime à cet effet.
De plus, un "dictionnaire" est destiné à définir brièvement des concepts liés à la programmation de jeux et propose quelques références sur ce concept.
Enfin, j'ai ajouté une petite page avec les albums de mes artistes préférés afin de leur faire un peu de pub :p.
Pour bien commencé cette nouvelle version, j'ai ajouté deux commentaires de livres, le premier conserne More OpenGL Game Programming et le second décrit Game Programming Golden Rules.
Enfin, j'ai commencé une nouvelle génération de samples, qui seront à la fois OpenGL et Direct3D. Ces samples sont basés sur une bibliothèque nommée GL Window. Je l'ai écrit afin de proposer une API identique pour la fenêtre graphique avec OpenGL ou Direct3D ceci pour limiter le "bruit" que le code de la fenêtre engendre.
Si vous trouvez des bugs n'hésitez pas à me contacter.
oZone3D propose une nouvelle version de Hyperion. Elle intègre de nouvelles fonctionnalités afin de permettre les traitements GPGPU. De plus, un nouveau tutorial est disponible sur le site. Il décrit le procédé de création de fractals de Mandelbrot sur GPU.
J'engage mon passage à Visual Studio 2005 (VC 8.0). Ma principale motivation repose sur le support d'OpenMP par le compilateur, une API offrant de bonnes possibilités dans la gestion des processeurs multi-cores.
Ce passage a commencé par le constat d'amélioration du support de la norme ISO98 du C++, notamment au niveau des templates.
S'en est suivi des tests de performances sur mon raytracer qui m'a paru être un bon représentant des performances que je recherche, c'est à dire le rendu 3D.
Les tests ont étés réalisés avec des programmes compilés en mode release et consistent à générer une image en 320*240 de la scene décrite par le fichier "full.xml". Le même code source est utilisé et compilé pour Visual C++ 2003 (VC 7.1), Visual C++ 2005 (VC 8.0), GCC 3.2.3 et GCC 3.4.2 avec les options décritent dans le résultat et le tout sous Windows XP SP2. Le résultat donne le temps en secondes pour la génération de l'image.
Quelques remarques sur les paramètres utilisés. L'option /fp est une nouvelle option de VC 8.0, destinée au nombre flottant. Il existe plusieurs valeures dont "precise" et "fast". "fast" est une option qui dégrade la précision des nombres flottants pour améliorer les performances. Cette option est équivalente à l'option -ffast-math de GCC. La valeur "precise" utilise les nombres flottants normalisés IEEE. VC 7.1 ne support pas ces optimisations basérs sur des flottants dégradés donc si l'on veut justement comparer VC 7.1 et VC 8.0, je pense qu'il faut comparé avec la compilation VC 8.0 utilisant l'option /fp:precise.
Les résultats sont ci-dessous et se passe de commentaires mais je les ai tout de même les chiffrés au moyens d'un ratio indique la vitesse des programmes générés via les différents compilateurs. Ce ratio est visible sur le graph suivant.
18.23s: VC 8.0, /Ox, /Ot, /Ob1, /fp:precise, /GL, Whole Program Optimisation 14.12s: VC 8.0, /Ox, /Ot, /Ob1, /fp:fast, /GL, Whole Program Optimisation 10.13s: VC 7.1, /Ox, /Ot, /Ob1, /Og, Whole Program Optimisation 16.22s: GCC 3.4.2, -O2 11.95s: GCC 3.4.2, -O2, -ffast-math 20.36s: GCC 3.2.3, -O2 17.71s: GCC 3.2.3, -O2, -ffast-math
13.73s: VC 8.0, /Ox, /Ot, /Ob1, /fp:precise, /GL, Whole Program Optimisation 10.52s: VC 8.0, /Ox, /Ot, /Ob1, /fp:fast, /GL, Whole Program Optimisation 8.02s: VC 7.1, /Ox, /Ot, /Ob1, /Og, Whole Program Optimisation 10.81s: GCC 3.4.2, -O2 9.08s: GCC 3.4.2, -O2, -ffast-math 14.02s: GCC 3.2.3, -O2 12.41s: GCC 3.2.3, -O2, -ffast-math
ERRATUM : Les tests sur VC7.1 ont étés réalisés en mode "fast" et non "precise" comme je le pensais. En effet, VC 7.1 utilise par défaut des optimisation non standard sur les nombres flottants, pour passer en mode "precise" il faut utilise l'option "/op".
oZone3D est le nouveau partenaire de G-Truc Creation. Il s'agit d'un site dédié au rendu temps réel au moyen de tutoriaux et d'un demo system nommé Hyperion.
Hyperion est distribué avec sa documentation en francais et anglais et plusieurs demoscenes sont disponibles. De plus de nombreux outils sont disponible pour l'accompagner.
Encore en rendu de terrain en actuscreen. Celui ci utilise GLSL notamment pour le rendu d'eau. D'autres rendus de terrains sont encore prévus mais il utiliseront d'autres algorithmes de génération de la geometrie. Il s'agit ici d'un quadtree qui diffère du précédent rendu de terrain, par une optimisation massive.
Un nouvel actuscreen a été ajouté montrant le model d'éclairage de Interstate Gangs.
Un nouvel actuscreen est disponible sur un projet que j'ai commencé l'été dernier et que je vais poursuivre.
Il est vrai que je n'ai pas updaté G-Truc Creation depuis un moment pourtant mon activité ne s'est pas arrété, voir au contraire.
J'ai d'ailleurs de nombreux sujets sur le feu, comme une mise à jour de GLM, de petites bibliothèques pour le chargement de textures ou la création de fenêtre, un nouveau pack de tutoriaux OpenGL voir encore une nouvelle version du site de G-Truc Creation.
Vous êtes au courant j'espère, Microsoft a décidé de tuer OpenGL sous Windows Vista en l'émulant avec DirectX et en empêchant un système d'extension comme actuellement sous Windows 9X, 2K et XP.
Les conséquences : Des performances très largement massacrés à hauteur de 50% et une limite au core d'OpenGL 1.4 : Pas de GLSL, c'est à dire pas de programmation GPU.
Bref dans un tel état qui voudrait bien encore d'OpenGL sous Windows : en tout cas pas moi, et vous ?
Alors si au niveau des jeux il est vrai que DirectX a pris le pas sur OpenGL nous étions en espoir de voir OpenGL revenir sur le devant de la scène car c'est cet API qui est utilisé pour programmer sous PS3. Plus important, la plus part des outils de développement tourne sous OpenGL et non DirectX (Lightware, Maya, After effect, ...)
Avec Windows Vista, Microsoft souhait continué à obtenir le contrôle des spécifications de tout le matériel.
Donc pour lutter contre ce fléau, la communauté OpenGL recommande d'écrire aux fabricants. Donc voici les adresses de deux bons colosses ci dessous.
Sans OpenGL, asta la Vista Windows !
Voici, pas mal de temps que je n'ai pas mis ajout le site et d'ailleurs il est vraisemblable qui ne sera plus être autant actualisé souvent avant novembre 2005.
Mais pourquoi donc cette nouvelle ?! Pour plusieurs raisons dont l'une est ma participation au contest GameDev "4 elements 4" avec une entrée nommée Interstate Gangs qui sera fortement inspiré de Interstate 76 (HiHi, c'est la 76eme news de G-Truc Creation ^_^) pour le gameplay et de Fallout et MadMax pour le background.
Je participe à ce projet avec DukeNuken(Codeur) et In_Head(Modeleur/Animateur) mais nous avons besoin de quelqu'un pour tout le coté scénario (Détail du scénario, rédaction des sous-titrage des cinématiques, etc...) ainsi que pour ce qui touche au bruitage. Donc si ca vous dit un petit email ;).
Autre conséquence, je mets mes autres projets en pause.
Voici une nouvelle version de Spots Battle. Elle intègre à présent une véritable FSM parfaitement robuste et introduit la notion de message router.
Cet amélioration on permit de complixifier le comportement des points bien que le programme manque encore de maturité.
J'ai le plaisir de vous annoncer la venue au monde d'un heureux évènement, il s'agit d'un magnifique bébé de 194 Ko prénommé GLM 0.2.
Pour rappel, GLM (OpenGL Mathematics) est une bibliothèque mathématique basée sur les spécifications de GLSL (OpenGL Shading Langage).
Cette nouvelle version étend les fonctionnalités issues de GLSL par le biais d'extensions et améliore le portage de GLSL à C++.
Un exemple d'utilisation est disponible au travers du RayTracer que j'ai présenté en "Actuscreen".
Pour plus d'informations, consultez le site de GLM.
Spots Battle est un petit programme d'"IA" basé sur les FSMs (Finite State Machines). Il n'y a aucun intéraction entre l'utilisateur et l'ordinateur, les points mènent leurs vie suivant leurs règles avec ici pour objectif, annihiler les autres races.
Je n'ai plus Linux pendant encore plus de deux mois, donc j'ai inclut un makefile mais je n'ai put le tester.
Dans un tout autre sujet, notez que le site de GLM a été mit à jour avec l'ajout d'un version anglaise réalisé par CH4NDL3R. Ceci annonce la sortie prochaine de GLM 0.2 ainsi que du Raytracer que j'ai présenté depuis quelques temps en guise d'exemple.
Les anciens forums, hébergés sur un autre site, ont été détruits c'est pourquoi j'en ai créé de nouveaux qui sont à présent hébergés sur G-Truc.net.
J'ai ajouté un forum pour le postage de commentaires sur les livres que j'ai commenté. Si vous connaissez l'un des livres, voir d'autres n'ésitez pas partager votre point de vue.
Une nouvelle version de Shoot(r) est disponible. Rien de bien nouveau, deux immondes bugs corrigés ainsi qu'une mise à jour pour le support de GCC et MinGW 3.4.
Je viens de terminer la série d'articles sur GLSL avec la dernière partie nommée "Place à la pratique". Il inclut un exemple du multitexturing avec test alpha.
De plus, tous les articles ont étés transformés au format PDF.
A l'avenir, des exemples de programmes GLSL seront ajoutés dans le pack du tutoriaux OpenGL de G-Truc Creation.
J'ai ajouté un nouvel album de photos nommés 'L'oeil du moustique'.
Le site d'OpenGL Mathematics (GLM) est à présent disponible en français. Une nouvelle version anglaise est en cours de traduction par CH4NDL3R.
Je viens de mettre à jour l'article sur les niveaux de détails dédiés aux cartes de hauteurs. Il explique maintenant le fonctionnement de ROAM dans une optique de subdivision seul.
J'ai ajouté un nouveau commentaire de livre sur "Pour mieux développer avec C++", encore un très bon livre.
J'ai commencé un nouvel article sur le rendu de cartes de hauteurs avec niveau de détails. Il pourra intéresser toute personne souhaitant s'investir dans le rendu de terrains. Pour le moment, il ne traite que du QuadTree mais ROAM viendra s'ajouter par la suite.
Sinon oui, la suite de la série d'articles sur GLSL va venir ^^. Il en va de même pour le pack de tuts OpenGL, qui en passant, s'offrira un petit régime, utilisera GLF, disposera de projets pour DevCPP et se tournera plus que jamais vers la programmation GPU.
Enfin, j'en profite pour signaler une information qui me semble importante mais qui est passée inaperçue. Les drivers BETA de 75.90 de nVidia sont disponible et sont qualifiés de drivers 'OpenGL 2.0'. Concrètement par rapport aux drivers officiels 66.93, il intègre deux nouvelles extensions : GL_ARB_half_float_pixel (Et dire que certains utilisent des 'double' :p) et surtout GL_EXT_framebuffer_object qui offre des possibilités de manipulation du framebuffer intéressantes et souples. Cette extension devrait être intégré au core d'OpenGL 2.1 selon les 'meeting notes'.
OpenGL Framework est une bibliothèque souhaitant offrir une implémentation C++ de l'API OpenGL. Il ne s'agit en aucun cas de proposer un modèle objet mais simplement de profiter de quelques fonctionnalités appréciables de C++ telle que la surcharge de fonctions, les constructeurs et les espaces de noms. En clair, au lieu d'utiliser la fonction glVertex3f(), l'implémentation proposera la fonction gl::Vertex(). Enfin, une interaction avec OpenGL Mathematics est prévu de tel manière que l'on pourra écrire : gl::Vertex(vec3(0,0,0)).
Quand à OpenGL Mathematics (GLM), il s'agit d'une bibliothèque basée sur les spécifications de l'OpenGL Shading Language (GLSL) et inclut dans GLF. Il s'agit d'offrir à l'utilisateur le même confort de programmation OpenGL que lorsqu'il programme avec GLSL. Ainsi, toutes les types vecteurs et matrices de GLSL sont supportés et la plus part des fonctions sont disponibles.
Actuellement, GLF est limité à GLM avec des headers portables pour OpenGL.
Pour ces projets, j'ai recherché à construire une bonne démarche de développement. Ainsi, je me suis basé les spécifications d'OpenGL mais aussi sur les documents décrivant comment doit être développé OpenGL et enfin sur les "meeting notes" qui sont le meilleur moyen d'être à la pointe du progrès d'OpenGL.
Enfin pour l'évolution des ces projets je compte sur vous car la pensée unique d'un seul homme n'est pas suffisante pour assurer un développement parfaitement robuste. Ceci explique pourquoi il existe deux types de releases : les 'users' et les 'contributors'. Les versions 'users' contiennent le minimum pour utiliser les bibliothèques et les contributors contiennent l'ensemble des documents utilisés pour le développement ainsi que tous les informations concernant les bugs connus les problématiques de développement ou encore des propositions d'extensions.
Le C++ Efficace est le titre d'un livre que je viens d'ajouter dans les commentaires de livres. Ce n'est autre que la version française de Effective C++. Un excellent livre que je vous conseille.
Planet Mods organise une Mod Party sur Paris. Il s'agit d'une réunion de développeurs de modifications de jeux. Des projets amateurs seront présentés et j'y participerai comme ex-membre du mod WormsHL.
La quatrième partie du tutoriau sur GLSL est disponible. Elle est chargé de présenter l'API des extensions permettant d'utiliser GLSL. Bonne lecture !
Le site GameTurotial a subit une mise à jour important. D'une part le design du site a complètement changé mais, surtout, tous les tutoriaux sont devenu payant. A 5$ le tutorial qui affiche un triangle dans une fenêtre !
Voici une grosse perte pour la communauté amateur car de nombreux tutoriaux sont vraiment intéressant.
GameTutorials choisi de rendre payant leurs tutoriaux, G-Truc Creation choisi de supprimer sont liens vers ce site et vous garantie qu'il n'en sera jamais de même sur ses pages.
Je viens de mettre le site de Shoot(r) à jour et j'en profit pour mettre à votre disposition ses sources. Pour rappel, le site est réalisé avec Flash MX et XML.
J'ai commencé une série d'articles sur le langage GLSL (OpenGL Shading Langage) permettant la programmation GPU. Trois premiers documents sont disponibles et d'autres sont avenir.
Le premier présent le langage mais aussi les tenants et aboutissants. Le second décrit les variables GLSL et le troisème liste les fonctions intégrés de GLSL.
De plus, une mise à jour de Piranha est disponible. Elle corrige quelques bugs et intègre la carte qu'Invalide avait réalisé pour TAM.
Enfin, vous pouvez télécharger GTL Beta 1.2 qui corrige quelques bugs.
Une nouvelle version de Piranha est disponible. De nouvelles scènes, des améliorations sur d'autres.
Je tombe a mon tour sour le joue de la photo numérique. J'ai ajouté une rubrique pour les photos ainsi que mon premier album nommé 'Il s'appelle Bob'.
Une nouvelle version de Piranha est disponible. Beaucoup de travail a été réalisé pour nettoyer le code mais aussi sur le rendu de terrain pour les scènes sur terre.
Je n'aurais normalement plus accès au net jusqu'au 5 janvier 2005 donc je ne pourrais pas mettre à jour G-Truc Creation jusqu'à cette date.
Pendant toute cette période de vacances, je vais passer un bon moment à programmer Piranha mais je pense aussi continuer le développement de G-Tut Pack avec de nouveaux exemples utilisant GLSL.
Je viens de terminer le nouveau site de Shoot(r). Il reprend le design de l'ancienne version mais est réalisé avec Flash MX.
Oui en Flash ! En effet, l'utilisation d'un outil propriétaire n'est pas dans mon habitude mais Flash offre des fonctionnalités intéressantes si l'on prend soin de s'y intéresser. Remarquez que le design se tourne toujours vers l'ergonomie et non vers le graphisme. Toutes les données sont chargées dynamiquement depuis des fichiers XML, ce qui m'a permit d'intégrer une traduction anglaise.
Je ne sais pas si je referais un site en Flash mais je suis convaincu que la normalisation d'une technologie issue de Flash pourrait énormément apporter à la programmation web.
Une première version de Piranha est à présent disponible au téléchargement. Le projet est prévu pour VC7.1, MinGW et GCC. Pour profiter de la démo, il vous faut une carte graphique comportant au moins 4 unités de textures et supportant GLSL 1.00, c'est à dire une GF FX 5200 ou une Radeon 9500 et supérieur.
G-Truc Creation accueil un nouveau partenaire : Coder Studio. Je vous invite à visiter ce site très intéressant.
Notez également que j'ai modifié la bannière du site.
Je réalise actuellement une démoscène OpenGL appelé Piranha. Voici, les premiers screenshots, des scènes d'intros et des scènes qui se déroulent dans l'espace. Retrouvez ces screenshots dans la rubrique actuscreen.
Voici une petite mise à jour de GTL qui apporte principalement des corrections de bugs.
Correction du bug de la transparence des particules dans l'exemple 'particles'. Optimisation de la gestion des collisions de l'exemple 'particles'. Correction des bugs des constructeurs des matrices CMatrix2x2 et CMatrix3x3. Correction des bugs des fonctions de rotation autour d'un axe de la matrice CMatrix4x4. Correction du calcul de déterminants et d'inverses de CMatrix3x3. Paramétrage de la longeur de champ de vision plus simple de la class CCamera. Amélioration de la classe CQuaternion. Correction des opérations += et -= de la classe CVector4. Amélioration des calculs de normes des classes CVector2, CVector3, CVector4.
Je viens de mettre à jour le Pack de tutoriaux OpenGL avec 11 nouveaux exemples ainsi que la page des tutoriaux OpenGL.
Ajout de l'exemple "ogl-fenetre2", Viewport Ajout de l'exemple "ogl-texture6", filtrage de textures Ajout de l'exemple "ogl-ligne1", lignes standards et stipples Ajout de l'exemple "ogl-ligne2", Algorithme de Bresenham Ajout de l'exemple "ogl-ligne3", Gestion des contours Ajout de l'exemple "ogl-lighting2", Materiaux Ajout de l'exemple "ogl-lighting3", Eclairage d'une texture Ajout de l'exemple "ogl-lighting4", Separate specular Ajout de l'exemple "ogl-test-scission2", Superposition de rendu Ajout de l'exemple "ogl-test-stencil1", masque de formes quelconques Ajout de l'exemple "ogl-test-stencil2", effet d'inversions chromatiques Renommage des exemples
De plus, je mets à votre disposition une démo de moteur de particules que j'ai réalisé cet été et que j'ai commenté dans les actuscreens.
Une nouvelle version de mon visualisateur de modèles MD5 est disponible. Elle permet a présent de visualiser le modèle texture avec DOT3 bump mapping.
Notez que G-MD5-Viewer est distribué sans modèle. Je recherche quelqu'un pour faire un modèle qui sera intégré au programme afin de mettre un exemple d'utilisation. Si vous êtes intéressé, veuillez me contacter.
De plus, G-Truc Creation dispose d'un nouveau partenaire : Le site Texel. Je vous invite à le visiter, il comporte des projets et des tutoriaux intéressants.
Je réalise actuellement un loader MD5, le format des modèles de Doom 3.
Ce format à la particularité d'être lisible sous forme de texte et d'être décomposé en trois partie : Mesh, Animation, Camera.
Pour le moment, le loader ne charge que les meshes MD5 sans texture.
Et oui, G-Truc Creation à 2 ans ! Né à la suite du site de Zglu, un mod que je développais pour Quake 2. Avec l'envie de partager mes connaissances, j'ai alors commencé à diffuser mes démos en open source. Ainsi, le site de Zglu quitta sa ligne directrice pour devenir G-Truc Creation.
Pourquoi ce nom G-Truc Creation ? Non, ce n'est pas le fruit du hasard, d'ailleurs je ne crois pas au hasard. Le 'G', c'est simplement la première lettre de Groove, mon speudo que j'ai choisi quand j'ai découvert Interstate 76 en 1997. 'G-Truc' c'est en hommage à mes premiers programmes écrit en quick basic que j'ai écris la même époque. Oui, je n'avais jamais eu beaucoup d'imagination pour les noms. Concernant le qualificatif 'Creation' c'est une référence à une décision législative de 1985-1986 au moment où il a fallu définir le droit d'auteur pour le jeu vidéo. Il s'agissait de choisir d'appliquer soit les règles du droit d'auteur définit pour le logiciel, soit celles définit pour les ouvres audiovisuelles, cette dernière étant notamment défendu par les créateurs de jeux comme ATARI. La justice a décidé que le jeu vidéo serait soumit au droit d'auteur définit pour le logiciel, ce qui renit toutes inspirations artistiques et de ce fait on peut l'appelé produit et non chef-d'oeuvre. Le choix du qualificatif 'Creation' précise mes convictions en insistant sur ce qui est le propre de l'art, son coté créatif. Voilà , j'en termine avec cette réflexion Groovienne :p.
Pour marquer cette journée, je vous propose tout d'abord une mise à jour du pack d'exemples de programmes OpenGL. Le nombre d'exemples passe à 48, soit 5 de plus que pour la version précédente. Quoi de neuf ? 2 exemples de motion blur supplémentaires. Le premier utilisant le tampon d'accumulation et le second utilisant l'extension d'OpenGL 2.0 nommée GL_ARB_texture_rentangle. En fait, pour cet exemple, je suis partie de l'exemple de motion blur utilisant les textures 2D pour montrer l'intérêt de l'extension car il est possible de réaliser un effet de motion blur en une seule passe alors qu'il en fallait deux jusqu'à présent. Un troisième exemple traite du texture adressing et enfin les deux derniers abordent l'OpenGL Shading Langage au travers d'un exemple élémentaire puis un exemple de vertex displacement avec une 'simulation de drapeaux'.
Il me reste une dernière chose à vous présenter, c'est mon dernier projet nommé Shoot(r). Il s'agit d'un simple Shoot 'em up OpenGL que j'ai réalisé pour le magazine Code(r). Il est disponible sous Windows et sous Linux sous licence GPL et j'espère pour votre plus grand plaisir.
Après de nombreux mois de gestation la beta 1.0 du basecode de G-Truc Creation est disponible.
Cette nouvelle version de GTL est utilisée dans la prochaine mise à jour de G-Tut-Pack et dans Shoot(r) v1.1 qui seront tous deux disponibles d'ici la fin du mois.
Ajout du chargement de shaders. Ajout de la vérification du support des extensions. Ajout du support des nombres complexes sous forme algébrique et trigonométrique. Ajout de fonctionnalités pour aux vecteurs : Maximum, minimum, saturation et valeur absolue. Ajout de d'une fonctionnalité permettant de réaliser simultanément une multiplication et une addition. Ajout de matrice 2x2 et 3x3. Ajout de la prise de screenshot. Ajout de la détection des erreurs d'OpenGL. Ajout d'une classe quaternion. Ajout d'outils pour les transformations par des matrices. Ajout de la convertion de couleur RGB en couleur HLS. Ajout de calcules de vecteurs projetés et de vecteurs perpendiculaires. Ajout d'un exemple illustrant les transformations par les fonctions OpenGL, par matrices et par quaternions. Ajout d'un exemple montrant l'éclairage d'un terrain avec calcul de normales par sommet. Ajout d'un exemple utilisant la projection de vecteur pour la gestion des collisions. Correction de la matrice 4x4. Correction de gtl_math.h. Support des extensions d'OpenGL 2.0. Support de MinGW complet.
Les archives suivantes contiennent des données identiques et fonctionnelles sous Linux et Windows. Notez l'efficacité du format libre 7z en terme de compression !
Voici la version 3.7 de G-Truc.net. Cette nouvelle version apporte notamment une réorganisation des menus mais surtout l'organisation des fichiers de données (les fichiers XML) a été complètement revue.
En effet, à présent toutes les données sont enregistrées dans un seul et même fichier. Ceci permet de supprimer les redondances de données et facilités la mise à jour du site. Concrètement, j'utilise une feuille de style XSLT pour chaque page du site, appliquée sur un unique fichier XML, chaque fichier XSLT récupérant les données qu'il a besoin.
Dans un autre sujet, je recherche un graphiste 2D pour réaliser des dessins de vaisseaux spatiaux, de bonus, de tires, etc. en vue de la publication de la version 1.1 de Shoot(r) du jeux début novembre sur ce site. Si vous êtes intéressé, merci de me contacter par e-mail.
A propos de cette version 1.1, sachez qu'elle sera disponible pour Windows (Devcpp, MinGW, MinGW Developper Studio et VC7.1) et Linux (GCC).
Je vous propose aujourd'hui de partager mes lectures de l'été au travers de huit commentaires de livres.
- Data Structures for Game Programmers - Design Patterns - UML 2.0 - The pragmatic programmer - Mathematics for 3D Game Programming and Computer Graphics - Game programming gems - PHP 5 - MySQL et PHP
Enfin, notez que le numéro 10 de Code(r), en kiosque depuis début septembre, publié deux articles que j'ai écrit. Le premier sur UML et le deuxième proposant la réalisation d'un shoot'em up.
Mitose, c'est le nom de ma nouvelle démo OpenGL. Vous pouvez la télécharger ici.
Comme je l'avais annoncé lors de la précédente news, j'ai supprimé la liste de tutoriaux pour en faire des groupes de tutoriaux afin de gagner de la place sur mon compte. Les tutoriaux sont donc regroupées dans un pack nommé G-Tut Pack et tous les tutoriaux sont disponibles pour GCC, MinGW et Visual C++ 7.1.
J'ai également réalisé quelques modifications sur le site : Correction de quelques bugs et changement des pages "liens" et "Tutoriaux".
Vous avez certainement remarqué que le site évolue très peu en ce moment. En effet, d'une part j'ai eu moins de temps à y consacrer en juin d'autre part mon espace d'hébergement en totalement pleins.
Pour remédier à ce second problème j'ai l'intention de transformer les tutoriaux en packs de tutoriaux qui seraient des groupes de tutoriaux en fonction du compilateur et de la bibliothèque pour la fenêtre OpenGL utilisés.
De plus, je pense supprimer les versions DevCPP et MinGW Developper Studio pour ne laisser que la version MinGW en ligne de commande. Si vous souhaitez que je conserve les tutoriaux pour DevCPP écrivez moi un petit courrier.
Enfin, je pense ajouter des exemples d'utilisations des conteneurs de la STL. Il ne s'agira pas d'exemples ayant le moindre intérêt, ils montreront simplement comment s'en servir.
G-Truc Creation accueil un nouveau partenaire : Game-Lab. Il s'agit d'un site sur la création de jeux vidéo et le game edting que je visite régulièrement et donc que je vous recommande personnellement.
J'ai ajouté trois commentaires de livres. Comme habituellement j'ai ajouté des livres que je trouve particulièrement intéressant mais parmi ces livres, le livre sur XSLT sort véritablement du lot.
- Programmer en langage C++ - Langage C - XSLT : Développement en XML et HTML
J'ai ajouté 3 nouveaux tutoriaux OpenGL et modifié celui sur le piking OpenGL.
- Piking : Sélection d'objets - Piking : Passage de coordonnées 2D en 3D - Test de scission - Test Alpha
J'ai ajouté 10 nouveaux tutoriaux. 6 sont consacrés aux vertex arrays avec notamment de l'utilisation de GL_ARB_vertex_buffer_object d'OpenGL 1.5, 2 montrant l'utilisation des display lists pour par exemple afficher du texte à l'écran, 1 sur l'extension GL_ARB_occlusion_query d'OpenGL 1.5 et 1 sur la sélection d'objets dans une scène 3D avec la souris.
- Sélection d'objets - GL_ARB_occlusion_query - Display list : Affichage de textes - Display list - GL_ARB_vertex_buffer_object : Indexed interleaved vertex array - GL_ARB_vertex_buffer_object : Interleaved vertex array - GL_ARB_vertex_buffer_object : Vertex array - Indexed interleaved vertex array - Interleaved vertex array - Vertex array
J'ai ajouté trois nouveaux commentaires de livres.