[SPARK 2] Journal de dev

Un petit post pour vous tenir informer des dernières updates de SPARK 2.
L'API est encore en developpement mais la version est cependant relativement stable et peux dès maintenant être utilisée.
Elle peut être trouvée sur le SVN à cette adresse : https://sparkengine.svn.sourceforge.net/svnroot/sparkengine/spark2/

La principale fonctionalité manquante pour l'instant et bloquant la release est la sérialisation des renderers. Un refactor des renderer est prévue permettant de factoriser le code des type de renderer pour éviter d'avoir à le reimplémenter par module de rendu. Le developpement de renderer spécifique au module de rendu sera neanmoins toujours possible.

PS : n'hésitez pas à poser vos questions ou à partager votre point de vue à la suite de ce post.

Le dernier developpement est quelque chose que je voulais implémenter depuis longtemps, il s'agit de la gestion du partitionnement de l'espace.
L'espace peut maintenant être partionné par groupe à l'aide d'un octree.

Cela va permettre d'optimiser considérablement les algorithmes en O(n²) en améliorant leur mise à l'échelle : La complexité des algos passant à O(nlog(n)) avec un octree.

Les algos de complexité quadratique vont être tous les algos ou chaque particule est influencée par toutes les autres (simulation N-body). Par exemple :

• La collision particule contre particule
  
• le flocking (les particules tentant d'uniformiser leur vitesse et position)
  
• simulation de forces gravitationnelles (univers, galaxie...)
  
• ...
  

La gestion de l'octree est totalement transparente pour l'utilisateur : Les modifiers souhaitant utiliser un octree vont setter une constante à true. De cette manière le groupe contenant au moins un modifier demandant un octree, va pourvoir le créer et le maintenir à chaque update. Les particules voisines et les noeuds de l'octree peuvent ensuite être récupérer facilement par le modifier.

J'ai porté le modifier collider (collision particule contre particule) pour utiliser le partitionnement de l'espace et le gain en perf est assez conséquent. Avec la démo collision je peux faire tourner environ 15000 particules (avec collision) à 60 fps. La time step doit cependant être ralentie pour que la simulation reste réaliste.

J'ai modifié la démo collision en mettant plus de particules et en permettant d'afficher l'état de l'octree (appuie sur F2) :



Il reste à modifier un peu l'interface et éventuellement à permettre de tweaker les paramètres de l'octree pour faire du "fine tuning". Quelques optimisations supplémentaires doivent également être possibles.

Très bonne fonctionnalité, au niveau perf ça sera très pratique!

Au niveau des renderers, as-tu une idée de l'architecture que tu vas mettre en place ?

C'est excellent, grand bravo et big thanks pour toutes ces merveilles

Je viens de terminer les spécifications du format binaire SPK (version 0) ainsi que le loader et le saver correspondant.

L'intégrité des données de chaque type d'objet dépend de la signature de son Descriptor (un hash calculé à partir du nom et du type de chacun de ses attributs)

Voilà les specs :

Code:

Note : The data are inserted in little endians

--- Header ---
"SPK" - Magic number - 3 bytes
version of the format (0) - 1 byte
size of the data part in bytes - 4 bytes
number of objects n - 4 bytes

--- Data ---
n Object Data

--- Object Data ---
object type - string nbChar bytes + 1 ('\0' char)
size of object data (not including object type) - 4 bytes
object descriptor signature - 4 bytes
n Attribute data

--- Attribute Data ---
attribute present (false : 0x00 or true : 0x01) - 1 byte
// if attribute present
attribute serialized - size depends on type of attributes (for array 4 bytes of length + data written sequentially)

Ca m'a l'air sympathique!
Par contre, est-ce que la taille des données comprend le nombre d'objets ? Pareil pour la taille des données des objets.

Pour la taille des data dans le header, c'est la taille total des data du fichier. Donc la taille du fichier moins la taille du header (qui contient le nombre d'objets)

