DAZ 3 besoin d'explications

Est-ce que quelqu'un pourrait m'expliquer en gros comment on se sert de ce truc (shader builder) j'ai beau bouger les flèches de couleur dans tous les sens, les connecter à d'autres, rien ne se passe.

Le shader builder de DAZ Studio correspond à l'environnement qui permet de concevoir de manière graphique les 'shaders' utilisés par le moteur de rendu de DAZ Studio, c'est-à-dire 3Delight. Il correspond globalement à son homologue chez Poser (onglet Material), au laboratoire de Bryce, etc. Mais en étant bien sûr totalement dédié au moteur 3Delight.

Ce qu'il faut savoir c'est que le moteur 3Delight est un moteur de type Renderman (une norme de description pour le rendu d'image créée par les studios Pixar pour la réalisation de films de synthèse) et que les shaders Renderman sont du code informatique (une sorte de langage avec une syntaxe à la langage C ou Java avec des fonctions spécifiques pour le rendu d'images). Il a donc toujours été possible de développer des shaders pour DAZ mais sous la forme de programmes informatiques. Avec la version 3, DAZ propose d'écrire du code via un graphe, ce qui explique le bouton "Compile" qui compile (au sens informatique du mot) le code généré dans du code compréhensible par le moteur 3Delight. C'est peut-être ce qui explique que tu n'arrives pas à grand-chose si tu ne compiles pas le shader.

Maintenant, comment programmer via l'arborescence ?

C'est là le plus gros problème car les noeuds proposés par l'interface (les cases d'où sortent et rentrent les flèches) sont les correspondances des fonctions Renderman, avec en plus des noeuds mathématiques pour faire des opérations (addition, multiplication, etc.). Donc, pour comprendre le sens des entrées et des sorties (les Ci, Oi, N, Nn, etc.) et comment il faut les agencer, il faut se référer à la description des fonctions de Renderman, donc acheter des livres sur le sujet ou aller glaner quelques rares informations sur le sujet sur le Web (il faut savoir que pour Renderman, un shader correspond à un besoin souvent spécifique : un développeur écrit un shader pour la couleur du pistolet du cow-boy dans Toy Story et ce shader ne sert qu'à cela, pour les autres textures du film, on écrit d'autres shaders ! Les compétences en matière d'écriture de shaders sont donc des compétences pointues et rares qui se monnayent dans les studios hollywoodiens - donc on a peu d'informations gratuites sur le Web !).

En fait, DAZ n'a fait que fournir un outil graphique qui évite de saisir du texte dans un éditeur de code mais qui ne cache en rien la complexité de l'écriture d'un shader dans Renderman. Cela explique probablement le peu de nouveautés coté shader dans DAZ 3 depuis sa sortie et la disponibilité de l'outil.

Ah, le Material Room alias Shader Builder Vaste programme...
Je n'ai pas encore entrepris de m'y atteler mais il y a une discussion sur Renderosity qui compile une volée de liens vers des tutoriaux en tout genre (sur la Material Room de Poser mais le principe est identique). Hope this help.

habot a écrit:

(sur la Material Room de Poser mais le principe est identique). Hope this help.

C'est vrai que le principe de l'interface est le même : des noeuds qu'on relie avec des fils afin de les connecter et transférer les résultats des uns (les sorties) vers les entrées des autres.

Par contre, pour DAZ, les noeuds sont directement les équivalents des interfaces de fonctions très pointues et très spécialisées dont l'utilisation est d'autant plus complexe qu'elle n'est pas ou peu documentée. D'ailleurs, je ne suis même pas sûr qu'une documentation aide vraiment à ce niveau car expliquer à un utilisateur "standard" que l'entrée est le "coefficient multiplicateur de la décroissance exponentielle de l'effet Fresnel pour le calcul des reflets spéculaires d'une illumination dans un modèle Oren-Nayar" ne va pas l'aider à faire ses propres shaders (d'ailleurs l'utilisateur standard doit rester un consommateur des modules payants ajoutant des shaders dans DAZ ).

En fait, je suis persuadé que cette interface a été réalisée pour 0,0001% des utilisateurs de DAZ qui ont demandé à corps et à cris d'avoir la même chose que dans Poser. Mais je doute de l'utilité pratique à grande échelle sauf pour quelques utilisateurs/concepteurs/créateurs très très avertis (comme le créateur des Uber-produit chez DAZ) qui d'ailleurs n'ont pas eu besoin de cela pour en créer.

Le problème est d'ailleurs similaire pour Poser mais à un niveau quand même moindre au sens où le "Material Room" reste abordable pour une utilisation simple. Mais la plupart des shaders Poser (Poser 6+) diffusés actuellement avec les bons produits sont des shaders hyper-complexes (jusqu'à plusieurs dizianes de noeuds) et sont générés par de la programmation externe à l'outil Poser.

