Discussion :

[Darktib]

En effet, il y a beaucoup de contraintes pour le full GPU et ça demande de redévelopper quasiment tout SPARK mais sous forme de shader (ou équivalent pour OpenCL).

[Frifron]

Bonjour, ca faisait longtemps que j'avais pas donnée de news.

Pour répondre aux questions :

• Mat M. : Il y a bien une version DirectX 9 pour SPARK mais uniquement sur le svn car pas considéré comme stable. La version stable des renderers directX arrivera avec la version 2 de SPARK
• Takezo02 : J'ai jeté un coup d'oeil au système de particule de torque et il a l'air effectivement plus limité que SPARK (même s'il y a quelques trucs en plus comme les soft particles) mais cependant suffisamment avancé pour réaliser des effets interessant. Le truc c'est que pour interfacer SPARK avec torque, il faut coder le module (les renderers et le système). Pour cela il faut une relativement bonne connaissance des 2 moteurs et un peu de temps. Je ferai bien un module mais comme torque est un moteur payant je n'ai pas accès aux sources donc c'est pas evident. Bref à moins d'avoir un besoin très spécifique, utiliser les particules de torque me semble être la solution demandant le moins d'effort. A part çà il n'y a pas de version full GPU de prévu pour SPARK. le CPU fait très bien l'affaire (quitte à utiliser un thread dédié pour l'update des particules) et en production je ne vois pas d'avantages a utiliser du full gpu. Après je prévois d'intégré l'utilisation intensive des shader dans le moteur mais l'update restera coté CPU.
• coda_blank : non pas de version OpenCL de prévu. Stardeath a bien réaliser une version full GPU mais en Direct compute qui est sur le svn mais je pense que c'est plus a l'état de proto (toutes les fonctionnalités ne sont pas implémentées). Enfin je ne l'ai pas testé en profondeur donc il en parlera surement mieux que moi.

[Takezo02]

Merci pour les reponses

J'utilise une version de Torque d'avant T3D qui est la dernière mouture, dans la mienne la TGEA 1.8.2 les soft particles sont à l'état de prototypes lol, les possibilités au niveau particle sont effectivement très bien mais il manque indubitablement les Modifier et certain types d'Emitter ce pourquoi je m'interresse très fortement a SPARK et à son intégration dans ma version de Torque.

Je connais vraiment bien Torque, son arcitecture et ses coding rules, donc je vais trouver un temps pour faire cette intégration, pour ce qui est des perf en CPU, oui le thread dédié est une bonne solution et je pensais aussi à utiliser OpenMP pour du traitement Multi CPU, voilà, pour l'instant la priorité pour moi c'est le prototype de Galaxy Battle Arena mais je plannifie l'intégration de SPARK à Torque après ce prototype ce qui me laissera aussi le temps de bien intégrer la philosophie de conception coté SPARK niveau renderers et system.

Encore merci et à bientôt

[Frifron]

Ok, dans ce cas je te conseille de partir directement sur la version 2 de SPARK.

Elle n'est pour l'instant accessible uniquement depuis le svn et n'est pas tout à fait terminée mais le gros du truc est fait. Il me reste surtout de la doc à faire et à finir de porter les démos et quelques petits trucs.

Comme il y a pas mal de concepts qui changent entre les 2 versions, autant partir directement sur la 2 qui est mieux en tout points (performance, design, facilité d'utilisation et d'interfacage).

Bref la version 1 n'évoluera plus maintenant (sauf des release de maintenance).

[coda_blank]

Bonjour, ca faisait longtemps que j'avais pas donnée de news.

Pour répondre aux questions :

• Mat M. : Il y a bien une version DirectX 9 pour SPARK mais uniquement sur le svn car pas considéré comme stable. La version stable des renderers directX arrivera avec la version 2 de SPARK
• Takezo02 : J'ai jeté un coup d'oeil au système de particule de torque et il a l'air effectivement plus limité que SPARK (même s'il y a quelques trucs en plus comme les soft particles) mais cependant suffisamment avancé pour réaliser des effets interessant. Le truc c'est que pour interfacer SPARK avec torque, il faut coder le module (les renderers et le système). Pour cela il faut une relativement bonne connaissance des 2 moteurs et un peu de temps. Je ferai bien un module mais comme torque est un moteur payant je n'ai pas accès aux sources donc c'est pas evident. Bref à moins d'avoir un besoin très spécifique, utiliser les particules de torque me semble être la solution demandant le moins d'effort. A part çà il n'y a pas de version full GPU de prévu pour SPARK. le CPU fait très bien l'affaire (quitte à utiliser un thread dédié pour l'update des particules) et en production je ne vois pas d'avantages a utiliser du full gpu. Après je prévois d'intégré l'utilisation intensive des shader dans le moteur mais l'update restera coté CPU.
• coda_blank : non pas de version OpenCL de prévu. Stardeath a bien réaliser une version full GPU mais en Direct compute qui est sur le svn mais je pense que c'est plus a l'état de proto (toutes les fonctionnalités ne sont pas implémentées). Enfin je ne l'ai pas testé en profondeur donc il en parlera surement mieux que moi.

