|
Alpha & Oméga
|
on en parlais du coup
du bug de la gestion d'alpha sur alpha mais je remarque que par exemple, selon les coupes parfois ça va faire le bug et parfois pas du tout comment est-ce possible que parfois... ça va faire ça.. et des fois ça sera okey? selon le build? quelle est donc l'erreur de build dans la dernière photo? il y a un lien avec le fait que la texture alpha soit png ou tga? voila voila simple curiosité  si vous avez un bout de réponse... Dernière modification par *RAV3N* ; 15/06/2015 à 22h52. |
15/06/2015, 05h32
|
alpha sur alpha (cheveux et autres)
| Suivre |
|
|
Partager | Rechercher |
|
Alpha & Oméga
|
Django a donné les réponses :
Citation :
|
|
15/06/2015, 11h35
|
|
Alpha & Oméga
|
bahh si l'un d'entre vous a compris son jargon technique et aurait la bonté d'expliquer ça dans des mots moins compliqués...
|
|
15/06/2015, 13h27
|
|
Héros
|
En gros, le problème c'est que, quand tu as plusieurs objets l'un derrière l'autre, avec des textures partiellement transparentes, il est très compliqué de déterminer ce qui est devant et ce qui est derrière, de manière à pouvoir décider quel pixel afficher, de quelle texture.
On constate d'ailleurs, par expérience, que le problème apparait en général lorsque les deux objets sont plutôt proches l'un de l'autre. Le problème se pose dès que la texture comporte une couche alpha. Il arrive parfois de voir des textures totalement opaques, par exemple sur un mur, mais qui ont été uploadées avec une couche alpha inutile, et qui posent alors le même problème. Ce n'est pas un problème spécifique à SL, mais aux cartes graphiques en général. Ce ne serait pas impossible à résoudre, mais demanderait un surcroît de calcul démesuré. Citation :
|
|
15/06/2015, 15h46
|
|
Alpha & Oméga
|
super, c'est bon à savoir
mais ce que je comprends pas c'est que par exemple je vais m'acheter des cheveux en flexy de chez ... dura par exemple et j'aurais pas de soucis de alpha sur alpha et parfois je vais mètre les cheveux d'une autre marque et j'aurais ce soucis là c'est louche on dirais donc que selon la personne qu'a crée, ça va faire ça ou pas il y a certains créateurs de cheveux qui n'ont jamais ce soucis (pour ne parler que des cheveux) |
|
15/06/2015, 18h03
|
|
Alpha & Oméga
|
Je suppose que c'est une question de position des mèches.
J'ai fais il y a quelques temps une coiffe (pas des cheveux mais c'est le même principe) composée presque entièrement de flexy avec alpha. Le problème de superposition est bien là, mais ça ne se voit quasiment pas parce que les flexy derrière "cachent" en quelque sorte les "trous" de transparence. Par contre, si les prims (ou les meshs) sont trop parallèles, trop symétriques, ou s'il y en a peu, alors on voit le problème dès qu'on passe devant un truc avec alpha. |
|
15/06/2015, 18h26
|
|
Alpha & Oméga
|
Citation :
je crois bien que c'est au moment de créer la texture des cheveux ou des vêtements , l'arrière plan doit être blanc et non transparent. |
|
17/06/2015, 19h27
|
|
Alpha & Oméga
|
mmmm intéressant!
mais... s'il est blanc, alors il sera pas transparent... si? a moins qu'il y aie une manip à faire au niveau de la diffusion de l'alpha une fois inword? |
|
18/06/2015, 00h49
|
|
Alpha & Oméga
|
Citation :
|
|
19/06/2015, 22h38
|
|
Alpha & Oméga
|
/me se gratte la tête
oui, mais... http://gyazo.com/c9ddd79300244a842c7c2129dbf3a0cf http://gyazo.com/620a99cb4c5965ba32c1171bb68e6595 http://gyazo.com/ef5163d248b28eec6ef9fb4f2bd505d7 sur la dernière j'edit la coupe de façon a montrer son plan alpha sur les pointes, et juste derrière en background j'ai une porte vitrée! là ,par exemple on voie qu'il y a de la transparence sur les pointes des cheveux et pourtant il y a une porté vitrée derrière moi et j'ai pas le bug (firestorm en semi ultra) pourtant avec d'autres coupes de cheveux le bug je vais l'avoir mais il y a des coupes, où je ne l'aurais pas du tout! (pas une seule fois... jamais) ce qui signifie que ce bug de transparence sur transparence on l'a pas forcement avec chaque coupe de cheveux qui utilise le plan alpha! (j'ai environs 50 coupes de cheveux qui n'ont pas ce bug là!!) donc d'après moi ça signifie que voila selon comment on a fabrique la coupe, on aura le bug ou pas |
|
22/06/2015, 02h08
|
|
Princesse
|
En gros, Raven est en train d'expliquer qu'elle n'a jamais remarqué ce problème de conflits entre les couches alphas avec lequel le reste de SL deal depuis que SL existe (un truc de OpenGL, jamais résolu, appelé aussi "alpha sorting"), si ma mémoire est bonne), des parts de nos outfits qui disparaissent quand on passe sur un tapis fait d'une texture alpha, la moitié d'une chevelure d'alpha flexis devant une autre texture alpha...
Et elle nous montre pour illustrer son exemple, des cheveux fait essentiellement en sculpties avec 3 flexi mèches.... Ici le genre de cheveux qui va se retrouver coupé au niveau des oreilles devant un mur avec texture alpha (Je parle d'expérience). Le designer est connu (Analog Dog). On peut d'ailleurs remarquer que ça glitche déjà aux épaules et au niveau des oreilles, puisque alpha sur alphas. Mais oui, ça flottait joyeusement dans le sens du vent (même dans une maison sans courant d'air, enfin, un peu moins dès que l'on passait devant la fenêtre du mur alpha...)  Ici sur le forum SL, une fille qui explique le problème en réponse à une autre se plaignant de la disparition de ses cheveux flexi:  Eh oui, pas de solution, il n'y en a jamais eu. Je ne connais pas une fille, qui avant les meshes, quand on voulait avoir une longue chevelure vaporeuse et bouclée, ou portant une flexi jupe avec des textures alphas, n'a pas expérimenté ce problème de voir les la masse de prims texturée avec des alphas, disparaître ou salement "bugger". Ici encore un exemple de conflit entre 2 alphas:  Et encore une autre qui râle sur ce problème sur son blog:  Bref, pas une légende urbaine, pas une question de talent du builder, juste un problème d'OpenGL quelque chose... |
|
23/06/2015, 06h02
|
|
Alpha & Oméga
|
Comme Raven, j'ai pu remarquer que parfois ce problème de chevauchement de transparences était atténué.
J'avais acheté un building avec des vitres. Une texture pleinement transparente. Le problème ne se posait jamais quand on mettait des trucs à base d'alpha derrière. De sorte que je réutilisais toujours ces vitres pour remplacer celles d'autres bâtiments. Il doit bien y avoir un truc. |
|
23/06/2015, 07h13
|
|
Alpha & Oméga
|
alpha blending
pas alpha sorting,  , Yenneferen gros tu as l'alpha masking qu'est un "tout ou rien" 1 ou 0 et tu as l'alpha blending que dispose de 256 degrés de transparence, zéro était full invisible et 255 étant full opaque dans la 3eme snap j'edit les mesh pour monter très clairement un plan alpha devant une transparence alpha, la porte vitrée OpenGL roule depuis 1992, il me semble avec le temps j'ai pu remarquer que parfois il y a des éléments comme cette coupe de cheveux qui ne vont pas présenter ce bug là quoi qu'on leur mette derrière comme plan alpha et ça c'est quand même quelque chose qu'est suffisamment curieux, pour qu'on tente de comprendre la chose peut importe combien d'autres auront trouvé le soucis (le soucis on sait bien qu'il existe, c'est pas quelque chose qui soit à prouver au stade où nous en sommes) Et essayer de tourner en dérision la bizarrerie que je présente ici, ne la fera pas disparaitre non plus, Yennefer! mais quelque part, il y a une solution, j'en suis sure! il y a un élément qu'on est pas en train de prendre en compte et qui fait que sur certains éléments (coupes de cheveux, vitres ou autres) le bug en question est résolut correctement par la carte graphique! |
|
23/06/2015, 07h14
|
|
Héros
|
Il n'y a pas une histoire qui dit qu'il ne faut pas complétement rendre invisible justement les parties qu'on ne doit pas voir ? Un peu comme quand on veut rendre invisible un prim , on le met pas à 100% mais à 99 voir 98. Pour la texture , il suffirait de jouer là dessus, non ?
|
|
23/06/2015, 08h43
|
|
Alpha & Oméga
|
ça voudrais dire que le soucis viens de l'alpha masking et non de l'alpha blending, ça vaudrait le coup de tester ça et voir ce que ça donne, en effet!
|
|
23/06/2015, 14h17
|
|
Princesse
|
"Alpha sorting issue"... "sorting" pour "tri". C'est à dire, un problème de tri des alphas, de gestion des priorités (excuse moi, mais erm, je ne crois pas qu'il y ai une seule chance pour que je confonde "blending" avec "sorting". Et le terme de "sorting" a été fréquemment utilisé
"Alpha sorting" est donc le terme correct. Et l'option d'alpha masking ne corrige pas complètement le problème. En plus, plus il y a de couches alphas, plus le problème de conflits augmente. On le remarque un peu moins maintenant car il est assez rare d'utiliser encore des textures alphas pour des murs avec fenêtres, les tapis, les rideaux sont davantage faits sans texture alphas et enfin, avec les cheveux sculpty puis meshes, nous n'avons plus beaucoup de cheveux faits entièrement de textures alphas (comme l'exemple que j'ai donné d'une coupe de cheveux de chez Analog). Pareil avec les vêtements en meshes, on peut faire une jupe avec des trous, sans avoir besoin de donner cet effet de trous via la texture. Et j'ironise sur le fait que définitivement, tu sembles découvrir un problème qui est archi connu sur SL, depuis des années.... |
|
24/06/2015, 09h01
|
|
Alpha & Oméga
|
Citation :
|
|
24/06/2015, 10h10
|
|
Alpha & Oméga
|
que le problème soit vieux comme Hérode, ne change rien à l’exception, et c'est sur l’exception que je pointe le doigt, Yennefer!
on a un soucis, qu'est connu et des fois, étrangement, le soucis n'a pas de prise sur certains objets! c'est suffisamment curieux pour chercher à comprendre pourquoi regardons les mesh body, par exemple... on met 3 couches de layers trois couches de transparence, les unes sur les autres et ces couches on les met très très proches et du coup des fois on se retrouve avec des truc bizarroïdes genre le glitz d'altitude dont le TMP souffre et les autres l'ont résolu (comment?) il y a bien quelque chose qui nous échappe!! nous; communs des mortels  Alors rigole autant que tu voudras, en te disant que ça ne vaux pas la peine de se pencher dessus, moi je persiste à croire qu'il y a un vrai problème et que quelque part il y a une vraie solution qui s’avère très d'actualité et très utile! |
|
24/06/2015, 15h08
|
|
Princesse
|
Citation :
|
|
24/06/2015, 15h26
|
|
Princesse
|
Citation :
Et je ne cris pas que ce soit sur ce forum que ce problème de conflit de textures alphas va se résoudre, des gars autrement plus compétents que nous dans ce domaine se sont penchés dessus, la recette miracle n'a jamais été trouvée.... |
|
24/06/2015, 15h30
|
|
Alpha & Oméga
|
aa oui ta Lara fait du glitch d'altitude aussi?
j'ai pas fait gaffe sur la mienne, faudra que je regarde voir mais j'ai vu que sur mon TMP en tout ça le glitch d'altitude est flagrant! Et c'est pour ça justement qu'on nous a mis l'option trubleshoting pour qu'on joue avec les différentes couches de transparence de façon a résoudre nous même le soucis (en altitude tu peux toujours courir, toutes fois^^) ce trubleshoting fonctionne sur l'alpha masking et on l'a sur toutes les grandes marques de mesh body (sous différentes dénominations) en revanche j'ai pu constater, que Lara (malgré l'update) a toujours un méchant petit bug de transparence au niveau des bouts de doigts je suis convaincue que la recette existe! parce que bon voila il y a des items qui ne pressentent pas le bug!! et ça voila, pour moi c'est la preuve qu'il y a une solution après peut-être qu'en effet nous on trouvera pas la solution mais ça vaut la peine de se pencher dessus et chercher à comprendre pi on sait jamais... je suis pas du genre à ne rien dire, quand je me pose une question, voila je la garde pas pour moi j'ai pas peur de passer pour une cruche, c'est pas grave, personne n'a la science infuse quand je sais pas; je demande quand je sais; j'explique voila comment je fonctionne Peut-être qu'on aura pas la réponse maintenant et peut-être que d'ici 3 mois quelqu'un remontera ce thread pour donner la réponse! va savoir... |
|
24/06/2015, 16h56
|
|
Alpha & Oméga
|
Ce qu'il y a d'étonnant, c'est qu'un parterre de gazon constitué de centaines de "planes" alpha pose parfois moins de problèmes qu'une simple vitre.
Le viewer décoderait les textures selon un ordre qui est celui des vertices. Si je comprends bien, il faudrait mettre au dessus la surface qui comporte le plus de triangles: " That's how most game read the layers by vertex number. So say.. you have 3 semi-transparent layers close to each other and the camera doesn't know which one should be on top when it comes to render and it simply render from the smallest numbers to the largest. so if your top layer is 1-4 and 2nd layer is 5-8 and bottom layer is 9-12. you will definitely get an alpha blending bug with the z-buffer rendering in SL. so what you should do is, have your top layer's vertices sort to 9-12, 2nd layer 5-8 and bottom layer 1-4. This way when z-buffer render the mesh it will load the bottom mesh 1st then cover it with the 2nd layer and then the top layer thus eliminates the bug shown in the picture you post. " https://community.secondlife.com/t5/...1227445/page/2 |
|
24/06/2015, 19h42
|
|
Princesse
|
Oui, Lara, les gants... J'ai TP sur le sol, et tout était OK. Bon, pas bien grave, je vise une clientèle de RPers, c'est rare qu'ils RP en skyboxes....
Et il me faut un autre café pour lire l'info que Bobo nous donne..... Douloureusement technique, lol! |
|
24/06/2015, 19h51
|
|
Alpha & Oméga
|
tiens tiens tiens!!
faudrait faire le test mais a vue d'oeil, ça fonctionne!! la fenêtre est un plan! les cheveux c'est plusieurs vertices ça fonctionnerais! mais pourquoi pas à chaque fois, alors? c'est quand même curieux que seulement quelques items soient immunisés contre ce bug haa tiens, tiens, du coup je lis le thread en entiers et je m'aperçoit que la personne qu'a écrit ça, Strawberry, parlais de blender!! donc ceci serait vrai dans blender (pas forcement sur sl) pourtant la théorie pourrais fonctionner sur sl mais ça n'explique pas le fait que ce soit l’exception tiens Yennefer, t'avais raison, ils parlent d'alpha sorting tout le long! quand à Lara même si tu est au RDC met toi contre une fenêtre (ou autre chose utilisant de l'alpha blending) et regarde attentivement le bouts de doigts! Par contre... si tes gants n'utilisent pas d'alpha, tu n'as pas de soucis à te faire!!! Enfin pour revenir au thread en question et toujours à la recherche de comprendre.... I am trying to create a mesh plant. Using a curved plane, I duplicate it and flip the normals so it has the same mesh for the top and bottom. I do not join the meshes. I import the mesh into second life. When I apply the texture,I apply it to the bottom mesh first, then the top. This gives me a nice leaf with no alpha sorting glitch. If I duplicate this object, the original now has the glitch, but the new one doesnt (weird). To get around this, I just rez another and repeat. When placing them together, there is still no alpha sorting glitch. But, if I take a copy and rez the copy i took, it now has the problem. ça c'est rudement intéressant!! (c'est au tout début du thread!) et il y a plus encore!! Most likely the reason you're seeing different effects with existing objects than with newly rezzed ones is because of certain tricks SL employs to save on processing overhead. It tries not to re-sort things that haven't changed from frame to frame. With that in mind, here's what might be going on. When you construct an item in the order of oprations you described, you are, in effect, manually supplying the renderer with information about which surface texture to draw first. In that situation, it might decide not to bother re-sorting if it doesn't think it has to. But when you you bring a new copy of the object into existence, both of its surface textures are generated at the same time, so they have to be sorted. Hence the copy displays the glitch. et là on detiens une idée qui vaux son pesant en or: I was thinking that maybe my temporary work around could actually become a feature. You could manually set the sorting yourself and it saves it per object. Not a great solution, but if I could do that and have it keep after I copied it, I would be happy. et là on pourrais avoir enfin la soluce: racalled someone saying, early in the beta, that the faces you added to a mesh last (at least in Blender 2.49) would always appear in front (be rendered last) where an alpha texture overlayed itself. I checked this at the time and it appeared to be correct. Biut I guess it could depend on all sorts of intermediate processing which could change the order. So I made some objects with two planes and textured then to test this again. It is appears to be still true. As long as they are on the same SLface (material), the last added mesh faces appear in fron even when that contradicts their physical location. However, whe the two planes were different materials this no nonger applied. The one in from always appeared in front independently of which had which material/face index (that is, looking at them from the front). It would be interesting to know if the effect of face addition is the same or different for the single material case with different software. là, d'après moi on tiens quelque chose! les faces que t’ajoutes en dernier (sur ton blender) seront renderer à la fin, donc elles vont apparaitre devant. ça pourrais expliquer l’exception à la règle!! et si ça venais à se confirmer on obtiens la soluce et à nous le prix nobel! Dernière modification par *RAV3N* ; 25/06/2015 à 00h46. |
|
25/06/2015, 00h02
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|