Pour la taille des data des objets, c'est la taille de la signature + la taille des data d'attributs (donc sans la string de type d'objet et les 4 octets de la taille). Le nombre d'attributs n'est pas encodé dans le format mais est connu par le moteur directement dans le descriptor du type. On sait que le descriptor qui a servi a encodé est consistant avec celui qui a servi a décodé avec un test d'égalité sur la signature.

Juste une petite idée qui pourra se révéler très pratique: maintenant que VC2010 est bien utilisé, c'est assez casse-pied de devoir recréer à chaque fois les fichiers projets et les mettre à jour manuellement lors d'un changement de version... Et maintenir un nouveau type d'IDE prend pas mal de temps.

Du coup, je pense que le mieux est de passer à CMake et de virer les fichiers projets actuels. A cela s'ajoutera une petite modif au niveau des dépendances externes : il faudra inclure l'ensemble des fichiers sources des dépendances, histoire de pouvoir les recompiler sans devoir les chercher manuellement sur Internet (parce que mine de rien, TinyXML compilé avec VC2008 n'est pas compatible avec VC2010).

Qu'en penses-tu ?

Ouais c'est une bonne idée. Si tu es chaud pour le faire, vas y.
Par contre au niveau de l'inclusion des sources dans le projet, c'est un peu problématique. Parceque tinyXML c'est une chose mais Irrlicht par exemple c'est quand même beaucoup plus lourd...

Je pensais juste à Glew et TinyXML. Pour Irrlicht, comme tu l'as dis, c'est trop gros, donc l'utilisateur devra rentrer l'emplacement de la lib qu'il aura compilé par ses propres soins

Pour l'instant, je met tout dans un dossier CMake, histoire de tester sans toucher au reste. Une fois que cela sera fonctionnel, on pourra supprimer les actuels fichiers de solution.

Edit: en passant, peut être que je pourrais changer de TinyXML à PugiXML, si je ne me trompe pas, seuls SPK_IO_XMLLoader.cpp et SPK_IO_XMLLoader.cpp sont concernés par ce changement.

Ok ca marche comme çà,

En passant, le code de SPARK 2 ne doit pas compiler pour le moment qu'avec visual, j'ai pas essayé avec GCC encore.

Pour changer de lib XML, si tu veux. Pour l'instant TinyXML me pose pas trop de problème même en terme de perf mais bon si pugy est mieux et pas plus lourd, c'est mieux. Il faut juste faire gaffe a rien péter lors de la conversion. L'idéal serait d'avoir un set de fichier xml de tests (valides et invalides) pour tester la non régression et bencher.

Pas de problème, je mettrai ça sur le SVN qu'après avoir fait un certain nombre de tests. Par contre, ça me demandera un petit bout de temps.

J'ai pas mal avancé, il ne me reste plus que 6 projets à ajouter au niveau de CMake, et j'ai passé SPARK de TinyXML à PugiXML. Les tests seront effectués bientot. Par contre, en compilant la démo Irrlicht, j'ai trouvé un gros bug: avec DirectX, le renderer ne prend pas en compte le fait qu'il est dans depth write et en mode add. Je suis en train de rechercher plus en profondeur (d'autant plus qu'il n'y a aucun bug avec OpenGL)

en même temps, les renderers dx9 n'ont jamais été testés sérieusement, une erreur de ma part est hautement probable.

Le truc, c'est que ce bug ne viens pas de toi mais d'Irrlicht, je pense, vu que c'est la démo avec Irrlicht (même si ça me parait très bizarre). Pour éliminer d'éventuelles incompatibilités binaires, j'ai tout recompilé (Irrlicht + SPARK + SPARK_IRR + pugixml + Test_Irrlicht), sans succès...

J'ai essayé Parallel NSight, avant de me rendre compte que c'est DX10/11 uniquement...
Je laisse ça comme ça pour l'instant, et je finalise le reste. Peut être que je testerais sur un autre ordinateur.

Désolé pour le double post...

Aucun problème niveau XML, outils de diff à l'appui (sur ce que SPARKTest génère).
Au niveau des perfs:

Code:

RELEASE - TinyXML
-----------------
SAVING SPK BENCH : 532ms
SAVING XML BENCH : 1405ms
LOADING SPK BENCH : 244ms
LOADING XML BENCH : 839ms

RELEASE - PugiXML
-----------------
SAVING SPK BENCH : 415ms for 1000 operations
SAVING XML BENCH : 493ms for 1000 operations
LOADING SPK BENCH : 147ms for 1000 operations
LOADING XML BENCH : 269ms for 1000 operations

En passant, j'ai fait quelques modifications à ce test:
- le test d'intégrité pour le format SPK n'était pas fonctionnel (il utilisait le résultat du chargement de 'test.XML' ...)
- il n'était pas précisé que les temps mesurés étaient pour 1000 chargements/enregistrements... Pour quelqu'un ne connaissant pas SPARK, ou ne faisant pas attention (comme moi;) ), ça donne l'impression qu'il faut 269 ms pour charger un système peu compliqué : c'est pas vendeur . Peut être qu'on pourrait aussi mettre le temps d'une opération (1 chargement ou 1 sauvegarde)...

Pour le reste, il me reste les démos DX et SPARK_DX à porter à CMake, mais ça ne devrait pas poser de problèmes.

Au niveau du build, le chemin final n'est plus un truc façon '...\SPARK2\lib\vc2010\dynamic' mais: '...\SPARK2\lib\(Windows@Visual Studio 10)\dynamic'
L'avantage de l'identifiant 'Windows@Visual Studio 10' est que CMake peut facilement le créer, donc ça permet une bonne intégration avec d'autres projets utilisant CMake.

Edit: c'est sur le SVN. J'ai laissé les projets VC2008 et Code::Blocks en cas de problème (ce qui m'étonnerais), j'ai aussi laissé glew1.5.8 pour ces 2 projets. Comme je n'ai pas vc2008 sur l'ordi qui a fait les changements, faudra changer manuellement les dépendances externes.
Dites-moi ce que ça donne!

Bonjour tout le monde,

Merci pour l'ajout de cmake au dépôt, j'ai d'ailleurs une question concernant sa mise en oeuvre.

Je souhaite utiliser Spark2 dans un contexte OpenGL pour une exploitation dans SFML2.

En ce sens, Irrlicht semble détaché de mes besoins (je pense..), aussi, je me demandais si le module CMake ne pouvait pas comprendre un paramètre nous donnant la main sur l'installation de spark que l'on souhaite obtenir, je vois différentes sorties possibles :

- un Spark2 Noyau
- un Spark2 OpenGL (paramètre cmake imaginé : -DSPARK2_OPENGL:BOOL=TRUE)
- un Spark2 DirectX
- un Spark2 Irrlicht

C'est juste une observation de passage, j'espère qu'elle aidera à faire avancer la discussion..

A bientôt.

Hello et bienvenue,
Je n'ai pas tout compris... Actuellement, avec CMake, tous les projets sont crées, mais tu est toujours libre de compiler ceux que tu veux (et si seul le noyau t’intéresse, tu n'as qu'a compiler uniquement SPARK_Core ainsi que les renderers pour la SFML (à ce propos, ceux pour la SFML 2 n'existe pas encore il me semble). Et alors, tu n'auras pas Irrlicht.
Pour ce qui est des warnings lors de la configuration du projet, c'est parce que les champs concernant les noms de la lib Irrlicht en débug et en release sont vides au départ. Si tu ne veux pas Irrlicht, tu peux toujours rentrer des noms fictifs (genre "a"), comme ça plus de warnings (mais par d'Irrlicht non plus).

Merci pour ces renseignements. Je vais utiliser SPARK dans un contexte Opengl que je couplerai moi-même à SFML.

Je vais essayer une approche de compilation CMake au cas par cas comme tu le suggères car à l'origine je compilais via le CMakeLists.txt générique fourni depuis spark2/projects/engine (qui n'offre pour le moment pas de possibilité de personnalisation).

