LDraw.org Discussion Forums

Full Version: 0 BFC NOCLIP
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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.
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.
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.
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:
[attachment=3772]


(2) WITH the 0 BFC NOCLIP line present in 802ap03.dat:
[attachment=3773]

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.
(2019-06-20, 1:15)Steffen Wrote: [ -> ]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.
(2019-06-20, 1:49)Steffen Wrote: [ -> ]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.
(2019-06-20, 20:54)Max Martin Richter Wrote: [ -> ]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.
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.
(2019-06-20, 20:54)Max Martin Richter Wrote: [ -> ]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 :/
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 !
Pages: 1 2