0 BFC NOCLIP

[Steffen]

I just stumbled over files on the PT containing
0 BFC NOCLIP
...
0 BFC CLIP
sections, for example
https://www.ldraw.org/cgi-bin/ptdetail.c...02ap03.dat

I think we need to decide if those sections shall be
* kept or
* removed.

They usually enclose the patterned areas of a part.

I think the reason why they were added (probably long time ago) was
that somebody thought "hmm. these patterns could be visible from behind
when the part itself is being used in a transparent color".

However, that reasoning is based on a wrong assumption I think.
Maybe the tools of older times needed such statements, but today, these lines are not necessary.

Especially it makes no sense to just include the pattern by those lines.
If the argumentation towards having these lines would be correct, then the whole part
would need to be BFC NOCLIP.

But as said, the reasoning behind the addition of these lines is probably wrong I think:

As soon as a part is using transparent portions, these portions allow to see other surfaces "from behind".
It does not matter whether those other surfaces are colored (patterns) or color 16.

Therefore, 3D rendering software anyway must have an implementation for dealing with that problem.
Usually its solution will be to simply turn off BFC at all for parts that contain transparent portions.
That would be the only way to get a correct rendering for all such parts as a general solution.

Therefore it is not necessary that such parts individually and additionally enclose some of their implementation by
0 BFC NOCLIP.
Doing that is a kind of "poor man's solution" to the overall 3D rendering problem just described.

And most of the current files on the PT incompletely solve that problem,
because they do not include their color 16 surfaces in that section.

It follows:
these sections should be removed I think.

[Travis Cobbs]

It's been a long time since I wrote the code, but I'm pretty sure that LDView always draws the back of transparent geometry, not the back of all geometry inside transparent parts. So, in theory, any geometry that isn't color 16 would need NOCLIP in order for a transparent part to render properly in LDView.

[Steffen]

yikes.
that would mean that we would need to recycle all parts through the PT
and include all non-color 16 lines in BFC NOCLIP sections.
that's not what we should do IMHO.
Can LDView be adjusted so that as soon as a part contains any transparent
surface, BFC is turned off for the whole part?
That would save us from having to do the above.

[Steffen]

I just verified this behaviour with LDView 4.3 (28 Jan 2018) by

1 47 0 0 0 1 0 0 0 1 0 0 0 1 802ap03.dat

using the current 802ap03.dat from the PT:
https://www.ldraw.org/cgi-bin/ptdetail.c...02ap03.dat

The effect is only visible
- if BFC is enabled in the preferences
- if the display of red/green/blue BFC coloring is disabled

When that is the case, the 2 following images result:

(1) WITHOUT the 0 BFC NOCLIP line present in 802ap03.dat:
   


(2) WITH the 0 BFC NOCLIP line present in 802ap03.dat:
   

I think that the current LDView implementation incompletely treats this case:

As said, it should have disabled BFC completely for any part that contains
any transparent section, because that section will allow to look at the "innards" of a part.
The current workaround of adding 0 BFC NOCLIP sections around non-color-16 areas
of a part works around that problem only incompletely. And we only applied
that workaround to a fraction of all parts. I think our library gets cluttered by that
partial workaround.

I suggest to fix LDView instead.

[Travis Cobbs]

yikes.
that would mean that we would need to recycle all parts through the PT
and include all non-color 16 lines in BFC NOCLIP sections.
that's not what we should do IMHO.
Can LDView be adjusted so that as soon as a part contains any transparent
surface, BFC is turned off for the whole part?
That would save us from having to do the above.

It shouldn't be too difficult to fix, but I have no idea when the next version of LDView will be released. Having said that, LDView has always behaved this way, and I think this is the first time someone has pointed out that it is a problem.

[Max Martin Richter]

I just verified this behaviour with LDView 4.3 (28 Jan 2018) by

1 47 0 0 0 1 0 0 0 1 0 0 0 1 802ap03.dat

using the current 802ap03.dat from the PT:
https://www.ldraw.org/cgi-bin/ptdetail.c...02ap03.dat

The effect is only visible
- if BFC is enabled in the preferences
- if the display of red/green/blue BFC coloring is disabled

When that is the case, the 2 following images result:

(1) WITHOUT the 0 BFC NOCLIP line present in 802ap03.dat:



(2) WITH the 0 BFC NOCLIP line present in 802ap03.dat:


I think that the current LDView implementation incompletely treats this case:

As said, it should have disabled BFC completely for any part that contains
any transparent section, because that section will allow to look at the "innards" of a part.
The current workaround of adding 0 BFC NOCLIP sections around non-color-16 areas
of a part works around that problem only incompletely. And we only applied
that workaround to a fraction of all parts. I think our library gets cluttered by that
partial workaround.

I suggest to fix LDView instead.

As far as I remember, we do the NOCLIP command only for parts which are available in transparent colours.

[Roland Melkert]

As far as I remember, we do the NOCLIP command only for parts which are available in transparent colours.

From a rendering point of view NOCLIP should be used at places where the pattern is basically 'paint' . You could even argue this should be done even when the part isn't available in transparent (as LDraw doesn't prevent non existing color use).

In all other situations the pattern should be repeated at the backside of the object's wall if it needs to be visible from the inside.

my 2cts

fyi: LDCad will render the whole part dual sided when noclip is encountered anywhere in the recursive mesh data.

[Travis Cobbs]

As an aside, that part actually highlights a bug in LDView. The top-level file contains a 0 BFC NOCLIP statement before the patterned sub-part is loaded. And yet, BFC is still applied to that sub-part. I'll fix that as well.

