Sympa tout ça, par contre j'ai vu qu'il utilise que le cpu, est ce qu'il n'y a pas des solutions du coté des cartes graphiques actuels pour alléger le cpu ?

nico :

j'ai vu qu'il utilise que le cpu, est ce qu'il n'y a pas des solutions du coté des cartes graphiques actuels pour alléger le cpu ?

Oui, sur son forum, il dit ceci:

Pour les VBO on va pas les utiliser pour le moment. Ca pourra etre fait dans une mise a jour eventuelle.

Ceci dit, même sans les VBO, les perf sont vraiment très bonne, et déjà à des années lumière du moteur de particule natif d'Irrlicht.

Et en video c'est encore plus bluffant. On aimerait bien que ça évolue et pourquoi pas que ça devienne natif à Irrlicht .... hmmmmm!!!
merci pour la new tmyke.

ok, merci pour l'info

TUpac :

Et en video c'est encore plus bluffant

c'est clair! je viens de voir et ça, et ça m'a bien plus emerveillé que les images

Hello,

je suis le developpeur de SPARK.
Merci tmyke pour la promo ! Je ne boude pas la communauté francophone d'Irrlicht mais je n'ai pas pris le temps de faire des annonces partout. En plus n'étant pas d'Irrlicht, je ne connais pas tous les sites communautaire pour Irrlicht.

Sinon pour en revenir au CPU/GPU. En fait quand je dis que le moteur est CPU, je parle du calcul des particules, de leur update, bref de la partie core du moteur. Ca permet beaucoup plus de modularité/flexibilité que si le moteur était full GPU (au dépend des perf).

Apres les modules de rendu peuvent utiliser la puissance de calcul parallèle des GPU ou optimiser la charge du bus en limitant le transfert. Par exemple il est possible d'utiliser les VBO avec le module Irrlicht (le gain est cependant notable uniquement pour les gros systèmes). Je compte aussi intégrer les géometry shader dans le module OpenGL pour déporter un peu de calcul coté GPU et éliminer les buffers coté CPU, donc un gros gain en perf en perspective.

Le truc c'est que je developpe la lib dans un soucis de support maximal, donc le calcul GPU doit rester optionel pour garder une bonne compatibilité même sur les petites configs.

Voila, a part ca, le moteur est en open source et tout le monde est invité a venir contribuer si interessé. Le moteur etant tout jeune, il reste plein de trucs a implementer et comme je n'ai pas forcément le temps de tout faire, si vous etes motivé pour contribuer, n'hésitez pas !

Merci pour ces précisions Juff. C'est toujours intéressant de les avoir du créateur même du projet.

Irrlicht à besoin de ce genre d'avancée, même si effectivement ton moteur est à la base générique.
Nous suivrons de très près ton projet, par exemple à titre plus personnel, je pense l'intégrer
au sein de N3xtD d'ici peu, ce qui me permettra de le tester vraiment, de le malmener aussi, et
donc de te faire remonter d'éventuel retour d'expérience et d'éventuel(s) bug(s).

Juff :

Le truc c'est que je developpe la lib dans un soucis de support maximal

C'est tout à ton honneur. Mais une possibilité de passer tout GPU serait vraiment mieu. D'autant plus qu'aujourd'hui, même les GPU à mémoire partagée de base acceptent les shaders.
En tout cas merci et n'oublie pas de proposer une integration dans le futur SDK

Merci pour ton commentaire.

Tu dis qu'un moteur de particule full GPU serait vraiment mieux mais je n'en suis pas si convaincu que çà. Oui un moteur de particules full GPU se débarasse de la necessité de faire transiter les infos sur le bus qui peut rapidement devenir un goulot d'étraglement et en plus permet d'utiliser la puissance de calcul parallèle pour l'update donc permet un gros gain en performance, mais a quel prix ? Au prix d'une complexité de developpement accrue et d'une perte de flexibilité et de controle par l'utilisateur. Faire du GPGPU uniquement a base de shader c'est vraiment pas evident et le faire de facon générique est encore plus complexe. Alors oui apres il y CUDA qui va faciliter un peu le truc mais dans ce cas ca limite vraiment son utilisation aux GPU haut de gamme.