mais les perf sont quand même plus intéressantes sur GPU non ? et même en full GPU l'update des VBO se fait sur CPU donc je ne vois pas le problème (à part le travail supplémentaire bien sûr )

[Frifron]

Oui les perfs vont être meilleures sur GPU parcequ'il n'y a pas besoin d'uploader les data et que ca va être du calcul facilement parallélisable. Mais en contrepartie, ca va être plus difficilement implémentable, tu perds en flexibilité, en extensibilité, en portabilité, c'est beaucoup plus compliqué de faire interagir les particules avec l'extérieur...

Bref, les particules GPU ca va être bien pour de la recherche ou la ou il va y avoir besoin de grosse puissance de calcul (simulation de fluide...).

Pour de la prod de jeu, le budget en particule ne se compte pas en millions de particules. Les goulots d'étranglement ne vont pas être l'update ou le transfert sur le bus mais plutôt les effets par pixel et le fillrate, et la pour le coup que ce soit GPU ou CPU ca ne change rien.

Moi je cherche à avoir un truc très modulaire, facilement extensible et interfaceable avec n'importe quel moteur, donc le full GPU n'apporterait rien.

[coda_blank]

Oui les perfs vont être meilleures sur GPU parcequ'il n'y a pas besoin d'uploader les data et que ca va être du calcul facilement parallélisable. Mais en contrepartie, ca va être plus difficilement implémentable, tu perds en flexibilité, en extensibilité, en portabilité, c'est beaucoup plus compliqué de faire interagir les particules avec l'extérieur...

Bref, les particules GPU ca va être bien pour de la recherche ou la ou il va y avoir besoin de grosse puissance de calcul (simulation de fluide...).

Pour de la prod de jeu, le budget en particule ne se compte pas en millions de particules. Les goulots d'étranglement ne vont pas être l'update ou le transfert sur le bus mais plutôt les effets par pixel et le fillrate, et la pour le coup que ce soit GPU ou CPU ca ne change rien.

Moi je cherche à avoir un truc très modulaire, facilement extensible et interfaceable avec n'importe quel moteur, donc le full GPU n'apporterait rien.

tu veux dire qu'un nuage de 30 000 particules aura un rendu aussi crédible qu'un de 100 000 ? Pour le fillrate je suis d'accord, c'est ce qui m'empêche d'atteindre la barre du million avec les billboards . Peut-on envisager une solution de culling en amont ?

[stardeath]

Frifron a très bien décrit les problèmes actuels de l'implantation en compute shaders.

c'est absolument pas flexible, et ça ce n'est pas du à l'implémentation, mais au langage des shaders, il faut bien se rendre compte qu'on a encore moins de possibilité qu'en c :
- pas de pointeur, pour simuler ça, il faut utiliser un index sur un tableau qui contient toutes les données
- pas de multiple buffer en écriture, par passe de CS (4.0) on ne peut avoir QU'UN seul tableau en écriture, alors soit :
--- on a un très gros tableau dans lequel on va écrire (pas génial pour les transferts cpu/gpu)
--- on fait plusieurs passes avec des tableaux plus petits et différents pour pouvoir écrire tout ce qu'on a besoin
--- on se passe de tout ce qui ne concerne pas les particules et on perd 75% des fonctionnalités de spark

bref c'est tendu d'avoir quelque chose de correct.

[shenron666]

juste un détail qui pour moi a son importance : direct compute c'est DX11 minimum
ce qui implique un GPU compatible mais aussi et surtout vista ou seven
XP n'est pas compatible

[stardeath]

juste un détail qui pour moi a son importance : direct compute c'est DX11 minimum
ce qui implique un GPU compatible mais aussi et surtout vista ou seven
XP n'est pas compatible

c'est dx10 minimum, mais ce n'est qu'un détail.

le problème que tu soulignes s'étend à tous les langages de gpu computing :
- direct compute, vista minimum, compatible ati/nvidia
- opencl, multiplateforme, support inégal entre ati/nvidia
- cuda, multiplateforme, nvidia seulement
- ati stream, multiplateforme, ati seulement

bref j'ai choisi direct compute parce que je bosse déjà (plus ou moins) sur les renderers directx

[Darktib]

Au niveau de SPARK: Une nouvelle version est sortie récemment, la 1.5.3, corrigeant un bug d'affichage avec Irrlicht.

Au niveau de l'éditeur:

nouvelle version 0.5; Au menu: corrections de bugs, arrivée de l'éditeur de courbes, et quelques nouveaux plugins.
Dans le pack est aussi fourni une sorte de sdk permettant de créer des plugins (ca n'est pas encore un 'vrai' SDK, la seule doc dispo étant les commentaires de code et les exemples). Ce 'sdk' ne contient pas encore les sources permettant d'intégrer des moteurs de rendu dans le logiciel.

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


Il s'agit d'une version release, contrairement à toutes les autres versions qui étaient en débug.

Enjoy!

[divxdede]

Je n'ai pas testé et je n'aurai probablement pas l'occasion de le faire.
Ceci dit, de l'extérieur, ce projet à l'air bien fichu et représenter un gros travail, alors je ne peu que te féliciter !! Continue comme ça !!

Tu as une liste de projets (en cours ou terminés) utilisant ton moteur de particules ?