37 réponses à ce sujet

[tlecoz]

Hello la communauté !

J'aimerais créer un bout de code AGAL qui retrouverait les composante RGB d'un code couleur (uint).

On ne peut faire que des opération mathématique en AGAL, il n'est pas possible d'utiliser toString(16) ni les opérateur binaires.

Je cherche depuis pas mal de temps maintenant, mais je trouve tout le temps les memes code du type

//24bit
var color:uint = 0x336699;
var r:uint = color >> 16;
var g:uint = color >> 8 & 0xFF;
var b:uint = color & 0xFF;
//32bit
var color:uint = 0xff336699;
var a:uint = color >>> 24;
var r:uint = color >>> 16 & 0xFF;
var g:uint = color >>>  8 & 0xFF;
var b:uint = color & 0xFF;
 

Ces bouts de code font exactement ce que je veux à ceci prés qu'ils utilisent les opérateur binaires, et je n'y ai pas accés en AGAL

Quelqu'un connait il le calcul mathématique qui se cache derriere les codes couleurs, et surtout quelqu'un connait il un moyen de récuper les différente composante de manière mathématique ?

Merci d'avance !

[Jano 95]

Salut.

var hexa:String = "FF3366";

var nb:String = "0123456789ABCDEF";

var r:Number = nb.indexOf(hexa.substr(0,1)) + nb.indexOf(hexa.substr(1,1))*16;
var g:Number = nb.indexOf(hexa.substr(2,1)) + nb.indexOf(hexa.substr(3,1))*16;
var b:Number = nb.indexOf(hexa.substr(4,1)) + nb.indexOf(hexa.substr(5,1))*16;

trace(r+"  "+g+"  "+ b );
 

Inspiré de http://translate.goo...ff/HEX2DEC.html

[Jano 95]

Petite erreur corrigée.

var hexa:String = "FF0566";
var nb:String = "0123456789ABCDEF";
var r:Number = nb.indexOf(hexa.substr(1,1)) + nb.indexOf(hexa.substr(0,1))*16;
var g:Number = nb.indexOf(hexa.substr(3,1)) + nb.indexOf(hexa.substr(2,1))*16;
var b:Number = nb.indexOf(hexa.substr(5,1)) + nb.indexOf(hexa.substr(4,1))*16;
trace(r+"  "+g+"  "+b );
 

[dldler]

A vu de nez, je dirais :

var color:uint = 0x336699;
var r:uint = (color / (256*256))%256;
var g:uint = (color /256) % 256;
var b:uint = color % 256;
 

[tlecoz]

@Jano
Merci pour ta réponse mais je ne peux pas utiliser la classe String, la solution doit etre 100% mathématique car l'AGAL ne comprend que ca

@Didler

Citation

A vu de nez, je dirais :




var color:uint = 0x336699;
var r:uint = (color / (256*256))%256;
var g:uint = (color /256) % 256;
var b:uint = color % 256;

Merci infiniment !

Je n'ai pas le temps de tester tout de suite (j'ai 1h de retard a un rdv...) mais je testerai ce soir en rentrant!
J'espère que ça va marcher !



EDIT : Excuse moi d'en rajouter, mais peux tu me donner également les calculs qui vont bien dans le cas d'un code couleur ARGB

Merci d'avance !

[dldler]

C'est toujours le même principe.
Division par la valeur 1 de la composante désirée, puis un modulo de 256.

Donc :

var color:uint = 0xFF336699;
var a:uint = (color / (256*256*256))%256;
var r:uint = (color / (256*256))%256;
var g:uint = (color /256) % 256;
var b:uint = color % 256;
 

[tlecoz]

Merci Didler !

Cela dit, je viens de tester ton code RGB et je n'ai pas l'impression que ça fonctionne (mais ça vient peut etre de la maniere dont je fais le modulo en agal et puisque je ne peux pas debugger en agal...).

Pour l'instant j'obtiens un camaieu de rouge...

[dldler]

:-/

Je ne connais pas l'agal alors je ne peux pas t'aider beaucoup plus.

J'ai tracé le code, et j'obtiens bien les bonnes valeurs en AS3. On peut donc supposer que le code est correct…



