[#SNOW-172] View of objects png objects

6. Second Life Snowglobe - SNOW

View of objects png objects

Created: 05/Aug/09 04:33 PM Updated: 13/Aug/09 02:43 PM

Return to search

Component/s:

Graphics

Affects Version/s:

Snowglobe 1.2

Fix Version/s:

None

File Attachments:

None

Image Attachments:

1. Picture 1.png
(314 kB)

2. Picture 2.png
(482 kB)

Environment:

« Hide

Model Name: MacBook Pro 15"
  Model Identifier: MacBookPro2,2
  Processor Name: Intel Core 2 Duo
  Processor Speed: 2.16 GHz
  Number Of Processors: 1
  Total Number Of Cores: 2
  L2 Cache: 4 MB
  Memory: 3 GB
  Bus Speed: 667 MHz
  Boot ROM Version: MBP22.00A5.B07
  SMC Version (system): 1.12f5
  Serial Number (system): W87012Y9W0G
  Sudden Motion Sensor:
  State: Enabled

Issue Links:

Duplicate

This issue duplicates:

~~VWR-27~~ Prim textures overlap strangely when transparent textures applied

Last Triaged:

13/Aug/09 02:43 PM

Description

« Hide

When viewing object the field of depth wil change, or a object like a sign will look farther than it is..like a sign infront of a fence, the sign is placed in front of the fence, but when looking head on the sign will behind the fence or not show at all, in my example pictures the flowers are on the side of the path, but when looking at the side the flowers split the path and the path takes over

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 05/Aug/09 04:56 PM

Duplicate of ~~VWR-27~~

[ Permlink | « Hide ]

Barrett Slade added a comment - 05/Aug/09 08:44 PM

You closed this ticket in refrence to dup 27 and 27 shows resolved well guess what not resolved, and shows no fix pending, and guess what problem still going on..if you want to dup this ticket to 27 reopen 27 and say fix pending

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 06/Aug/09 04:15 AM

That is because this issue and ~~VWR-27~~ are not solvable, from ~~VWR-27~~:

BigPapi Linden added a comment - 06/Mar/09 08:48 AM
Sigh, closing this again. OpenGL AND DirectX both suffer from this drawback in the rendering of partially transparent objects, because rasterization libraries that rely on the depth buffer for simple occlusion sorting ALL have this issue. There is NO magic rasterization library that doesn't suffer this problem. I am re-pasting a link from the OpenGL wiki that explains the issue and why there is no solution to it:

http://www.opengl.org/wiki/Alpha_Blending

PLEASE DO NOT REOPEN THIS ISSUE. Especially if you haven't read or understand the above linked wiki page!

Alpha sorting problems can ONLY be solved in one of three ways:
1) Having artists not create geometry that is susceptible to alpha sorting issues (aka don't create the issue).
2) Cutting up semi-transparent polygons (breaking them into smaller polygons) per viewer frame (camera dependant) and sorting each and every new transparent face perfectly from back to front based on "coverage".
3) Draw the entire scene using ray-tracing.

I've been recommending #1 all this time, because #2 & #3 are currently impossible to do in real time for the geometry that our residents create in world. Yes, impossible. No, not because we "don't get it." If we were to implement #2 or #3, the viewer framerate would quickly approach 0, which would make it very hard to move around.

Like I said a couple of times already, for objects that you don't want partial transparency, you can instead vote for the following jira, which deals with the adding of support to treat alpha textures as masks (every pixel is either opaque or invisible, with no partial transparency and thus no blending), which allows us to use the depth buffer and would thus not suffer from alpha sorting errors:

http://jira.secondlife.com/browse/VWR-6713

[ Show » ]

Harleen Gretzky added a comment - 06/Aug/09 04:15 AM That is because this issue and ~~VWR-27~~ are not solvable, from ~~VWR-27~~:

BigPapi Linden added a comment - 06/Mar/09 08:48 AM Sigh, closing this again. OpenGL AND DirectX both suffer from this drawback in the rendering of partially transparent objects, because rasterization libraries that rely on the depth buffer for simple occlusion sorting ALL have this issue. There is NO magic rasterization library that doesn't suffer this problem. I am re-pasting a link from the OpenGL wiki that explains the issue and why there is no solution to it: http://www.opengl.org/wiki/Alpha_Blending PLEASE DO NOT REOPEN THIS ISSUE. Especially if you haven't read or understand the above linked wiki page! Alpha sorting problems can ONLY be solved in one of three ways: 1) Having artists not create geometry that is susceptible to alpha sorting issues (aka don't create the issue). 2) Cutting up semi-transparent polygons (breaking them into smaller polygons) per viewer frame (camera dependant) and sorting each and every new transparent face perfectly from back to front based on "coverage". 3) Draw the entire scene using ray-tracing. I've been recommending #1 all this time, because #2 & #3 are currently impossible to do in real time for the geometry that our residents create in world. Yes, impossible. No, not because we "don't get it." If we were to implement #2 or #3, the viewer framerate would quickly approach 0, which would make it very hard to move around. Like I said a couple of times already, for objects that you don't want partial transparency, you can instead vote for the following jira, which deals with the adding of support to treat alpha textures as masks (every pixel is either opaque or invisible, with no partial transparency and thus no blending), which allows us to use the depth buffer and would thus not suffer from alpha sorting errors: http://jira.secondlife.com/browse/VWR-6713