1. #1
    Membre habitué
    Homme Profil pro
    Responsable des études
    Inscrit en
    septembre 2005
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Responsable des études
    Secteur : Bâtiment Travaux Publics

    Informations forums :
    Inscription : septembre 2005
    Messages : 104
    Points : 165
    Points
    165

    Par défaut [Discussion - Spéculation] La vision du moteur NxEngine

    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.

  2. #2
    Membre confirmé
    Avatar de funkydata
    Profil pro
    Inscrit en
    mai 2006
    Messages
    515
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2006
    Messages : 515
    Points : 504
    Points
    504

    Par défaut

    Citation Envoyé par lougne
    (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.

    Citation Envoyé par lougne
    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é )

    Citation Envoyé par lougne
    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.

  3. #3
    Membre habitué
    Homme Profil pro
    Responsable des études
    Inscrit en
    septembre 2005
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Responsable des études
    Secteur : Bâtiment Travaux Publics

    Informations forums :
    Inscription : septembre 2005
    Messages : 104
    Points : 165
    Points
    165

    Par défaut

    Citation Envoyé par funkydata
    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

    Citation Envoyé par funkydata
    * 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!

    Citation Envoyé par funkydata
    * 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

  4. #4
    Membre confirmé
    Avatar de funkydata
    Profil pro
    Inscrit en
    mai 2006
    Messages
    515
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2006
    Messages : 515
    Points : 504
    Points
    504

    Par défaut

    Citation Envoyé par lougne
    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.

  5. #5
    Membre habitué
    Homme Profil pro
    Responsable des études
    Inscrit en
    septembre 2005
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Responsable des études
    Secteur : Bâtiment Travaux Publics

    Informations forums :
    Inscription : septembre 2005
    Messages : 104
    Points : 165
    Points
    165

    Par défaut

    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

  6. #6
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    septembre 2002
    Messages
    11
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : septembre 2002
    Messages : 11
    Points : 13
    Points
    13

    Par défaut

    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

  7. #7
    Membre à l'essai
    Profil pro
    Développeur .NET
    Inscrit en
    juillet 2005
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : juillet 2005
    Messages : 9
    Points : 12
    Points
    12

    Par défaut

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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 3
    Dernier message: 09/09/2009, 14h08
  2. Réponses: 0
    Dernier message: 03/09/2009, 16h17
  3. Réponses: 4
    Dernier message: 20/07/2007, 12h24
  4. Présentation de mon moteur 3D (NXEngine)
    Par funkydata dans le forum Projets
    Réponses: 151
    Dernier message: 27/04/2007, 23h52
  5. NXEngine - Moteur 3D C# DX9
    Par funkydata dans le forum Moteurs 3D
    Réponses: 3
    Dernier message: 18/07/2006, 18h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo