[W.I.P.] nxEngine v0.4

**Laurent Gomila** · 05/09/2007, 22h52

Oui oui, je trouve aussi que supporter ce format est une bonne chose, je voulais juste dire qu'il ne faut pas en faire le format "officiel" du moteur.

**funkydata** · 06/09/2007, 00h22

Envoyé par Laurent Gomila

Oui oui, je trouve aussi que supporter ce format est une bonne chose, je voulais juste dire qu'il ne faut pas en faire le format "officiel" du moteur.

Tu me conseillerais quoi comme format car j'ai pas vraiment trouvé un format correct correspondant à mon besoin.
Au minimum j'aimerais :

Stocker les tangents (je me fous des binormales)
Stocker des matériaux plus élaborés que ceux du format .x
- Textures ambientes
- Lightmaps
- Textures spéculaires
- Textures normal
- Textures height (pour le parallax notamment)

Je n'ai pas vraiment trouvé de format capable de me fournir ces fonctionalités et comme je sais que c'est plutot long de développer son propre format j'aimerais l'éviter.

-----------

Changement de sujet, un test bizarre que je viens de faire sur la différence de comportement entre le MDX et le nxPlateform.
J'ai fait une scène composé de 1000 cubes en mouvement (rotation sur les 3 axes sur leur pivot), éclairés au pixel et bump-mappé... tous visibles, pas d'optimisations au niveau de la gestion de la scène. Code et médias bien sur identiques, sauf qu'une application utilise MDX et l'autre le nxPlateform.

Avec Mdx j'obtiens :

198 Fps en 1024x768 fenétré
128 Fps en 1680x1050 plein écran

Avec nxPlateform j'obtiens :

238 Fps en 1024x768 fenétré
236 Fps en 1680x1050 plein écran

Je me pose pas mal de questions quant à ce résultat....

Et j'aimerais avoir votre avis ou votre interprétation.

**Laurent Gomila** · 06/09/2007, 08h30

En général, quand on commence à faire quelque chose de sérieux, on en vient toujours à faire son propre format perso. Mais c'est sûr que c'est long, il faut écrire des exporteurs pour quelques logiciels de modélisation 3D. Ou alors un utilitaire de conversion depuis / vers un fichier Collada.

Pour ce qui est des différences de performances, je n'y connais rien à MDX mais une telle différence est plutôt étonnante.

**MoDDiB** · 06/09/2007, 09h16

Envoyé par funkydata

Et j'aimerais avoir votre avis ou votre interprétation.

Mon avis ? Postule chez MS

**funkydata** · 06/09/2007, 10h00

Envoyé par MoDDiB

Mon avis ? Postule chez MS

Euh non mais attends que l'on soit bien clair je sais pourquoi c'est plus rapide et je dirais heuresement. MDX est bourré de tests en tout genre et de partie de code plus ou moins "scotchée" qui ralentissent sensiblement son execution. As-tu regardé les sources de MDX ?
Ma question ne portait donc pas la dessus. Mais plutôt sur le fait que dans le cas de MDX, à priori, j'ai une perte substancielle de performances liée au fillrate (montée en réso), que je n'ai pas avec le nxPlateform qui lui semble être limité à un autre niveau mais lequel. Appli C#, Geometrie... enfin bref je sais pas trop...

**Laurent Gomila** · 06/09/2007, 10h04

Tu ne peux pas faire un petit profiling avec un outil du genre PIX ou nvPerfHUD ?

**MoDDiB** · 06/09/2007, 14h03

Envoyé par funkydata

Euh non mais attends que l'on soit bien clair je sais pourquoi c'est plus rapide et je dirais heuresement. MDX est bourré de tests en tout genre et de partie de code plus ou moins "scotchée" qui ralentissent sensiblement son execution. As-tu regardé les sources de MDX ?
Ma question ne portait donc pas la dessus. Mais plutôt sur le fait que dans le cas de MDX, à priori, j'ai une perte substancielle de performances liée au fillrate (montée en réso), que je n'ai pas avec le nxPlateform qui lui semble être limité à un autre niveau mais lequel. Appli C#, Geometrie... enfin bref je sais pas trop...

Oui bien entendu, juste que sans le code il est difficile de répondre :/

**CORBASE** · 07/09/2007, 12h16

Es-ce que la limite n'est pas justement due au partage du .NET managé et natif de ta DLL nxPlatform.

Si je comprends bien, dans le nxPlatform tu balance tout les calcul mathématiques dans la DLL en C++ et tu garde le C# pour la mise en forme ?

La limitation est quand même (à mon avis) la machine virtuelle .NET. Bien qu'optimise, elle ne rivalise pas avec du code compilé. Je pense que ta limitation vient de là, mais je palre uun peu en aveugle n'ayant strictement rien vu du projet.

-----

Pour en revenir au passage du nxPlatform, je pense que c'est une bonne solution, surtout au niveau mathématique, ou tu peux optimisé au mieux en assembleur les calculs les plus pointus et ainsi avoir des performances impressionnantes même avec un front en C#.

Beau défi technologique, j'aime bien !

