Discussion :

[funkydata]

J'ouvre ce post suite à l'actualité ajoutée sur le portail :

J'ai fait un premier test de performances sur la 0.3 béta.

Descriptif de la scène :

# HDR
# Skybox multi-texture + animation (même si ca ne se voit pas bien sur la vidéo)
# Vaisseau
# 2 planêtes
# 5000 asteroides de potentiellement 2500 faces chacun dans un espace relativement restreint
# Bump-Mapping, éclairage dynamique par pixel et attenuation par vertex sur tous les objets de la scène

La scène affiche en moyenne 330000 faces/frames à une cadence d'environ 80 fps sur ma GeForce 6800 GS. Le test a été réalisé avec FSAA 4x-Anisotropy 16x en 1280x1024 plein écran. Cette scène utilise le scenegraph et les shaders génériques du nxEngine.

Beaucoup d'optimisation à venir permettront sans aucun doute d'améliorer largement ce framerate, mais j'aimerais que vous me donniez votre opinion sur les performances actuelles. Si vous avez des questions ou si vous voulez des précisions sur ce point je serais aussi heureux d'y répondre

[MoDDiB]

Personnellement ça m'impression beaucoup j'attends de faire tourner ça sur mes petites machines pour voir ce que ca donne.

[Baptiste Wicht]

Je ne m'y connais pas énormément, mais ca me semble un excellent résultat

[stailer]

Vraiment impressionnant... Que se passe t il par contre si tu mets par exemple 1000 de ces asteroides en rotation, ou en mouvement ?

En fait ce que je veux dire : y a t il un moyen de faire en quelque sorte un système de "cache" dans le moteur ? Par exemple, des objets qui sont à une certaine distance, virer leur qualité de texture ? ou leur bump si on en a mis ?

[funkydata]

Que se passe t il par contre si tu mets par exemple 1000 de ces asteroides en rotation, ou en mouvement ?

J'avais déjà effectuer le test avec les 5000 asteroids en rotation. Donc avec les 5000 asteroids en rotation la scène perds de 7 à 4 Fps suivant le point de vue. je n'ai par contre pas tester avec en plus une translation je ferais un test ce soir.

En fait ce que je veux dire : y a t il un moyen de faire en quelque sorte un système de "cache" dans le moteur ? Par exemple, des objets qui sont à une certaine distance, virer leur qualité de texture ? ou leur bump si on en a mis ?

Oui le nxEngine supporte le LOD tant sur la géométrie que les shaders. Tu peux donc définir x niveaux de LOD géométrique pour ton object et affecter à ces LOD des matériaux différents. Par exemple tu peux trés bien définir la chose suivante :

• LOD 1 : Parallax Bump Mapping
• LOD 2 : Bump Mapping
• LOD 3 : Bump Mapping
• LOD 4 : Diffuse + Spéculaire
• LOD 5 : Diffuse

Comme les matériaux sont indépendants tu peux également définir des textures spécifiques pour chaque LOD.
Les LOD sont automatiquement appliqués par le scène graph en calculant la distance minimale entre la boite ou la sphere englobante de l'objet et le point de vue de la caméra. Ce calcul prend bien sûr en compte l'échelle de l'objet dans la scène.
Donc tu auras juste à renseigner les matériaux spécifiques de chaque niveau de LOD si tu le désires puis à indiquer au moteur les limites de distance auquelles le LOD est destiné. Le moteur se charge ensuite de t'afficher le LOD correct.

Personnellement ça m'impression beaucoup j'attends de faire tourner ça sur mes petites machines pour voir ce que ca donne.

Je ferais moi même un test une machine plus "modeste" même si j'estime qu'actuellement la mienne est trés loin du haut niveau de performances
Mais je ne m'attends pas à des miracles... le hardware présent sur la machine qui fait tourner l'application est essentiel tu auras beau optimiser des jours et des mois durant, si le hardware ne suis pas tu ne gagneras au mieux que quelques maigres fps

[sylvain39]

Toujours aussi impressionnant Funky.

Ayant testé la premier beta ( ), le résultat à l'époque était déjà impresionnant.
Cette nouvelle monture, donne un avant goût .

La conception du moteur permet une programmation en C# abordable par tous le monde.

[funkydata]

Toujours aussi impressionnant Funky.

Ayant testé la premier beta ( ), le résultat à l'époque était déjà impresionnant.
Cette nouvelle monture, donne un avant goût .

La conception du moteur permet une programmation en C# abordable par tous le monde.

