|
| Module Irrlicht en développement | |
| | |
Author | Message |
---|
Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Module Irrlicht en développement Mon Jul 20, 2009 3:46 pm | |
| Darktib a proposé de réaliser un module SPARK pour Irrlicht. Ca peut interesser du monde puisque les systèmes de particules de base d'Irrlicht sont assez limités (Les data des particules étant fixe et sont composé de peu de paramètres) Un premier essai est disponible en téléchargement ici. Il s'agit de la démo basique portée rapidement sur Irrlicht. | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Thu Jul 23, 2009 3:32 pm | |
| Ca avance bien, j'en suis au point renderer, et j'en suis à a peu près 100 à 200 fps de plus que la démo. Pas en fullscreen, je reconnais^^ C'est ici: http://www.mediafire.com/download.php?chzfhy3tn4mTouches: Fleches, et Espace pour mettre en pause. Alt gele l'application. Y a un problème avec la caméra, je vais essayer de résoudre ca le plus vite possible. | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Thu Jul 23, 2009 4:42 pm | |
| Cool ! En effet c'est déja beaucoup plus optimisé que le premier essai ! 3/4 petites remarques (ce sont des détails) :
- Il y a beaucoup de particules qui sont spawnée a la première frame. Du coup le système finit par atteindre sa capacité max en particules (2100) et l'emetteur ne génére plus rien pendant un temps. Ca m'a permis de me rendre compte d'un bug dans les demos, les particules spawné a la première frame n'ont pas de couleur car j'update la couleur après les particules dans la boucle principale.
- Il y a en effet un effet bizarre lorsqu'on se rapproche du système (ca doit etre le bug de camera dont tu parles). On dirais que c'est plus ou moins lié au culling avec le near plane.
- Quand on met en pause avec espace, les particules continue a se déplacer très légèrement. C est bizarre, c est au niveau du renderer ca ?
- Quand on met en pause avec alt, le temps de la frame continue a s'incrémenter, du coup quand on enleve la pause apres un moment, les particules sont partie a perpet et l'emetteur en génère la dose d'un coup.
En tout cas, c'est bien cool, ca avance bien ! bravo | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Fri Jul 24, 2009 4:14 pm | |
| Merci ! Sinon: 1/ Oui, je pourrais changer dès que j'y pense. 2/ Ca vient apparement du mode de rendu en points, je vais voir s'il n'est pas possible d'optimiser ca (et oui ca à un rapport avec le near plane) 3/ J'ai remarqué ca aussi, mais il me semble que je n'ai plus ce bug, enfin, ca doit etre des problèmes de précision float. Faudra tester sur un amd, les proco Intel ont un vieux défaut de fabrication qui enlève une partie de la précision que pour certaines valeurs. En tout cas, apparemment ca ne dépend pas du renderer. 4/ En fait la touche Alt met en pause tout le programme, c'est pas moi qui l'ai codé ^^ (ca doit etre inclus dans Irrlicht, faudra que je vois ca de plus près, mais pour l'instant ca m'aide pour certains tests. edit: J'ai crée les buffers Irrlicht, et les aient utilisés pour le rendu par points. Au passage, je change de méthode : le rendu par point ne pourra plus etre stocké en mémoire graphique comme les VBOs (d'autant plus que les vbos ne servent à rien ici). Le fps-meter grimpe encore, chez moi je passe d'environ 870 fps à 930 fps environ (cette fois ci en utilisant les buffers des groupes). J'ai commencé le rendu par lignes, mais j'ai la flemme de chercher la 'formule' pour les lignes: le premier point qui compose une ligne est particule.position(), le second dépend de la vélocité, j'ai essayé 'particule.position()-particule.velocité() mais ca donne un truc qui ressemble à un plat de spaghettis... Enfin, voila la démo (F4 pour changer de mode de rendu, rien/point/ligne): http://www.mediafire.com/download.php?vayzyzwmfgdPeut tu me donner le fps stp ? PS: deux-trois petites idées pour l'aide : télécharge le HTML Help Workshop de Microsoft (gratuit) (je me souviens pas vraiment du nom) et compile l'aide en chm, c'est beaucoup plus pratique à utiliser. Comme options à demander à Doxygen: générer les fichiers projets pour l'outil sus-nommé, trier les fonctions par ordre alphabétique, ne pas réafficher les fonctions héritées, et autoriser l'aperçu du code source des headers (un peu comme la doc d'irrlicht). | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Sun Jul 26, 2009 1:08 pm | |
| ca plante chez moi (le programme a cessé de fontionner). Sinon pour les lignes, tu peux reutiliser la formule du renderer de ligne opengl :
- position
- position + velocite * length
Avec length etant un parametre setté par l utilisateur Pour les VBO ca n 'a en effet que peu d interet comme le modele est integralement updaté a chaque frame. J avais essayé de les implémenter il y a quelques temps mais le gain en perf était negligeable (voir pire il me semble), du coup j'ai laissé tomber. Pour la doc, les chm c est bien mais c'est windows only. Concernant les options de doxygen, ok pour l ordre alphabétique et l'affichage des headers mais moi je préfère quand les méthodes héritées sont affichées, ca permet d'avoir l'interface complete de la classe directement. | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Mon Jul 27, 2009 4:40 am | |
| Merci pour la formule. - Juff wrote:
- ca plante chez moi (le programme a cessé de fontionner).
Comment ca plante ? Je veut dire : c'est le rendu par point qui plante ? celui par lignes ? D'après ton erreur tu est sous vista, et c'est une segfault... edit: Jeviens de le retélécharger pour voir si ca ne viens pas du zip, mais tout fonctionne chez moi - par contre je n'ai pas encore testé sous Vista. Pourra tu me dire ce qui est écrit dans la console au moment du crash ? | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Mon Jul 27, 2009 8:53 am | |
| La console m'ecrit bien tout ce qu'il faut : le dernier truc ecrit est "nvd3dum.dll 8.15.11.8603"
J'ai en effet vista. Je vais checker si ca fonctionne avec mon PC du taf qui est sous XP. Je te tiens au courant | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Mon Jul 27, 2009 9:49 am | |
| Bon j ai checke au taf sous xp et ca fonctionne. Voila les fps que j ai :
- point : 1720
- lignes : 660
- rien : 1870
Sinon en effet le rendu des lignes ne rend pas terrible. C est parcequ elle sont bien trops longues. Essaie avec un facteur de 0.1 sur le velocite, ca rendra deja mieux. En fait le facteur que tu doit mettre depend de l echelle du systeme et aussi de ce que l utilisateur veut obtenir d ou un facteur parametrable. Et en plus ca permet de specifier le sens. Ce soir je testerai les versions precedentes sur mon pc avec vista voir si ca passe. Mais il me semble que je l'avais fait et que ca planté pas avant. Enfin je te confirme ca. | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Mon Jul 27, 2009 10:57 am | |
| J'utilise la bonne formule maintenant et ca rend beaucoup mieux. En fait, dans la démo, c'est position - vélocité, et pas plus, donc c'est pour ca que ca rend mal. En tout cas, c'est vrai que les lignes sont trop longues, je vais mettre le paramètre longueur à 0.1 par défaut. | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Mon Jul 27, 2009 6:20 pm | |
| Salut,
j'ai rechecké chez moi sous Vista et je confirme que les demos 1 et 2 fonctionnent mais la 3 plante. | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Thu Jul 30, 2009 3:52 am | |
| Bizarre ca, que sous vista. Bon, je vais essayer ce soir de tester sous vista avec gdb.
Sinon : le rendu par lignes tout comme celui par points, est terminé. J'attaque celui par quads, pour l'instant je suis dans la partie math pour déterminer lesdits quads.
Edit: une question sur les buffers dans les groupes : quand le groupe est supprimé, les buffers doivent etre supprimés. Mais comme ils ont été crées par un BufferCreator, pourquoi ne pas utiliser un BufferErasor ? Car pour les IrrBuffer, étant donné que les indices ne changent jamais, il est possible de les mettre en mémoire graphique, et à la suppression du buffer il faudrait que cette mémoire soit nettoyée.
edit2: j'ai testé sous Vista, ca plante, et impossible de récupérer des infos lisibles (et l'exe est une version debug). Autrement dit, soit ca vient d'Irrlicht.dll, soit de SPARK.dll, et je penche plus pour Irrlicht (vu que j'ai changé de version, de la 1.5 à la 1.6). Je vais essayer d'utiliser des versions debug de SPARK et d'Irrlicht. | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Thu Jul 30, 2009 10:06 am | |
| Pour les quads, il va y a voir pas mal de formules dans GLQuadRenderer pour l'orientation. Concernant le rendu par point ? As tu implémenté la gestion des POINT_SPRITE ? Il me semble que Irrlicht les gèrent et c'est très utilisé pour les particules puisque ca permet de texturer des points a faible coût.
Concernant les buffers, en fait le BufferCreator n'existe que parcequ'il est necessaire : Il permet d'envoyé du state au groupe pour lui permettre de créer correctement son buffer. Par exemple dans le cas du FloatBuffer, le FloatBufferCreator contient simplement le nombre de float necessaire par particule dans le futur buffer.
Pour ce qui est de la destruction des buffers, c doit être géré dans le destructeur du buffer tout simplement. Si tu as besoin de state pour la destruction, pourquoi ne pas simplement l'encapsuler directement dans la classe buffer ?
En fait j'aimerai éviter de trop multiplier les classes et de créer une nouvelle classe uniquement quand necessaire. (Déja si j'avais pu faire sans BufferCreator ca aurait été mieux.)
Finalement j'ai une question concernant les indices de vertex : Les buffers d'irrlicht t'oblige a en avoir ? Parcequ'il servent a rien vu que ce sera uniquement une liste ordonnée 0,1,2,3... En fait ca bouffe juste de la ménoire : disons sizeof(short) * nb de vertices par particules * capacité du groupe, ce qui fait plus de 300ko pour 10000 quads | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Thu Jul 30, 2009 3:01 pm | |
| Pour les quads les indices sont nécessaires, vu qu'en fait les quads je les génèrent avec des simples polys (2 polys par quad). Pour les lignes, ils sont nécessaires aussi, mais ils ne servent à rien. Et malheureusement, c'est l'API qui le demande... Pour les points, je triche à mort, et je lui passe un seul indice (qui fait 2 octets) et ca lui va, donc ca ne prend pas de mémoire. Avec les quads, les indices ressemblent à: 0+n,2+n,1+n , 2+n,3+n,1+n avec n le numéro du quad, c'est à dire en taille mémoire: 6*nbParticules*2(octets) Il est impossible d'affiche 10 000 quads d'un coup avec l'implémentation telle qu'elle est. En effet, la taille d'un indice est de 2 octets, donc au max 65535 index, alors qu'avec 10 000 quads tu as 120 000 indices... Il est possible d'avoir des indices en 32bits, mais ca n'est pas supporté par toutes les cartes graphiques.
Ok pour la destruction du buffer, je vais ca dès que possible.
Sinon, j'ai pas encore pu tester avec une version debug d'irrlicht sur Vista, et comme j'étais sous xp et sur l'ordi de prog', j'en ai profité pour implémenter les quads. J'ai le meme rendu que la démo basique, mais à 160 fps au lieu de 450. Apparement il existe encore quelques bugs dans le mesh buffer généré, car lorque j'essaie d'utiliser une fonction que je pense plus rapide et surtout plus appropriée pour des polys standards, ca plante (DX n'arrive pas à afficher le buffer, j'ai pas testé avec OGL).
Il me semble qu'avec les points sprite tu ne peux pas les tourner ni changer les coordonnées uv ? Je pense l'implémenter en plus, comme renderer de quads optimisé, mais ca dépendra de ta réponse^^ (Si oui, peut tu m'expliquer comment ?) Autre question : pour les angles, tu utilises degrés ou les radians ? (d'ailleurs je pense que dans la doc tu peux le préciser ainsi que tu utilise des couleurs entre 0 et 1). | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Thu Jul 30, 2009 9:59 pm | |
| Salut,
Tu utilises 2 triangles pour générer tes quads alors. La primitive QUADS n'existe pas dans Irrlicht ? Avec ca il n'y aurai plus besoin de tableau d indices puisqu il n'y aurait plus aucun sommets de partagé. Enfin si c'est pas possible de faire sans indices de toutes facon ca ne change pas grand chose. Vu d'ici Irrlicht me semble pas super flexible niveau format des données (du moins des qu on rentre dans le bas niveau d'Irrlicht)
La limitation de 10000 particules, c'est dommage tout de meme. Il y a sans doute moyen de setter le format des indices en fonction de la capacité du groupe.
Pour le bug c'est possible aussi que ca vienne de mon coté puisque tu as également changé de version de SPARK entre les démos. Maintenant je ne vois pas pourquoi ca planterai uniquement sous Vista. Enfin je regarderai.
Concernant les point sprites, il ne peuvent en effet pas être tourné. Concernant les coordonnées de texture, je crois qu'il est possible de les changer mais c'est via une extension supplémentaire en openGL il me semble. En Direct3D, je ne sais pas. Pareil je me renseignerai. Pour l'implémentation des point sprites, en openGL je l'ai fait dans le rendereur de point (puisque les point sprite sont des points en openGL).
Sinon oui les angles sont interprété en radians dans le module openGL et SFML. C'est du au fait que les fonctions trigo de la STL prennent des radians, ca fait de l'overhead en moins du coup. Après c'est a l'utilisateur de convertir, s'il veut des degrés. Mais c'est vrai que les degrés sont en rêgle général plus agréable a utiliser (Pas besoin d'avoir des PI partout). | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Fri Jul 31, 2009 11:47 am | |
| Si, la primitive quad existe bien, mais j'ai quand meme besoin d'indices. Le problème, c'est que DirectX les demandent (au moins, et il me semble qu'OpenGL aussi, mais je suis pas sur). Aucun sommet n'est partagé, sinon il y aurait des artefacts. Pour la limitation, je peut demander à Irrlicht d'utiliser du 32 bits, en 2 minutes c'est fait. Après, ca dépend des cartes graphiques. Ou alors, je peut créer plusieurs buffers avec chacun des indices en 16 bits... Mais je mettrais une option pour choisir le type d'indices. Sachant que le rendu par point n'est pas limité. Pour les quads, les fonctions sinus et cosinus sont lentes : maintenant je fais 2x moins d'appels à ces fonctions, et en plus j'ai codé mes propres fonctions de sinus et de cosinus, qui sont beaucoup plus rapide (car j'utilise une approximation qui n'utilise que des carrés). Du coup je passe de 160 fps à 405 fps, en plein écran, en 640x480 (d'ailleurs, quelle est la résolution des démos ?) Je peux encore optimiser je pense, en effet j'utilise une fonction qui calcule pas mal d'intersections entre plans pour déterminer une base vectorielle pour la creation des quads, peut etre en essayant de supprimer le plus de calculs d'intersections, et en regardant si la caméra à bougée entre chaque calcul de base vectorielle. Ok pour les radians, par défaut mes fonctions sont en degrés, je vais changer ca. En tout cas, ca donne ca (screen pas a jour faut remplacer le fps par 405^^): Et pour comparatif, la démo basique tourne à 500 fps chez moi pour le rendu 'normal'. | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Fri Jul 31, 2009 12:10 pm | |
| Cool, ca ressemble bien a la demo maintenant, sauf le blending qui doit etre additif (la tu as un blending alpha il me semble)
La resolution des demos est celle du systeme d exploitation.
Concernant tes fonctions d approximation de cosinus et sinus, ca m interesse pas mal de voir a quoi ca ressemble. Je pourrai sans doute les integrer au core de SPARK si l approx est assez precise et le gain consequent. Je pourrai de coup aussi en profiter pour passer l interface publique en degre. J ai fairt pareil avec la fonction rand en codant ma propre fonction plus optimisé (et aussi plus precise et plus uniforme) ,j avais pensé le faire pour la trigo mais j ai pas eu le temps. Si les tiennes sont bien, ca pourrait faire gagner un peu partout (le rendu et la gestion de la physique interne).
Sinon concernant le format des indices, il y a moyen de le masquer a l utilisateur en choississant directement a la creation du buffer le format le plus optimise. Il suffit pour cela de checker la capacité en particules du groupe dans lequel est créé le buffer et de regarder le nombre mazimum d indice induit. En fonction de ce nombre on set le bon format car on est sur que ce nombre ne pourra pas etre depassé (en cas de realloc d un group (qui ne peut se faire que par un appel utilisateur), les buffer sont recréés).
Une petite note au niveau du check des performance : dans la majorité des système le goulot d etraglement est le fillrate. Pour vraiment checker les perfs, utilise des quads tres petits. | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Fri Jul 31, 2009 1:06 pm | |
| Ce qui est très bien, c'est que la valeur pour les quads est de 0.05 et rend exactement pareil que le renderer OGL, mais avec une méthode différente^^. Pour les approximations: - Code:
-
inline float f_cos(float v) { static float inv90 = 1.0f/90.0f; static float inv180 = 1.0f/180.0f;
int numClass = (v + f_sign(v) * 90.0f) * inv180; float x = (v * inv90 - (float)numClass * 2); if(numClass & 1) return x * x - 1; else return 1 - x * x; } Avec f_sign la fonction signe (|x|/x) et f_abs la fonction valeur absolue. Pour le sin : f_sin = f_cos(x-90) Si tu trace un graphe comparatif, les deux fonctions sont très proches, et la différence maximum entre les deux est d'environ 0.05 . Il y a mieux niveau approximation, mais la rapidité est la (et de toute facon, on va pas raler si un quad est 1 ou 2 degrés trop à droite ou a gauche ) Sinon, j'essaie de résoudre le bug sous Vista, le problème c'est que Code::Blocks plante dès que je veux changer de compilo (enfin, juste afficher les options pour en changer), et il ne trouve pas gdb, le débuggeur. Ah... Vivement mon Visual Studio^^ Je vais voir si je peux utiliser VC express sur l'ordi vista, mais ca m'obligerais à tout recompiler (Irrlicht y compris, avec le sdk directx). Ou alors utiliser gdb manuellement. edit: la fonction 'compilation' étant la seule qui fonctionnait, j'ai tracé le code avec des printfs... comme quoi... En fait, le bug semble venir des indices : sous xp, je peut tricher en ne passant qu'un indice. Sous Vista, ca plante... Le rendu par lignes et par quads fonctionne sous vista. Je vais voir aussi si ca vient de DX 10 ou du système (je penche pour dx) edit2: bingo, ca vient de dx10 du wrapper de dx9. Je vais donc changer le tout pour que ca fonctionne correctement avec. C'est fait, tout marche maintenant. Voici l'archive: http://www.mediafire.com/download.php?jmddalwemyeToujours pareil, F4 pour changer de mode de rendu, Alt+F4 pour quitter, souris et fleches pour la caméra. Sinon j'ai dit n'importe quoi pour la limite de particules : en fait on est limité a 65536 particules avec le renderer point, 32768 particules avec le renderer lignes, 16384 avec le renderer quad, le tout avec des indices 16bits. J'en suis actuellement à 415-425 fps, j'ai du mal à optimiser plus... Je vais essayer de faire un renderer point_sprite. Actuellement, voici les paramètres supportés par les différents renderers: -Point: RED,GREEN,BLUE,ALPHA -Ligne: RED,GREEN,BLUE,ALPHA -Quad: RED,GREEN,BLUE,ALPHA,ANGLE,SIZE, et bientot TEXTURE_INDEX dernier edit: je vais essayer de mettre un module pour choisir si on met du 32bit ou non. Avec le 32 bits, la limite est d'environ 1 milliard de particules... | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Sat Aug 01, 2009 12:48 pm | |
| Salut, j'ai regardé ta fonction trigo, elle est en effet plus rapide mais l'approximation est pas terrible. (0.056 ca fait au pire entre 3 et 4 degrés) Déjà, j'ai changé cette ligne : - Code:
-
int numClass = (v + (abs(v)/v) * 90.0f) * inv180; en - Code:
-
int numClass = (v + (v > 0 ? 90.0f : -90.0f)) * inv180; Il y a une division en moins et surtout ca rêgle la valeur indeterminé de v = 0 Ensuite j'ai fait un petit bench en comparant ta fonction avec des approximation par LUT et j'obtiens : - Code:
-
fast cos is 50% faster than std cos lut cos is 108% faster than std cos lut2 cos is 76% faster than std cos
fast cos : avg error=0.0104858 - max error=0.0560169 lut cos : avg error=0.00292838 - max error=0.0174548 lut2 cos : avg error=3.61282e-005 - max error=0.000186011 On voit clairement que ta fonction est moins rapide que des LUT et moins précise. Bon avec ta fonction, il n'y a ni besoin d'initialisation ni de mémoire (contrairement au LUT) mais ca ne vaut pas le coup je pense. lut cos est avec 360 valeurs donc l initialisation est instantannée et la mémoire négligeable (1.5ko) . lut2 cos est avec une LUT de 36000 valeurs et la on voit qu'on atteint une très bonne précision pour de meilleurs performance que ta fonction. J ai fait les tests avec 100 millions de valeurs sur une plage de -10000 a 10000 pour l'angle. Les fonctions ne sont pas inliné car c'est une mauvaise pratique que d inliner des fonctions de cette taille. SI tu veux le code, dis le moi. Sinon pour en revenir au module Irrlicht, sur mon PC avec Vista, la démo ne plante plus mais le rendu par point n'est pas correct (il n'y en a que quelques uns qui s'affichent en fonction de la caméra. En fait, je ne vois pas exactement ce que tu fais comme opti sur les points pour ne passer qu'un indice. Es tu sur que cette opti est une bonne pratique qui est safe ? Dans un premier temps je pense qu'il ne faut pas optimisé plus que de raison mais plutot se concentrer sur les fonctionnalité et la robustesse du code. Est ce que je pourrais voir un peu ce que donne le code ? | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Sat Aug 01, 2009 4:26 pm | |
| Je poste une partie du code demain. Sinon pour les point il ne faut qu'un seul indice, ce que j'utilisais avant etait de ne passer qu'un indice pour tout le buffer (au lieu de nbParticles indices). Si il y a des problèmes sur Vista avec des points, je n'y peut rien, vu qu'en théorie les buffers sont correctement générés.
Sinon pour l'approximation de cos: OK je change la ligne, ca sera sans doute plus rapide. Sinon la différence entre LUT et fast_cos, c'est que fast_cos utilise une approximation continue, tandis que LUT est de manière discrète. Certe, il y a plus de précision avec LUT, mais si on trace la courbe et qu'on zoome beaucoup, elle sera crénelée. Peut etre qu'en modifiant un peu le polynome on pourrait avoir de meilleurs approximations. De toute facon, l'écart max n'est quasiment pas visible par l'utilisateur.
Sinon, puis-je voir le code utilisé pour le test ?
Enfin, voici comment se présente le renderer: Il n'y a qu'une classe visible, appellée IrrRenderer. Cette classe fait tout en fonction du type de rendu : point, ligne, etc... Pas besoin de créer plusieurs classes pour plusieurs renderer. Evidemment, toutes les fonctions sont présentes dans cette classe. Par exemple, appeler setLength() ne fera que changer la longueur des lignes à dessiner. Si le mode de rendu n'est pas par lignes, rien de spécial, mais les modifications sont enregistrées. Puis, si on change de mode de rendu vers celui par ligne, on verra des lignes ayant la bonne longueur, c'est à dire celle spécifiée plus tot.
Pour changer de mode de rendu: renderer->setRenderMode(mode_de_rendu).
Pas de problème niveau implémentation, il s'agit de plusieurs classes cachées à l'utilisateur, et qui ont une interface ressemblant beaucoup à celle des renderer.
Sinon j'ai pas encore codé le système. | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Sun Aug 02, 2009 12:56 pm | |
| Salut, ok pour l'approximation discrete d'une LUT mais si on veut un truc continue, il suffit d'utiliser une interpolation linéaire entre 2 valeurs dans la LUT plutot que de prendre uniquement la valeur la plus proche. Ce sera un petit peu plus lent mais toujours beaucoup plus rapide et plus précis. Sinon le code du bench est la | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Sun Aug 02, 2009 2:28 pm | |
| Pour l'instant, je garde le fast_cos, je verrais si je le change, mais ma priorité est de finir le renderer et le système. Pour les news : j'ai réussi à optimiser, du coup le cosinus n'est utilisé qu'en cas de besoin, comme pour la plupart des paramètres. Du coup, sans angle et sans index de texture, j'arrive à 510 fps. Sinon maintenant les quads supportent les index de texture parfaitement, j'ai fait un petit test en utilisant la texture avec toutes les voitures, sans aucune erreur. Demain, je ferais le gros de la gestion des indices 16 ou 32 bits. Sinon, voici le fichier main.cpp, histoire de montrer comment le renderer s'utilise (a noter que tout le renderer n'est pas inclu dans spark pour l'instant): - Code:
-
#include <irrlicht.h> #include <SPK.h> #include <ctime> #include "SPARK\final\SPK_IRR_Renderer.h" #include "SPARK\final\imp_QuadFinder.h" using namespace irr; // Calls back function to have particle bounce on the floor bool bounceOnFloor(SPK::Particle& particle,float deltaTime) { if (particle.position().y < 0.015f) { particle.position().y = 0.015f; particle.velocity().y = -particle.velocity().y * 0.6f; } return false; } bool paused = false; SPK::IRR::IrrRenderer* renderer = 0; class MyEventReceiver : public irr::IEventReceiver { public: virtual bool OnEvent(const irr::SEvent& event) { if(event.EventType == irr::EET_KEY_INPUT_EVENT) { if(event.KeyInput.Key == irr::KEY_SPACE && event.KeyInput.PressedDown == false) { paused = !paused; return true; } if(event.KeyInput.Key == irr::KEY_F4 && event.KeyInput.PressedDown == false) { static int last=1; last++; if(last>3) last=0; if(renderer) renderer->setRenderMode((SPK::IRR::E_IRRSPK_RENDERMODE)last); return true; } } return false; } }; int main(int argc, char** argv) { //!IRRLICHT IrrlichtDevice *device = createDevice(video::EDT_DIRECT3D9, core::dimension2d<u32>(640, 480), 32, false,false,false,new MyEventReceiver); video::IVideoDriver* driver = device->getVideoDriver(); scene::ISceneManager* smgr = device->getSceneManager(); gui::IGUIEnvironment* guienv = device->getGUIEnvironment(); device->setWindowCaption(L"SPARK using Irrlicht"); irr::scene::ICameraSceneNode* cam = smgr->addCameraSceneNodeFPS(smgr->getRootSceneNode(),100.0f,0.0005f); cam->setPosition(irr::core::vector3df(1.5f,1.5f,1.5f)); cam->setTarget(irr::core::vector3df(0.0f,0.015f,0.0f)); cam->setNearValue(0.05f); //!SPARK SPK::randomSeed = static_cast<unsigned int>(time(NULL)); // importé depuis BasicDemo.cpp // Inits Particle Engine SPK::Vector3D gravity(0.0f,-0.8f,0.0f); // Renderer renderer = new SPK::IRR::IrrRenderer(device); renderer->setTexture(driver->getTexture("media\\point.bmp")); // System SPK::System particleSystem; // Model SPK::Model particleModel(SPK::FLAG_RED | SPK::FLAG_GREEN | SPK::FLAG_BLUE | SPK::FLAG_ALPHA); particleModel.setParam(SPK::PARAM_ALPHA,0.8f); // constant alpha particleModel.setLifeTime(8.0f,8.0f); // Emitter SPK::Point point(SPK::Vector3D(0.0f,0.015f,0.0f)); SPK::SphericEmitter particleEmitter(SPK::Vector3D(0.0f,1.0f,0.0f),0.1f * irr::core::PI,0.1f * irr::core::PI); particleEmitter.setZone(&point); particleEmitter.setFlow(250); particleEmitter.setForce(1.5f,1.5f); // Group SPK::Group particleGroup(&particleModel,2100); particleGroup.addEmitter(&particleEmitter); particleGroup.setRenderer(renderer); particleGroup.setCustomUpdate(&bounceOnFloor); particleGroup.setGravity(gravity); /* // Emitter 2 SPK::Point point2(SPK::Vector3D(0.0f,2.0f,0.0f)); SPK::SphericEmitter particleEmitter2(SPK::Vector3D(1.0f,1.0f,1.0f),0.1f * irr::core::PI,0.1f * irr::core::PI); particleEmitter2.setZone(&point2); particleEmitter2.setFlow(250); particleEmitter2.setForce(1.5f,1.5f); // Group 2 SPK::Group particleGroup2(&particleModel,2100); particleGroup2.addEmitter(&particleEmitter2); particleGroup2.setRenderer(renderer); particleGroup2.setCustomUpdate(&bounceOnFloor); particleGroup2.setGravity(gravity);*/ particleSystem.addGroup(&particleGroup); http://particleSystem.addGroup(&particleGroup2); //!BOUCLE float time=(irr::f32)device->getTimer()->getTime() / 1000.0f,oldtime,deltaT; float step=0.0f; while(device->run()) { oldtime = time; time = (irr::f32)device->getTimer()->getTime() / 1000.0f; deltaT = time - oldtime; driver->beginScene(true, true, irr::video::SColor(0,0,0,0)); // Changes the color of the model over time step += deltaT; http://particleModel.setParam(SPK::PARAM_RED,0.6f + 0.4f * sin(step)); http://particleModel.setParam(SPK::PARAM_GREEN,0.6f + 0.4f * sin(step + irr::core::PI * 2.0f / 3.0f)); http://particleModel.setParam(SPK::PARAM_BLUE,0.6f + 0.4f * sin(step + irr::core::PI * 4.0f / 3.0f)); // Updates particle system if(!paused) particleSystem.update(deltaT); // 1 defined as a second // render particles smgr->drawAll(); particleSystem.render(); // infos irr::core::stringw infos; infos+="FPS: "; infos+=driver->getFPS(); infos+=" - Nb Particles: "; infos+=particleSystem.getNbParticles(); guienv->getBuiltInFont()->draw(infos.c_str(),irr::core::rect<irr::s32>(0,0,170,20),irr::video::SColor(255,255,255,255)); driver->endScene(); } particleGroup.setRenderer(0); delete renderer; device->drop(); return 0; } Ensuite, voici l'interface des renderer. J'ai commencé la doc, mais elle est a finir (je doit en etre à environ 8%) - Code:
-
#ifndef _SPARK_IRRLICHT_RENDERER_ #define _SPARK_IRRLICHT_RENDERER_
#include <irrlicht.h> #include <SPK.h> #include "SPK_IRR_Defs.h"
namespace SPK { namespace IRR { class ImpIrrRenderer;
//! A renderer using Irrlicht /** This renderer allow you to use several renderers easily with Irrlicht. You can switch between render mode simply by calling setRenderMode(). Each rendermode will be described here: * First, there is a point renderer. Each particle is rendered as a point, and you can change the size for a point. Don't forget that the default size is about 1 px, therefore some people might see this points hardly... This is a simple renderer, mainly designed for debugging purposes. However this renderer has been optimized for speed and is the fastest render mode of this renderer. Be aware that changing point size affect the fps heavily if the fill rate of your graphic card is average. * You can also use a line renderer. **/ class IrrRenderer : public Renderer { SPK_IMPLEMENT_REGISTERABLE(IrrRenderer)
public: //! Constructor IrrRenderer(irr::IrrlichtDevice* d);
//! Destructor ~IrrRenderer();
// QUADS //! Set the texture to apply on quads or to use as atlas //CONVENIENCE FUNCTION virtual void setTexture(irr::video::ITexture* tex);
//! Get the texture applied on quads (or used as atlas) //CONVENIENCE FUNCTION virtual irr::video::ITexture* getTexture() const;
//! Set atlas dimensions virtual void setAtlasDimension(unsigned int dimX, unsigned int dimY); virtual void setAtlasDimension(irr::core::dimension2d<irr::u32> dim);
//! Get atlas dimensions virtual irr::core::dimension2d<irr::u32> getAtlasDimension() const;
// QUAD AND OBJECT //! Set quads or objects orientation virtual void setOrientation(E_IRRSPK_ORIENTATION o);
//! Get quads or objects orientation virtual E_IRRSPK_ORIENTATION getOrientation() const;
// QUAD, OBJECTS, POINTS AND LINES //! Set scale (for non 3D : thickness) virtual void setScale(float s);
//! Get scale (for non 3D : thickness) virtual float getScale() const;
//! Get the material virtual irr::video::SMaterial& getMaterial();
//! Update material (must call this after a modification to the material) virtual void updateMaterial();
// LINES //! Set line length virtual void setLength(float l);
//! Get line length virtual float getLength() const;
// MISC //! Render the group virtual void render(const Group &group);
//! Create mesh buffers virtual inline void createBuffers(const Group& group) {}
//! Delete mesh buffers virtual inline void destroyBuffers(const Group& group) {}
//! Get the Irrlicht Device virtual irr::IrrlichtDevice* getDevice() const { return device; }
//! Set the VBO hint virtual void setHardwareMappingHint(irr::scene::E_HARDWARE_MAPPING m);
//! Get the VBO hint virtual irr::scene::E_HARDWARE_MAPPING getHardwareMappingHint() const;
//! Set the render mode virtual void setRenderMode(E_IRRSPK_RENDERMODE rm);
//! Get the render mode virtual E_IRRSPK_RENDERMODE getRenderMode();
//! Set the index mode virtual void setIndexMode(E_IRRSPK_INDEXMODE im) {}
//! Get the index mode virtual E_IRRSPK_INDEXMODE getIndexMode() {} private: irr::IrrlichtDevice* device; ImpIrrRenderer* rendererArray[EIRM_COUNT]; int currentRenderer; }; } }
#endif // _SPARK_IRRLICHT_RENDERER_ | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Sun Aug 02, 2009 2:28 pm | |
| Avec les defines: - Code:
-
#ifndef _SPARK_IRRLICHT_RENDERER_DEFINES_ #define _SPARK_IRRLICHT_RENDERER_DEFINES_
#include <irrlicht.h> #include <SPK.H> #include <string>
namespace SPK { namespace IRR { //! Lists all possible render modes enum E_IRRSPK_RENDERMODE { //! Do not render anything EIRM_NONE = 0,
//! Only render particles as points EIRM_POINT = 1,
//! Particles are rendered as lines EIRM_LINE = 2,
//! This rendermode is useful if you want textured particles EIRM_QUAD = 3,
//! Each particle is rendered as an instanced object EIRM_OBJECT = 4,
//! Useful only for counting possible render modes EIRM_COUNT = 5 };
//! Names for E_IRRSPK_RENDERMODE values const std::string EIR_NAMES[EIRM_COUNT] = { "None", "Point", "Line", "Quad", "Object" };
//! Lists all possible orientations for a quad enum E_IRRSPK_ORIENTATION { //! Quad faces active camera EIO_CAMERA,
//! Quad is aligned on x axis EIO_XAXIS,
//! Quad is aligned on y axis EIO_YAXIS,
//! Quad is aligned on z axis EIO_ZAXIS };
//! Lists indices modes enum E_IRRSPK_INDEXMODE { //! Choose the best index mode according to the group size EII_AUTO=0,
//! Always use 16bits indices. Any attempt to create a buffer with more particles will fail (and the renderer won't render anything) EII_16BITS,
//! Try to always use 32bits indices. Not available on all graphic cards. EII_32BITS,
//! Always use 16 bits indices, but if a buffer is created with too much particles, it's dispatched in several 16 bits buffers. Available on all graphics cards. EII_DISPATCHED16BITS };
//! Conversion function
//! Vectors inline irr::core::vector3df spk2irr(Vector3D v) { return irr::core::vector3df(v.x,v.y,v.z); }
//! Colors inline irr::video::SColor spk2irr(float a, float r, float g, float b) { return irr::video::SColorf(r,g,b,a).toSColor(); } } }
#endif // _SPARK_IRRLICHT_RENDERER_DEFINES_ Enfin, voici l'interface des buffers: - Code:
-
#ifndef _SPARK_IRRLICHT_RENDERER_IRRBUFFERS_ #define _SPARK_IRRLICHT_RENDERER_IRRBUFFERS_
#include <irrlicht.h> #include <SPK.h>
namespace SPK { namespace IRR { //! A buffer designed to use with Irrlicht /** A ECRIRE ! **/ class IrrBuffer : public Buffer, public irr::scene::CMeshBuffer<irr::video::S3DVertex> { public: //! Constructor IrrBuffer() : Purpose(0) { /*setHardwareMappingHint(irr::scene::EHM_STATIC,irr::scene::EBT_INDEX);*/ }
//! Construct indices of this buffer in order to use it with a point renderer virtual inline void constructIndicesForPointRendering() { Purpose=0;
Indices.set_used(Vertices.size()); for(unsigned int t=0; t<Indices.size(); t++) Indices[t] = t;
setDirty(irr::scene::EBT_INDEX); }
//! Construct indices of this buffer in order to use it with a line renderer virtual void constructIndicesForLineRendering() { Purpose=1;
Indices.set_used(Vertices.size()); for(unsigned int t=0; t<Indices.size(); t++) Indices[t] = t;
setDirty(irr::scene::EBT_INDEX); }
//! Construct indices of this buffer in order to use it with a quad renderer virtual void constructIndicesForQuadRendering(unsigned int nbP) { Purpose=2;
Indices.set_used(nbP*6); for(unsigned int t=0; t<nbP; t++) { Indices[6*t+0] = 4*t+0; Indices[6*t+1] = 4*t+2; Indices[6*t+2] = 4*t+1; Indices[6*t+3] = 4*t+2; Indices[6*t+4] = 4*t+3; Indices[6*t+5] = 4*t+1; }
setDirty(irr::scene::EBT_INDEX); }
//! Set the number of particles, and the purpose /** \param nbParticles : The number of particles the buffer can handle * \param purpose : The purpose of this buffer (e.g. 0 for point rendering) **/ virtual void set(unsigned int nbParticles, int purpose) { if(purpose>=0 && purpose<3) { Purpose=purpose; switch(Purpose) { case 0: { Vertices.set_used(nbParticles); for(unsigned int t = 0; t < Vertices.size(); t++) Vertices[t] = irr::video::S3DVertex(); constructIndicesForPointRendering(); break; } case 1: { Vertices.set_used(nbParticles*2); for(unsigned int t = 0; t < Vertices.size(); t++) Vertices[t] = irr::video::S3DVertex(); constructIndicesForLineRendering(); break; } case 2: { Vertices.set_used(nbParticles*4); for(unsigned int t=0; t<nbParticles; t++) { Vertices[4*t+0] = Vertices[4*t+1] = Vertices[4*t+2] = Vertices[4*t+3] = irr::video::S3DVertex(); Vertices[4*t+0].TCoords = irr::core::vector2df(1,0); Vertices[4*t+1].TCoords = irr::core::vector2df(0,0); Vertices[4*t+2].TCoords = irr::core::vector2df(1,1); Vertices[4*t+3].TCoords = irr::core::vector2df(0,1); } constructIndicesForQuadRendering(nbParticles); break; } } } }
//! Returns the number of primitives /** \return The number of primitives according to the purpose of this buffer **/ virtual inline unsigned int getPrimCount() { switch(Purpose) { case 0: return Vertices.size(); case 1: return Vertices.size()/2; case 2: return Vertices.size()/2; default: return 0; } }
//! Get the purpose of this buffer /** \return An int representing the aim of this buffer. **/ virtual inline int getPurpose() { return Purpose; }
//! Get primitive type /** \return the primitive type for this buffer (depends on purpose) */ virtual irr::scene::E_PRIMITIVE_TYPE getPrimType() const { switch(Purpose) { case 0: return irr::scene::EPT_POINTS; case 1: return irr::scene::EPT_LINES; case 2: return irr::scene::EPT_TRIANGLES; default: return irr::scene::EPT_POINTS; } }
private: //! Clone the buffer /** \return An exact copy of this buffer. **/ virtual IrrBuffer* clone() const { return new IrrBuffer(*this); }
//! Swap 2 particles /** \param index0 : Index of the first particle to swap. * \param index1 : Index of the second particle to swap. * Indexes must be valid for the two particles to be swapped. * Warning : for performances reasons, there is no index verification ! **/ virtual void swap(size_t index0, size_t index1) { switch(Purpose) { case 0: { swapPoints(index0,index1); break; } case 1: { swapLines(index0,index1); break; } case 2: { swapQuads(index0,index1); break; } } }
//! Internal functions //! Swap 2 points void inline swapPoints(irr::u32 i, irr::u32 j) { irr::video::S3DVertex temp = Vertices[i]; Vertices[i] = Vertices[j]; Vertices[j] = temp; } //! Swap 2 lines void inline swapLines(irr::u32 i, irr::u32 j) { irr::video::S3DVertex temp1 = Vertices[i*2]; irr::video::S3DVertex temp2 = Vertices[i*2+1]; Vertices[i*2] = Vertices[j*2]; Vertices[i*2+1] = Vertices[j*2+1]; Vertices[j*2] = temp1; Vertices[j*2+1] = temp2; } //! Swap 2 quads void inline swapQuads(irr::u32 i, irr::u32 j) { irr::video::S3DVertex temp0 = Vertices[i*4+0], temp1 = Vertices[i*4+1], temp2 = Vertices[i*4+2], temp3 = Vertices[i*4+3]; Vertices[4*i+0] = Vertices[4*j+0]; Vertices[4*i+0] = Vertices[4*j+1]; Vertices[4*i+0] = Vertices[4*j+2]; Vertices[4*i+0] = Vertices[4*j+3]; Vertices[4*j+0] = temp0; Vertices[4*j+1] = temp1; Vertices[4*j+2] = temp2; Vertices[4*j+3] = temp3; }
//! The purpose of this buffer /** 0 -> Points * 1 -> Lines * 2 -> Quads * default : Points **/ int Purpose; };
//! A buffer creator to create IrrBuffers class IrrBufferCreator : public BufferCreator { public: IrrBufferCreator(int purpose):p(purpose) {}
private: virtual IrrBuffer* createBuffer(size_t nbParticles, const Group& group) const { IrrBuffer* buff = new IrrBuffer; buff->set(nbParticles,p); return buff; }
int p; }; } }
#endif // _SPARK_IRRLICHT_RENDERER_IRRBUFFERS_ Le reste, c'est l'implémentation, si tu la veux, dis le moi et je mettrai tout le projet en ligne. | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Mon Aug 03, 2009 3:31 pm | |
| Ok, j ai regarde vite fait, ca a l'air pas mal.
Juste dans le IrrBuffer pourquoi tu utilise un int pour le type de rendu plutot que l'enum E_IRRSPK_RENDERMODE ?
Apres j'ai vraiment survolé parce x est pas evident de lire du code direct sur le forum en fait. Et puis il faudrait que tu sépares la déclaration de la définition des methodes d'une classe. | |
| | | Darktib Committer
Messages : 389 Date d'inscription : 2009-07-20 Localisation : A coté de Paris
| Subject: Re: Module Irrlicht en développement Mon Aug 03, 2009 4:00 pm | |
| En fait j'utilise surtout des interfaces style Irrlicht, autrement dit si une fonction d'une classe est inline elle est mise dans la déclaration de la classe. Sinon j'ai implémenté la gestion des indices 32 bits, j'ai testé basiquement, voici le resultat: 40 fps pour 21000 particules... perso je trouve ca plutot pas mal... Graphiquement c'est pas le top pour dispatcher un peu plus les particules (genre multiplier par 10 la force des emetteurs) Sinon, j'ai testé fast_cos avec ton code de bench, et les résultats ne sont pas du tout ceux que tu as (désolé encore sur le forum, mais c'est plus lisible que du code): - Code:
-
------------------------------------------------------------------ Benchmark for cosine functions. Platform: Asus Computer Intel Pentium M (Centrino) ATI Mobility Radeon 9600 512 Mo Ram 1,70 GHz Proc Windows XP IDE: Code::Blocks 8.02 Compiler: MinGW GCC Testing environment: 3 applications are running while making the test: Code::Blocks IDE, Windows Media Player Serie 9, Notepad + 1 Explorer window Date: 03/08/2009
Test runned several times to allow disk caching work itself out (disk caching caused by test environment). Different configurations have been tested.
Functions sorted by speed: fast_cos lut lut2 std::cos ------------------------------------------------------------------
------------------------------------------------------------------ Precision of cosine functions. std::cos used as reference. ------------------------------------------------------------------ fast cos : avg error=0.0104858 - max error=0.0560169 lut cos : avg error=0.00146479 - max error=0.00873788 lut2 cos : avg error=1.81488e-005 - max error=9.94056e-005 ------------------------------------------------------------------
------------------------------------------------------------------ Target: Release. Optimizations: O2. ------------------------------------------------------------------ [Executed from IDE] fast cos is 254% faster than std cos lut cos is 108% faster than std cos lut2 cos is 104% faster than std cos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Executed from IDE] fast cos is 256% faster than std cos lut cos is 108% faster than std cos lut2 cos is 104% faster than std cos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Executed from Explorer] fast cos is 257% faster than std cos lut cos is 110% faster than std cos lut2 cos is 106% faster than std cos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Executed from Explorer] fast cos is 263% faster than std cos lut cos is 110% faster than std cos lut2 cos is 105% faster than std cos
------------------------------------------------------------------ Target: Release. Optimizations: O3,expensive_optimizations. ------------------------------------------------------------------ [Executed from IDE] fast cos is 270% faster than std cos lut cos is 112% faster than std cos lut2 cos is 104% faster than std cos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Executed from IDE] fast cos is 274% faster than std cos lut cos is 114% faster than std cos lut2 cos is 105% faster than std cos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Executed from Explorer] fast cos is 271% faster than std cos lut cos is 115% faster than std cos lut2 cos is 106% faster than std cos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Executed from Explorer] fast cos is 275% faster than std cos lut cos is 113% faster than std cos lut2 cos is 104% faster than std cos
------------------------------------------------------------------ Target: Debug. No optimizations. ------------------------------------------------------------------ [Executed from IDE] fast cos is 250% faster than std cos lut cos is 107% faster than std cos lut2 cos is 104% faster than std cos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Executed from Explorer] fast cos is 258% faster than std cos lut cos is 110% faster than std cos lut2 cos is 104% faster than std cos En moyenne, fast_cos est 260% plus rapide que std::cos, et est largement devant lut... J'en ai fait plusieurs pour éviter le problème du cache disque, mais les résultats ne changent pas^^ J'ai commencé à implementer la démo de feu, mais j'ai un problème avec la transparence des quads, problème qui vient des materiaux. Je pose la question sur le forum officiel, je vais voir ce qu'ils disent. | |
| | | Juff Developer
Messages : 539 Date d'inscription : 2009-07-14 Age : 42
| Subject: Re: Module Irrlicht en développement Mon Aug 03, 2009 8:38 pm | |
| oui c'est assez étonnant cette différence au niveau du bench.
Concernant les 21000 particules pour 40fps c'est pas forcément terrible en soi (ca fait du 800000 particules / secondes). Mais après ca dépend évidemment de ta config (si ta config est limité c pas mal). J'ai testé chez moi avec la demo basic avec 50000 particules et en réduisant par 10 la taille des points (pour économiser le fillrate) et j'arrive a 250fps soit 12 millions de particules / secondes. Après sur la demo basique c'est du POINT_SPRITE donc beaucoup plus rapide. Enfin de toute facon les renderer irrlicht ne seront jamais plus performant que des renderer direct en openGL puisque moins bas niveau, soumis a plus de contraintes et avec plus d'overhead.
Il sera assez interessant de tester les perf du module irrlicht de SPARK contre les perf des particules directement intégré a Irrlicht en utilisant 2 systèmes identiques. | |
| | | Sponsored content
| Subject: Re: Module Irrlicht en développement | |
| |
| | | | Module Irrlicht en développement | |
|
Similar topics | |
|
| Permissions in this forum: | You cannot reply to topics in this forum
| |
| |
| |