Format de fichier: sauvegarde des systèmes de particules

Pour l'éditeur j'ai crée un format de fichier utilisant le XML, mais ce format est impropre au chargement direct de systèmes de particules par SPARK (déjà c'est un format texte, et ensuite il est très lié à la structure de l'éditeur). Du coup je me suis dit que qu'il fallait un format que SPARK puisse charger sans dépendances. Le mieux est à mon avis un format binaire, pour les perfs.

Le principe serait d'avoir un loader dans lequel on 'enregistre' des modules: un module est une classe (existant que pour ce type de loader) créant un élément SPARK à partir de proprietés; chaque module à son nom propre. Ca permettrait d'étendre facilement les capacités du format, et d'étendre SPARK sans devoir recréer tout le format. Je pense par exemple à un truc du genre

Code:: loader->registerModule("spk::sphere",sphereModule);

Comme extension, c'est tout trouvé: ".spk" ^^

J'ai rédigé des specs, dites m'en ce que vous en pensez:

Code:: ------------------------
SPARK Effect File Format
------------------------

1. Characteristics
------------------

Extension: .spk
File type: binary

This file format aims to provide an extensible, fast and lightweight
way to save and load SPARK particle systems. It supports up to 8 options.
Data is separated according to their role: rendering/simulation. All
elements depending only on SPARK must be stored in the simulation part,
other elements (which relies on both SPARK and a rendering engine) must
be stored in the second part (rendering). For example, SPK::System ->
first part, SPK::IRR::IRRSystem -> second part.

A .spk file can be loaded and used with several engines: the simulation
part is always loaded, but only the rendering part corresponding to the
used engine is loaded: for example, a .spk can contain elements for
Irrlicht, and other for SFML, and can be used with both engines without
having to set up a file for Irrlicht and another one for SFML. It can be
really useful to have a file containing elements for OpenGL and for DirectX.

2. Format specification
-----------------------

2.1 File organization
---------------------

[Header]
[First part of contents]
[Second part of contents]

2.2 Header
----------

| File tag: "SPARKEFFECT", 11 characters [11 bytes]
| File format version [1 byte, unsigned]
| SPARK major version [1 byte, unsigned]
| SPARK medium version [1 byte, unsigned]
| SPARK minor version [1 byte, unsigned]
| Options [1 byte, unsigned]

Total: 16 bytes

2.3 First part of contents, non-rendering-related elements
----------------------------------------------------------

2.3.1 Module list
-----------------

| Number of used modules [2 bytes, unsigned]
| For each module:
|| Module internal id [2 bytes, unsigned]
|| Module identification name [30 bytes]

The module internal id is a number used in the file to store
module type. It is used only in the file ("indexed modules").
The module identification name is used to retrieve the module
at loading: the Sphere SPK::Zone could have for identification
name "SPK::Sphere" for example.
Note these module ids are only valid in the first part of contents.

2.3.2 Element list
------------------

| Number of elements [4 bytes, unsigned]
| For each element:
|| Module id [2 bytes, unsigned]
|| Optional name (see Options) [? bytes, '0'-terminated string, case insensitive]
|| Size of properties area in bytes [2 bytes, unsigned]
|| Properties [? bytes]

2.4 Second part of contents, rendering-related elements
-------------------------------------------------------

2.4.1 Rendering engine list
---------------------------

| Number of rendering engines [1 byte, unsigned]
| For each engine:
|| Engine identification name [? bytes, '0'-terminated string, case insensitive]

2.4.2 Per engine module list
----------------------------

|| Number of used modules [2 bytes, unsigned]
|| For each module:
||| Module internal id [2 bytes, unsigned]
||| Module identification name [30 bytes]

Note these module ids are only valid in the second part of contents.

2.4.3 Per engine element list
-----------------------------

|| Number of elements [4 bytes, unsigned]
|| For each element:
||| Module id [2 bytes, unsigned]
||| Optionnal name (see Options) [? bytes, '0'-terminated string, case insensitive]
||| Size of properties area in bytes [2 bytes, unsigned]
||| Properties [? bytes]

2.5 Whole specification
-----------------------

