7 réponses à ce sujet

[Jean-Marc Le Roux]

Bonjour,

comme vous le savez, la création d'effets graphiques est en 3D une tâche tout aussi compliquée qu'essentielle. Pour simplifier ce travail, Minko permet de programmer le GPU directement en ActionScript. C'est une petite révolution qui permettra de vous simplifier la vie. Nous publierons bientôt des tutoriaux à ce sujet sur le Hub.

Pour vous permettre d'impliquer les graphistes dans ce processus de création, nous travaillons actuellement sur un outil: le "shader lab". Cet outil permettra aux graphistes et aux développeurs de travailler ensemble pour créer des shaders sans aucune programmation. L'outil propose un environnement de développement visuel qui ne nécessite aucune connaissance en code et permet de programmer le GPU directement dans une web application.

Voilà une première preview :



Pour l'instant, les possibilités restent très bas niveau et sont calquées sur des opérations atomiques simples (addition, multiplication, etc...). Mais comme le montre la vidéo, nous sommes en train de rajouter des opérations bien plus haut niveau, par exemple la possibilité de créer des effets graphiques qui dépendent du son.

Nous voulons recréer un éditeur de matériaux tel que celui proposé par 3D Studio Max - et donc connu des graphistes - mais disponible dans une application Flex et adapté à la 3D temps réel pour Flash. Si vous avez des suggestions, des propositions ou des idées, n'hésitez pas à réagir !

[tlecoz]

Hello !

Ce n'est pas évident d'évaluer un outil sans l'essayer, mais j'ai regardé la vidéo plusieurs fois et voilà ce qui me vient.

Actuellement, sans vouloir minimiser le travail accompli, j'ai un peu l'impression que le shaderLab offre plus une manière de programmer un shader à la souris que de créer un shader sans programmer. Les graphs présents dans les démos sont beaucoup plus explicite que le code AGAL équivalent mais cela reste quand même hyper abstrait.

Dans la démo mettant en scène un SoundSpectrum par exemple, ca part un peu dans tout les sens alors qu'on fait pourtant quelque chose de relativement simple (je ne doute pas que le cheminement pour faire cette chose "simple" soit compliqué et je ne veux pas dire qu'il y a du code en trop, je n'en sais rien, mais le rapport entre 'information à l'écran' / 'propriétés modifiable vraiment voulue' ne me parait pas assez efficient pour un graphiste).


Histoire d'émettre une critique constructive, j'ai essayé de recopier le graph correspondant au soundSpectrum et de le réorganiser (ca m'a pris la nuit à vrai dire ^^)

Voila le graph que j'ai recopié (je n'ai pas recopié les "in"/"out" , je ne pensais pas y passer tant de temps quand j'ai commencé)



Je me suis dit que si j'étais un graphiste qui voulait faire ça, j'aurais tendance à décomposer le projet en 2 partie distincte :
- la gestion du mouvement du maillage (-> Motion)
- la gestion de la lumiere/couleur (-> Material)

Je sais que la force de Minko est de réutiliser autant que possible les éléments déjà utilisé pour améliorer les performances, mais je pense qu'on peut faire la même chose de manière implicite (en codant une couche supèrieure).

J'ai essayé de démêler le graph pour le décomposer en une partie ne s'occupant que du mouvement



et une autre ne s'occupant que de la création d'un 'Material'



Les textes écrits en rouge représentent les 'constantes' ; le bloc entouré de rouge met en évidence les éléments communs aux deux graphs. Ce bloc représente plus ou moins le Mesh sur lequel on va appliquer les transformations.


Actuellement toutes les opérations sont définies explicitement : il y a un bloc pour chaque type de calcul et on peut créer n'importe quelle fonction en reliant les blocs entre eux. Ca fonctionne mais le graph devient vite gigantesque.

Pour palier à ce problème,je vois deux solutions complémentaire :
- utiliser une notion d'échelle permettant de regrouper certaines opération au sein d'un même bloc d'un niveau plus haut, comme des composants en quelques sorte.
- supprimer les bout de code nécessaire et non parametrable (faire en sorte que ces opération se passent de manière implicite)


J'ai donc essayé de décomposer ces graphs par "type d'opérations"

Les blocs verts représentent les 'outils'
Les blocs bleu représentent les 'variables'
Les blocs rouge représentent ce qui , je pense, pourrait être des données implicite n'ayant pas besoin d'être affichées



J'ai mis en rouge toute la fin du graph 'motion' car elle pourrait être traduite par "applique l'effet en prenant en compte la position du Mesh". Je suppose (mais je me trompe surement) que cette opération concerne toute les type de calcul lié à l'animation d'un maillage ; si tel est le cas, on peut la généraliser et l'enlever du graph.









J'ai mis en rouge casiment toute les opération lié à la création de l'effet de lumière car je ne pense pas qu'un graphiste utilisera de lui-même le bloc 'normalize' ou 'dotProduct'.
Selon moi, si un graphiste veut créér un effet de lumière il voudra avant tout définir la couleur de la lumière et sa position.

L'idéal serait de pouvoir poser un bloc 'directional Light' mais en conservant la possibilité, pour les devs, de rentrer dedans (de la meme manière qu'on rentre dans un MovieClip dans Flash quand on double clic dessus) pour voir comment l'objet est construit et, eventuellement, pour l'éditer.