Woaw! many thanks my friends, je crois que je suis mal parti pour me servir de cet outil, je vais fouiller un peu plus Renderosity, ce qui me gêne un peu c'est cette manie de faire des tutos en vidéo, je n'ai aucun problème pour lire ou parler l'anglais mais par contre, un tuto video fait par un américain, pour peu qu'il soit Texan c'est vraiment galère à suivre.
Mais je pense qu'après ce que dit Bison je ne vais pas trop m'attarder sur le sujet, surtout moi qui fait une allergie violente aux maths. C'est quand même dommage, j'aime bien Daz studio, mais là ils sont quand même bizarre chez Daz d'aller coller un truc hyper complexe dans un logiciel aussi simple. Tant pis, je vais aller faire un peu chauffer Vue, ça va me calmer.

Encore merci à vous.

Bison Ravi a écrit:

En fait, je suis persuadé que cette interface a été réalisée pour 0,0001% des utilisateurs de DAZ qui ont demandé à corps et à cris d'avoir la même chose que dans Poser.

Je pense qu'il y a un peu plus d'utilisateurs que ça qui on envie d'aller plus loin avec les Shaders. Il y avait déjà une solution avec la v2, un complément Java nommé Eilir Material Room. On en a parlé longuement sur les forum de Daz3D.

Christian a écrit:

... je vais fouiller un peu plus Renderosity...

Sinon tu peux aussi titiller Google avec Renderman, RSL, Renderman Shading Language

Christian a écrit:

Mais je pense qu'après ce que dit Bison je ne vais pas trop m'attarder sur le sujet, surtout moi qui fait une allergie violente aux maths. C'est quand même dommage, j'aime bien Daz studio, mais là ils sont quand même bizarre chez Daz d'aller coller un truc hyper complexe dans un logiciel aussi simple.

Si tu es intéressé par le sujet, ne t'arrête surtout pas par ce que j'ai dit ! Mais je pense qu'il est mieux de ne pas te cacher que ce n'est pas un domaine évident... Dans tout voyage, il est mieux de bien s'équiper que de partir la fleur au fusil

