La documentation est en ligne !
Bonsoir à tous !
La documentation du moteur est maintenant disponible en ligne !
Toute personne voulant participer à la documentation (correction du mauvais anglais, ajout de doc manquante, etc., y'a du boulot) est la bienvenue, et peut nous contacter via le forum.
Bonne visite de la doc ;-)
Premiers tests de shadow mapping
Salut,
Après deux journées d'acharnement, le fruit de mes efforts est enfin mûr (ou presque). J'ai hébergé en vitesse un screenshot du résultat que je parviens à obtenir actuellement sur ma nouvelle carte graphique, une Radeon HD4850.
J'ai utilisé deux shaders, un pour le rendu de la depth map et un autre pour le rendu final, comme vous pouvez le voir l'alpha de la texture appliquée au modèle est pris en compte. L'ombre n'est pour le moment pas encore lissée, mais bon cette étape, on verra plus tard, j'ai pour l'instant quelques problèmes de z-fighting sur ma 6600GT que je ne parviens à éviter qu'en hackant dans mon shader...
Bon, le point positif c'est que j'ai réussi à créer une vraie ombre qui marche bien, même que l'implémentation de la technique avec mon moteur n'a pas été laborieuse, ce qui est une bonne chose qui permet d'avancer que la structure de mon moteur n'est pas trop mauvaise. De toute façon, ce n'est qu'en l'essayant que je saurai réellement ce qu'il vaut, donc au fil de mes tests de technique je me rendrai bien compte des lacunes de mon moteur.
Petit mot au passage, vous remarquerez qu'aucune nouvelle version du moteur n'est sortie pour le 42 juillet, et ceci pour la simple et bonne raison que je n'avais pas suffisamment travaillé dessus pour prétendre pouvoir augmenter un chiffre de version.
Annonce : un Git repository est maintenant disponible pour le moteur ! Vous pourrez ainsi obtenir la toute dernière version en cours de développement. Pour récupérer le SCEngine à partir du repository tapez simplement :
$ git clone git://git.tuxfamily.org/gitroot/scengine/scengine.git master
Vous l'aurez remarqué, je me suis créé un compte chez TuxFamily, pour l'instant il me servira uniquement pour le repository du moteur.
Sortie d'OpenGL 3.0 !
C'est le 11 août dernier que les spécifications de la troisième version d'OpenGL ont été publiées. Annoncée il y a déjà un an, la 8ème révision de l'API 3D s'est faite attendre, c'est le moins qu'on puisse dire.
Au premier survol des spécifications d'OpenGL 3, qui sont franchement imbouffables, j'ai constaté avec joie que la nouvelle version de l'API n'est pas le gros changement du siècle comme tout le monde le laissait entendre, on aura donc droit à nos glBegin/glEnd et à nos display lists contrairement à ce qui était "prévu" (sachant que mes prédictions se basaient sur des rumeurs).
Au menu des nouveautés je serai malheureusement bref, car je n'ai pas encore réussi à comprendre toutes les subtilités des quelques nouvelles fonctions qui ont vu le jour. On pourra noter un "transform feedback" qui semble sauvegarder dans un buffer grâce à un vertex shader des informations sur le précédent rendu. Les frame buffer objects sont "officialisés", donc plus obligé de passer par les extensions si on dispose de l'implémentation d'OpenGL 3. Les vertex arrays sont maintenant implémentés sous forme d'objets à l'instar des VBOs, ce qui permet aux programmeurs une meilleure organisation du code pour switcher entre VBO/VA. Les vertex buffer objects peuvent dorénavant être mis à jour de manière "non bloquante" (ne m'en demandez pas plus), et il est possible de ne mettre à jour qu'une partie du buffer, cela permet de limiter les transferts et de gagner en bande passante.
Du côté des shaders on notera là aussi une nouvelle version du GLSL, la 1.3. Les geometry shaders sont bien sûr disponibles et sont représentés par l'extension GL_ARB_geometry_shader4.
http://opengl.org/documentation/specs
Régalez-vous !
Dynamic Ambient Occlusion : vu dans Crysis
Salut tout le monde,
Suite à la récente acquisition d'une carte graphique relativement récente (et du PC qui va avec), je ne pouvais pas passer à côté du test de ce jeu de dernière génération présentant un lot de techniques de rendu sympathiques. On trouve parmi elles de l'ambient occlusion dynamique. L'ambient occlusion est une technique d'ombrage visant à assombrir deux polygones s'ils sont relativement proches l'un de l'autre. Posez par exemple une balle au sol, et regardez en dessous, un zone sombre circulaire est présente. En théorie le calcul de ambient occlusion est relativement lent, mais l'alternative de Crytek est intéressante. Comme pour les reflets spéculaires sur Trackmania, c'est un gros fake mais le résultat est très convaincant : 
Pour parler de la technique utilisée, je vous avouerai que je n'ai pas pu m'assurer, contrairement à Trackmania, que c'était bien ce que j'ai supposé. Toutefois cela m'a donné des idées qu'il faudra que je pense à mettre en pratique.
D'après ces screens, on peut remarquer que l'ambient occlusion forme une zone sombre qui suit les contours de(s) l'objet(s), cette impression est d'autant plus grande lorsqu'on joue à Crysis et que l'on peut faire bouger la caméra. 
La mise en œuvre semble simple (à priori), il suffirait d'effectuer le rendu de la géométrie et de la profondeur de chaque pixel sur un buffer, flouter ce buffer et le rendre par dessus la scène en prenant en compte la différence de profondeur entre le pixel du buffer et celui du framebuffer. Si l'écart est faible, on peut considérer que le mesh générant l'ombre est « proche » de celui la recevant, et donc assombrir la zone correspondante. Bon, ma description (remaniée par Ban au passage) n'est peut-être pas super compréhensible voir même ne produit pas un résultat correct, mais l'idée est là, et le concept est attrayant. C'est donc une idée à creuser.
Bonne nuit !
SCEngine v0.0.6 released !
Salut à tous !
Après 15 jours de "rééducation" afin de me replonger dans le code de mon moteur, je sors aujourd'hui la version 0.0.6. Pourquoi aujourd'hui ? Parce qu'on est le 42 juin, alors je me suis dis que ça pouvait être rigolo. Dorénavant je vous donnerai rendez-vous tous les 42 du mois pour une nouvelle version du moteur !
Au menu des améliorations, on pourra trouver :
- La possibilité d'utiliser la commande de préprocesseur #include dans les fichiers de shaders GLSL et Cg ;
- La possibilité d'envoyer un paramètre de shader automatiquement à chaque frame ;
- Un algorithme de tri de l'ordre de rendu des faces des meshs, de la plus éloignée à la plus proche ou l'inverse ;
- Implémentation d'un module de gestion des octrees, ce module n'est toutefois pas encore utilisé ;
- Une refonte totale du gestionnaire de scènes, avec l'élaboration d'une architecture avec un principe de fonctionnement bien défini (contrairement à la version 0.0.5 qui proposait de spécifier quelques callbacks de façon bourrin sans trop qu'on sache ce qui se passe, en bref c'était un lot de fonctions divines).
Avec cela s'ajoute une habituelle correction de bugs divers et variés. La nouvelle architecture du gestionnaire de scènes s'appui maintenant sur un principe simple : une update de la scène implique la sélection des informations nécessaires et suffisantes à la réalisation d'un rendu. En clair, on demande une update avec telle caméra sur tel framebuffer, et paf les informations de rendus sont disponibles et peuvent être exploitées (pour un rendu par exemple). Il est évidemment possible d'imbriquer plusieurs rendus, c'est-à-dire faire plusieurs updates à la suite tout en conservant les informations de rendu précédentes. 8 sauvegardes sont possibles pour le moment, mais pour faire bouger cette limite il suffit de toucher à une constante et c'est dans la poche. En bref, j'espère que cette architecture me permettra de faire à peu près tout ce qui est possible de faire... il ne reste plus qu'à essayer de faire des applications exotiques pour tester sa fiabilité.
En attendant que le module de téléchargements soit remis sur pieds, je vous propose le lien vers mon ftp où j'ai hébergé et où j'hébergerai dorénavant tous les médias et versions du moteur : http://downloads.goldzoneweb.info/scengine/
Et un lien direct pour télécharger la dernière version du moteur ici.
J'essayerai de programmer une petite application sympathique histoire de vous faire parvenir quelques nouveaux screenshots.
Bonne soirée !
Site en maintenance
Salut,
Le site est actuellement en maintenance. GoldZoneWeb m'a offert un accès ftp illimité (merci !), alors le site risque de ne pas fonctionner super bien du côté downloads/médias le temps qu'on mette tout ça en place.
A+
Technique de rendu des reflets spéculaires
Vous connaissez probablement Trackmania, un jeu de course de voiture fun et acrobatique développé par le studio français Nadeo. Il s'avère que je suis un fan de ce jeu, et comme tout fan qui se respecte, je joue à Trackmania de temps à autres. Aujourd'hui, j'ai inopinément décidé et me balader en mode caméra libre, et j'ai découvert (de manière inattendue) la technique de rendu des reflets spéculaires dans Trackmania, reflets que Ban et moi avons toujours trouvé très réussis et très beaux. Ces si fabuleux reflets ne sont en réalité rien d'autre que des billboards dessinés sur la scène rendue avec ses spécular maps (ainsi les zones sombres ne produisent aucun reflet). L'image obtenue est ensuite additionnée sur le rendu final pour un effet semblable à celui-ci :
Essayons à présent de nous rendre dans un endroit de la scène où le reflet sera systématiquement dessiné, c'est-à-dire sans aucune restriction dûe aux spécular maps. Voici l'image obtenue quelques étages plus bas, sous le "sol" de la scène :
Comme vous pouvez le constater, les billboards correspondant aux reflets spéculaires des sources lumineuses sont dessinés entièrement et sur fond noir, ce qui nous permet de bien les distinguer.
On pourrait voir ici une technique "révolutionnaire" ; non seulement elle produit un résultat visuel très appréciable, mais en plus elle permet la gestion d'une multitude de lumières sans faire ramer l'application (à modérer toutefois, car des billboards de cette taille ne sont pas très rapides au rendu). Mais comme il fallait s'en douter, cette technique a ses inconvénients. Bien qu'ils ne soient pas remarquables au premier abord lorsqu'on joue à Trackmania, si on y regarde de plus près on s'aperçoit que les artefacts de rendu sont très nombreux, en fait il s'agit plus de défauts "physiques" que de réels artefacts. Premièrement, on remarquera qu'aucun support des ombres n'a été implémenté, et n'est peut-être même pas possible à implémenter, et si jamais c'était possible, le gain de performances grâce à l'utilisation des billboards deviendrait nul ou quasi-nul. On devra donc se contenter de reflets spéculaires sans gestion des ombres.
Comme vous le voyez sur cette image, le bloc ne produit aucune ombre sur le reflet qui est totalement rendu, y compris dans la surface normalement isolée de la lumière par le bloc. On notera que dans certains cas on n'aura pas besoin de gérer les ombres, et que donc cette technique a ses contextes d'utilisation. Trackmania est un bon contexte, l'absence des ombres ne se fait pas ressentir.
Second point faible, et non négligeable, la totalité de la surface réfléchissante ne peut qu'être plate. Eh oui, imaginez que la route soit ondulée, cela aurait un impact sur le reflet qu'elle renverrait, on ne pourrait donc plus se contenter d'un simple billboard sous peine d'avoir à subir une faute physique flagrante.
Troisième problème, mais cette fois-ci largement résolvable, l'orientation du billboard. Nadeo n'ont visiblement pas pensé à reprogrammer la gestion de l'orientation de leurs billboards pour les reflets spéculaires, car un reflet spéculaire ne réagit pas tout à fait de la même façon qu'un simple billboard selon la position de la caméra. En effet, le billboard prend en compte l'orientation de la caméra, alors que le reflet est indépendant de celle-ci. C'est ainsi que l'on a droit à un reflet qui bouge avec l'orientation de la caméra dans Trackmania :
Remarquez la position du reflet en fonction de la marque au sol. La position de la caméra sur ces trois images est exactement la même. Heureusement cette erreur ne se remarque pas facilement, et ce "phénomène" ne se produit quasiment pas lorsqu'on joue au jeu normalement. Aucun réel soucis de ce côté donc.
Une autre petite erreur de la part de Nadeo est d'avoir décidé de ne pas effectuer le rendu du billboard si la caméra est plus basse que la surface du bloc contenant la lumière :
Comme vous le voyez, après avoir un petit peu descendu la caméra, pouf, le reflet disparaît.
C'est en fin de compte une technique aux applications limités, mais aux avantages grands ! Pratique pour éclairer un sol ou une quelconque surface uniforme, mais à utiliser avec prudence (voir pas du tout en fait) sur les formes courbes.
Sur ce, je vous dis bonne nuit.
Reprise du développement et projet de jeu
Salut à tous,
Après une pause bac, me revoilà à la tâche avec pour objectif l'écriture d'une doc pour le moteur. En effet, c'est toujours le genre de trucs qui peuvent servir, on a même parfois tendance à oublier le code que l'on a soi-même écrit. Outre une utilité personnelle mineure, l'écriture se fait ressentir car il se trouve que j'ai réussi à convaincre certaines personnes de bien vouloir utiliser mon moteur pour la réalisation d'un petit jeu. Bien qu'à priori je serai le seul à toucher à mon moteur dans ce modeste projet, s'il est muni d'une doc cela permettra toutefois aux autres d'y toucher également (on sait jamais).
Ce projet est un jeu de space racer/shooter, comme son pseudonyme l'indique, il s'agira d'un jeu dans l'espace, donc avec des vaisseaux, des stations, tout ça quoi. On pensait également rajouter un mode sur terre (ou une planète quelconque) qui ressemblerait à une course de modules comme dans Star Wars, l'idée est encore à développer toutefois, car je ne tiens personnellement pas à faire un mode de course identique à celui de Star Wars.
Une page dédiée à spaceracer a été ajoutée dans le WikiNyug : http://wiki.nyug.org/spaceracer
Bonne journée à tous !