Bienvenue sur le site officiel du SCEngine

Le SCEngine est un moteur 3D programmé, comme son nom l'indique, en langage C. Il est libre, open-source, et distribué sous licence GNU GPL. Il utilise exclusivement l'API OpenGL pour le rendu.

OpenGL 4.0 : tadam !

Par Yno le 11/03/2010 à 22:51 – édité par Yno le 11/03/2010 à 23:00

Rigolo, c'est toujours les personnes que je soupçonnais le moins de m'en informer qui m'en informent, c'est ainsi qu'une cygale me dit tout à l'heure sur IRC « tu as vu ? OpenGL 4.0 est sorti. cui cui. ». Ben non j'avais pas vu. Heureusement, l'information est fraîche, elle date d'aujourd'hui.

En fait ils sont malins chez Khronos, parce qu'ils ont compris que changer le numéro de version ça donnait l'impression aux gens que l'API évoluait beaucoup, même si c'est super faux. Ça me fait penser à certaines personnes qui ont oublié de réfléchir avant de dire « haha mais opengl c'est dépassé, il n'est qu'en version 2 alors que directx est en version 9 ! ». Haha. De même que la réaction de beaucoup de personnes lorsque OpenGL 3.0 est sorti qui ressemblait à « ah enfin des évolutions du côté d'OpenGL ! ».

Cette nouvelle version apporte des extensions amusantes mais n'est pas un changement aussi radical que l'a été OpenGL 3.1. Et là je vais vous apprendre un truc trop dingue, je ne me suis pas encore penché sur ces extensions et les ai encore moins essayé, je vais donc en décrire quelques unes brièvement et n'importe comment.

  • Double précision des flottants dans les shaders (youpi.).
  • Possibilité de passer les paramètres first, count et autres paramètres chiants via un buffer aux commandes de dessin (extension ARB_draw_indirect, fonctions DrawArraysIndirect() et DrawElementsIndirect(), type de buffer DRAW_INDIRECT_BUFFER). L'idée est évidemment de réduire les échanges CPU/GPU, surtout que avouez, ces paramètres en général ils sont tout le temps pareil alors autant utiliser un buffer OpenGL et laisser tout ça côté GPU sans y toucher trop.
  • Nouvelle version du GLSL ! On kiffe.
  • Support de nouveaux formats de textures à trois composantes comme RGB32F, RGB32I ou RGB32UI.
  • Objets "transform feedback" qui enregistrent les options pour ce mode de rendu. En plus on peut faire de nouvelles choses avec le transform feedback, mais je vous en dirai pas plus, car je n'en sais pas plus !
  • Nouveaux types de shaders pour la tessellation.
  • Et d'autres trucs plus ou moins cool/utiles.

À noter aussi que les spécifications 3.3 sont également sorties. Me demandez pas pourquoi, j'en sais rien, peut-être par soucis de transition 3.x -> 4.x.

Je vous laisse déguster les subtilités sur le site d'OpenGL à l'adresse suivante.

http://www.opengl.org/registry/

PS: Le SCEngine n'est pas mort, et Spaceracer encore moins.

Particles engine, screenshot à l'appui !

Par Yno le 02/09/2009 à 08:14 – édité par Ban le 03/09/2009 à 02:16

Lors de ma dernière semaine passée chez Ban, du 19 au 26 août, je n'ai pas chômé : après trois jours consacrés au déboguage du moteur suite aux nouvelles fonctionnalités et aux grosses modifications majeures (geometry, vertex arrays & VAO, sphere & box, etc.) j'ai utilisé les jours qu'il me restait à concocter un petit gestionnaire de particules.

Bref maintenant que ma vie est racontée et que j'ai précisé implicitement que le développement du moteur de particules ne m'a pris que quatre jours (oups voilà qui est fait explicitement), je peux passer aux descriptions techniques.

First particles test, looks awesome!J'exploite donc le nouveau module de géométrie du moteur afin de stocker les particules d'un système. Je propose de définir une taille maximale, c-à-d un nombre limite de particules que le moteur se charge ensuite de remplir à sa guise suivant le débit choisi, etc. Il est possible de demander l'allocation d'espace supplémentaire en mémoire pour chaque particule et ainsi y stocker des données bonus. Enfin la spécification du mouvement et du comportement des particules est entièrement personnalisable par la création de "modifiers" qu'il est possible de combiner. Une fois la géométrie gérée comme bon nous semble, il suffit de créer un mesh avec cette géométrie et lui assigner des matériaux ou des textures comme bon nous semble. Un résultat basique ci-contre, avec blending additif évidemment. Le screenshot a été pris sur mon misérable ordinateur portable, donc je ne peux rien dire à propos des performances ; il faut dire qu'un Poulsbo sous Linux n'est absolument pas représentatif des performances pouvant être atteintes (ou pas) par un rendu 3D. Il faudra demander à Ban de faire des petits tests, ou même à vous si vous êtes intéressés, rien ne vous empêche de me contacter.

