Discussion :

[lougne]

C'est un sujet qui me dérange depuis que j'ai découvert ce moteur déjà incroyable par ces vidéo, le bien nommé NxEngine(il faudra qu'un jour Funky nous explique ce nom là)

Bon voilà,
Ce moteur à pour vocation d'être entiérement basé sur les shaders. Qu'est que cela signifie? A vrai dire, malgré mes recherches il n ya pas d'explication claire, mais une chose est sure, il ne supporte pas le rendu logiciel: donc EXIT les cartes inférieurs à DirectX 8


Pour vous donner une idée il y a le moteur 3D de S.T.A.L.K.E.R. X-RAY Engine pour ces caractéristique je vous renvoie vers ce lien X-ray engine lire l'intervention Woohoo juste aprés les images,plutôt épatant non? Bon vous avez aussi Source Engine le moteur de Half-life 2 à la différence qu'il est orienté OpenGL (GLSL et Cg), le fameux UnrealEngine 3 , bref tous les nouveaux moteurs pour les récents jeux et consoles Next-gen, enfin pour la majorité. Et putain j'en oublie Un notre NxEngine

Maintenant que vous êtes familiarisés avec mon sujet, ce qui me tracasse est cette compatibilité de full shader Rendering. Qu'est ce que cela veut vraiment dire? Dans un moteur de rendu 3d, quels sont les sections qui utiliseront ce concept et lesquels il ne faut même pas envisager? Je me rapelle d'un vielle article de TomsHardware qui ne permettait pas de rêver aussi vite. Donc à part la puissance des cartes graphiques, qu'est ce qui à changer? C'est là ou mon cher Funkydata devrait intervenir car n'ayant pas les ressources de ton moteur ou d'un autre Next-gen j'aimerais bien avoir un cours magistrale sur le sujet.

Ah oui j'ai été stupéfait de voir que le beau moteur de Rendu Ogre3d n'est pas aussi un full Shader Rendering d'où certaines personnes parlent de faible perfomances à certains moments.

[funkydata]

(il faudra qu'un jour Funky nous explique ce nom là)

Au départ le nxEngine s'appelait NeXus Engine. Quand j'ai commencé le dev je voulais en faire un moteur spécialement dédié aux simulations spatiales (d'ou le nexus) qui requiert des algorithmes d'affichage et de gestion de scène trés différents de ceux implémentés dans la majorité des moteurs 3D disponibles. Puis le moteur a dérivé vers un moteur beaucoup plus générique. A ce moment je l'ai rebatisé nxEngine pour faire plus court.

Bon voilà,
Ce moteur à pour vocation d'être entiérement basé sur les shaders. Qu'est que cela signifie? A vrai dire, malgré mes recherches il n ya pas d'explication claire, mais une chose est sure, il ne supporte pas le rendu logiciel: donc EXIT les cartes inférieurs à DirectX 8

Cela signifie que le moteur affiche absolument tout via des shaders... modèles, sprites, Gui... Rien n'est affiché "à l'ancienne" en utilisant le fixed pipeline.
Et j'irais même plus loin EXIT les cartes inférieurs à DirectX 9 et EXIT les cartes ne supportant pas au moins les shaders 2.0 (2.x recommandé )

Maintenant que vous êtes familiarisés avec mon sujet, ce qui me tracasse est cette compatibilité de full shader Rendering. Qu'est ce que cela veut vraiment dire? Dans un moteur de rendu 3d, quels sont les sections qui utiliseront ce concept et lesquels il ne faut même pas envisager? Je me rapelle d'un vielle article de TomsHardware qui ne permettait pas de rêver aussi vite. Donc à part la puissance des cartes graphiques, qu'est ce qui à changer? C'est là ou mon cher Funkydata devrait intervenir car n'ayant pas les ressources de ton moteur ou d'un autre Next-gen j'aimerais bien avoir un cours magistrale sur le sujet.

Il n'y a pas plus d'incompatibilités avec un moteur fullshader qu'un moteur en fixed pipeline. Tu peux demander aux anciens béta testeurs, il me semble qu'un test avec le nxEngine avait été réalisé avec succés sur un "vieux" portable à base de GeForce 5. De plus lors des premières béta aucun problème de compatibilté n'était survenu. La seule chose qui limitera l'utilisation du moteur sera la version des shaders supportée par le GPU embarqué. A partir de la, si cette spécification est respectée, il n'y aura (à priori) pas d'autres soucis de compatibilité.

Alors pourquoi avoir fait un moteur n'utilisant que des shaders ?

* Les performances :
Les shaders permettent d'effectuer des opérations sur la géométrie et les pixels directement sur le GPU. Sur un fixed pipeline pure beaucoup d'opérations sont réalisées par le CPU puis les données sont ensuite transmises au GPU (je simplifie...). Ces allers-retours sont une vrai calamité pour les performances. L'utilisation des shaders permet donc de limiter ces transactions et de gagner en performances.
De plus, beaucoup de ces opérations sont maintenant cablées en hardware sur le GPU alors que bien entendu si le CPU devait être chargé de ces tâches ce serait du software. On a encore ici droit à un gain substanciel de performances.
* La qualité du rendu :
Le fait de gagner énomément en performances et d'avoir beacoup d'opérations cablées en hardware dans le GPU permet d'augmenter d'autant la finesse des calculs et leur précision. Beaucoup d'effets next-gen (voir tous) ne peuvent être effectués que via des shaders si l'on veut obtenir un framerate ne serais-ce que correct.
* C'est du C# :
Même si le C# depuis le .net 2.0 est trés performant, il n'en reste pas moins que pour ce genre d'application il a encore du retard par rapport au C++. Le fait d'utiliser intensivement les shaders permet de décharger au maximum le CPU et par la même de limiter les opérations effectuées par le code C# à l'indispensable.
* C'est l'avenir :
Si il est certain que beaucoup de moteur 3d propose encore le fixed pipeline, il est aussi certain qu'à plus ou moins long terme tout cela va être remplacer par des shaders. Le DirectX10 confirme d'ailleurs largement cette tendance puisqu'il est quasi entièrement tourné vers le support de ces petits programmes magiques

Voilà, je suis pas sur d'avoir bien ciblé mes réponses sur ce que tu me demandais mais si tu as des questions plus précises n'hésite pas.

[lougne]

Cela signifie que le moteur affiche absolument tout via des shaders... modèles, sprites, Gui... Rien n'est affiché "à l'ancienne" en utilisant le fixed pipeline.

Donc en plus long, j'aurais pu prendre un sérieux racourci en me lançant sur les shaders directement, d'autant qu'ils deviennent de plus en plus facile à comprendre. Ma méthode: tuto -> Book -> Optimisation du tuto

* C'est du C# :
Même si le C# depuis le .net 2.0 est trés performant, il n'en reste pas moins que pour ce genre d'application il a encore du retard par rapport au C++.

Connais-tu là où le C# pêche par rapport à C++, car si je regarde bien, la partie code est essentiellement, maintenant, le chargement des fichiers (on parle ici du rendu biensûr), maybe les performances vont chutter au niveau de I.A., physique ( pas sûr),...On verra!

* C'est l'avenir :
... Le DirectX10 confirme d'ailleurs largement cette tendance puisqu'il est quasi entièrement tourné vers le support de ces petits programmes magiques

C'est sûr que c'est l'avenir (jette encore un coup d'oeil sur les spécifications de DX 10) Geometry -> Vertex -> Pixel en boucle , on dirait même que ce schéma ce prête au multithreading

en tout cas j'ai hâte de voir et d'avoir déjà le moteur et ensuite les sources. Merci encore

[funkydata]

Connais-tu là où le C# pêche par rapport à C++, car si je regarde bien, la partie code est essentiellement, maintenant, le chargement des fichiers (on parle ici du rendu biensûr), maybe les performances vont chutter au niveau de I.A., physique ( pas sûr),...On verra!

Principalement au niveau des IO. Il faut faire trés attention à l'utilisation des listes et des tableaux qui peuvent ralentir beaucoup l'application. Il faut également bien faire attention de limiter autant que possible des paramètres de fonctions trop volumeux ou trop peu explicites. Les : "void MaFonction(float[] MonTableau)" sont, par exemple, à éviter autant que possible.
Dans le même esprit, il faut mieux éviter de déclarer et d'instancier de trop nombreuses variables dont la portée n'est qu'une fonction.

Il y a beaucoup d'autres choses que j'ai remarqué et qui sont suceptibles de ralentir l'application en C#... ceci est donc une liste loin d'être exaustive.

Le mieux étant de faire beaucoup de tests pour trouver comment optimiser le code au mieux tout en gardant une certaine "souplesse" de construction.

[lougne]

Pour les tableaux et les listes j'avais remarqué, mais du code Unsafe est là pour nous aider, heureusement. Bon instancier ou ne pas instancier est trés souvent la question, il faudrait que dans la section Dotnet on en parle ou c'est déjà fait, je cours regarder cela trés vite

[the thibz]

Bon, comme c'est mon premier post (mais je suis le cours des discussions et des videos depuis un certain temps) j'en profite pour dire que c'est un des moteur les plus prometteur que j'aie vu (l'ironie est que j'aie fait des jours entier de recherche pour trouver un moteur C# performant et que je tombe sur celui ci par hasard )



voila un compte rendu d'un benchmark sur les "grands" language utilisé

et le lien vers les details
http://www.osnews.com/story.php/5602...File-IO/page1/

j'ai pas beaucoup le temps de me plonger dedans pour dire si c'etait du DotNet 1.1 ou 2.0

[Smallpox]

.NET 1.1 car ils disent utiliser Visual .NET 2003...
sachant que le .net 2.0 est plus performant on doit pas être loin du c++ maintenant.