renderer directx

bonjour,

donc voilà j'ai commencé et pas mal avancé un renderer directx; les points sprite et quad sont quasi finalisés.

je suis en train de faire un zip des fichiers nécessaires, pour le poster

Salut et bienvenue.

Cool, si tu as des questions, n'hésite pas.

merci,

oui j'ai une question, pour les licences des fichiers que j'ai écrit, ça marche comment, histoire de pas avoir de problème?

SPARK est depuis peu sous licence zlib. Tu peux utiliser la même, elle est très permissive.
Il te suffit de reprendre le texte de la licence a partir de n'importe quel fichier de SPARK et de l'intégrer au début de tous tes fichiers .h et .cpp tout en remplacant mon nom par le tien.

voilà le zip, j'ai nettoyé au maximum les fichiers inutiles dans mon cas de figure, le code est encore assez sale, mais ça à l'air de marché, au moins pour la démo "basic" adaptée pour dx9, gérant les points sprites et les quad (touche F4 pour changer), la vue étant controllée par clic droit+souris.

http://stardeath.evoconcept.net/doc/SPARK_DX9.zip

ps: il doit y avoir des fichiers où je me suis trompé pour l'en-tête, mais bon, c'est pas dramatique

C est un bon début.

Première chose que je remarque tu crées les buffer direct3D a chaque boucle de rendu, ce n'est pas très optimisé. En fait le mieux serait d'utiliser la classe Buffer de SPARK qui permet justement de gérer les buffers pour le rendu. La en fait tu utilises des ArrayBuffer que tu copies dans les nouveau buffer directX a chaque frame. Autant mettre a jour directement les buffers directX plutot que de passer par des buffers intermediaire.

Pour cela, il faut deriver la classe SPK::Buffer et SPK::BufferCreator : Par exemple un SPK::DX9::DX9Buffer et SPK::DX9::DX9BufferCreator. Ces buffers contiendront directement les buffers DirectX.

ok, je regarde ça, j'avais pas compris l'utilité de la classe Buffer

Oui c est peut être pas très clair. En fait Buffer et BufferCreator sont des classes bas niveau dans SPARK, l'utilisateur n a normalement pas a s'en soucier sauf éventuellement pour créer des nouveau renderers, alors je n'ai pas fait beaucoup de doc dessus.

Je vais tenter une petite explication (dis moi si c'est pas clair) :

En fait les Buffers dans SPARK servent a stocker les données organisé correctement pour être rendu. Ces buffers ne sont pas stockés par les renderers mais par les groupes. Lorsqu un renderer désire rendre un groupe de particule, il interoge le groupe pour savoir si le bon buffer existe, si oui il le récupère, sinon il demande au groupe de créer le buffer (ca c est le comportement par défaut). Le renderer itère ensuite sur le buffer pour le mettre a jour puis l'envoie au GPU.

Par défaut, seuls les ArrayBuffer existent pour l'instant car openGL utilise des tableaux de float classique pour le rendu. Le ArrayBuffer<float> ou FloatBuffer contient en fait simplement un tableau de float. Comme ce sont les groupes qui crée leur buffer, lors de la demande de la création d'un buffer, il faut que le groupe sache quel type de buffer créer et quel paramètres il aura. Pour ca on passe un BufferCreator au groupe qui est un objet temporaire qui se chargera de créér le bon buffer pour le groupe. Les buffers des groupes sont stockés dans une map et disposent donc d'un ID unique permettant de les récupérer. En plus de leur ID, chaque buffer de groupe dispose d'un flag. Ce flag permet au renderer de connaitre la facon dont sont stocké les données dans le buffer. Si le flag ne correspond pas au flag désiré, on va recréer le buffer par exemple.

Pour Direct3D, j y ai pas vraiment réfléchi en profondeur, mais comme l API utilise ses propres format de buffers, une classe DX9Buffer encapsulant tout ca avec son DX9BufferCreator associé parait necessaire. En fonction de parametre setté dans le DX9BufferCreator, le DX9Buffer sera soit un indexBuffer, soit un vertex buffer avec un format donné... On peut aussi penser a créer un DX9IndexBuffer et un DX9VertexBuffer, a voir...

le problème si je comprend bien, c'est qu'il risque de falloir modifier la classe Group, car si lors d'une demande de mise à jour, c'est la classe Group qui gère tout, ça risque de poser problème.

les buffers que je recréé à chaque fois pour l'instant (QuadRenderer), nécessitent un verrou pour leurs modifications, problème, je ne sais pas (si je dérive Buffer et BufferCreator) qui et quand des modifications auront lieu pour mettre ces fameux verrous.

bref je regarde le code, car finalement c'est assez confus pour moi XD

Nan la classe groupe ne modifie rien. Elle ne fait que stocker les buffers. La mise a jour est effectué par les renderers, le groupe ne fait que leur donner le bon buffer.

En fait le seul moment ou le groupe modifie le contenu des buffers, c est lorsque le swap de particules sur le buffer est activé. Dans ce cas, lorsque 2 particules sont swappées (pour des questions d optim), le groupe appel la methode swapParticles de chacuns de ses buffers pour conserver l intégrité des données. Mais dans le cas de buffer servant uniquement a organiser les données et donc ou les données de la frame precedente sont inutiles, le swap est desactivé et rien ne se passe.

Dans le cas plus précis des buffers Direct3D faire du swap de données inmposerai un lock unlock par paires de particules swappées. Ce serait très lent (surtout si les buffers sont stockés coté GPU). Donc on peut dire que le swap de particules sur les buffers DX9 et toujours desactivé et implémenter la methode virtuelle swapParticles vide. De toute facon tous les buffers que tu utilisera dans les renderers ne swapperont pas les particules puisque la lecture des données du buffers de la frame précédente n est pas utile.

ok, je m'active à une tentative de modification dans ce sens, la suite au prochain épisode

Si tu veux de l'aide, tu peux regarder le renderer Irrlicht que je suis en train de fignoler (du moins, les quelques sources que j'ai diffusé), Tu met à jour les buffers au moment du rendu.

