Transparency fights fog?

[Hrolf]

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?

[EgonOlsen]

Which renderer is that? Soft- or hardware?

[Hrolf]

Software

[EgonOlsen]

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.

[Hrolf]

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!

[EgonOlsen]

Not very elegant!

And difficult to mix, isn't it?

[EgonOlsen]

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...

[Hrolf]

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?

[EgonOlsen]

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