editeur de système de particule de SPARK (topic de dev)

J'ouvre ce post car j'ai commencé un editeur de système de particules pour SPARK.

Comme Darktib en a commencé un aussi, ca permettra de mieux en parler.

c dommage de developper 2 editeurs en parallèle, autant combiner nos efforts. J'étais parti sur Qt aussi a la base mais apparemment l'integration sous visual studio express était pas evidente alors je me suis rabatu sur wxWidgets que j'ai intégré sans problème. Moi je suis parti sur un rendu avec OpenGL dans l'éditeur mais l'export pourra se faire pour n'importe quel module de rendu.

Pour l'instant je n'ai fait que la parti rendu du système avec gestion de la caméra :
ctrl + souris permet de translater la caméra sur le plan (x,z)
alt + souris de faire des rotations
molette pour déplacer la caméra en y

Je comptais utiliser ce système de déplacement également pour les objet directement dans la zone de rendu.

J'ai intégré le système de la démo basic juste pour tester la caméra, le système n'est pas éditable. J'ai rajouté un début de GUI aussi a gauche mais pour l'instant ca sert a rien. En fait je voulais attendre que ce soit plus avancé pour en parler mais comme tu as commencé de ton coté autant en parler tout de suite.

Comment vois tu ton éditeur toi ? Est ce que tu comptes le réaliser spécifique Irrlicht ? Et comment vois tu l'import/export des fichiers ? xml ? format dédié ? A la base moi j'avais pensé partir sur du xml mais en fait un format dédié me parait mieux car il n'y a pas de dépendance supplémentaire a avoir et surtout le loading sera beaucoup plus rapide. Après l'idéal serait d'avoir les 2.

Voila ce que j'ai fait pour l'instant

Je t'avoue que le developpement de tools n'est pas la partie que je préfère dans le dev logiciel mais bon c'est vrai qu'un éditeur est un peu indispensable pour un moteur de particule.

en fait, j'ai jamais compris à quoi servait un éditeur pour ça, quelqu'un pourrait m'expliquer, j'en ai téléchargé quelques uns mais je les ai trouvé juste tous plus inutiles les uns que les autres.

Bah ca sert a plein de chose :

• Comme un système de particules n'est au final qu'une somme de petites entités soumis a une sommes de petits comportements, c'est pas évident de visualiser le comportement global du système. Un éditeur va te permettre de visualiser en temps réel comment un changement dans un des comportement va influer sur l'aspect général du système.
  
• En plus ca t'évite d'avoir à recompiler a chaque fois que tu veux modifier ton système (quand tu le met en place notamment). Tu as juste a modifier la ressource et non l'exe. Après ca ca peut être fait a partir d'un fichier editable également (du style xml).
  
