Author Topic: Transparency fights fog?  (Read 3475 times)

Offline Hrolf

  • int
  • **
  • Posts: 84
    • View Profile
Transparency fights fog?
« on: September 26, 2009, 08:49:44 pm »
Hi Egon,

These trees render perfectly with fog turned off, but with it on the trees become increasingly transparent depending on the distance of the polys behind them.
Is there a workaround to save my trees from having their heads cut off? I've tried every possible value in setTransparency(), setSortOffset() &c, but to no avail... Can you help?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11747
    • View Profile
    • http://www.jpct.net
Re: Transparency fights fog?
« Reply #1 on: September 26, 2009, 09:35:49 pm »
Which renderer is that? Soft- or hardware?

Offline Hrolf

  • int
  • **
  • Posts: 84
    • View Profile
Re: Transparency fights fog?
« Reply #2 on: September 26, 2009, 09:54:14 pm »
Software

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11747
    • View Profile
    • http://www.jpct.net
Re: Transparency fights fog?
« Reply #3 on: September 26, 2009, 10:18:09 pm »
I see...that's a problem with the way per-pixel-fog is being applied in the software renderer. It renders the fog based on the data in the zbuffer. Problem is, that transparent objects don't write into the zbuffer, because that causes problems with overlapping parts.
One possible solution would be to make this restriction optional...all other solutions that i can think of at the moment fill kinda sick and will eat performance for breakfast...
Could you provide me with a simple test case that mimics what you are doing? Then i could see if writing into the buffer would be a solution or not in this case.

Offline Hrolf

  • int
  • **
  • Posts: 84
    • View Profile
Re: Transparency fights fog?
« Reply #4 on: September 26, 2009, 10:29:45 pm »
Thanks for the answer - I was afraid it was something like that! I'll try to get a test case together tomorrow...
What I was thinking was to render in two parts with different near/farplanes; with fog for the 'distant' part and without fog for the 'near' part of the view. Not very elegant!



Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11747
    • View Profile
    • http://www.jpct.net
Re: Transparency fights fog?
« Reply #5 on: September 26, 2009, 10:36:07 pm »
Not very elegant!
And difficult to mix, isn't it?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11747
    • View Profile
    • http://www.jpct.net
Re: Transparency fights fog?
« Reply #6 on: September 26, 2009, 11:15:11 pm »
Try this build: http://www.jpct.net/download/beta/jpctapi_119pre2_5.zip. It adds an option to Object3D (setDepthBufferWrites(<boolean>)) that makes transparent objects write into the zbuffer. Setting this to true may cause visual problems when using real alpha blending for transparency but as long as you are using jPCT's cheap software renderer transparency, it should fix the problem.

BTW: Applying the fog is another nice location to add multicore support to...i think i'll do this before 1.19 goes final...

Offline Hrolf

  • int
  • **
  • Posts: 84
    • View Profile
Re: Transparency fights fog?
« Reply #7 on: September 27, 2009, 02:18:27 am »
Egon, you are a marvel! *falls on knees and worships*

Many thanks!

PS I got a new logger message 'Additional visibility list (2) created with size: 4096'? Poly-picking still seems to work fine... Should I worry about this?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11747
    • View Profile
    • http://www.jpct.net
Re: Transparency fights fog?
« Reply #8 on: September 27, 2009, 01:28:17 pm »
That happens if you render multiple worlds (or the same world twice) into one frame buffer without calling display() in between. It's nothing to worry about.
I've updated the build from last night with a version that can use multiple threads for the fogging calculation: http://www.jpct.net/download/beta/jpctapi_119pre2_5.zip
Usage is described in more detail in http://www.jpct.net/forum2/index.php/topic,1435.0.html