Enfin, j'ai essayé de reproduire tout le graph en prenant de compte ce que je viens de dire plus haut





En haut du graph, j'ai "créé" de nouveaux bloc à partir d'un groupement de bloc. Ce n'est pas absolument nécesasire mais ca me paraissait plus lisible. En faisant cela, je me suis dit que ça pourrait être pratique d'intégrer cette fonctionnalité dans le shaderLab si ce n'est pas déjà le cas (ainsi qu'un répertoire 'custom' répertoriant tout les blocs de plus haut niveaux créés, dans la library située à gauche de l'écran du shaderLab).


Voila ...!
J'ai probablement fait quelques erreurs dans ma compréhension du graph original car je n'ai jamais codé de Shader, mais j'espère ne pas mettre complètement planté non plus ^^
C'était passionnant à faire en tout cas

[Jean-Marc Le Roux]

Merci pour toutes ces suggestions et les schémas qui permettent de bien expliquer ton point de vue !
Tu seras content d'apprendre que les fonctionnalités dont tu parles sont déjà en cours d'élaboration

Comme dit dans la description de cette vidéo, il s'agit d'une première version qui permet de faire de créer un shader AGAL en live. Des noeuds de (très) haut niveau seront disponibles, et une autre fonctionnalité très importante qui ressemble un peu à ce que tu as évoqué.

La séparation du vertex et du fragment shader est une problématique plus large qui a des implications à d'autres niveaux et nous n'avons pas pris de décision à ce niveau là. Un des gros problème est le fait qu'ils sont parfois très intimement liés. Par exemple, lorsqu'on anime la sphère en fonction du son dans le VS, on a aussi besoin de cette nouvelle position dans le FS...

Je pense que cette séparation sera donc faite plus au niveau des options offertes par l'UI qu'à un niveau fonctionnel.

Il y'a encore beaucoup beaucoup de fonctionnalités qui n'ont pas été traitées dans ce que nous avons montré jusqu'ici.
Si tu as d'autres questions/suggestions n'hésite pas.

a+

[tlecoz]

Citation

Par exemple, lorsqu'on anime la sphère en fonction du son dans le VS, on a aussi besoin de cette nouvelle position dans le FS...

J'ai tendance à penser que la partie concernant les VertexShader sera toujours effectué avant la partie concernant les fragmentShader car ça me parait plus logique de définir une zone à dessiner et de peindre dedans, plutôt que de peindre une zone puis de définir ce qui doit être dessiner.

Si ça marche vraiment comme ca, ne peux t on pas simplement partager la référence de l'objet 'VertexPosition'

var vertexPosition:VertexPosition = new VertexPosition()
var vertexShader:VertexShaderLab = new VertexShaderLab(vertexPosition);
var fragmentShader:FragmentShaderLab = new FragmentShaderLab(vertexPosition);
 

