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

C'est très cool tout ca, ca prend forme. Hate de voir la fenetre de rendu. J'ai eu quelques plantages mais je te détaillerai tout ca dans un autre post.

Pour les changements principaux de la version 2 :

• Le plus gros c'est que les modèles disparaissent, en fait ils sont intégrés aux groupes. Le set up des parametres ne passent plus par des flags mais par des interpolateurs que l'on set ou non sur les paramètres pour les activer et définir comment ils evolue (en fonction du type d'interpolateur). C'est plus intuitif et ca marche bien.
  
• Il y a maintenant une classe couleur en RGBA. Ca prend moins de place en mémoire (32bits au lieu de 128) et c'est plus facile a manipuler qu'avoir les 4 composantes séparées.
  
• La gestion de la mémoire a un peu évolué, les registerable se crée maintenant uniquement dynamiquement, les groupes sont forcément créé dans un système et les systèmes ne sont plus des registerables (ca permet de laisser la gestion des système entièrement au moteur dans lequel est intégré spark, par exemple pour irrlicht de gérer ses systèmes comme n'importe quel scene node.)
  
• Les modifiers sont un peu changé, l'appel a modify se fait par groupe et non plus par particule. Il n'y a plus de trigger et de zone (ou seulement pour les modifier ou c'est légitime comme les obstacles)
  
• Il y a une nouvelle sorte de registerable : les actions qui permettre d'agir sur une particule a un moment donné. Ca permet de supprimer les callback de l'ancienne version et les problèmes liés a ceux ci.
  
• Après en interne les données ont été réorganisées . D'après mes tests ca va un petit peu plus vite maintenant.
  
• Sinon le reste n'a pas trop changé. les modules de rendu fonctionne de la meme facon. Juste les renderBuffer qui sont géré différemment en interne (pour régler le problème de la perte de device en DX9 notamment)
  

Voila en gros il y a pas mal de changements mais les fonctionnalités restent les même. C'est juste une remise a plat du truc mieux designé et réglant tout les problèmes rencontrés au cours de l'évolution de la version 1. Ca va faire quelques changements au niveau de l'éditeur mais rien de trop galère je pense (j'espere).

Je poserai rapidement sur svn une branche avec la version 2. La il y a le module Opengl et le core quasiment terminé. Après faut que je rajoute les classes d'extensions et que je documente le tout.

A oui sinon pour les '/' ou les '\' c'est quoi qui fonctionne dans tout les cas alors ? Parceque les includes dans spark sont avec des '/' et toi tu parles de '\'

[edit] ah oui et puis la version 2 a également un logger qui peut être dirigé sur n'importe quel flux.

Juff wrote:

A oui sinon pour les '/' ou les '\' c'est quoi qui fonctionne dans tout les cas alors ? Parceque les includes dans spark sont avec des '/' et toi tu parles de '\'

ce qui devrait marcher tout le temps c'est '/', le problème du '\' en c/c++ c'est que c'est là pour indiquer un caractère d'échappement : '\n', '\t', '\\' etc ... et pas un chemin, même si certain compilateur s'en moque un peu.

bah oui c'est ce qu'il me semble, ce sont des '/' dans spark d'ailleurs donc il ne devrait pas y avoir de problème.

Sinon pour les __declspec apparemment c'est uniquement sous windows que c'est necessaire (suffirait de rajouter un check de plateforme). Il faudra que je me renseigne, le problème c'est que je ne peux pas tester sous autre chose que windows.

Le \ est aussi un séparateur de chemin sous Windows - le problème avait lieu au niveau du préprocesseurn d'ailleurs. Ca n'est qu'un problème bénin, déjà corrigé.

Je vais voir pour compiler SPARK sous linux, j'ai mis à jour la version que j'ai, wait'n'see...

Je prend note pour SPARK 2.0 . En gros, mixer le tab modèle avec le tab groupe; ajouter le tab action, modifier celui des modificateurs.

Pour les registerables qui deviennent dynamiques, ca veut dire quoi concrètement ?

Beaucoup de nouvelles choses pour l'éditeur.

A mieux regarder mon code, je me suis rendu compte que je répétais beaucoup de fois la même chose, ce qui n'est pas bon pour la maintien du code. Le tout était devenu compliqué - surtout le débogage.
J'ai donc fait un rewrite, en repensant les modules.

Les modules seront donc:

• Une base de donnée permettant de stocker toutes les informations de la scène [fait]
  
• Un gestionnaire de plugin pour permettre au logiciel de gérer plus d'éléments spark [fait]
  
• Une intégration de moteur graphique (Irrlicht, SFML, etc...) générique et ne dépendant pas de Qt. [fait en partie pour Irrlicht]
  
• Un gestionnaire de propriétés [fait],un logger[fait]
  
• Un gestionnaire des données SPARK [pas dispo dans l'exe posté mais quasiment fini]
  
• La gui finale [pas encore fait, mais ca sera le plus facile a faire, avec QtDesigner]
  
• Quelques autres modules de moindre importance qui seront trouvés plus tard
  

Tout ce qui utilisera des plugins / intégrations sera sous surveillance accrue, càd que le logiciel pourra intercepter les exception du SEH (sous windows) et les signaux (sous linux) pour éviter de crasher si un plugin rencontre une segfault par exemple.

Actuellement, il n'y a que la scène de test (un cube qui tourne), vous pouvez changer le fps via le fichier config (attention, il ne s'agit que d'une indication, par exemple si vous mettez 900 le fps peut très bien être de 1000...). C'est vraiment pas grand-chose pour l'instant.

Autre chose importante : je code maintenant l'éditeur avec Visual Studio, je suis plus productif dessus. Et les binaires sont plus légers...

Pour la suite : je vais créer le gestionnaire des éléments SPARK, adapter un peu les plugins, et faire une scène toute bête (la démo basique par exemple). A partir de ce moment, je commencerais la gui.

Concernant les versions de Spark : L'éditeur utilisera Spark 1, mais je prévois de rapidement le passer à la version 2.0 . Tel qu'est conçu à l'instant présent l'éditeur, ca demandera de réécrire/ajouter certains plugins, de modifier le gestionnaire spark... et c'est tout !

Voila le lien: http://www.mediafire.com/?mmy1mjdwmny

Le code est beaucoup plus clair à présent. Si j'ai le temps, je ferais un schéma des modules utilisés dans l'éditeur.

edit: j'oubliais : l'interface est actuellement en français - c'est temporaire, tout sera conçu en anglais dès que la gui finale sera entamée.

edit: voila un schéma très très simplifié.


edit: Au niveau de la license, ca sera soit LGPL, soit zlib, pour l'instant j'hésite encore (et je cherche des explications précises sur ces 2 licenses, surtout pour LGPL)

Tadam! la première version avec le rendu est là !
Pour tous les utilisateurs de ce forum



A noter: tous les boutons ne servent à rien, sauf le bouton quitter (lol)

Il y a déjà une sauvegarde, le programme va la charger. Si elle n'existe pas, elle sera automatiquement recrée avec une scène par défaut. Vous pouvez modifier les options, seule l'option fpsHint est utilisée pour l'instant.

Et évidemment... vous pouvez bidouiller la sauvegarde pour changer la scène.

C'est ici: http://www.mediafire.com/?dzg4ekaoyau

Have fun!

PS:Dites moi si vous trouvez des bugs

pas mal du tout.

par contre petite remarque, le xml, c'est obligé? je trouve ça pas très lisible, un bon vieux fichier ini à l'ancienne c'est plus facilement éditable à la main.

ensuite pour le nom des types dans le xml, autant bool, int double, ok, par contre QString ça fait très lié à qt; faudrait presque voir à spécifier un format et une syntaxe pour la sérialisation des données de spark, qu'en pensez vous?

Merci

Ok, je vais changer QString par string.

Pour le xml, c'est pas obligatoire, d'ailleurs le système de chargement/sauvegarde fonctionne avec des plugins donc sera extensible. Je prévois d'ajouter l'autre format xml, celui de SimpleSpark, qui je pense pourra devenir le format xml "officiel". Et après... sans doute un format binaire.

Note: le format actuel n'est pas fait pour etre directement chargé dans un projet Spark (mais il est possible de le faire), il sera integré dans un fichier "projet" contenant tout ce qui est important dans la création d'un projet, càd: la scène, les options, les médias (pour visualiser un système il peut être pratique d'utiliser des médias).

Ca avance, j'en suis aux widgets principaux de la GUI, pour l'instant à l'explorateur de scène. Au niveau visible, c'est pas extraordinaire, mais comme la majorité des contrôles de ce widget se fait avec un clic droit...



@Juff: Qu'en penses-tu ?

PS: La Gui sera organisée dans une unique fenêtre, mais pour l'instant, je développe comme ca pour plus de facilité.

C'est encore un peu tôt pour pouvoir émettre un avis vu que y a pas beaucoup de fonctionnalités encore mais en tout cas à avance dans le bon sens, c'est cool.

Par contre je te conseille de passer a la version 2 assez rapidement (le module Irrlicht vient d'être porté). D'un part ca me permettra d'avoir un retour sur la nouvelle version et puis ce sera plus pertinant d'avoir l'éditeur sur la V2. Mais bon après c'est comme tu le sens.

Je pense mettre les widgets indispensables (explorateur de scène, éditeur de propriétés) pour la v1, ca me permettra de pas mal tester l'éditeur, puis après étudier la v2 pour porter l'éditeur dessus. Ca m'évitera d'avoir à rédiger tous les plugins pour la v1^^

Un petit screen pour dire que ca avance:

Un autre up: dorénavant il est possible d'éditer en temps réel les paramètres visibles sur la droite, à l'exception des éléments spark.

Capture d'écran:

Et pour tester: http://www.mediafire.com/?myynmnkizmw

Enjoy!

Ca commence a prendre forme, c'est cool.

Faudrait pouvoir se déplacer dans la scene et changer la couleur de fond.

On peut se déplacer dans la scène maintenant, et j'ai corrigé un gros tas de petits bugs.

J'ai profité de l'éditeur pour essayer un effet:
Désolé, la compression jpeg de paint est pourrie...

Je mettrai la version en ligne pas avant au moins une semaine.

EDIT: un autre screen, pour montrer l'arrivée du plugin final des zones:

Nouvelle version : 0.30

Avec: possibilité de tourner la caméra (clic droit), possibilité de changer la couleur de fond, d'ajouter plus facilement des objets SPARK, et d'autres ajouts. Toutes les zones par défaut de SPARK (sauf union et intersection) sont ajoutées et utilisables.
L'interface permettant d'utiliser un moteur à été completement revue, et il y a pas mal de corrections de bugs.

C'est ici: http://www.mediafire.com/?yynn1mihqqz ( h t t p : / / w w w . m e d i a f i r e . c o m / ? y y n n 1 m i h q q z )

Et quelques stats:

Module	Lines	Files
Editor	7792	44
Plugins	2155+893	20+2
QMake generated	7318	17

PS: Le forum déconne méchamment avec les liens hypertexte, ca renvoie sur la bonne page mais par l'intermédiaire d'une page de pub - peut être le résultat d'une attaque ?

edit: J'ai essayé de compiler avec gcc. Pour la compilation, à part des erreurs bénignes, ca va. Par contre, lors de l'exécution, ca déconne de temps en temps... mais ca reste du bug très léger.
Bilan:
- Sous Windows, l'éditeur sera compilé avec Visual C++. Par conséquent, tout plugin devra être compilé avec ce même compilateur (compatibilité binaire).
- Sous Linux, l'éditeur sera compilé avec Gcc. Pour les plugins : tous seront compilés avec Gcc sur Linux (compatibilité binaire aussi).
- Sous Mac... gcc sans doute, s'il y a une release Mac... (je ne ferais sans doute pas moi-même le portage Mac)

edit2: J'ai essayé d'intégrer de manière vraiment basique la SFML... et çà a marché du premier coup! Pour ce qui est d'intégrer OpenGL et DirectX directement, ca sera faisable sans trop de problèmes - mais demandera beaucoup de code...

J'ai testé un peu et ca commence vraiment a devenir utilisable et c'est du bon boulot. Félicitations !

Modificateur 'Vortex' (un peu modifié):

Tout ca me donne quelques idées de logo...

Hello, on pourrait avoir une petite version avec chargement de textures ou bien c'est fait en dur dans le code actuellement ?

Je vais partir en randonnée pour une semaine, donc je fais ça la semaine prochaine.
Sinon, les textures ne sont pas codées en dur.

Voila une nouvelle version.

Désolé pour la taille, mais gcc sort des binaires beaucoup plus gros - et tout recompiler en release me prenait trop de temps.
Sinon, la zone 'Cylindre' n'est pas ajoutée dans l'éditeur pour l'instant. Enfin, j'ai désactivé l'éditeur de courbes car il n'est pas terminé.

h t t p : / / w w w . m e d i a f i r e . c o m / ? 0 l 4 t u 7 u 1 c w p o s h w

Normalement les exemples devraient marcher directement. Si ca n'est pas le cas (notamment pour les textures), il faut chercher les textures dans le project dock et choisir un fichier (je ne sait plus si les chemins sont en absolu ou en relatif dans les fichiers que j'ai enregistré ^^).

PS: T'aurai pas un réglage dans l'administration du forum pour virer la redirection sur les liens ?

Vraiment superbe ! Ca commence a avoir de la gueule. Tout n'est pas encore implémenté mais on sent déjà le potentiel.

Sinon ouais les textures ne marchaient pas directement chez moi. Mais en les reselectionnant ca fonctionne.

A part ca regarde du coté de System::setClampStep pour éviter que les petit freeze de l'éditeur aient une influence sur le rendu du système. Peut être utiliser un System::useAdaptiveStep peut être pas mal aussi.

Aussi avoir les angles en degrés dans l'éditeur serait peut être plus intuitif pout l'utilisateur.

Pour les liens faudra que je regarde...

Merci !

Pour ce qui est des freeze, ca vient de gcc - suffit que je repasse à vc++ pour qu'ils disparaissent... Le bug vient de Qt, les clampStep ne changent rien

Pour les degrés, à quoi penses-tu précisément ? A un cercle sur lequel on pourrait choisir une position ? Si c'est cela, c'est pas une mauvaise idée, je la mettrai après l'édition des couleurs.

Le System::setClampStep n'empecherait pas les freezes ou quoi que ce soit, ca permet juste de garder un rendu consistant même avec des chutes ponctuelles de framerate. En gros la s'il y a un freeze, il va y avoir un trou dans l'émission des particules (a cause du deltaTime qui va être très gros sur 1 frame). En settant un seuil sur le deltatime avec le setClampStep, ca permet d'éviter ce genre de chose.

Pour les degrés, je pensais tout simplement à utiliser des degré dans l'édition plutôt que des radians. C'est quand même plus facilement compréhensible que les radians pour l'édition. Après dans le moteur ca reste en radians parceque ca évite une conversion pour utiliser les fonction trigo de la STL.