En note de fin, je souhaiterais souligner que je me suis beaucoup inspiré de SPARK pour l'architecture du gestionnaire de particules, si vous ne connaissez pas encore ce projet je vous suggère de le découvrir !

À la prochaine !

P.S. Votre serviteur étant encore en vie, il vous propose plus de médias en rapport avec les particules et vous les laisse découvrir.

Catalyst 9.8 : enfin des geometry shaders !

Par Yno le 17/08/2009 à 10:15

Comme espéré dans la dernière news, l'ajout des geometry shaders aux dernières spécifications d'OpenGL inciterait sûrement ATI à les implémenter dans leurs drivers, et c'est chose faite !

Les Catalyst 9.8 ajoutent également le support des uniform buffers et de quelques autres extensions.

Malheureusement, toujours aucun support des noyaux Linux 2.6.29+ ne semble présent. Je me demande s'ils ont un « mail des réclamations ».

Dernière version

La version 0.0.9a est disponible !

Développement

20/02/2008 à 20h33

Modification complète du module de gestion des caméras : il implémente à présent la gestion d'une simple structure contenant deux matrices (projection et visualisation). La gestion des mouvements de la caméra se fera via des modules tiers (un module pour chaque type de gestion).

20/02/2008 à 20h30

Ajout d'une fonction de calcul de l'inverse d'une matrice (c'est pas trop tôt).

16/02/2008 à 19h18

Déplacement de la fonction de chargement d'un mesh du gestionnaire de modèles au gestionnaire de meshs, amélioration de cette dernière.

13/02/2008 à 14h33

Ajout de la fonction SCE_Resource_Add(), qui permet d'ajouter manuellement une nouvelle ressource.

07/02/2008 à 23h25

Implémentation des bibliothèques libwar et lib4fm que j'ai récemment développée afin de permettre le chargement de fichiers .obj et .4fm, respectivement (ce dernier est un format maison).
Correction d'un bug dans SCE_Mem_ConvertDup() qui empêchait la copie d'un lot de donnée vers un type identique.

13/01/2008 à 23h50

Petite mise à jour du gestionnaire de matériaux : adaptation aux nouvelles fonctionnalités des textures et épuration du module ; système plus robuste et plus simple basé sur les listes chaînées.

12/01/2008 à 01h14

Correction de nombreux bugs, un bug dans SCEString, un autre dans SCEMesh et un dernier dans SCEShaders.
Petit test utilisant deux textures, un mesh et un shader effectué avec succès. Aucune mémoire non libérée en fin de programme.

11/01/2008 à 23h00

Résolution des dernières fuites mémoire : j'en ai profité pour constater et corriger quelques erreurs dans mon gestionnaire de textures côté cœur.

11/01/2008 à 21h49

Correction du bug d'affichage des textures (module non initialisé :-°) et diminution du nombre d'allocations mémoire non-libérées en fin de programme.

10/01/2008 à 21h50

Correction de fuites mémoire grâce à l'ajout d'une simple et petite fonction au sein du gestionnaire de mémoire, qui permet de connaître le fichier, la ligne et la taille de toutes les allocations effectuées encore non-libérées

10/01/2008 à 00h31

Passage aux listes effectué avec succès dans le gestionnaire de ressources.
Petit problème rencontré avec les listes, une mauvaise récursion conduit à une utilisation simultanée d'une même liste, ce qui conduit à un comportement indéterminé.
Un indice sur le bogue de Ban : il semblerait que cela provienne de l'option -fPIC qui est mal supportée par le ou les modules SCECamera et SCEInert.

09/01/2008 à 19h38

Gestionnaire de nœuds mis à jour et testé. il reste deux/trois trucs à régler, mais globalement il fonctionne. Je suis actuellement entrain de réviser la plupart des modules afin de commencer (sereinement) un gestionnaire de scènes.

07/01/2008 à 21h25

Ban subit quelques problèmes d'affichage aléatoires ; sur l'application de test (rendu d'un simple mesh), l'affichage a lieu une fois sur trois environ.

07/01/2008 à 21h24

Mise à jour du module de nœuds : utilisation des listes plutôt que des tableaux pour stocker les fils d'un nœud. Ce module est actuellement en test...

07/01/2008 à 21h23

Bug d'affichage enfin résolu ; c'était une simple erreur d'utilisation d'une fonction. Toutefois ce petit remue ménage m'a permis de cerner de nombreux bugs au sein de SCEMesh.c, et c'est tant mieux.

02/01/2008 à 21h43

Correction de quelques erreurs dans SCEMesh.c, j'ai repéré des incohérences dans l'utilisation de mes propres fonctions. Cela ne règle pas le principal problème (rien ne s'affiche), mais il semble que le filon d'erreurs se poursuive, to be continued...