• Ca permet aussi de mettre en place un format non textuel pour optimiser le chargement (plutot que d'avoir a parser un xml, un fichier binaire va être loadé bcp plus rapidement).
  
• Ca va également permettre de proposer du contenu pré fait, des système a utiliser tel quel, que l'utilisateur peut visualiser dans l'éditeur et choisir d'utiliser dans ses applis.
  
• Dans une chaine de production, ce sont les graphistes qui mettent en place les systèmes de particules et non les programmeurs. Les graphistes ont besoin d'un outil WYSIWYG pour mettre en place leurs assets (car ils ne savent par définition par programmer)
  
• Coté developpement de la lib, ca permet de tester les système et les nouvelles features très rapidement et permet donc de debugguer la lib et la rendre plus robuste.
  

Le truc c'est d'arriver à faire un éditeur qui soit a la fois intuitif et puissant. S'il n'est soit pas assez intuitif soit pas assez puissant, il ne sert a rien.

Donc moi je pense que ca a un réel interet si c'est bien réalisé, le truc c'est que c'est long a developper pour arriver à un truc efficace.

ok, merci pour ces précisions, j'ai toujours tout fait à la main, j'avais jamais pensé aux considérations utilisateurs ^^

Perso je le développe avec Qt, et QtCreator, ca permet de faire la GUI très vite. Le fonctionnement prévu:

La première partie est la partie GUI. C'est à dire, le controleur de tous les widgets, etc... avec bonne liaison des signaux et des slots.

La deuxième partie est la base de donnée de l'éditeur. En gros : cette base de donnée est un QObject pour pouvoir profiter du système de signaux et de slots. Cette classe contient des listes sur d'autres classes servant à stocker les données : par exemple, DatabaseModel, DatabaseZone, DatabaseEmitter, etc... Les signaux sont reroutés et transformés à partir de cette classe. Les DatabasePatati sont des classes qui contiennent un partie 'Données statiques' (ex: la position d'une zone pour un DatabaseZone, en bref : toutes les données de la classe de base de SPK), un partie donnée Dynamique (les objets SPARK en tant que tels) et une partie référencage, pour pouvoir savoir qui pointe sur qui (les references sont des chaines de caractère). Il n'y aura pas d'emetteur, de modifieur, etc... déjà intégré dans le code source de l'éditeur, tout sera dès le début sous forme de plugin.
En effet, un plugin réimplémentera les DatabasePatata (plus la réimplémentation de la classe spk et la partie gui), et ce sera lui qui gerera l'objet de la bdd.

Tout changement sera donc répercuté sur les données statiques et dynamiques. Ca permet: de recommencer la simulation, de sauvegarder facilement, de pouvoir récupérer les données en cas de crash spk (ces crash me paraissent improbales pour l'instant^^ - du moins j'en ais pas vu), et d'organiser le tout.

Ca serait plus clair avec un schéma, mais je n'ai pas le temps de scanner puis de mettre en ligne une image pour l'instant.

Où j'en suis : j'ai commencé la gui, et normalement les tests des plugins avec les DatabaseZone (une classe clef de spark, sans elle, pas grand chose) devraient arriver sans doute ce week-end.

Perso je trouve que développer avec Qt est plutot sympa, j'ai d'ailleurs déjà fait un éditeur avec (pas fini, largement améliorable), qui s'appelle GC Edit (faites une recherche sur Gamecorp ou sur Sourceforge pour avoir plus d'informations)


edit: pour l'éditeur, ca peut etre très utile pour créer un nouvel effet de particules sans se casser la tète avec 1000 lignes de code.

edit2: j'oubliais... utilisation d'irrlicht ou sfml (choix du renderer donc, mais je commence avec Irrlicht). Fichiers : xml sans doute. Les plugins seront des dlls

ok,

pour l'instant je met en suspens le developpement du mien alors puisque tu sembles bien parti et que de toute facon je ne suis pas très avancé. Je continuerai peut etre tanquillement mais comme ca je peux me concentrer sur la lib a proprement parler.

Par contre je vais sans doute faire un format spécifique dont les spécification seront open et libres avec un loader associé. Libre à toi de l'utiliser ou non.

Aussi si tu veux une branche sur le svn pour ton éditeur, il y a pas de probleme

Pour la branche, merci, mais je vais déjà attendre qu'il soit un tout petit peu plus développé. Sinon, si tu fait ton propre format, il sera intégré à l'éditeur car fera partie de spark^^

Le projet à commencé, pour l'instant j'implémente les zones, et j'ai quasiment fini la partie gui des zones. Les résultats graphiques ne seront pas forcéments très convaincants, mais au niveau du fonctionnement, avoir les zones fonctionnelles signifiera avoir toute la base de donnée + la gui + les plugins + spark qui fonctionnent bien ensembles. Après, le reste devrait aller un peu plus vite.

En passant, les fonctions de callback de spark sont des fonctions statiques, c'est à dire fixées lors de l'execution. Pourquoi ne pas plutot utiliser des foncteurs, ca permettrait de garder les avantages des fonctions statiques tout en étant dynamique ?
Pour l'éditeur, ca sera pratique lors que je mettrait les scripts pour les fonctions callback (c'est possible maintenant, mais ca boufferait plus de perfs)

En fait les pointeurs de fonctions pour les callbacks vont disparaitre. C'est un relicat de la toute premiere version. C'est bien pour mettre en place vite fait un petit comportement mais c'est pas assez flexible. Tout sera fait a partir de modifiers a terme (comportement a la naissance, a l'update et a la mort).

D'après ce que tu vient de dire, je peux en déduire que pour les modifieurs, une proprieté ageMin,ageMax va apparaitre (pour spécifier une zone temporelle ac les memes déclencheurs que pour les zones spatiales, par exemple, tel particule à tel age.)

Ca signifie aussi qu'au lieu d'utiliser des fonctions callback, je peut déjà maintenant créer un modifieur admettant un script, comme ca ca sera compatible avec les prochaines versions de spark ?