Si le traitement est asynchrone il ne devrait pas y avoir de problème (?)

[Jean-Marc Le Roux]

[quote name='tlecoz' timestamp='1320598139' post='845416']
J'ai tendance à penser que la partie concernant les VertexShader sera toujours effectué avant la partie concernant les fragmentShader car ça me parait plus logique de définir une zone à dessiner et de peindre dedans, plutôt que de peindre une zone puis de définir ce qui doit être dessiner.
[/quote]

Si tu regardes attentivement, ce qui se passe dans le VS est en bleu, ce qui se passe dans le FS est en rouge
Ca ne se voit pas beaucoup, mais c'est beaucoup plus visible dans la nouvelle version de l'interface qui et plus jolie est plus claire.

[quote name='tlecoz' timestamp='1320598139' post='845416']var vertexPosition:VertexPosition = new VertexPosition()
var vertexShader:VertexShaderLab = new VertexShaderLab(vertexPosition);
var fragmentShader:FragmentShaderLab = new FragmentShaderLab(vertexPosition);
[/code]

Je ne vois pas trop où tu veux en venir avec ce bout de code

a+

[tlecoz]

Citation

Si tu regardes attentivement, ce qui se passe dans le VS est en bleu, ce qui se passe dans le FS est en rouge

Peux tu poster une capture d'écran représentant le graph du soundSpectrum, parce qu'a partir d'une vidéo c'est pas facile

Citation

Je ne vois pas trop où tu veux en venir avec ce bout de code

Citation

La séparation du vertex et du fragment shader est une problématique plus large qui a des implications à d'autres niveaux et nous n'avons pas pris de décision à ce niveau là. Un des gros problème est le fait qu'ils sont parfois très intimement liés.

J'essayais de montrer que si comme je le pense (mais je me trompe sans doute) les VertexShader sont traités avant les FragmentShader, alors ils n'ont pas vraiment besoin d'être lié. Ils peuvent simplement partager les même objets.

Je reprend mon bout de code, avec des commentaires

//on créé un bloc VertexPosition dont la référence sera partagé par l'objet
//s'occupant du VertexShader et par celui s'occupant du FragmentShader
//cet objet peut être partagé car il est la clé de voute du shader (si j'ai bien compris...)

var vertexPosition:VertexPosition = new VertexPosition()
var vertexShader:VertexShaderLab = new VertexShaderLab(vertexPosition);
var fragmentShader:FragmentShaderLab = new FragmentShaderLab(vertexPosition);

//au moment de la compilation des shader, il faudra sans doute faire quelque chose comme ca

vertexShader.process();
fragmentShader.process();

//mais entre les deux appels à 'process' les valeurs contenues dans VertexPosition
//auront changé car elles auront été transformé par le VertexShader.

//du coup les objet ne sont plus imbriqué mais juste executé l'un aprés l'autre,
//tout en utilisant un seul objet

//cette méthode n'est pas viable ?
 

EDIT: Ouais non en fait, après reflexion, ca marche pas comme ça car le moment de la compilation n'a rien a voir avec le moment de l'execution

[tlecoz]

Citation

Des noeuds de (très) haut niveau seront disponibles, et une autre fonctionnalité très importante qui ressemble un peu à ce que tu as évoqué.

Super !!!

Est ce que ce sera un outil gratuit ?

(parce que je me rend compte que ça représente pas mal de boulot, et je crois me rappeler qu'initialement Minko devait être payant (cf : back-from-max de l'année dernière) )

[Jean-Marc Le Roux]

tlecoz, le 06 November 2011 - 21:12 PM, dit :

Est ce que ce sera un outil gratuit ?

(parce que je me rend compte que ça représente pas mal de boulot, et je crois me rappeler qu'initialement Minko devait être payant (cf : back-from-max de l'année dernière) )

Les outils seront tous accessibles via un compte Aerys ID gratuit.
Mais certaines fonctionnalités seront réservées à des comptes premium qui seront, eux, payant.

Cela dit, les prix resteront extrêmement attractifs.
Nous donnerons plus de détails sur tout ça dans les prochains mois.

a+