Interface des renderer

Il s'agit d'une question d'interface pure:

La fonction render() est mise const, or il se peut qu'elle doit modifier des ressources, ce qui est impossible si elle est const. Par conséquent, ca peut bloquer lors de la création de nouveax renderers. Je pense qu'il faudrais rendre cette fonction non const (d'autant plus que le const ici n'apporte pas grand chose). Ca permettrait par exemple d'éviter de tout devoir réenvoyer à la mémoire graphique...

PS: Une autre question, mais je vais pas ouvrir un post pour ca: les coordonnées couleur dans SPARK sont toujours entre 0.0 et 1.0 ?

Salut,

tu parles de quel render() ? celui de System ou celui de Renderer ?
Vu le titre du message, j'imagine que c'est celui de Renderer.

Du coup c'est render(Group&) const. C'est constant parcequ'un renderer n'est pas sensé modifier quoique ce soit chez lui mais uniquement les buffers du Group qui l'interesse (qui du coup n'est pas constant). Un renderer n'est pas lié a un groupe en particulier, il sert juste a traiter les données d'un groupe d'une certaine facon, eventuellement a les organiser avant de les dessiner.

Pour faire ca, il peut avoir besoin de buffers qui sont stocké dans le groupe qu'il doit rendre. Il va d abord aller checker si les buffers dont il a besoin existe dans le groupe. Si non soit il les créés, soit il ne fait rien (ca dépend d'un parametre a setter). Si les buffers existent, il les récupère et fait son traitement en ecrivant ce qu'il veut dans les buffers avant de les envoyer au GPU. En gros c'est comme ca que ca marche.

Maintenant dans la version actuelle les buffers qu on peut attacher aux groupes sont seulement des tableaux de float (suffisant pour openGL et SFML). Le problème c'est que ce n'est pas assez générique (par exemple dans Irrlicht il va falloir attacher le meshbuffer d'irrlicht par exemple). La je suis en train de refaire une version qui permettra d'attacher des buffers custom. Pour Irrlicht il va sans doute falloir créer un IrrBuffer qui va contenir un irr::MeshBuffer plus tout le state dont tu as besoin. Les renderers irrlicht créeront et ecrirons dans ce type de buffer.

Pour les couleurs dans SPARK, chaque composante est en effet un float. Maintenant il n'y a pas de clamp, l'utilisateur met ce qu'il veut dedans, donc ca peut tres bien être au dela de [0.0f,1.0f]. Apres il me semble que openGL fait le clamp lui meme en interne donc si ton R vaut 7.4 ce sera comme s il valait 1.0. Après la facon dont sont interprété les données dependent uniquement du renderer. Par exemple ca pourrait etre entre 0 et 255. Après ca chaque composante reste un float pour permettre une interpolation précise et que tout les paramètre soit uniformisé (car le stockage est réalisé dans un tableau de float optimisé).

Personellement je pense que cette méthode devrait etre non const. Tout d'abord, il facilement possible de faire sauter le const. Ensuite, d'un point de vue de logique, un renderer peut modifier certaines choses, en calculer d'autre et les stocker 'chez lui' pour de meilleures perfs, enfin quasiment toutes les librairies n'utilisent pas de méthodes const pour tout ce qui effectue un rendu...

Sinon pour l'histoire des buffers, le mieux serait un void*, ca permettra une bonne évolutivité, et du coup l'interface des Group au niveau des buffers sera plus light. Par exemple, Irrlicht utilise des floats et des unsigned int, mais CrystalSpace ou Ogre3D ou autre utilisent encore autre chose...

En fait, il faut bien se dire qu'un renderer n'est pas sensé stocké des trucs lié a un groupe. On doit pouvoir utiliser un renderer pour rendre plusieurs groupes différents par frame. La tout de suite, je vois toujours pas trop pourquoi rendre un groupe avec un renderer devrait pouvoir modifier des trucs dans le renderer qui n'ont rien a voir avec le groupe mais retirer le const n'est pas forcément une mauvaise idée et ca peut sans doute avoir du sens dans certain cas. En attendant tu peux stocker tes trucs en mutable dans le renderer comme ca meme une methode const pourra y toucher. En fait je crois aussi que je vais passer le group en const dans la methode render et les buffers du groupe en mutable car un renderer peut toucher tant qu'il veut aux buffers mais pas au groupe en lui meme.

Sinon concernant les buffers, j'ai pensé au void aussi mais en fait j'ai besoin d'avoir certaine opération sur les buffers :

• seul le groupe doit pouvoir les créer/détruire
  
• le groupe doit être capable de swapper les infos relatives a 2 particules dans le buffer (pour garder le buffer bien ordonné lors du swap de particule au sein du groupe)
  
• Un buffer doit pouvoir se cloner
  

Du coup ca oblige a avoir une interface abstraite pour pouvoir faire tout ca. C,est en effet un peu lourd a implémenter mais faut se dire aussi que c'est du bas niveau et que l'utilisateur n'aura jamais a en faire, ni meme a y toucher.

Le mieux, c'est sans doute ce que tu as dit, une interface abstraite, et c'est au renderer de créer le buffer cette fois ci. Pour swapper une particule, je pense qu'un callback auquel on passe les indices des particules à swapper pourra faire l'affaire.

Pour faire sauter le const sinon il suffit de faire un const_cast sur le this.

L'architecture pour les buffers générique a été faite dans la derniere version (1.03.02).

Les renderers sont responsable de la creation/destruction des buffers dont ils ont besoin au sein du groupe qu'il sont en train de rendre. une methode prepareBuffer dans le renderer de base effectue ce qu'il faut. Apres il faut surcharger au besoin checkBuffer, createBuffer et destrouBuffer dans le renderer. Regarde les codes des renderer déja implémentés pour voir comment c'est fait.

Après quasiment tous les renderers implémentés pour l'instant utilise des FloatBuffer (certains n'ont pas besoin de buffers ), pour irrlicht il faudra surement implémenter un buffer spécifique (IrrBuffer), la il faut aller voir du coté de Buffer et BufferCreator (voir les ArrayBuffer aussi) pour voir comment ca se passe. le swap se définit ici (meme si pour le renderer il n'est souvent pas utilisé etant donné qu'on ecrase en général les données de la frame précédente).

Sinon, je vais devoir refaire une nouvelle version tout a l'heure parceque j'ai introduit d eventuelle sources de bugs avec la dernière (des membres non initialisés), j'en profiterai pour rendre le render non constant.

OK, j'attend donc la 1.03.03

Au passage, si tu pouvais ajouter quelques lignes vides à la fin de chaque header du dossier include, histoire d'aviter les avertissements compilo de gcc^^