edit: Au fait, à propos de la fonction TraceAll de la fabrique, le mieux serait de renvoyer une chaine de caractère ou de laisser le choix à l'utilisateur, plutot que d'afficher le tout par la console. Ca peut etre pratiquepour enregistrer dans un log ou afficher dans un widget (possible maintenant, mais plus complexe)

1ere version alpha: http://www.mediafire.com/?ejvyzodgjwd
Au menu:

• Possibilité d'éditer les zones
  
• Base de donnée et gestionnaire de plugins bien avancés
  
• Possibilité d'ajouter de nouveaux type de zone en faisant des plugins.
  

Pour la prochaine fois: émetteurs, modificateurs, références internes de la base de données.

Edit: 2-3 précisions:
1/ Je fournirais toujours les versions releases, et pour cause: les versions débug prendraient quasiment 100 Mo !
2/Il n'y a pas encore de vue 3D Elle ne sera mise que lorsqu'il y aura suffisamment d'éléments implémentés pour faire fonctionner spark. A ce propos, je ne pourrais pas faire la partie modèles tant que je ne connaitrais pas la nouvelle architecture, pour éviter de faire du code inutilement.

cool. Par contre niveau loc, tu prévois de le faire en anglais aussi ?

Pour répondre à tes questions :

• Pour les callbacks : le calback d'update peut déjà être remplacé par un modifieurs custom. Les callback de naissance et mort vont disparaitre au profit d'une liste de modifieurs a appliquer a la naissance et a la mort. Les modifieurs auront une nouvelle méthode modify qui sera ponctuelle (donc ne prendra plus de deltatime) pour gérer la naissance et la mort en plus de la méthode modify discrete déjà en place pour l'update. Le comportement sera définie par modifieur. Enfin c'est comme ca que je vois le truc pour l'instant apres c'est pas figé dans la roche encore.
  
• Quand tu parles de script que veux tu dire exactement ?
  
• Pour la ligne temporelle, ce n'est pas prévu pour l'instant mais a terme il faudrait implémenter un truc qui permettrait de réaliser des petites actions en fonction du temps courant d'un système (activation/désactivation d'un objet dans le système, modification sur la transform d'un transformable...). Tout ca pour pouvoir gérer de facon automatique l'évolution d'un système au cours du temps. Ce n'est pas encore bien définie et c'est par pour tout de suite tout de suite.
  
• Pour les trace, tu as moyen de changer le read buffer du cout comme tu veux (pour écrire dans un fichier, une string...). Un exemple ici
  
