|
History
| Log In
|
|
|
|
|
|
[
Permlink
| « Hide
]
Lex Neva - 17/Jan/07 02:51 PM
I'm fairly certain that this is an issue with many 3d games. This problem has never been solved in a manner that is compatible with real-time rendering, and I believe that such a solution is generally considered impossible. There may be exceptions, such as the current First Look viewer with a new rendering pipeline that seems to at least solve this problem for the case where a hollow prim has a transparent texture on its hollow and outside faces. However, I don't think we'll see an actual universal solution for this problem for a long time, if ever.
There are solutions, but they require additional subdivisions of geometry happening on the fly, client-side.
It is a "tough" problem, but not a "hard" problem. Give it some time and someone who has a clue about real time graphics and re-tessellation of prims and it can be fixed. I think this should rather be high priority, though. It's a biggie with regards to graphics integrity. Have you checked out the First Look viewer? Does it repro for you there?
Joshua, just tried it and it repros in First Look viewer as well.
^ Great example of an issue which could benefit from an attached screenshot to help illustrate the point.
This sounds like Z-fighting? (If so, I see it @ my place in Grasmere because I'm very fond of transparencies. Torley, it's not really Z-fighting, that occurs when 2 surfaces are on the same spot in 3D space (see http://en.wikipedia.org/wiki/Z-fighting).
This happens because the Z-buffer (which you can see if you go to Snapshot > Capture > Depth) doesn't allow transparent texturing. You can make it work in a lot of situations, but it breaks when several objects are both behind -and- in front of eachother (like a ring around a pole, the ring is behind the pole, but the pole is behind the ring). As Thygrrr said, it requires geometry subdivisions, divide the ring in 2 pieces, one piece behind the pole and one piece in front of it. VWR 824 was identified as a major issue, and resolved as a dupe of this. I have increased this to a major to reflect that.
My own justification for the uplift is that a complex textured build is ruined by this bug e.g. I have a door texture that has a transparency for the glass, the door leads onto a balcony which has a wrought iron textured railing (with transparency. The Z-ordering bug means that passers by do not get to see a balcony with a door but a jumble of prims fighting on their screen. I've added a snapshot of how I see this bug. I use transparencies all over the place and this bug hurts a lot.
The screenshot "Z-Order bug example" shows what at first glance may seem to be a normal screenshot. It is a view from my dining room through the partition doors across the Salon to the rear doors. As the screenshot shows, the rear door texture which is actaully on the back wall of my house appears to be in front of the partition doors and "in" my dining room. A representation worthy of M.C. Escher I think. The Salon is at least 5metres square, the textures both have transparencies and despite their disitnt separation in coordinate space all recent viewers have this problem. The only solution I have found is to waste precious prims on constructing prim doors and windows to avoid transparency, and that assumes you are happy not to have glazingin your doors and windows. Any workarounds that do not involve additional prim usage are most welcome. I am having the same problem and it drives be bonkers. I did notice that the only time *I* seem to see it is when I am on my own property. Perhaps I am interested in other things at other properties and just don't notice but maybge there is some truth to this and another clue provided. I hate what it does to my land as i look it over after I have worked so hard on it. I am sure others feel the same way.
I have noticed that this also occurs with 2 textures that do not appear transparent at all.
I had a book case with afreebie books texture and a wallpaper texture. Placed the book case in front of the wall with the wallpaper on and then changed the angle of view and the wallpaper was see instead of the books. I chanege one of the textures and it stopped happening. So I Iooked at the textures in Gimp and they both have alpha channels even though it isnt neccessary for them to have. So I dont think its due to transparency itself but due to the alpha channel data overriding the other channels data in some way. I dont know how occlusion works technicallly so I am stuck at this point but I hope this information helps in some way for those who do know. [ Show » ] bob wellman - 02/Aug/07 05:01 AM I have noticed that this also occurs with 2 textures that do not appear transparent at all. I had a book case with afreebie books texture and a wallpaper texture. Placed the book case in front of the wall with the wallpaper on and then changed the angle of view and the wallpaper was see instead of the books. I chanege one of the textures and it stopped happening. So I Iooked at the textures in Gimp and they both have alpha channels even though it isnt neccessary for them to have. So I dont think its due to transparency itself but due to the alpha channel data overriding the other channels data in some way. I dont know how occlusion works technicallly so I am stuck at this point but I hope this information helps in some way for those who do know. OK, this shows the issue - perhaps a bit more obviously. The "rug" below the furniture that is obviously rendered improperly (loveseat has no transparency in it at all) has some edges that have transparent alpha - to remove an unwanted tassled edge.
Bob: "So I Iooked at the textures in Gimp and they both have alpha channels even though it isnt neccessary for them to have. So I dont think its due to transparency itself but due to the alpha channel data overriding the other channels data in some way."
Correct, the renderer sees a texture has an alpha channel and from then the object is treated differently. When a texture has no need for an alpha, people should know how to not use it, it only takes up disk space and causes such problems. voted for this issue, Im also experiencing this problem.
the issue clearly isnt limited to intersecting objects, like the screens show. Im getting similar issues, in some rare cases I get the windows of the neighbour´s house clipping in front of my walls when Im standing inside my house. this happens despite the two houses being about 20 meters apart at the "offending" place! I acknowledge that intersecting objects require complex solutions, but objects which are obviously seperated should work fine. Ive yet to see a game with similar issues, to be honest. the view angle seems to be a major factor. seems like the z order only works correctly in a 2D sense and only when viewed straight on. thus the alpha rendering appears to not exactly be 3D graphics programming. would love to see a fix for this. i don't like walls in my hair. bit by bit sl is returning to a no alpha no flexi world. soon everything will have to be default to render properly. including avatars.
Additional screenshot that illustrates the problem well. The rug is on the floor BEHIND the window.
Another screen shot that illustrated the problem well. The bamboo should appear in front of the railing and the water in the pond below should appear behind the railing.
This bug has been bothering me since the beginning of secondlife.. its impossible to have a plant in front of a textured window
Updated version info to reflect this still happening in latest viewer.
In this picture, I have a tree in the foreground that is semi-transparent. I have a window behind it, which is also semi-transparent. The tree appears BEHIND the windows, even though it is not.
I believe the same issue in hair using lots of alpha textures? As noted elsewhere, the issue does not appear when the avatar is facing south (here facing north).
This problem has been persistent since atleast v1.7. Though it's impact has become lessened in recent versions there are still moments where it can lead to atrocious graphic faults.
This problem is solvable, but as already noted it is a difficult one to do without hogging performance. It may be a good one to provide as an advanced graphics option; put the slider up and the rendering engine will use greater sub-divisions to solve transparency issues. At some point in the future computers may be fast enough to be able to keep this slider right up. Have it affected by LOD as well and lower-end users may be able to at least enjoy the advantage in non-laggy periods, but have it scale back to normal if things get too tough.
Alternatively just an on/off option, either you play without alpha sorting issues and take the performance hit, or you play with them at greater speeds. Could be a good option for snapshots as well, meaning snapshots will always come out perfect even if the game itself looks a bit iffy. 3D environments seven years ago had no problem with this bug and yet they ran stable on the midrange computers of that day. It's all about bugsquashing and optimizing the code.
llyara:
7 years ago people used mask transparency usually, not partial alpha transparency. It's a crapload simpler to sort mask transparency right. Can you name one 3D environment you have seen the last seven years that use alpha transparency that has experienced this type of z-ordering bug?
I've seen it in games using the Quake 3 engine, it's actually really easy to do. When you make a map just turn the compilation onto basic, all it will do is create the geometry and other essentials, but not do any pre-rendering. The alpha can actually screw up worse than SL's does.
The key thing to note is that most games from the last 7 years use pre-rendered scenes, and as a result are able to identify areas where these bugs may happen, and generates information which allows the game-engine to reduce or eliminate the issue when you come to play the game. In SL the load from trying to do this would be HUGE, either on the simulator side or on the client side. All it takes is a single object to switch from opaque, to 50% transparency and your performance is fucked. Wouldn't this be significantly improved by splitting prims into simpler parts as a matter of course, on the client side, before they're rendered? Break cubes into 6 planes, cylinders into 4 equal curves + top & bottom, etc.
Thinking specifically of "Issue - Transparency-render-1.jpg", if the cylinder was turned into 4 equal curves, I'm fairly certain that from every angle alpha sorting should work correctly. It's not a complete solution, but should work well until we can get real time raytracing clients! Yes, Xugu, that's basically also what Thygrrr Talaj is saying in the 2nd comment here. ;)
Afaik, as simple cube in SL already consists of 56 vertices (rather than the minimum 8) (each cube face has 18 mesh faces) (at least that's what wireframe mode shows), so maybe a crude subdivision per face could help, but I'm worried this will cost far too much (often already too low) framerate. I'm having the same issue.. i'd love to see it resolved..
This old bug makes a lot of design ideas impossible.
Sorry, my first thought on how to solve this was based on detecting this problem, and then solving it. Hadn't occurred until later that just subdividing as a matter of course would help.
So, best algorithm idea I've had so far: 1. Find furthest and nearest point of all on screen semi-transparent objects (fairly expensive, but shouldn't be too bad as long as there aren't too many semi-transparent objects on screen). 2. Look for objects which are between the near/far point of those objects. Any objects found are a problem case. 3. For each problem case create a plane orthogonal to the camera, centered on the mid-point of each contained object. 4. Break down the containing objects such that they do not intersect any plane from an object within them. First 3 steps are fairly well straight forward, AFAIK. Last one's still not terribly easy, alas, but I think shouldn't be impossible for someone with a better grasp on geometry than me... Or am I talking nonsense? I intentionally created a fan with alpha to demonstrate this, if I could drop a copy on one of the Lindens, I'd be more than happy to.
Added Snapshot1_001 wich shows how i arranged two transparent textures. One is far infront of the other.
[
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Open
Major
Prim textures overlap strangely when transparent textures applied