Voilà le même avec un modulo maison… attention au type uint.

var color:uint = 0xFF336699;
var a:uint = modulo(color / (256*256*256));
var r:uint = modulo(color / (256*256));
var g:uint = modulo(color /256);
var b:uint = modulo(color);
trace (a.toString(16));
trace (r.toString(16));
trace (g.toString(16));
trace (b.toString(16));
function modulo ($value:uint):uint
{
return $value - uint($value / 256) * 256;
}
 

[tlecoz]

Merci Didler !
Je m'y recolle !

[tlecoz]

Ca ne fonctionne toujours pas , je poste mon code agal au cas ou quelqu'un voit l'erreur

"mov vt2, va0 \n"+        //va0 est un FLOAT3
"mov vt3, va0 \n"+        //va0 est un FLOAT3

//va4.x -> uint color
//vc12.y -> 256 * 256
//vc11.w -> 256

//--RED--
"div vt2.x, va4.x, vc12.y \n" +   //r = color / 256*256  |
"div vt3.x, vt2.x,vc11.w \n" +  //_r = (color / 256*256) / 256
"sub vt2.x, vt2.x,vt3.x \n"+    // r = r - _r;

//--GREEN--
"div vt2.y,va4.x,vc11.w \n" +    //g = color / 256        |
"div vt3.y, vt2.y,vc11.w \n" +  //_g = g / 256
"sub vt2.y, vt2.y,vt3.y \n"+    //g = g -_g
 
//--BLUE--
"div vt3.z, va4.x,vc11.w \n" +  //_b = color / 256
"sub vt2.z, vt2.z,vt3.z \n"+    //b = b - _b
 

Merci d'avance !

[tlecoz]

Je n'ai pas réussi à coder ce passage ; ca m'agace car j'ai réussi à faire tout le reste sans trop de problème...
Je m'y suis pris autrement, c'est moins optimisé mais ca fonctionne quand même.

Si vous voulez voir ce que ca donne, voila mon premier shader AGAL :
http://www.beginfill.com