Bonne continuation !

voilà c'est implanté dans le sens DX9Buffer, il ne me reste plus qu'à nettoyer et comparer les performances pour valider la technique.

par contre ça devient vite le bordel de devoir passer le device, ça devient franchement moins glamour XD

Oui en effet, du coup il faut passer le device au bufferCreator et au Buffer. c est vrai que c est pas terrible.

Est ce que du multi device a du sens ( je ne connais pas tres bien directX ) ? On peut peut être imaginer un acces au device de facon statique a partir de la classe renderer.

voilà, archive mise à jour, ça a encore besoin de nettoyage et amélioration.

http://stardeath.evoconcept.net/doc/SPARK_DX9.zip

Cool, ca marche bien.

Je regarderai mieux le code quand j'aurai un peu plus de temps. J ai vu que tu été parti des renderers OpenGL pour faire les tiens. J'ai changé quelques trucs dans le renderers de Quad OpenGL concernant l'orientation des quads (c'est beaucoup plus puissant maintenant), je peux te filer les sources si tu veux implémenter les modifs.

oui je me suis servis de ton travail, ça permet de garder au maximum la philosophie du moteur, je pense que c'est plus facile autant pour les utilisateurs que pour les lecteurs/programmeurs du code.
(c'est pour ça que je demandais la licence, d'ailleurs je suis toujours pas sur, je dois mettre ou pas l'utilisation des fichiers originaux? je suis clairement pommé la dessus, si il y a des trucs incorrects, je les modifierai pour rester dans la légalité)

pour tes améliorations, aucun problème pour que je les mette dans la version dx, je les attends ^^

Moi aussi je suis souvent pommé des qu'il s agit de licences...
En fait, ton probleme est que tu as repris des fichiers (les renderers OpenGL) comme base pour les modifier ? Ca ne pose pas vraiment de problème je pense car tu reste sous licence zlib. Au pire est pour être en accord avec cette ligne :

Quote :

Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

Tu peux rajouter une ligne en dessous de la licence sécifiant que tu t'es basé sur d'autres fichiers du style :

Quote :

// This file is based upon the file blabla.h from the SPARK particle engine under zlib licence

Ou un truc dans le style, mais ca n'a pas réellement d'importance, je pense.

Sinon concernant le GLQuadRenderer modifié, je poste ca ce soir (même si c'est pas forcément la version finale).

au pire (je sais pas si c'est le terme approprié) je met les 2 noms dans la licence de chaque fichier, vu que je sais plus quels fichiers j'ai créé de toutes pièces et ceux dont j'ai littéralement plagié la structure pour garder la même présentation, je tacherai de faire gaffe maintenant pour les prochains fichiers que je créerai/modifierai.

Ouais tu peux aussi faire comme ca

Voila les nouveaux quad renderer OpenGL. En gros, il y a beaucoup plus de possibilités dans l'orientation des quads, les rotations s'effectuent maintenant sur les vertices et non sur les coordonnées de textures, et j'ai corrigé un bug de plantage en utilisant des quads non texturé. Du coup la classe est un peux plus lourde mais plus puissante. Enfin ce n'est pas la version finale, il y a moyen d'optimiser et puis toute la doc n'est pas faite. Mais ca ne devrait pas trop changer maintenant.

GLQuadRenderer

dernières nouvelles :

- nouveau sample écrit avec dxut
- refonte de DX9LineRenderer
- refonte de DX9Renderer pour l'intégration avec DXUT
etc ...

problème avec Group::setRenderer, il créé les buffers et ça fout le merdier avec ma tentative de séparation directx/non directx

Salut, quand tu dis que ca pose probleme ? Tu peux expliquer plus précisément pourquoi ? Normalement ca ne devrait poser aucun problème. L'allocation / desallocation des buffers doit pouvoir se faire a n'importe quel moment.

pas spécialement un problème, juste un truc chiant à tracer quand l'application m'a planté à la figure.*

je posterai les mises à jour demain ^^

ha si un petit truc, tu n'as jamais pensé à faire une sorte de log en mode debug histoire de tracer les opérations effectuées?

* grosso modo, un set qui dedans fait un create m'a un peu perturbé