Partial transparent parts and "needs work" note's

[Roland Melkert]

Hello all,

I was playing around (testing) in my dev versionof LDCad this weeked when I noticed this:



(You can look through the IR receiver)

In the header of 58123 BFC is enabled, so are the subparts, but then I noticed the comments in some of the subfiles ("Needs Work: inner side not modelled").

This made me think, my rendering loop is correct after all, but when I open the above little test ldr in LDView 58123 seems to be rendered without culling.

Am I missing something here? In short what's the (by authors) expected correct behavior here.

[Philippe Hurbain]

Yes, I know this might be a problem on this part (and some similar ones). But when I look at this part with LDView, the IR glass is MUCH darker and you simply can't see anything through it (alpha of color 32 is pretty high). Maybe the difference between LDview and LDCad is that you culled out back side of transparent part. The glass of the IR receiver has two sides, each ones attenuating light, precisely to decrease transparency. But yes, the only real solution would be to create an inner skin on this part... Some part authors are decidedly careless ;D

[Roland Melkert]

Yes I'm culling the backside of the transparent stuff away, that's the cause of it being more transparent. But if you turn on stipple and bfc info in LDView, you'll see the back side (now red) should be culled away, yet LDView doesn't.



I'm wondering why it's ignoring BFC. Because if it didn't it would look the same as in LDCad I think.

And taking all this into account: is the way LDView handles this part the favored way by part authors?

Do mind, I'm not complaining about this part. I'm happy with the way it is. Just wondering about the associated technical issues

[Orion Pobursky]

Travis correct me if I'm wrong but I think LDView turns off BFC for transparent colors.

[Travis Cobbs]

With BFC enabled, I get the same effect in LDView that you see in LDCad. Here are my steps:

• Disable "Process LDConfig.ldr" in LDView's preferences so that the IR glass isn't so dark.
  
• Set LDView's background color to bright green.
  
• Enable BFC (with red/green/blue faces disabled).
  
• Load 58123.dat all by itself.
  

The green background clearly shows through.

Orion: LDView does indeed disable BFC for the transparent portions of the part, but not for the opaque portions of the part.

[Roland Melkert]

Ouch, for some reason I thought the 'BFC' button in LDView was for the red/green info only. So I didn't realize I've turned culling off altogether.

Turning culling off for transparent triangle/quads causes double blending, and as a result makes things less transparent. Is this 'wanted' behavior from renderers (by the color maintainers/part authors)?

[Travis Cobbs]

The only way for BFC-certified transparent parts to look consistent with non BFC-certified transparent parts is if BFC is disabled during all transparent part drawing, so I chose to do that. Of course, I added BFC support to LDView over 6 and a half years ago, and there were a lot fewer BFC-certified parts then.

Whether or not it is "wanted" is anybody's guess, but I've never had anyone complain that LDView's transparency was too opaque. However, LDView does cheat on this a bit. The default alpha value (from ldconfig) is 128, and this gets mapped to 110 in LDView. Everything below 128 is interpolated such that 0-128 maps linearly from 0-110. Everything above is interpolated such that 128-255 maps linearly from 110-255.

Note that I chose the 110 value via empirical testing (with two-sided transparent surfaces) before having ldconfig.ldr support, so the mapping was my solution to 128 being the standard alpha for transparent parts in ldconfig.ldr.

[Travis Cobbs]

Here's my mapping code (transA is hard-coded to be 110, and both alpha and transA are integers):

Code:

// This is a little odd, but we want 128 to map to our standard
// transparent alpha (transA), anything below transA to smoothly map
// from 0 to transA, and anything above transA to smoothly map from
// transA to 255.
if (alpha == 128)
{
    alpha = transA;
}
else if (alpha < 128)
{
    alpha = alpha * transA / 128;
}
else
{
    alpha = transA + (alpha - 127) * (255 - transA) / 128;
}

[Philippe Hurbain]

Turning culling off for transparent triangle/quads causes double blending, and as a result makes things less transparent. Is this 'wanted' behavior from renderers (by the color maintainers/part authors)?

Imho it makes sense to cut off culling for trans parts makes sense since IRL you may see the back side of trans parts!

[Roland Melkert]

Thanks for the info, I think I'm going to add a option to do something similar.

Only downside for me is I can only toggle culling on a per part usage level, out of mesh management/performance considerations.

[Travis Cobbs]

I just realized that the 127 and 128 values are swapped in the last equation above. It should be the following instead:

Code:

alpha = transA + (alpha - 128) * (255 - transA) / 127;

Mind you, I highly doubt anyone would ever be able to see the difference, but the above is the correct equation.