[Steffen]

we do the NOCLIP command only for parts which are available in transparent colours.

That's exactly what I am aiming at with the above post.

LDRAW uses color 16 to allow you to use any part in any color.

Applying the above technique will forbid you to use a patterned part in transparent.

As said above, I instead would like to really humbly request from Travis to fix LDView in the way
that as soon as a part contains transparent portions, no BFC is applied at all.

Otherwise we would have to clutter the whole library with NOCLIP statements.

The answer "we only do that for parts that exist as transparent in real life" is unsatisfactory to me :/

[Philippe Hurbain]

While I agree that fixing all BFC aware programs would be the best (maybe LDview is not alone?), the situation is much less serious than you suggest. On parts that don't exist in transparent version, it's generally meaningless to use them in trans color AND look at them from backside AND expect to see the pattern !

[Steffen]

Yes, haha, that's of course true...

[Steffen]

I have now removed all my previous hold votes on parts on the PT which contained
0 BFC NOCLIP
.

Check here:
https://www.ldraw.org/cgi-bin/ptscan.cgi?q=noclip

I still hope that our programs will be improved so we in future can get rid of this workaround.

[Philippe Hurbain]

Thanks, Steffen.

I still hope that our programs will be improved so we in future can get rid of this workaround.

So do I, but as I said on the tracker, no harm is done by the noclip statement, neither now nor in the future.

[Magnus Forsberg]

Thank you for dropping your votes.

[N. W. Perry]

From a rendering point of view NOCLIP should be used at places where the pattern is basically 'paint' . You could even argue this should be done even when the part isn't available in transparent (as LDraw doesn't prevent non existing color use).

In all other situations the pattern should be repeated at the backside of the object's wall if it needs to be visible from the inside.

my 2cts

fyi: LDCad will render the whole part dual sided when noclip is encountered anywhere in the recursive mesh data.

I noticed that the other day. I had a part (772p01.dat) that I tried adding the NOCLIP statement to, but it changed the rendering of the whole part, not just the geometries between NOCLIP and CLIP.

So, in LDCad, the intened way to view patterns from both sides of a transparent part is to disable "Use BFC info if available"? That of course affects not only the transparent part, but all other parts in the model (though I'm not sure what effect this would have on rendering non-transparent parts, other than affecting system performance).

Or should we enable "Two sided transparency"? Again, that affects the entire transparent part, not just the pattern geometries—and i a slightly different way than disabling BFC. I suppose that's probably the point, although I visually prefer the rendering when neither of these options is used (except for being unable to see the reverse sides of patterns).

[Roland Melkert]

I noticed that the other day. I had a part (772p01.dat) that I tried adding the NOCLIP statement to, but it changed the rendering of the whole part, not just the geometries between NOCLIP and CLIP.

So, in LDCad, the intened way to view patterns from both sides of a transparent part is to disable "Use BFC info if available"? That of course affects not only the transparent part, but all other parts in the model (though I'm not sure what effect this would have on rendering non-transparent parts, other than affecting system performance).

Or should we enable "Two sided transparency"? Again, that affects the entire transparent part, not just the pattern geometries—and i a slightly different way than disabling BFC. I suppose that's probably the point, although I visually prefer the rendering when neither of these options is used (except for being unable to see the reverse sides of patterns).

The 'noclip => all dual sides' rule is a bit of easy way out solution I chose long before I took a second look at the transparency problems.

That's why I added the "Two sided transparency" option later on.

LDCad 2's render engine will take noclip more serious

[Orion Pobursky]

As an aside, that part actually highlights a bug in LDView. The top-level file contains a 0 BFC NOCLIP statement before the patterned sub-part is loaded. And yet, BFC is still applied to that sub-part. I'll fix that as well.

I hate to necro this post but it seems as if this bug hasn't been fixed. The 825 and 826 doors still render incorrectly in 4.4.1.

[Travis Cobbs]

I hate to necro this post but it seems as if this bug hasn't been fixed. The 825 and 826 doors still render incorrectly in 4.4.1.

I can't reproduce the problem in Windows or macOS. Here is what 825.png looks like for me using LDView 4.4.1 using color 1 (blue):

   

And here is 802ap03 using color 47 (trans clear):

   

They look the same in macOS. BFC is enabled in both. If I show red back faces, green front faces, and blue neutral faces, the opaque part is blue, and the transparent part is green (on both parts).

What am I missing?

[Orion Pobursky]

Here's the test code:

Code:

0 826atest
0 Name: 826atest.ldr
0 Author: Orion Pobursky [OrionP]
1 2  0 96 0  0 0 -1  0 1 0  1 0 0  700a.dat
1 14  0 72 0  1 0 0  0 1 0  0 0 1  3001.dat
1 47  50 0 -90  0 0 -1  0 1 0  1 0 0  825ap01.dat
1 47  -50 0 -90  0 0 1  0 1 0  -1 0 0  826ap02.dat
1 47  -50 0 90  0 0 1  0 1 0  -1 0 0  825ap03.dat
1 47  50 0 90  0 0 -1  0 1 0  1 0 0  826ap04.dat
0

Here's the output on my machine, 4.4.1, BFC turned on, Win 10, AMD Ryzen 5 2400G:
   

[Travis Cobbs]

Here's the output on my machine, 4.4.1, BFC turned on, Win 10, AMD Ryzen 5 2400G:

Thanks. I don't know why my test model rendered properly, but I see the problem with yours. I'll see what I can do to fix the problem.