Unusual Texture Overlapping Issue

[Atop Seid]

Salutations.

I am working with a mesh object, then copying it and placing a different texture on each. One texture is partially transparent, while the other is not. When I put both meshes in the exact same location, then change the colour (not the texture) of one mesh, the alpha texture does not seem to conflict with the non-alpha texture. Instead, the alpha texture seamlessly covers the none-alpha.

I find this to be particularly useful for customisable objects, or rather it be would were it not for one unusual issue: When I add more than two objects to the linkset and subsequently change the colour of one mesh again, the textures experience conflicts. This exact same issur occurs with regular prims as well, and thus the issue does not only lie with meshes.

An interesting solution I have found is to drag a copy, or simply rez the object. However, is only a temporary solution as the conflicts occur again when I change the colour of one of the meshes a second time.

Note: the textures used are both identical. I simply disable the alpha on one of them.

Any assistance you can provide on this issue would be most appreciated.

Regards.

[Drongle McMahon]

Can you explain exactly what you mean by "conflicts"?

[Atop Seid]

Thank you for your response.

By "conflicts" I refer to how two textures overlap with each other, each one fighting to be visible over the other. If you place two prims of the same size in exactly the same location, each with different textures, you should experience this effect.

[Drongle McMahon]

Ah yes. I think that's called z-fighting. It's horrible. Different from the alpha-glitch. I didn;t think it depended on alpha channels at all. I don't know what you can do about it other than moving the layers slightly apart.

[Atop Seid]

As I stated in the original post, the glitching seems to end when I drag a copy of the linked object, or when I rez a new version. Somehow, resetting the object seems to correct the issue. All I require is some way to reset the object manually.

[Drongle McMahon]

Now you are confusing me. Your first post seemed to imply that you had two objects exactly superimposed. Now It sounds as if you have one object with two copies of the geometry superimposed.

If it's all one object, that's rather different. It should still be possible to get the two layers of geometry separated by enough to prevent the effects, but the separation has to be enough to avoid rounding errors when the geometry coordinates are converted to 16 bits on upload, and when their distances from the camera (z) positions are calculated inside the rendering engine. I would still try the solution out, as long as one of the layers is supposed to be always on top. If not, I can't suggest anything.
If this is the explanation, I have to suppose that the changes you see when you drag or rez the object might be dur to differences in the rounding errors for different object and camera locations. If that is the case, then at least the drag remedy would be unreliable, sometimes turining the z fighting on and sometimes off. How reproducible is it?

I suppose there is a slight possibility that the two layers are made of (presumably identical) quads but are differently triangulated by the uploader (which only ever uploads triangles). In that case, the calculations would be different for the two layers and that might have an effect on z in some camera/position combinations. If that's possible, then you might get improvement by triangulating them before export to collada, and checking that the chosen diagonals are the same on each layer.

[Atop Seid]

Apologies for not being clear enough. Normally, by "Object" I refer to the two linked meshes and any additional prims/meshes in the link set. The two meshes share the EXACT same geometry. There are no differences. They are simply in the exact same location.

This issue only occurs when there are more than two prims/meshes in the link set. Again, thisdoes not apply only to meshes. The same issue occurs with just simple prims such as cubes.

When dragging a copy of the object (specifically, the object with two meshes and an additional prim, making three objects in total in the link set), the glitching textures somehow fix themselves. This is the same in EVERY instance of dragging a copy of the linked items.

[arton Rotaru]

Like Drongle mentioned already, z-fighting is a common issue in video games. What you really want to do is blending 2 texture maps with a shader. Sadly SL doesn't have this abillity, (hopefully the next gen platform will), beyond the terrain texture maps.

And like Drongle mentioned, I wouldn't be so sure if rezzing a copy will "fix" it. It might fix it for you temporary, but somebody else will probably still see the flicker, when entering the area. Fighting z-fighting with that method is most likely a non starter.

However you could take a look at this thread.

http://community.secondlife.com/t5/Mesh/Assigning-multiple-materials-to-a-polygon/td-p/1896749/highlight/true

[Drongle McMahon]

I went to Aditi and played around with two identical 2x2x2 cubes exactly superimposed. I don't really umderstand. but here is what I observed. When you shift drag, the ome that moves is the old one, and the duplicate is left behind. After superimposimg them, I could onl;y see the blue cube. Then when I linked them, the yellow cube became the root, and I could only see it. If I used edit linked and  either moved or scales the selected yellow cube, then the faces that remained superimposed (in the same plane) immediately exhibited z fighting. Whem the edit was restored, the z fighting ceased.

Now I started making duplicates with shift drag. The new copy (the one left behind when you drag) always showed z fighting as soon as the old one (the one moving) started to move. If I then moved the camera around, and/or zoomed, the z fighting evenyually stopped, sometimes with the yellow cube, but more often with the blue cube visible. All new cubes showed z fighting whether they were made by shift dragging blue, yellow or z-fighting cubes. All three kinds re-rezzed after copying to directory also always showed z-fighting, although occasionally it was only transient.

From what I said before, from my point if view the unexpected behaviour is when the z fighting stops. I assume this happens when by chance the camera angle etc. cause one cube to completely occlude the other, causeing the rendering system to mark the latter as occluded, so mthat it never tries to render it again.

This is consistent with what happens if the blue is made transparent. Now the z fighting surfaces are yellow and grey (yellow seen through transparent blue). The behave the same way, except that the grey cubes start z fighting again at some camera angle and/or zoom. Thta is presumably because the yellow cube cannot be excluded by the transparent cube, so that it is never marked as such.

Advice remains the same. Move the one of the surfaces so that they don't z-fight.

[Atop Seid]

Drongle McMahon, thank you for your reply.

I believe I understand, although I must verify one thing, if you are not understanding, which I hope you are.

The transparency I refer to is that both textures are literally exactly the same. I simply disable the alpha layer on one of them. As a result of this, the alpha texture is always visible over the none-alpha texture, but I believe you know the rest from here.

If you do indeed already know this, then I thank you for your assistance. Unfortunately, simply increasing the size of the meshes in such a way is unreasonable for me at this time. I shall either have to find a way around this issue, or to wait until LL implements proper texture layering.

Again, thank you for your assistance, and best regards.