**funkydata** · 07/09/2007, 12h32

Oui c'est peut être C# qui limite dans ce cas... j'ai pas assez fait de tests pour le dire. Ce qui est certain en revanche, c'est que le gain en performances par rapport à MDX est trés trés substanciel. Bien plus que je ne l'aurais imaginé.

**wizad** · 10/09/2007, 09h49

C'est possible que le c# soit une des cause de limitation. Mais j'emet un doute sur le fait que ce soit l'unique cause. Un test avait d'ailleur été fait entre un programme c# et un programme C. Et bien il aura fallu pas mal d'heure d'optimisation du code C pour atteindre les perf du code C#. La différence majeure se situe au niveau du chargement de l'appli C# plus longue qu'une appli compilé type C/C++.

Concernant la différence de perf entre les résolution, peut être que MDX effectue plus de test, vérification,... lors de la montée en résolution.
Maintenant n'ayant pas vu les deux codes-sources difficile de se prononcer de façon catégorique.

**georgeduke** · 14/09/2007, 21h42

Dans tous les cas, c'est une bonne nouvelle : au moins le temps de dev que te "coûte" le nxPlateform n'est pas vain !!

**wizad** · 14/09/2007, 22h29

Je dirais même plus sachant que non seulement ce n'est pas vain mais même carrément bénéfique pour le coup.

**funkydata** · 17/10/2007, 12h30

Salut, quelques nouvelles de la version 0.4 :

La librarie C++ commence à être assez complète sur le support de DirectX9... mais trés trés trés incomplète sur le support de DirectX 10. Je pense donc inclure le support de DirectX 10 que dans la version 0.5 ou 0.6 suivant les demandes.
J'ai recodé une bonne partie de la librairie "frontend". J'ai notamment revu totalement quelques points qui m'ont semblé inutiles ou limitants. La partie ayant la plus évoluée est sans conteste la gestion des scènes. Vous devrez être bien plus autonomes car le moteur ne gérera pas de lui même la totalité de l'espace. Quelques exemples :
- Vous devrez renseigné avant le rendu l'éclairage à appliqué à tel ou tel objets
- Vous devrez gérer vous même le culling
- ...
- Bien sur, le moteur dispose de toutes les fonctions pour réaliser ces tâches trés facilement... mais leur appel sera à votre charge
Il n'y aura plus de shaders "globalisés" au niveau des matériaux. Il faudra donc correctement connaitre cette technologie et créer ou adapter vos propres shaders aux besoins de votre scène. Les shaders par défaut seront donc trés simples et limités et ne sont considérés que comme des paliatifs.

Voilà dans les grandes lignes.
La sortie de cette version 0.4 est prévue fin novembre / début décembre sauf si imprévu.

J'informe les habitués que les comptes béta test 0.3 seront remis à zéro. Il faudra donc me renvoyer un MP pour me confirmer votre volonté de réinscription.

Dernière info enfin, je pense qu'à la fin de la béta 0.4 (qui sera donc privée), une première version publique verra le jour. Le déroulement de la béta décidera si effectivement le moteur à maintenant assez de "bouteille" pour être disponible librement.

Pour toutes questions, demandes de précisions, idées, commentaires... merci de poster à la suite

**funkydata** · 17/10/2007, 18h39

La version 0.4 inaugurera un format de modèles propriétaire. Ce format permet de stocker toutes les informations relatives à un modèle destiné au nxEngine pour son affichage.

Ainsi avec un modèle sous ce format une simple commande suffit a charger la totalité des resources utilisées par le modèle :

Géométrie
Shader(s) + Paramètre(s)
Texture(s)

Le modèle peut se présenter sous forme de fichier texte ou sous forme de fichier binaire compressé. Dans le même esprit que le format .x.

Enfin une GUI développée par georgesduke est disponible pour pouvoir convertir de manière conviviale vos modèles vers ce format.
Merci à lui

**funkydata** · 18/10/2007, 20h32

J'ai ajouté une vidéo au site sur mes tests de lumières et notamment le rendu des ombres intégré à la version 0.4. Pour voir la vidéo rendez vous ici (c'est la 1ère).

Désolé pour l'environnement un peu simpliste (sutout aux niveaux des textures

) mais je n'ai pas encore eu le temps de me muer en infographiste

**ThunderZ** · 19/10/2007, 09h58

Très bon travail.

Tes ombres sont propres avec un leger "adouci" sur les bords.

Tu utilises un deriver du stencil buffer dessus ou directement via shader par projection ?

**Yno** · 19/10/2007, 15h11

Miam, je raffole des vidéos du NXE

Les ombres ont l'air de très bonne qualité sur cette vidéo. Une seule lumière omni a l'air présente sur cette scène, as-tu fais une shadow cube map ou bien as-tu utilisé les stencil shadow volume ?

**funkydata** · 19/10/2007, 15h58

En effet, il n'y a qu'une seule lumière omnidirectionnelle dans la scène. La technique employée est celle des dual parabolic shadow maps, qui évite justement de devoir utiliser un cube pour ce genre de lumières. On adouci ensuite le tout en post-process.