A bientot,
Joffrey

En gros, tu voudrais un fichier CMakeList qui compile directement ce qu'il faut ? genre, compile directement le module OpenGL et rien d'autre ?

C'est vrai que j'ai écrit les fichiers CMake avec des IDE en tête, pour un makefile ça doit pas être évident. Mais tu peux toujours utiliser directement les CMakeLists présents dans spark2/projects/engine/core, spark2/projects/engine/ogl, etc..., qui permettent de compiler directement un projet, sans passer par un IDE. Par contre, les dépendances seront à gérer manuellement.

a) Exactement un simple module OpenGL greffé au core, et voilà. Je travaille en 2D et couple mon petit jeu à des particules.

b) Sinon, je peux aussi vous aider à remanier un peu le Cmake moi qui suis un sincère appréciateur de cet outil. Si ca vous intéresse je peux vous livrer les fichiers que j'imagine ici, avec gestion des dépendances.

Joffrey

Si tu veux, tu peux me passer des fichiers CMake, comme ca je pourrais voir les modifications éventuelles qui pourront être apportées au SVN.

Juste une question : avec quoi travailles-tu ? makefile directement ? Code::Blocks ? Visual Studio ?

Merci pour cette nouvelle réponse.

Je travaille avec Microsoft Visual c++ 2010 Express, en exploitant, via CMake, la technologie NMake (lignes de commandes). J'évite la surcharge de l'IDE étant donné mon penchant pour un vim seul.

Par ailleurs, je recontre un bug avec CMake, les librairies externals sont, après compilation, installées dans un chemin un peu curieux... Je vais prendre un peu de temps pour remanier l'ensemble, j'installerai irrlicht pour faire des essais complets.

A mon avis, ce qui manque:

1) Un emplacement de destination pour les éléments compilés pris en charge par CMake. (on définit le prefix_path dans la commande CMake).

2) Une capacité à définir un Spark2 personnalisé (avec ou sans irrlicht), incluant un mécanisme d'auto-génération de la doc.

Je m'en occupe sous 48Heures.

Joffrey

Ok merci.

Pour les externals: le chemin 'un peu curieux' (si c'est bien "external/<libname>/bin"), c'est pour bien les séparer des binaires SPARK. Je crains que cela ne puisse pas changer. Par contre, l'ajout de libs externes se fait une fois tous les 36 du mois, donc il est possible d'hardcoder le chemin.

Pour la doc: doc/makeDoc.bat . Il est possible d'ajouter une commande dans le projet CMake, du style "cmd.exe ...makeDoc.bat". Pour Doxygen ailleurs que sous Windows, faudra des binaires Linux/Mac/autre.

Oui j'avais bien compris l'état d'esprit, je fais une proposition et on verra si c'est retenu j'ai encore un peu de boulot jusque là cependant.

[EDIT] Par contre je pense à un truc, le chemin un peu curieux dont je parlais ce n'est pas la particularité que tu évoques que je considérais comme logique ..

Mais la sortie des externals s'est effectuée sur la base de du dossier de travail où mon fichier NMake s'est installé.

Je crée un dossier détaché du dépôt svn qui constitue le point de travail de la compilation où les Makefiles vont être générés.. et là, c'est à partir de ce dossier que les externals sont élaborés, étrange sur un relative path indiquant : ../../externals/libs

A plus tard.