Utiliser un vecteur different comme parametre pour chaque ve

[nafasso]

C'est effectivement l'idee. En fait quand je parle de mes 3 images, il y a l'image X, l'image Y et l'image Z. Elles sont toutes les 3 de la taille de l'ecran d'affichage reel et dans un script C# j'analyse ces image et la couleur de chaque pixel correspond donc a sa coordonnee (sur l'image X, la coordonnee obtenue sera le X du pixel, sur l'image Y, la coordonnee Y et sur l'image Z la coordonnee Z).
Donc en gros l'analyse de l'image pour en extraire les coordonnees est deja faite et c'est ce qui me donne ces 3 tableaux. Je dois maintenant reussir a passer ces 3 tableaux dans TEXCOORD0 pour en suite m'en servir dans le shader. Avec TEXCOORD qui devrait correspondre a (TabX[vertex], TabY[vertex], TabZ[vertex])
C'est vraiment simplement ce passage d'information que je ne sais pas faire et pour lequel j'aurai besoin d'aide.

[Alesk]

Hello,

Si l'écran n'a pas une forme super complexe, il me semble tout de même plus "simple" d'essayer de générer un mesh 3D de l'écran avec ses coordonnées UV à partir des données de ton scan kinect, et afficher la projection avec un shader tout simple.
Plutôt que de batailler à essayer de faire un shader qui va utiliser les images pour déformer la projection (sans parler des soucis de focale/perspective qu'il faudra aussi gérer dans le shader)

[nafasso]

Je crois que j'ai trouve la solution pour envoyer mes donner dans TEXCOORD.
J'utilise mesh.uv
Maintenant ma nouvelle question est pourquoi mesh.uv est absolument un Vector2 alors que TEXCOORD peut etre de type float2,3 ou 4 ? Ca n'a aucun sens, ce n'est pas logique.
Du coup je suis oblige d'envoyer mon X etY dans TEXCOORD0 et mon Z dans TEXCOORD1. Soit je dois rater un truc soit c'est totalement stupide ...

[boubouk50]

http://answers.unity3d.com/questions/53 ... loat4.html
Ça s'appelle des UVs parce que justement il y a deux axes U et V qui définissent le repère de coordonnées. Dans 99.9% des cas, on utilise que 2 valeurs sur les 4, donc ça a du être optimisé, mais ouais, du coup ça réduit les possibilités, surtout celles de pouvoir faire passer des infos sur les 2 valeurs suivantes.

-EDIT- en checkant un peu sur le net, je vois souvent que mesh.uv est un float4, parfois un float2, du coup serait-ce une restriction que tu t'imposes sans le vouloir?
http://answers.unity3d.com/questions/15 ... -work.html

[nafasso]

Hello, ouai tu as raison ca doit etre parce que dans 90% des cas c'est des textures2D qu'on manipule mais du coup c'est un peu relou quand on veut manipuler des cubemap.
En fait c'est dans l'API de Unity que le mesh.uv est defini par un Vector2[] http://docs.unity3d.com/ScriptReference/Mesh-uv.html
Je ne m'embeterai clairement pas a me compliquer la vie si je pouvais passer directement un Vector3 ou 4.
Du coup d'un cote tu as unity qui definie Mesh.uv comme un Vector2[] et de l'autre cote tu as CG prog qui permet d'utiliser TEXCOORD comme un float2, 3 ou 4. C'est pour cela que je disais que c'est un peu idiot. Ils auraient pu faire une correspondance. Du coup la je suis oblige de modifier Mesh.uv pour y mettre (X,Y) que je recupere sous le nom TEXCOORD0 dans mon shader, et Mesh.uv1 pour y mettre seulement Z (Z,0) et que je recupere sous le nom TEXCOORD1.
Du coup c'est sans doute optimise pour une utilisation sur un texture 2D mais dans mon cas ca l'est clairement pas en fait

[boubouk50]

Merci pour le lien.
Effectivement, c'est "stupide" puisque restrictif. Tu peux, comme tu le fais, passer par deux sets d'UV donc au final tu t'y retrouves même si c'est un peu cracra.

[Alesk]

Au lieu de mesh.uv, tu peux utiliser (si tu ne l'utilises pas déjà pour autre chose) la propriété mesh.colors qui accepte 4 floats (r,g,b,a).
En attendant, je suis curieux de voir comment tu vas t'en sortir avec ce shader

Et je suis bien d'accord que c'est idiot ces restrictions dans l'api

[nafasso]

Ha c'est pas bete ca. Je n'utilise effectivement pas la propriete color, ca me parait etre une bonne alternative pour faire passer mes 3 coordonnees, en tous cas plus adapte que les 2 uvs.
merci pour l'astuce