|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 09/Mar/07 08:39 AM
This is a known issue. This has to do with the fact that the textures you're using have transparency in them, even if that's not obvious from looking at them. SL (and all other 3d apps) has trouble figuring out what order to layer transparent textures in, because to do it "properly" would take an unacceptable amount of CPU time.
Yeah, the new rendering pipeline has broken rendering transparent objects and has yet to be fixed. There's really no argument for not fixing this, but yes I'm knowledgeable enough to know getting this stuff right ain't easy.
The strange escher rendering shows up in a lot of places and tends to destroy the sense of (second) reality... Here's one from just standing around in the Furnation Luxor.
I think this is the same as SL-15831, but I'd like to get confirmation from someone at Linden Lab.
Maybe also related to VWR-504? See my screenshot of in correct ordering there.
some people that advantage of this bug to achieve interesting effects (like single prim cell shading), so killign this could upset lots of people....but...dunno.... I'll let the crowd decide on heir own, but I'm not voting for this unless an alternative way to intentionally obtain such effect is provided
I had this problem occur recently too (multiple instances), with two objects that were NOT intersecting. If this problem can be fixed for objects that do not intersect, that would be acceptable to me. The two examples I can think of right away are a shelf in front of a partially transparent textured wall (half of the shelf would vanish), and the dance floor in my club, where a coloured prim under a partially transparent textured prim would randomly bleed through. I tried to make them 0.010 apart from one another, and as far as 0.100 apart, and the same problem persisted.
Well I'm not sure if this is the same one as two issues I'm seeing. Firstly is involving transparent items, panels against windows, items on glass desks etc, where the effect is dependent on viewing angle. Moving causes normal redraw on occassions. Moving things off the wall by 0.005 usally stops the window showing over, even though the panels are 0.01 thick, but with items on a desk, normally need to be moved in excess of 1 metre.
Secondly, on abutting prims, where there should be no transparency eg curved three part photo studio background, the thin edges sometimes show through, again dependent on angle, but moving viewing angle does not change it back to normal as often. Thinking about this, I am seeing more edge effects than before eg abutting floor and wall panels too. I've noticed this with 1.15, not sure about 1.14 as I never used it as it caused way too many issues for me, like half speed cf 1.13. A sort of work around for things where the textures are transparent but shouldn't be is to download the texture, save it as a .bmp in a graphics editor (removing any transparency), then re-upload. I have an entire folder of marble textures I had to do this to. It still won't fix the alpha sorting when you need both objects transparent, but can be useful in a lot of cases.
this issue is quite a persistant one, and is not limited to intersecting objects. a good example I have experienced is a bed with a semi-transparent canopy, standing about half a meter infront of a transparent wall. when looking at it from a certain angle, the canopy will be drawn behind the wall, even though it isnt even remotely intersecting it. I agree alpha sorting is a thing that is hard to get right - but all major game engines can do it, so SL should be able to get the job done, too.
a suggestion to ease some of the alpha-sorting woes, though: there should be a default action that takes place during the jpeg2000 compression: if the image alpha is completely white (aka 255,255,255), then it gets removed. this will save alpha testing, memory consumption and general confusion as to why a non-transparent texture is affected by alpha sorting issues. The problem here is the z-buffer. To understand what z-buffer is, see http://en.wikipedia.org/wiki/Z-buffering
 Let's take the cone and cube from that page as example. The cone is partially in front of the cube, so the cube isn't fully rendered. Applying a transparent texture to the cone would thus not work, because the z-buffer tells the render engine not to draw the cube behind the cone. In other words: z-buffering prevents transparency completely. Also read http://www.sjbaker.org/steve/omniv/alpha_sorting.html
Any current solution works only partially. You'd have to come up with a whole new, fast rendering engine, imho, to solve this. I think semi-transparent renders fine if it is in front of a non-transparent (opaque)object.
When a semi-transparent object is in front of another semi-transparent object, then the one in front gets rendered as completely transparent while the one behind is rendered as opaque. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
rendering of intersecting objects is wrong, and hidden surfaces are not hidden at all, resulting in an Esher-like drawing