| File tag: "SPARKEFFECT", 11 characters [11 bytes]
| File format version [1 byte, unsigned]
| SPARK major version [1 byte, unsigned]
| SPARK medium version [1 byte, unsigned]
| SPARK minor version [1 byte, unsigned]
| Options [1 byte, unsigned]
| Number of used modules [2 bytes, unsigned]
| For each module:
|| Module internal id [2 bytes, unsigned]
|| Module identification name [30 bytes]
| Number of elements [4 bytes, unsigned]
| For each element:
|| Module id [2 bytes, unsigned]
|| Optional name (see Options) [? bytes, '0'-terminated string, case insensitive]
|| Size of properties area in bytes [2 bytes, unsigned]
|| Properties [? bytes]
| Number of rendering engines [1 byte, unsigned]
| For each engine:
|| Engine identification name [? bytes, '0'-terminated string, case insensitive]
|| Number of used modules [2 bytes, unsigned]
|| For each module:
||| Module internal id [2 bytes, unsigned]
||| Module identification name [30 bytes]
|| Number of elements [4 bytes, unsigned]
|| For each element:
||| Module id [2 bytes, unsigned]
||| Optionnal name (see Options) [? bytes, '0'-terminated string, case insensitive]
||| Size of properties area in bytes [2 bytes, unsigned]
||| Properties [? bytes]

3. Options
----------

3.1 Optional name
-----------------

Flag: 1 << 0
Description: If set, the name of all elements will be saved, else only the name of
SPK::System elements will be saved. Can be useful to easily identify elements,
but increase the file size.

Developer Messages : 539 Date d'inscription : 2009-07-14 Age : 41

Salut, j'étais également en train de réfléchir au processu de sérialization des objets de spark. En fait comme j'en avais déjà parlé dans un autre post, je pense inclure 2 formats à terme : un binaire et un xml, parceque les 2 sont complémentaires. Chaque fichier contiendra un et un seul system. Il y aura des fonctions de serialisation et de désérialisation dans SPARK qui permettront d'exporter/importer des systèmes.

Maintenant la difficulté est plutôt le design du truc et comment intégrer tout çà avec l'existant, les spécifications ca va pas mal en découler. Mais en gros ca ressemblera sans doute pas mal à ce que tu proposes. Mis a part le coté multi module. J'ai pas concu SPARK pour être un moteur de particule cross rendering engine mais plutôt comme un moteur de particule pouvant s'interfacer avec plusieurs moteurs graphiques mais de facon independante. Si quelqu un veut interfacer SPARK avec son moteur graphique qui gère et OpenGL et DirectX, soit il fait un bridge, soit il recode des renderers qui utilise directement son moteur.

Après c'est vrai qu'avec cette philosophie on a théoriquement des fichiers qui vont être compatible uniquement si utilisés avec le bon module de rendu. Mais c'est outrepassable si on peut dériver des propriétés communes. Par exemple mettons qu'on peut loader unformat d'objet qui aura comme ID "QuadRenderer" et bah en fonction du module de rendu chargé, on sera capable de loader soit un GLQuadRenderer, soit un IRRQuadRenderer... Après rien n'empêche de faire un format "IRRQuadRenderer" qui sera plus spécifique et donc plus modulable mais rendra le fichier incompatible avec tout autre module de rendu qu'Irrlicht.

Enfin tout ca ne sera inclus que dans la version 2 de SPARK, il n'y aura aucun format officiel pour la version 1 puisque je ne fais plus que de la maintenance. Je préfère consacré le peu de temps que j'ai pour ce projet à la version 2 qui sera beaucoup plus aboutie et mieux designé. D'ailleurs la sérialization est le dernier gros truc qui me reste à faire (Peut être que ce ne sera que dans la 2.1 je ne sais pas encore).

Sinon est ce que tu comptes passer l'éditeur à la version 2 ? Je pense que ce serait bien. Ca manque encore un peu de doc mais je peux répondre à tes questions si t'en as. Dans ce cas je fais passer tout ce qui est sérialisation en priorité. Pour la version 1 il y a déjà l'éditeur de kvakvs qui est fonctionnel.

Merci du com'.

Pour ce qui est des modules, on peut ranger les proprietés par classe, genre toutes les proprietés de la class 'zone', puis suivent celles de la class 'sphere' par exemple, idem avec le reste, ca permettra d'utiliser des proprietés communes, mais certaines proprietés sont spécifiques aux moteurs - genre le zfactor avec la SFML.

Pour l'éditeur, il ne reste qu'a faire les plugins pour les groupes et les systèmes et je passe à la version 2 - histoire que ca soie quand même un peu utilisable avec SPARK 1^^ Par contre comme je suis en prépa ca risque de pas avancer très vite...

» Démo collision particules vs particules