Ce n'est pas que le domaine soit plus compliqué qu'autre chose, simplement tout ce qui touche au texturage procédural (c'est-à-dire calculé par le moteur de rendu) fait appel à des procédés de simulation du comportement de la lumière, ce qui finit par se traduire par des algorithmes (comment le moteur simule les trajets de la lumière, crée les ombres, etc.), de la géométrie (comment ces trajets se propagent, se réfléchissent, se réfractent, se divisent, s'amoindrissent dans un milieu ambiant comme un brouillard, etc.) et des simulations de comportement (réflexions anisotropiques sur les cheveux ou le métal brossé, réflexion en sous-couche pour la peau, le lait ou l'ambre, etc.). C'est tout cela qui est matérialisé directement ou indirectement dans les interfaces de description des matériaux et sans compréhension des phénomènes simulés, on ne peut comprendre de quoi parle ces interfaces. Imagine un utilisateur ne sachant pas compter devant une application de comptabilité !

De plus, ce n'est pas la faute à DAZ Studio même si les concepteurs ont préféré donner un accès brut à la définition des shaders plutôt que de tenter de masquer la complexité derrière des simplifications qui peuvent ensuite être des freins à la puissance du moteur. Pour Poser, il m'a fallu pas loin de 4 mois pour trouver une information valable sur le Net concernant les canaux appelés alternate_diffuse et alternate_specular ; tout cela pour juste découvrir que ce sont deux canaux qui permettent d'ignorer les procédures de calcul par défaut (lumière diffuse et spéculaire) et les remplacer par d'autres méthodes pour justement simuler d'autres matières. Le problème est qu'il n'existe pas de documentation claire car il faudrait pas mal de chapitres préliminaires avant d'aborder le sujet. Je reprend mon analogie : imagine un manuel d'un logiciel de comptabilité dont les 20 premiers chapitres sont des cours d'arithmétique requis pour comprendre au chapitre 21 ce qu'est un bilan comptable !

habot a écrit:

Bison Ravi a écrit:

En fait, je suis persuadé que cette interface a été réalisée pour 0,0001% des utilisateurs de DAZ qui ont demandé à corps et à cris d'avoir la même chose que dans Poser.

Je pense qu'il y a un peu plus d'utilisateurs que ça qui on envie d'aller plus loin avec les Shaders.

Avoir envie, c'est indéniable. Le pouvoir ensuite, c'est autre chose !

J'ai compris l'utilité c'est déjà un point, comme dit Wiki c'est un outil de communication entre le modeleur et le moteur de rendu.
Ensuite, deux choses me plaisent bien :
1 - le Visual effects supervisor de WETA digital dit "Renderman is the ultimate creative tool. It's the easyest and most flexible way to create a picture from an idea" donc d'après lui c'est fastoche. MDR
2 - je suis allé faire un tour sur un site d'images réalisées avec renderman et là effectivement j'ai pu constater que les rendus étaient très chouettes.
c'est ici dans la section renderman
Alors finalement je vais quand même "essayer" de comprendre un peu plus ce machin.

Les informations que tu vas glaner te serviront certainement vu que 3Delight n'est jamais qu'un autre fork de Renderman.

Christian a écrit:

... sur un site d'images réalisées avec renderman et là effectivement j'ai pu constater que les rendus étaient très chouettes.

... comme D|S utilise le même ... YAPUKA

habot a écrit:

... comme D|S utilise le même ...

Si ma mémoire est bonne (ce dont je doute parfois, c'est l'âge ), DAZ Studio 2 avait un module d'extension qui permettait de faire des rendus avec un autre moteur compatible Renderman comme Pixie par exemple. Je ne sais pas ce que c'est devenu en V3 ?

Comme Iglesias ... ça n'a pas changé
Render Setting / Render to RIB ... et c'est sans doute resté la même galère

OK !! vous allez encore penser que ce truc est pour moi quoi ??

Je suis occupé à faire mes notes. Je regarde ce système depuis la v2 (d'autant que les Shaders de la v2 permettaient - enfin, au moins un - de faire la même chose) avec Eilir.

Une des premières utilisations simple sera quand même l'utilisation de textures procédurales qui peuvent, parfois, avantageusement remplacer les map (ou en créer si on exploiter la partie Shader Baking de D|S3A).

d-jpp a écrit:

... vous allez encore penser que ce truc est pour moi quoi ?

Non, pas nécessairement mais, ceci dit, si le coeur t'en dit et que tu as envie de faire des phrases courtes

habot a écrit:

Une des premières utilisations simple sera quand même l'utilisation de textures procédurales qui peuvent, parfois, avantageusement remplacer les map

C'est clair ! Une texture actuelle de V4 en 4000 x 4000 encodée sur 24 bits (1 octet par couleur en RGB) coûte 46,9 Mo de RAM pour le corps, idem pour le visage et les membres, plus 3 x 16 Mo pour la carte de bump-mapping (corps + visage + membres, l'image occupe moins de place car en niveau de gris), plus 3 x 16 Mo pour la carte de spécularité. Total des courses : 140 Mo de RAM en oubliant volontairement les yeux, les lèvres, les ongles et autres tatouages... Et ce rien que de textures ! Et on n'a pas les cheveux, ni les vêtements (parfois absents )

Il faut au moins cela pour un gros plan, mais pour un personnage sur pied, une réduction des dimensions des fichiers (sur des copies des fichiers !) est un excellent truc pour diminuer les ressources nécessaires pour le rendu de l'image.

Donc :

• Gros plan : supprimer les textures des parties non cadrées dans l'image et laisser en blanc.
  
• Sur pied : récupérer les fichiers des textures, les copier ailleurs, les réduire avec une application 2D (du 2000x2000 est largement suffisant et les textures de bump-map ou de spécularité peuvent se contenter d'un 1000x1000).

Et votre ordinateur vous remerciera en calculant vos images plus rapidement

Cela marche aussi sur une combinaison intégrale non transparente : cela ne sert à rien de coller une texture sur des membres recouverts par un vêtement !

Je supprime également les parties non visibles, pas seulement la texture mais les morceaux de membres tout entiers, je supprime aussi régulièrement les machoires, dents, langue (quand le modèle ne sourit pas) c'est toujours des polygones en moins. Sur Vue je choisis également l'option qui consiste à ne calculer que ce qui est visible.
Autre chose, en fouillant internet pour me documenter sur ce sujet, j'ai trouvé un site qui contient une quantité de tutoriels sur tous les softs existants, sauf bien sûr celui que je cherchais, mais pour le reste c'est complet. (En anglais bien sûr)
C'est tutorialhero.com

d-jpp a écrit:

--- L.O.D. -----
.. Level of details ...
just I saied

Je ne comprends pas trop ton message mais la référence à la technique du LOD n'est pas vraiment en relation avec les textures. Elle concerne les maillages géométriques et les niveaux de subdivision applicables à un modèle. En ce sens, il s'agit d'une "intelligence" du moteur de rendu qui utilise le niveau de maillage adéquat pour éviter des maillages trop fins sur des objets éloignés ou des maillages trop grossiers sur des objets rapprochés.

Si on reprend dans l'ordre

1) c'est moi qui ai proposé de faire "court"
2) d-jpp donne une solution qui diminue le nombre de polygones sur v4
3) c'est un bon complément à ton astuce (celle ne couper les membres non vus charge quand même les maps en mémoire).

