Author Topic: Tree transparancy occlusion  (Read 745 times)

Induane

  • Veteran
  • *
  • Posts: 1287
  • What should I put here?
    • View Profile
    • Vaalnor Inc.
Tree transparancy occlusion
« on: October 28, 2005, 06:00:39 am »
I searched the forums and found a few posts relating to this - but it was never really solved.  Trees and other things which use transparancy are having a problem in PlaneShift. The occlusion goes too far back, excluding geometry it shouldn\'t, creating an odd disconcerting effect.  So I decided that since I didn\'t know anything about programming, and it didn\'t seem to be a crystalspace bug like people thought (I only deduced this because it was never ever fixed in any of the crystalspace builds, and I couldnt\' find any bug reports on it either), that I would research the problem and figure out wha was going on.  After a bit of searching I came across a small piece of evidence:

Quote
CS supports two kinds of transparency: alpha and binary. Alpha allows smooth transparency, with the downside that geometry with such textures needs to be sorted back to front to correctly display it; also, it usually can\'t write to the Z buffer (e.g. can\'t use zuse Z buffer mode), as transparent areas will be written to the Z buffer (and subsequently wrongly occlude other geometry).


Hmm so it would seem that you need z directional sorting for alpha transparancy to work well, but since the z buffer is where the alpha transparancy is written - the two can\'t occupy the same buffer.  Thus the transparancy gets written to that buffer resulting in an occlusion of geometry far beyond that of the mesh the texture containing the alpha is in.


So... what is the solution - perhaps a greenscreen like effect - choose one specific color, and then make it a keycolor - as described here:

Quote
Usually, for binary transparency, a keycolor is set on the texture. Internally, keycolor basically works like following: all keycolored pixels are searched, their color value replaced with the average of all non-keycolored neighbor pixels (or the average of all non-keycolored pixels if no neighbors are opaque), and their alpha set to 0. (The color replacement is done to avoid color bleeding due texture filtering - if that wouldn\'t be done, you could e.g. see a pink halo around transparent areas if the keycolor is pink.)


probabily people are already aware of this and I\'m just spewing useless nonsense - but I figured I\'d post on the off chance that it was something useful.

LigH

  • Forum Legend
  • *
  • Posts: 7096
    • View Profile
(No subject)
« Reply #1 on: October 28, 2005, 06:08:23 pm »
You probably mean this effect or that one. A similar problem are the transparent joints of road surface around the plaza.

Gag Harmond
Knight and Ambassador
The Royal House of Purrty

Induane

  • Veteran
  • *
  • Posts: 1287
  • What should I put here?
    • View Profile
    • Vaalnor Inc.
(No subject)
« Reply #2 on: October 28, 2005, 06:22:55 pm »
Yes - those are exactly what I am talking about - they really look quite weird.