(machinbidules.com ne marche plus, voila le nom de mon futur blog, pour l'instant ya que ca dessus )

[dldler]

Hello.

2 petites questions :
- je ne trouve pas de liens vers le langage AGAL, tu peux me trouver un point d'entrée ?
- y a t'il une fonction permettant d'avoir la partie entière d'un nombre (notre Math.floor() en AS3) ?

[dldler]

Bon.
Juste pour jouer…

… En supposant :
- qu'il y a bien une fonction floor,
- qu'elle s'appellerait flo…
- que la multiplication s'appelle mul
- et que j'ai a peu près compris la syntaxe, ça donnerait ça :

// Utilisation de constantes
// vc12.w = 0x1000000;// Calcul de l'alpha
// vc12.x = 0x10000;// calcul du rouge
// vc12.y = 0x100;// Calcul du vert

// définition de la couleur
// va4.x = 0xFF996633;

// Les résultats sont stockés dans une variable vt2
// vt2.w // alpha
// vt2.x // red
// vt2.y // green
// vt2.z // blue

// Les calculs temporaires sont stockés dans une variable vt3
// vt3.w // alpha
// vt3.x // red
// vt3.y // green

//--ALPHA--
"div vt3.w, va4.x, vc12.w \n" + // Décalage vers la droite
"flo vt2.w, vt3.w \n" +  // Puis arrondi
"mul vt3.w, vt2.w, vc12.w \n" + // Décalage inverse
"sub va4.x, va4.x, vt3.w \n"+  // Soustraction de la part calculée
//--RED--
"div vt3.x, va4.x, vc12.x \n" +
"flo vt2.x, vt3.x \n" +
"mul vt3.x, vt2.x, vc12.x \n" +
"sub va4.x, va4.x, vt3.x \n"+
//--GREEN--
"div vt3.y, va4.x, vc12.y \n" +
"flo vt2.y, vt3.y \n" +
"mul vt3.y, vt2.y, vc12.y \n" +
//--BLUE--
"sub vt2.z, va4.x, vt3.y \n"+
 

Fais attention, j'ai modifié le nom de certains trucs qui semblaient te servir de constantes et de variables temporaires de calcul pour avoir quelque chose d'un peu plus clair à mon goût

PS : au fil des calculs, je détruit la couleur initiale (va4.x). Si tu veux la conserver, tu dois utiliser à la place une variable temporaire (vt3.z est disponible par exemple…)

[tlecoz]

Salut Didler !

Merci encore, malheureusement il n'y a pas de Math.floor en AGAL ...

Citation

je ne trouve pas de liens vers le langage AGAL, tu peux me trouver un point d'entrée ?

Voila la doc (tu verras c'est court ):
http://members.iinet...l/pb3d/AGAL.pdf

Tu trouveras d'autres précisions et d'autres liens ici : http://en.nicoptere.net/?p=2194

[dldler]

OK
J'ai vu :
http://help.adobe.co...4ec56-8000.html


Mais c'est pauvre en instructions :-) Je ne suis pas sûr d'avoir pu aider.

[tlecoz]

Un autre site avec des tutos pas mal :
http://pierrechamber...rs-texture-agal

[tlecoz]

Merci pour ce lien en francais que je n'avais jamais vu auparavant

Citation

y a t'il une fonction permettant d'avoir la partie entière d'un nombre (notre Math.floor() en AS3) ?

En AGAL , les couleurs sont géré par des nombres compris entre 0 à 1, pas entre 0 et 256. Il est important ce Math.floor ?

[dldler]

A ce stade, je suis dans un flou total… Le floor est important si tu n'as pas de type int ou uint…
Dans le calcul que je te proposais, il permettait de soustraire les valeurs déjà calculées… mais ça se passe tout en uint… Avec des nombres, je n'en sais fichtrement rien. ça chamboule tous mes neurones.
je laisses décanter un peu et je te dis ce qu'il en ressort.

Du coup, je ne suis même plus trop sûr de comprends ta consigne…
Tu as une valeur argb en uint, et tu veux en récupérer les valeurs a,r,g,b sous la forme de 0.2, 0.1, 0.9, 1 ?

[dldler]

Ce qui est fou, c'est que je n'ai même pas le début d'un semblant d'idée de comment faire le premier test…

Regarde toujours là, quand même =
frc 0x08 fractionnaire destination = source1 - (float)floor(source1), au niveau du composant

Ça semble te donner la partie fractionnaire d'un nombre… Si oui, je peux l'intégrer dans le code précédent. Mais sert-il vraiment à quelque chose ?

[dldler]

Bon.
Après, je me repose.
C'est vraiment ardu comme shéma de pensée.

//--ALPHA--
"div vt3.w, va4.x, vc12.w \n" + // Décalage vers la droite
"frc vt3.x, vt3.w" +
"sub vt2.w, vt3.w, vt3.x" +
"mul vt3.w, vt2.w, vc12.w" +
"sub va4.x, va4.x, vt3.w" +
//--RED--
"div vt3.x, va4.x, vc12.x \n" +
"frc vt3.y, vt3.x \n" +
"sub vt2.x, vt3.x, vt3.y" +
"mul vt3.x, vt2.x, vc12.x \n" +
"sub va4.x, va4.x, vt3.x \n"+
//--GREEN--
"div vt3.y, va4.x, vc12.y \n" +
"frc vt3.z, vt3.y \n" +
"sub vt2.y, vt3.z, vt3.y" +
"mul vt3.y, vt2.y, vc12.y \n" +
//--BLUE--
"sub vt2.z, va4.x, vt3.y \n"+
 

Ce que fait devrait faire ce code :
- il prend une valeur de couleur, par exemple : 0xFF996633 et le tronçonne en 4 valeurs que l'on retrouve dans :
vt2.w = 0xFF
vt2.x = 0x99
vt2.y = 0x66
vt2.z = 0x33

[tlecoz]

Citation

Tu as une valeur argb en uint, et tu veux en récupérer les valeurs a,r,g,b sous la forme de 0.2, 0.1, 0.9, 1 ?

C'est exactement ca !



J'essaye ton code ce soir (là je suis au bureau et je n'ai pas les fichiers de mon anim avec moi) , mais il ressemble beaucoup à la premiere version de mon code (en tout cas j'utilisais 'frc' aussi)

Merci !

[dldler]

tlecoz, le 14 May 2012 - 12:33 PM, dit :

C'est exactement ca !

Dans ce cas, la formule n'est pas bonne. Il faut encore diviser les valeurs finales par 256.
Et sans doute qu'il y a une grosse optimisation possible. Il faut que je force mon cerveau à voir les choses en biais…

[dldler]

Bon, je joue toujours dans l'absolue le plus total

Voici 2 versions qui devraient faire ce que tu attends… En espérant que l'une des 2 le fasse vraiment.

La première est une décomposition qui me semble plus laborieuse.
La seconde, je la trouve belle et simple, et peu gourmande en variables et constantes…

Les 2 versions provoquent un arrondi inférieur situé entre 1/256e et zéro…
Tu pourrais récupérer les valeurs exactes sur 256 pour chaque valeur en multipliant par 256 puis ajouter 1, mais je pense que ça ne devrait pas te servir.

Version 1 : vision "en biais" de mon cerveau

// Utilisation de constantes
// vc12.w = 0x100000000;// Calcul de l'alpha
// vc12.x = 0x001000000;// Calcul du rouge
// vc12.y = 0x000010000;// Calcul du vert
// vc12.z = 0x000000100;// Calcul du bleu
// définition de la couleur
// va4.x = 0xFF996633;
// Les résultats sont stockés dans une variable vt2
// vt2.w // alpha
// vt2.x // red
// vt2.y // green
// vt2.z // blue
//--ALPHA--
"div vt2.w, va4.x, vc12.w \n" +
"frc vt2.w, vt2.w" +
//--RED--
"div vt2.x, va4.x, vc12.x \n" +
"frc vt2.x, vt2.x" +
//--GREEN--
"div vt2.y, va4.x, vc12.y \n" +
"frc vt2.y, vt2.y" +
//--BLUE--
"div vt2.z, va4.x, vc12.z \n" +
"frc vt2.z, vt2.z"
 

Version 2 : en processus logique récursif

// Utilisation d'une seule constante
// vc12.x = 0x100
// définition de la couleur
// va4.x = 0xFF996633;
// Les résultats sont stockés dans une variable vt2
// vt2.w // alpha
// vt2.x // red
// vt2.y // green
// vt2.z // blue
//--BLUE--
"div va4.x, va4.x, vc12.x \n" +
"frc vt2.z, va4.x"
//--GREEN--
"div va4.x, va4.x, vc12.x \n" +
"frc vt2.y, va4.x" +
//--RED--
"div va4.x, va4.x, vc12.x \n" +
"frc vt2.x, va4.x" +
//--ALPHA--
"div va4.x, va4.x, vc12.x \n" +
"frc vt2.w, va4.x" +
 

[tlecoz]

Merci Didler !
J'essaye des que je rentre !

[tlecoz]

Hello !
Je verrais ça demain
Il est 4h18 et je suis encore au bureau...

[tlecoz]

Je viens de tester tes deux codes et les deux fonctionnent !
La dernière version est super ! Merci beaucoup !

Grace à toi je vais pouvoir gagner pas mal de millisecondes en utilisant BitmapData.getVector() plutot qu'une double boucle pour récuperer la couleur des pixels d'une image.

Je te l'ai déjà dit mais tu devrais te mettre à molehill, pas forcément pour faire de la 3D mais plus pour apprendre à créer toi même des Shaders. Je suis sur que ça va te plaire , le plus dur étant de ne pas fuir devant l'AGAL et c'est déjà fait

Merci encore !

[dldler]

Content de savoir que ça fonctionne.

Pour molehill ou autres jouets, il faudra encore attendre un peu que la cagnotte grossisse.

[tlecoz]

so sad...

EDIT : tu as essayé récemment de voir une anim avec Stage3D ? Le FP11.2 (ou 11.3 je sais plus) est sensé tourner sur davantage de config qu'avant (il peut etre necessaire de reinstaller les pilotes de la carte graphique)

[Jean-Marc Le Roux]

Dans Minko il y'a la fonction "unpack" qui transforme un scalaire en float4 :

protected final function unpack(packedScalar : Object) : SFloat
{
  var bitSh : SFloat = float4(1. / (256. * 256. * 256.), 1. / (256. * 256.), 1. / 256., 1.);

  return dotProduct4(packedScalar, bitSh);
}
 

Il y'a aussi "pack", qui fait l'inverse

[lilive]

Je ne comprends pas en quoi cela répond à la question de tlecoz?

[Jean-Marc Le Roux]

lilive, le 30 June 2012 - 00:53 AM, dit :

Je ne comprends pas en quoi cela répond à la question de tlecoz?

La question est :

Citation

J'aimerais créer un bout de code AGAL qui retrouverait les composante RGB d'un code couleur (uint).

Et mon code permet de transformer un uint en float4 au format RGBA. En tout cas c'est ce qu'il est censé faire
Donc ça répond plutôt bien à la question je pense non ?
Après c'est pas de l'AGAL, mais il est assez malin pour l'adapter au besoin (et s'il n'y arrive pas c'est peut-être mieux de ne pas le faire en AGAL, du coup...)

Edit: un détail important c'est que ça unpack une valeur qui est censée être normalisée (donc entre 0 et 1). Du coup il faut diviser la couleur par 0xffffffff avant d'appeler unpack. On s'en sert généralement pour stocker la profondeur des pixels dans une texture par exemple, puisque stocker un float sur un float4 nécessite le même genre d'opération.

Modifié par Jean-Marc Le Roux, 30 June 2012 - 01:58 AM.

[alama.be]

Bonjour JM, Si ta classe ne fait pas ça en AGAL, il le fait en quoi? AS3? Car le but de Tlecoz est de faire ça par le GPU.

En tant que spécialiste Minko, je prend un exemple:

j'ai des valeurs de type Float, je cherche à les manipuler dans le GPU (add, sub, mul, etc..) les résultats doivent toujorus être des float. une fois les résultats obtenu (dans des registres GPU ou VRAM, peu importe où) quand tous les calculs sont faits, je dois afficher à l’écran mes floats sous la forme de pixels ARGB .

Minko ferait ça comment? et est-ce minko utilsera bien le GPU pour faire toutes les manip sur les floats?

Après, il est sympa de faire mes début en AGAL et Stage3D natif, ne fus-ce-que pour apprendre la mécanique interne.

Mais il va de sois, qu'après, les routines de manipulation seront plus facile à faire à l'aide d'un framework ou un outil capable de faire AS32AGAL ou dans le genre..

EDIT:

Ce qui manque à AGAL selon moi, c'est simplement la manipulation binaire (et algèbre de bool).. car avec ça, on peut tout faire..

PS: quelqu'un aurait un set d'instruction complet d'un GPU classique? (pour voir) car si ça se trouve, AGAL n'exploite pas la moitié des possibilités.. j'en sais rien, je fais des suppositions..

[tlecoz]

Citation

Si ta classe ne fait pas ça en AGAL, il le fait en quoi? AS3?

Avant tout, désolé JM si je suis approximatif...

Apriori il code son Shader en AS3 via Minko (qui pilote le GPU)

Citation

j'ai des valeurs de type Float, je cherche à les manipuler dans le GPU (add, sub, mul, etc..) les résultats doivent toujorus être des float. une fois les résultats obtenu (dans des registres GPU ou VRAM, peu importe où) quand tous les calculs sont faits

Tout est forcément Float coté GPU donc pas de problème à ce niveau.

Citation

je dois afficher à l’écran mes floats sous la forme de pixels ARGB .

La sortie écran se fait comme ça en AGAL

mov oc, vc0.xyzw
 

ou x,y,z,w sont des Float représentant respectivement r,g,b,a .

Citation

et est-ce minko utilsera bien le GPU pour faire toutes les manip sur les floats?

Oui !

EDIT : Le mieux serait que tu poses ta question dans le forum dédié à Minko

[alama.be]

ok

[Jean-Marc Le Roux]

Citation

Minko ferait ça comment? et est-ce minko utilsera bien le GPU pour faire toutes les manip sur les floats?

Oui.

Citation

Après, il est sympa de faire mes début en AGAL et Stage3D natif, ne fus-ce-que pour apprendre la mécanique interne.

C'est une bonne idée tant que tu n'as pas l'impression qu'apprendre l'AGAL veut dire apprendre à programmer un GPU. Par ce - encore une fois - penser qu'apprendre AGAL c'est apprendre à programmer un GPU, c'est comme imaginer qu'apprendre PHP fait de vous un développeur web

Cela dit, même si je pense qu'AGAL n'a pas d'intérêt en tant que langage et que ça ne doit rester qu'un support pour comprendre la logique de ce qui se passe matériellement sur un GPU, l'API Stage3D est-elle une bonne source d'apprentissage dans son ensemble. C'est un mix entre OpenGL et DirectX où on retrouve l'essentiel. Il est très intéressant de confronter l'approche d'une API 3D comme Stage3D avec la notion de scène telle qu'impliquée par des frameworks plus haut niveau par exemple. Comment les deux interagissent est un point clef en terme de possibilités et de performances. Minko apporte par exemple une solution il me semble très innovante dans ce domaine, et c'est entre autre ce qui occasionne une grande différence de performances.

Citation

Mais il va de sois, qu'après, les routines de manipulation seront plus facile à faire à l'aide d'un framework ou un outil capable de faire AS32AGAL ou dans le genre..

Là encore il y'a une petite incompréhension. Les outils qui permettent d'utiliser un langage de plus haut niveau intègre plus que de la traduction. Ils doivent apporter beaucoup beaucoup plus en terme d'API, d'optimisations, etc... Donc c'est bien plus que juste un langage différent

Citation

Ce qui manque à AGAL selon moi, c'est simplement la manipulation binaire (et algèbre de bool).. car avec ça, on peut tout faire..

Toi qui a fait de l'élec. (il me semble) tu dois comprendre que c'est par ce qu'un GPU n'a pas d'ALU mais juste un FPU. Du coup, le bitwise c'est pas sa tasse de thé... Dans Minko on a "résolu" le problème en proposant direct des méthodes qui font ça en arithmétique flottante :

https://github.com/a...derPart.as#L738

Mais bon dans l'absolu ça ne sert pas beaucoup étant donné la nature même des calculs effectués sur un GPU.

[alama.be]

Citation

Toi qui a fait de l'élec. (il me semble) tu dois comprendre que c'est par ce qu'un GPU n'a pas d'ALU mais juste un FPU. Du coup, le bitwise c'est pas sa tasse de thé... Dans Minko on a "résolu" le problème en proposant direct des méthodes qui font ça en arithmétique flottante :

En effet, mais bon, parfois c'est plus simple avec des rol et ror etc.. Mais bon, faut dire que c'était pour un cas particulier.. sinon, oui,
value* (2 exp X) revient au même que value <<< x ..

C'est vrai que dans FPU, y a pas "Logic" .. j'avais même pas fais le rapprochement entre FPU et le fait que tout est Float là dedans.. ben oui, je dis GPU sans réfléchir..

Ceci dit, celui qui veut vraiment rester en agal peut toujours modifier la classe Adobe assembleur et implémenter lui même ces features..

Merci pour ta réponse

A la limite, AGAL est inutile, pour prendre un niveau + bas, suffirait de construire un flux binaire de codes hexa qui correspond à toutes les intrus qu'on veut que le GPU fasse.. mais là, on descend encore .. et je ne sais même pas comment le core player gère ça.. si il ne va pas y avoir blocage de sa part.. mais bref, là, j'épilogue..

[Jean-Marc Le Roux]

Citation

A la limite, AGAL est inutile, pour prendre un niveau + bas, suffirait de construire un flux binaire de codes hexa qui correspond à toutes les intrus qu'on veut que le GPU fasse.. mais là, on descend encore .. et je ne sais même pas comment le core player gère ça.. si il ne va pas y avoir blocage de sa part.. mais bref, là, j'épilogue..

L'AGAL est lui même transformé en véritable code machine en fonction de l'API ciblée (DirectX ou OpenGL), donc on ne peut pas envoyer ce qu'on veut au GPU. Ca serait trop facile

[alama.be]

Citation

L'AGAL est lui même transformé en véritable code machine en fonction de l'API ciblée (DirectX ou OpenGL), donc on ne peut pas envoyer ce qu'on veut au GPU. Ca serait trop facile

Oui! Aussi..