• Pour les model, l'interface utilisateur sera la même donc tu ca ne changera pas (en fait il y aura juste des trucs en plus) mais l ancienne interface sera compatible avec la nouvelle, donc tu ne fera pas de code inutilement. EN fait ca devrait arriver très bientot, c'est déjà implémenté mais il me reste des trucs a debugguer et après je pose sur le svn (peut etre ajd si j'arrive a tout bien debugguer)
  

OK.
Pour la langue, oui je prévois de le traduire. En fait, l'éditeur pourra etre traduit en anglais, allemand, italien, espagnol, polonais, russe, portugais, suèdois, ... ^^

Avec Qt, il n'y a pas besoin de changer ne serait-ce qu'une ligne de code pour traduire, c'est un énorme avantage (en fait, les devs de Qt sont partis du principe que ca n'est pas le programmeur qui traduit le programme) (perso je ne ferait qu'au max la traduc en anglais... et le reste sera fait pas les utilisateurs^^)

Sinon pour les scripts, ca va etre un modificateur avec une méthode modify qui appellera une fonction scriptée (QtScript).

Merci pour le trace.

edit: en fait, pour le trace, ca ne peut pas marcher (la redirection) car le cout que spark appelle est dans une dll. Je n'ai pas essayé en statique, mais en tout cas, avec spark.dll, la redirection ne fonctionne pas.

ah ouais ? je regarderai ca.

Sinon j'ai commité les nouveaux modeles. Je pense que c'est a peu près debuggué. Il me reste la doc a faire.

Ah! Je vais voir ca.

Pour la question du nom...

J'ai pensé à plusieurs noms pour l'éditeur, dites moi celui que vous préférez:

• SparkGalaxy ou SGalaxy
  
• PSYS
  
• SparkEditor
  

N'hesitez pas à en proposer !

Personellement je le garderai simple Spark Editor est bien.
Après appelle le comme tu veux, ce n'est pas le nom qui fera l'éditeur

Ok, c'est noté. Personnellement, j'étais plutot attiré par SGalaxy, ou SparkGalaxy, c'était plus original^^ Je vais peut etre attendre d'autres avis.

Sinon il ne me reste que les références zones/émetteurs, puis les modifieurs, et la deuxième alpha pourra sortir. Si tout ce passe bien, c'est ce week-end.

2ème alpha, dans les temps^^

http://www.mediafire.com/?vm2hd21gh5z

Ajouts:
modificateurs, émetteurs, références internes. Normalement, si tu l'éxecute à partir de la console, tu verra qu' la fin du programme tous les objets SPARK sont bien nettoyés.

Pour la prochaine alpha:
Modèles, et groupes. Ca sera peut etre un peut plus long à implémenter, vu que c'est deux classes différentes (alors que les modificateurs sont un copier-coller des émetteurs).

Par contre, je n'ai pas encore téléchargé la dernière version SVN, l'éditeur fonctionne avec la révision 45...


edit: je vient de me mettre à la révision 65. Je te conseille de mettre pas mal de lignes vide à chaque fin de fichier, sinon ca génère 36000 warnings par mingw...

Ok j'ai regardé. Quelques petites remarques :

• Quand tu change le type d'un object (par exemple une sphere a une AABox), tu es obligé de recréer en interne l'objet et du coup j'ai l'impression que les références ne sont pas mises a jour dans les autres objets.
  
• Il faudrait pouvoir setté la zone d'un modifier a NULL comme ca n'a pas toujours de sens d'avoir une zone pour le modifier. Et en plus ca alourdit l'édition s'il faut créé une zone pour chaque modifier.
  
• Le full zone n'a pas de sens pour un modifier il me semble, pourtant il y a une checkbox dans la fenetre d'édition.
  

Voila c'est a peu pret tout. Je me doute bien que comme c'est une version peu avancé, ce sont sans doute des trucs que tu a vu et qui vont etre modifié plus tard mais je les signale quand meme.

Merci du com'.

Pour les références, normalement elles sont bien changées, enfin je vais vérifier

Pour la zone à NULL, en fait je pense simplement ajouter une zone 'NULL' (que l'utilisateur ne pourra pas supprimer).

Sinon merci pour le full zone, je vais l'enlever (je ne savais pas vraiment si ca avait de sens, donc par défaut, il y est^^)

A noter que je n'ai pas pu programmer du tout de la semaine, donc ca n'a pas encore avancé...

L'alpha 0.4 est prête, il ne me reste plus qu'a trouver un accès internet rapide et je l'upload. Au menu: modèles avec interpolateurs, et groupes, ainsi que pas mal de bugfixes. Au pire, ca arrivera ce week-end.

Cool, j'attend de voir ca.

Par contre, je te conseille de pas trop avancer en fait parceque je compte ressortir une version 2 de la lib qui remettra tout bien a plat. C'est pas loin d'être pret et il y aura quand même pas mal de chose qui vont changer dans l'interface même si la philosophie restera la même. Ca devrait pas être trop dur de passer de l'une a l'autre par contre.

Ca sera vraisemblablement samedi ou dimanche.

Sinon faut quand même que j'avance un peu, j'aimerais bien arriver a l'étape de rendu. Normalement j'ai prévu le truc de manière à minimiser les changements à faire du coté SPARK.

Les plus gros changements concerneront quoi, au niveau fonctionnement/interface?

edit: a ce propos, j'essaie de compiler SPARK sous ubuntu, et gcc n'aime pas les __declspec. Apparemment, faudrait plutôt faire une macro avec les __atribute__((dllexport)) il me semble.

Sinon, je vais essayer de compiler l'éditeur sous linux, il ne me reste qu'a changer tous les includes car linux ne supporte pas les '\' dans les chemins - c'est d'ailleurs débile, Windows supporte les 2 et ca n'a pas l'air très compliqué de rajouter le '\' ...

Voila le fichier:
http://www.mediafire.com/?imgmnytkizf

Windows only, 39 Mo car contient toutes les dlls en mode débug (gcc, ou mieux, qtcreator pour le mode débug). Toutes les dlls de Qt ont été compressées en plus du 7z global, faudra les décompresser à coté de l'exe.

Une requête : soyez le plus violent possible avec cette alpha, et rapportez moi tous les bugs^^