alpha sur alpha (cheveux et autres)

Répondre
Partager Rechercher
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.
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 :
Publié par *RAV3N*
il y a un lien avec le fait que la texture alpha soit png ou tga?
De toute façon, quel que soit le format d'origine, la texture est convertie en jpeg2000 lors de l'import.
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)
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.
Citation :
Publié par *RAV3N*
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)
Bonjour,

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.
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?
Citation :
Publié par *RAV3N*
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?
Voila, il ne sera pas transparent.
/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
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...)

4246362147_c1ab9ca6e2.jpg


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:
5eab2af26afce0fa38fd84be4efd29ed.png


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:
3145627ecb7ab3d5fb8709186ed38872.png

Et encore une autre qui râle sur ce problème sur son blog:
f072b079f77b8bc6f566076657999c5f.png

Bref, pas une légende urbaine, pas une question de talent du builder, juste un problème d'OpenGL quelque chose...
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.
alpha blending
pas alpha sorting, , Yennefer

en 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!
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 ?
"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....
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!
Citation :
Publié par *RAV3N*
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!
Le glitch d'attitude, si tu parles des "flickering" textures, je l'ai eu avec Maitreya....

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....
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...
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
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!
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.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés