version 2 sujet à questions en vrac XD

Mon père a Seven avec dx11 - mais faut qu'il me prête son ordi...

J'ai vu qu'il n'y avait pas d'exe. C'est dommage, vu que le seul ordi sur lequel je peut tester n'a absolument aucun outil de dev, et que je n'ai le droit d'installer quoi que ce soit

ok je mets un exécutable sur le svn

ps : c'est fait

J'ai testé, et ca rend vraiment très bien.Je tourne à 300 fps avec la config par défaut, cg NVidia GeForce 9500 GT (2,7 Go dédié), 4Go ram système, Windows Seven, Intel Core i7.

as tu regardé un peu le code?

Très vaguement, mais comme je connais mal DirectX, je ne pourrais pas être bon juge ^^

J'ai testé et c'est bien mais je trouve que la différence cpu vs gpu ne saute pas aux yeux. Je pense qu'il faudrait prendre une démo plu significative. Je pense par exemple a porter la démo flakes pour comparer les perf de SPARK en cpu vs en gpu dans des conditions idéales (beaucoup de particules et pas de bottleneck au niveau du fillrate). J'essaierai de faire ca en portant la démo flakes sur spark 2 et avec ta version (je pense que tous les éléments nécessaires sont dispo).

Après j'ai pas regardé le code mais j'ai lu ta doc et c'est du bon boulot. D'ailleurs est ce que je pourrais réutiliser le schéma uml que tu a fait de spark ?

ouaip tu peux l'utiliser, j'ai tout mis pour que ça serve (je dois avoir le png en grande taille si tu veux).

effectivement c'est pas flagrant, au dessus de 60fps on voit plus rien de toute façon, faudrait voir dans une vraie scène; et encore on s'en va de plus en plus vers des scènes "gpu-bound".
avoir le moteur de particules en plus sur le gpu exclusivement n'est peut être pas une bonne idée.
je verrai plus un système coopératif cpu/gpu. à voir

Oui c'est très vrai. Mais les particules apparaissent pas mal comme idéales pour le tout GPU : de la géométrie dynamique qui n'a aucune influence sur la scene autre que graphique (en rêgle général) et dont le calcul est hautement parallélisable. Le seul problème étant qu'un moteur de particule se doit d'être très générique et modulable et ca c'est moins compatible avec le calcul sur GPU.

ha ça le coté modulable, je crois que tu as vu la solution que j'ai du adopter, il n'y a plus grand chose qu'on peut modifier facilement.

dans peu de temps on aura accès à un vrai langage pour le gpu, mais pour l'instant c'est pas la joie.

question : pourquoi est ce que les renderers attachés à un groupe sont détruits à la sortie de l'application et pas ceux qui ne le sont pas?

Rien n'est détruit a la sortie de l'application, par contre la destruction est récursive. Donc si tu détruit un système, ses groupes vont être détruit ainsi que tous les objets dans les groupes et ainsi de suite. Sauf dans certains cas. Si un objet est non destroyable ou si un objet est encore référencé ailleurs (chaque registerable a un compteur de référence)

oui pas à la sortie de l'application, j'ai écrit une bourde ><

par contre ça m'embête, soit le cas suivant :

- un renderer attaché à un groupe
- un renderer alloué mais non attaché

sur une défaillance du device, je dois détruire tous les buffer_dx9 (pour bien différencier les interfaces dx des interfaces spark);

je rajoute donc une liste de ressources à ma classe qui gère les éléments dx.

le problème est que si dans cette liste je référence :

- les buffers (ceux de spark) : là aucun problème les buffer_dx9 seront détruits sauf si un buffer a été détruit par son groupe entre temps -> problème et la méthode destroyRenderBuffer ne sert donc à rien

- les groupes : là seuls les buffers attachés verront leurs buffer_dx9 détruits -> problème

- les buffers et les groupes : comment différencier les buffers qui sont attachés à un groupe donc détruits par le groupe et ceux libres donc à détruire -> problème

est ce que tu as une idée?

les buffers natifs directX doivent être encapsulés dans une classe BufferDX9 qui hérite de SPK::Buffer. Les buffers sont créés par les renderers pour un groupe donné avec la méthode attachBuffer. Des buffers non attachés ca devrait pas arriver normalement.

Les renderers ne doivent pas contenir de data, leur but est juste de remplir des buffers qu'on leur passe et de les envoyer au GPU.

c'est ce que j'ai fait les buffers dx sont dans une classe DX9Buffer qui hérite de RenderBuffer.

ha je crois avoir compris où je me suis planté ><

je vérifie et je reviens éditer ce message

edit : bon c'est bon pour ce point là XD

Je fignole encore quelques truc sur l'éditeur, et je passe à la version 2. J'avais 2 question sur cette version:

1/ Est il possible d'affecter un interpolateur pour a peu près n'importe quoi (genre, mettre un interpolateur sur la propriété "forceMin/forceMax" d'un émetteur) ?

2/ Est-il possible à un émetteur d'émettre autre chose que des particules (genre système, émetteur, modificateur, etc...) (il me semble pour pour émettre un émetteur, il faut émettre une particule à laquelle on à "attaché" une zone, et créer un émetteur dont on aurait changé sa zone vers celle qui est attachée à la particule)

Merci.

Darktib wrote:

Est il possible d'affecter un interpolateur pour a peu près n'importe quoi (genre, mettre un interpolateur sur la propriété "forceMin/forceMax" d'un émetteur) ?

Pour l'instant non mais ce sera sans doute possible a terme a l'aide d'objet pouvant modifier les paramètres d'autre objets a l'aide d'interpolateurs. Dans la mesure ou ce sont des classes templates, on peut théoriquement interpoler n'importe quoi.

Darktib wrote:

Est-il possible à un émetteur d'émettre autre chose que des particules (genre système, émetteur, modificateur, etc...) (il me semble pour pour émettre un émetteur, il faut émettre une particule à laquelle on à "attaché" une zone, et créer un émetteur dont on aurait changé sa zone vers celle qui est attachée à la particule)

Ca se sera possible plus tot. Peut etre pas dans la premiere release mais le moteur a été developpé pour que ce soit possible. Pour l'instant le seul truc implémenté c'est la création d'un emetteur sur une particule a un moment donné (naissance,mort...) (voir spawnParticleAction)

ok, merci pour les renseignements

bon je viens donner un peu de nouvelle, j'ai toujours pas un internet décent, ça me gave sévèrement là.

je sais pas où tu en es de tes objectifs de la version 2, mais si ça continue comme ça, il n'y aura toujours pas de release officielle des renderers directx.

ps: finalement je viens de récupérer le net, j'up ce week end

j'ai un plantage sur spark test (debug dll) quand je tente de quitter l'appli, ça plante, je suis en train de regarder pourquoi.

Je viens de tester et c'est du a la suppression de la zone par défaut. En debug chaque registerable est stocké dans une map pour pouvoir tracer leur durée de vie. C'est un problème d'ordre des suppression des statique sans doute. Je vais corriger ca. Merci du report

EDIT : J'ai viré le système pour l'instant. C'était temporaire de toute facon et il faudra que je fasse un meilleur tracage de la mémoire en debug.

nouveaux renderers sur le svn.

et pareil j'attends vos questions, remarques etc ^^

Tu as oublié de commiter SPARK_DX9.h

oups, c'est corrigé.

au fait, je mets sur le svn les fichiers solutions pour vs 2010 ?