Bonne annnée à tous

Pourtant Habot, quand j'exporte V4 dans Vue par exemple, après avoir supprimé les membres "inutiles" dans Daz, ceux-ci n'existent plus arrivés dans Vue, donc les polygones non désirés n'ont pas suivi.

Je m'explique :
V4 complète exportée - 373 ko de maps - 4ko de MTL - 10,50 Mo pour l'objet
V4 avec bras, cuisses, intérieur de la bouche enlevés - 373 ko de maps - 4ko MTL - 7,24 Mo pour l'objet
Gain : 3,26 Mo
Dans le premier cas 132050 polygones
Dans le second 90010 polygones
L'intérieur de la bouche seul (dents, machoires, langue) fait à lui seul 1,71 Mo !

Lorsque j'importe plusieurs persos, le logiciel me signale "out of memory", en pratiquant la suppression des zones inutiles il les accepte. Bien sur que les maps entières suivent, quoique sur le fichier maps je peux intervenir et supprimer également tout ce qui me gêne pour réduire le poids de façon très conséquente, Photoshop est là pour çà.

Avec ces méthodes, je n'ai aucun ralentissement pour travailler les scènes énormes.

En ce qui concerne le rendu, c'est une autre histoire, j'ai trouvé des tutos sur RR (pour Vue) qui expliquent certains réglages pour gagner du temps de rendu sans trop perdre de qualité.

Je n'utilise que Daz Studio donc ce que je raconte ne s'applique qu'à Daz Studio

Deux liens que j'ai trouvés sur le site de DAZ et qui mènent vers des vidéos sur YouTube : partie 1 et partie 2.

Malheureusement, c'est en américain (c'est-à-dire de l'anglais parlé avec un chewing-gum et un bout de hamburger simultanément dans la bouche ) et sans les explications, les vidéos sont arides. Mais enfin c'est mieux que rien ! Par contre, si vous arrivez à les comprendre, les vidéos sont véritablement instructives.

tutot infernal car en plus de la bouillit a l'américaine you tube avance par a coups ..
si au moins les a coup tombaient entre les phrases ... mais nom juste au milieux ...infernale je vous dit ....
majedo! les informations que contiennes ces vidéo sont de première bourre( les imaes sans le son parlent déjà pas mal )