Tu n'es pas le premier a me dire qu'un moteur full GPU serait bien mieux parceque ca va permettre de gérer facilement un million de particules en temps réel mais concretement est ce qu'on a besoin de ca ? Un gros budget de particules pour un jeu temps réel sera au pire quelque milliers de particules simultanément. Et dans ce cas le CPU le gere sans probleme. le full GPU c'est très bien dans les domaine de la recherche pour faire du calcul très avancé du style simulation physique de pointe mais pour gérer des effets de particules temps réel dans un jeu, le CPU est toujours préféré même actuellement car ca permet d'avoir un moteur facile d'utilisation, très flexible et générique. Le truc après c'est de séparer la charge : déporter certains calcul coté GPU peut être avantageux voir obligatoire pour gérer certains effets (orientation en vertex shaders, génération des primitive avec un geometry shader, post process avec du pixel shader...). Tout çà je prévois de le faire avec SPARK à terme mais passer le tout en full GPU ca rendrait seulement le truc trop spécifique. En gros ce serait très puissant pour une utilisation précise. Je préfère perdre en perf et permettre une multitude d'utilisation possible.

C'est un peu ce que je voulais te dire, juste qu'on ai le choix pour les possésseurs de CG récentes (pas forcément de combat). En tout cas les moteurs quasi FullShader sont bien plus performants et surtout stables en FPS.

Merci pour les explications Juff, je comprend tout à fait les choix que tu à fait pour ton moteur, et il parait normal que l'utilisation des gpu ne soit pas une priorité, donc bravo pour ton boulot.

Juff :

.....ca va permettre de gérer facilement un million de particules en temps réel mais concretement est ce qu'on a besoin de ca ?...

"Besoin", pas forcement, mais je pense que malgrès tous les progrès technologiques à venir, on aura jamais assez de puissance pour reproduire toutes les caractéristiques du monde réels.
Donc il est clair que tout progrès est le bien venu.
Cela dit, je ne remet pas en cause ton choix de la portabilité, comme l'a dit tupac, "c'est tout à ton honneur".

Pour ceux qui aiment cette librairie... Je développe actuellement un éditeur de particules utilisant SPARK, qui sera probablement intégré a SPARK (fallait bien que je fasse qqchose après avoir développé le module Irrlicht avec Juff^^). Plus de news ici: http://spark.forum0.net/evolution-fr-f4 … ev-t26.htm

Impec, cet éditeur donnera une vraie dimension à cette lib, je vais tester cela de suite

Bon, je reviens donc de tester la version actuelle disponibe de l'éditeur. Pour être franc j'ai pas compris grand chose dans son utilisation.
Je pense que certaines fonctionnalités ne sont pas implantées, mais pour le moment j'ai pas vraiment saisi l'approche...

En effet, ca n'en est qu'au tout début, donc c'est normal que ca soit inutilisable^^
Normalement, ca respectera l'approche SPARK (modèles, zones, emetteurs, groupes, sustèmes, etc...)

Petite news : SPARK à pas mal évoluée, maintenant, la version 2.0 est en préparation, et à pas mal changé. Un autre éditeur à aussi été commencé (pas par moi par contre), ce qui fera 2 éditeur pour SPARK. Chaque éditeur à sa philosophie propre.
Un renderer DirectX (API utilisée directement) est présent, et son auteur essaye maintenant de faire un renderer DX10/11 full GPU.

Je vous encourage à aller voir tout ca sur le site officiel ou le forum.

Petite node: il n'y aura que des bugfixes pour la version 1. Je vous conseille vivement d'utiliser la version SVN plutôt que les packs, car ceux ci ne sont plus à jour.

vraiment bien, j'adore les explosions, très très réussie, vraiment bon boulot.
merci pour l'info

Une autre news: la dernière version est la 1.5.3 (aussi avancée que le svn), la 2 est très avancée et continue sur son rythme. SPARK est déjà utilisée dans un projet professionnel (utilisant Irrlicht, il s'agit d'un jeu en 2d de Enki Games)


Pour 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.

Un recrutement est ouvert pour faire les icones de la gui de l'éditeur, ici: http://www.developpez.net/forums/d96441 … le-editor/

Enjoy!

Cool ça commence à devenir sérieux comme projet, n'hésitez pas à poster dans les sections "projets" , "recrutement" ou encore "graphisme" , afin de mieux cibler les utilisateurs
Bonne continuation

Merci !