Oui mais tu verras (si ce n'est déjà fait ) que même si les concepts des premières versions sont les mêmes (accents sur la simplicité de programmation du moteur et de la qualité du rendu), les concepts d'appels et de gestion ont pas mal changé. D'ailleurs si ca vous interesse je peux poster sur le portail le source de la scène en question pour que vous puissiez voir, notamment, les changements de syntaxe apportés depuis les premiers tutoriaux... que je mettrais à jour dans peu de temps.

[sylvain39]

les concepts d'appels et de gestion ont pas mal changé

Je m'en doutais .

si ca vous interesse je peux poster sur le portail le source de la scène en question

Alors la.... je dis OUI.

[lougne]

d'accord,ainsi en mettant un peu de code tu vas satisfaire mon impatience . J'aimerais comprendre un terme que tu as utilisée, shader générique, c'est pour dire shader intégré au moteur ou shader utilisant de générique(je suis presque sûr de la premiére proposition)

2/ Connais tu un bon glossaire , index, tableau de toutes les fonctions de HLSL qui peuvent me servir, car les bouquins c'est bien bon mais pour utilisation immédiate c'est lourd. J'ai ShaderX 2 et ShaderX 3 comme livre

[funkydata]

J'aimerais comprendre un terme que tu as utilisée, shader générique, c'est pour dire shader intégré au moteur

Tout à fait... ceux pas optimisés car compatible plus ou moins avec tous les cas de figures pouvant apparaitre dans la scène.

Connais tu un bon glossaire , index, tableau de toutes les fonctions de HLSL qui peuvent me servir, car les bouquins c'est bien bon mais pour utilisation immédiate c'est lourd. J'ai ShaderX 2 et ShaderX 3 comme livre

Oui en effet, ces bouquins c'est vraiment pas l'idéal pour commencer (c'est peu de le dire ). Le mieux reste les tutoriaux sur internet, tu en as plein. Ensuite je te conseille d'utiliser et de regarder les exemples fournis notamment avec FX Composer (chez NVidia) ou RenderMonkey (chez ATI). Personnellement je prefère FX Composer car il colle bien plus au profil "développeur" que RenderMonkey qui lui est plus (à mon sens) orienté infographiste. Mais bon le mieux est que tu testes les deux pour voir celui qui te plait le plus.

[funkydata]

Code source posté

[MoDDiB]

if (Engine.Init("profil_1024x768x4x16") == false) return;
->Une enum ! une enum ! une enum !
Le reste me semble facile d'accès malgré les nombreuses options.
Petite question : pourquoi ce truc exotique : newMaterial.UVOptions.ScrollX = 0.02f;
et pas une rotation du model de la planète ?

[funkydata]

if (Engine.Init("profil_1024x768x4x16") == false) return;
->Une enum ! une enum ! une enum !

Difficile de faire une enum sur un nom de fichier
En effet "profil_1024x768x4x16" est un fichier xml contenant les paramètres de démarrage du moteur... c'est un fichier d'initialisation si tu préfères.

newMaterial.UVOptions.ScrollX = 0.02f;
et pas une rotation du model de la planète ?

Ici j'applique un scroll UV pour donner l'impression que la planète tourne. J'aurais pu également faire tourner le modèle mais dans ce cas précis le scroll des UV est plus judicieux. Pourquoi ? Parceque la planète est une demi-géosphère donc si tu tournes le modèle...
C'est d'ailleurs pour cette raison que le node de transformation à une méthode de rotation en "AlwaysFacingCamera"... comme ça peut importe le point de vue se sera une sphère Petite astuce pour économiser quelques vertices ou accessoirement augmenter la finesse de la géométrie de la planète...

[lougne]

Ah enfin, voici mes questions:

1/Je constate qu'il ya l'utilisation d'une fonction générique Load<T>(string). De un j'imagine que tous les générique hérite d'une classe du genre Material(T), mais ce que je ne comprends pas c'est le fait que tu ne spécifie pas l'extension comme dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Engine.Contents.Load<TextureCube>("TextureCube")

.
Le string ne posséde pas d'extension .jpd,.dds..... cela signifie t-il que le paramétre générique donne lieu à l'ajout d'une extension (ex:TextureCube.dds), et si c'est le cas, est-il possible qu'il octroie pluisieurs type (jpg,png..) ou chaque paramétre ne donne qu'un type (là ça en fait beaucoup). Explication PLZ

2/En lisant le code, je constate que mon concept de Node, ou SceneManager est un peu léger. As-tu des bons tuto , livres whatever, j'accepte tout.

3/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
// On charge un shader externe au moteur qui va se charger du rendu de l'atmosphère
            // On crée ensuite un matériau associé afin de controler ce shader et de pouvoir l'affecter 
            // à notre modèle
            Material AtmosphereMaterial = new Material(Engine.Contents.Load<Shader>("atmosphere"));
            // On défini les différents paramètres du shader
            AtmosphereMaterial["DiffuseColor"].Set(new Color(1.0f, 0.7f, 0.7f));
            AtmosphereMaterial["ViewPow"].Set(1.0f);
            AtmosphereMaterial["LightPow"].Set(1.0f);
            // On spécifie une transparence par canal alpha pour le modèle
            AtmosphereMaterial.Transparency = eMaterialTransparency.ByAlpha;
            // Par défaut, lors du clonage les matériaux ne sont pas répliqués (surement pas définitif)
            // Donc comme le matériau d'index 0 n'existe pas on en ajoute simplement un nouveau
            PlanetAtmosphereModel[0].AddMaterial(AtmosphereMaterial);

Je demande, non je supplie pour une explication approfondie. En fait ce qui m'intérresse ici, c'est comment sont passés les paramétres au shader. a quel niveau va t-on retrouver le commun effect.setvalue("X",xX);

[funkydata]

1/Je constate qu'il ya l'utilisation d'une fonction générique Load<T>(string). De un j'imagine que tous les générique hérite d'une classe du genre Material(T), mais ce que je ne comprends pas c'est le fait que tu ne spécifie pas l'extension comme dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Engine.Contents.Load<TextureCube>("TextureCube")

.
Le string ne posséde pas d'extension .jpd,.dds..... cela signifie t-il que le paramétre générique donne lieu à l'ajout d'une extension (ex:TextureCube.dds), et si c'est le cas, est-il possible qu'il octroie pluisieurs type (jpg,png..) ou chaque paramétre ne donne qu'un type (là ça en fait beaucoup). Explication PLZ

Le moteur pour charger des médias utilise des codecs. Les codecs s'appuient sur l'interface "IContentCodec". Le codec contient toutes les infos afin de charger le média. Le codec défini (entre autre) :
* le type de médias en entrée-sortie (dans ton exemple il défini une instance de "ITexture")
* les extensions affectées au médias (le codec chargé d'importer les "ITexture" par exemple admet les extensions "dds", "bmp", "tga", "png", "jpg", "hdr")

et diverses autres choses que j'aborderais dans un tuto la dessus.
Pour résumé voilà ce qui ce passe lors de l'appel de la fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Engine.Contents.Load<TextureCube>("MonFichier")

* Recherche d'un codec correspondant au type "TextureCube" -> Trouve un codec pour les objets interfacés avec "ITexture" donc le type "TextureCube" à un codec d'import/export valide.
* Lit le/les extensions supportées par ce codec et cherche récursivement dans le répertoire des médias que tu as spécifié un fichier correspondant. (Trouve par exemple "MonFicher.dds")
* Appel la procédure d'import qui va charger le média et retourne l'objet "TextureCube" utilisant la ressource que tu viens de spécifier.

Tu peux accessoirement fixer l'extension en spécifiant "MonFichier.dds" mais cela ne pourrait être utile que si tu as par exemple un "MonFichier.hdr" dans tes médias. Mais le fait de ne pas renseigner l'extension présente 2 avantages majeurs :

* Le moteur n'importera que les médias pour lequel il possède un codec valide avec une extension valide
* C'est moins long à taper

2/En lisant le code, je constate que mon concept de Node, ou SceneManager est un peu léger. As-tu des bons tuto , livres whatever, j'accepte tout.

Non pas vraiment... C'est plus l'expérience et tes besoins qui vont définir la structure et le fonctionnement de cette partie. Comme je l'ai dit dans un autre post je ne suis pas trés satisfait de cette partie qui va surement subir pas mal de chamboulement d'ici peu... grosso modo les "nodes" représente des entitées indispensables au rendu (transformations, matériaux, données diverses pour le rendu...) et le scenegraph est là pour organiser le tout afin que le rendu soit correctement effectué et le plus rapidement possible.

3/Je demande, non je supplie pour une explication approfondie. En fait ce qui m'intérresse ici, c'est comment sont passés les paramétres au shader. a quel niveau va t-on retrouver le commun effect.setvalue("X",xX);

Les shaders dans le nxEngine sont virtualisés... donc pas de Effect.SetValue. En effet aucun type utiliser par DirectX (Matrices, Vecteurs, Couleurs et autres) n'est utilisé par le moteur dans la mesure ou il utilise des classe propriétaires pour toutes ces données. De plus, un tampon de données est utilisé entre le shader et les paramètres ce qui interdit toutes modifications en direct des paramètres du shader. Mais pour répondre à ta question, la commande "AtmosphereMaterial["ViewPow"].Set(1.0f);" équivaut à un "Effet.SetValue("ViewPow", 1.0f)".
Donc quand tu importes un shader externe dans le nxEngine, il faudra toujours l'affecter à un matériau. Ensuite tu modifieras le matériau comme indiqué dans l'exemple afin d'accedes aux differents paramètres de ton shader.
Par exemple le .fx associé à cet exemple contient les déclarations suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
half ViewPow;
half LightPow;
half4 DiffuseColor;

tu vois donc que "AtmosphereMaterial["ViewPow"].Set(1.0f);" équivaut à un "Effet.SetValue("ViewPow", 1.0f)"

[lougne]

Suite à la discussion sur le SceneGraph, je viens de trouver ce petit truc, RetinaX sur sourceforge