[split] Teemu's Part Checker

[Chris Dee]

yes please.

we have brought the BFC-problematic files to nearly 0 now.

just a small handful of "weird relicts" are remaining:
https://www.ldraw.org/cgi-bin/ptbfcstatus.cgi

I suggest to delete all of them from the PT:
- one is a "minifig torso + head" physical shortcut assembly which - if we would add these combinations to the library - would make the library size explode due to the possible combination
- the others are mockups which have no visual resemblence with the parts they mimick and are waiting unfinished for years now on the PT.

All now deleted.

[Chris Dee]

Go ahead. Could the non-BFC column be removed, as we expect everything tpo be BFC these days?

I have removed the non-BFC column, but not checked for compatibility with the new agreement.

[Roland Melkert]

"Filename ending does not match declared LDRAW_ORG file type.": what does this mean? How do filename endings correlate with LDRAW_ORG file type? I guess subfiles have 's01' and so on but other than that I don't really get it.
"Filename ending does not match declared LDRAW_ORG part type qualifier." likewise...?

I think this means the file is .ldr instead of .dat when LDRAW_ORG indicates it's a part.

"Wrong BFC command found." What is a wrong BFC command?

Illegal combination of meta keywords.

[Roland Melkert]

"T-Junction detected." T-junction detection can be very difficult to implement and only a small minority of T-junctions are actual problems. Do we really want to automate this?

T-Junctions can cause seams during rendering so I would prefer them gone

Detecting them could be done by checking if vertices are near triangle/quad side lines without being part of that polygon.

This might need to include full recursive mesh data so it can check on the assembled part level.

[Philippe Hurbain]

T-Junctions can cause seams during rendering so I would prefer them gone

May I say I don't agree (at all!!!)? Most so called T-junctions never produce artifacts and can significantly reduce the number of faces to render!!!

[Willy Tschager]

"HELP entry length":

 It should trigger a warning because of readability. If this text would end up in just one line it get's harder reading it

w.

[Roland Melkert]

May I say I don't agree (at all!!!)? Most so called T-junctions never produce artifacts and can significantly reduce the number of faces to render!!!

It partly depends on the size of the polygons but it can really cause seams due to rounding errors.

This because the rasterizer doesn't guarantee the calculated final position of the projected vertex is (still) exactly on the companion polygon's side. This can cause a single pixel offset resulting in a seam.

See also:
https://computergraphics.stackexchange.c...-in-cracks

It can also upset normal calculations, because weird jumps in smoothness could occur if the two t-juncted polygons aren't on the same plane.

[Orion Pobursky]

It partly depends on the size of the polygons but it can really cause seams due to rounding errors.

This because the rasterizer doesn't guarantee the calculated final position of the projected vertex is (still) exactly on the companion polygon's side. This can cause a single pixel offset resulting in a seam.

See also:
https://computergraphics.stackexchange.c...-in-cracks

It can also upset normal calculations, because weird jumps in smoothness could occur if the two t-juncted polygons aren't on the same plane.

Ok, but take this part for example:

https://www.ldraw.org/cgi-bin/ptdetail.c...004p0d.dat

If I got rid of T-Junctions, there would a huge amount of small, thin triangles around the border.

[Roland Melkert]

Ok, but take this part for example:

https://www.ldraw.org/cgi-bin/ptdetail.c...004p0d.dat

If I got rid of T-Junctions, there would a huge amount of small, thin triangles around the border.

That part doesn't seem to suffer from the problem indeed, but it has only 4 quads introducing t-junctions (the side frame).

So it would only need 14+14+4+4=36 extra quads to be completely t-junction free.

But in the end it's all on a very small surface so you might be right about it not be 'worth' it for such parts.

[Philippe Hurbain]

It partly depends on the size of the polygons but it can really cause seams due to rounding errors.

This because the rasterizer doesn't guarantee the calculated final position of the projected vertex is (still) exactly on the companion polygon's side. This can cause a single pixel offset resulting in a seam.

See also:
https://computergraphics.stackexchange.c...-in-cracks

It can also upset normal calculations, because weird jumps in smoothness could occur if the two t-juncted polygons aren't on the same plane.

I know the rationale behind that, I just say that if you SEE no problem, then there IS no problem having T-junctions. And actually it's fairly rare you see artifacts (at least in planar surfaces)

[Orion Pobursky]

I know the rationale behind that, I just say that if you SEE no problem, then there IS no problem having T-junctions. And actually it's fairly rare you see artifacts (at least in planar surfaces)

This is actually my philosophy for almost the entire HOLD list: an unnoticed error is not an error. I reiterated it several times when we were discussing it.

[Travis Cobbs]

That part doesn't seem to suffer from the problem indeed, but it has only 4 quads introducing t-junctions (the side frame).

So it would only need 14+14+4+4=36 extra quads to be completely t-junction free.

But in the end it's all on a very small surface so you might be right about it not be 'worth' it for such parts.

Actually, the T-Junctions in that part do produce visible artifacts (at least in LDView on some hardware):



At many viewing angles, there are no artifacts, and I had to very slowly rotate to get to a viewpoint where three were visible at once, but at least one was commonly visible.

[Travis Cobbs]

I know the rationale behind that, I just say that if you SEE no problem, then there IS no problem having T-junctions. And actually it's fairly rare you see artifacts (at least in planar surfaces)

As I point out above, the problem exists. Granted, my screenshot was an unusual situation, where the part is zoomed in quite far, but since the artifacts on T-junctions are pseudo-random, they scale based on the total number of pixels that are in the scene that happen to lay on a boundary where T-junctions exist. So, if the above part were used repeatedly in a scene, but each one were quite small in the view, it's still likely that the T-junctions would lead to a similar number of incorrectly colored pixels. On average, the number of incorrectly colored pixels might be less than 1 (so none visible in many frames), but they would flicker into existence during animation.

[Philippe Hurbain]

This is actually my philosophy for almost the entire HOLD list: an unnoticed error is not an error. I reiterated it several times when we were discussing it.

Heartfully, isotropically and continuously agree!

[Philippe Hurbain]

As I point out above, the problem exists.

Yes it does but...

Granted, my screenshot was an unusual situation,

...add in some antialiasing, and it becomes next to impossible to see, even in this pathological view case!

[Travis Cobbs]

Yes it does but...
...add in some antialiasing, and it becomes next to impossible to see, even in this pathological view case!

Just to clarify, I don't feel that T-junctions should trigger a hold. However, I do feel that every effort should be made to avoid them (even in the example given).

[Willy Tschager]

I had some time to work on the checking tool and I put up a new version up at the usual location, 

Teemu,

any idea how this can be integrate into ldraw.org o is a link in the PT Tools enough?

w.

[Santeri Piippo]

[*]
0 BFC CERTIFY INVERTNEXT

w.

There's a separate entry in the issue list for "CERTIFY INVERTNEXT".

[*][*]

 It should trigger a warning because of readability. If this text would end up in just one line it get's harder reading it

w.

I guess that makes sense since it reads so in the spec...

[*][*][*]

Just to clarify, I don't feel that T-junctions should trigger a hold. However, I do feel that every effort should be made to avoid them (even in the example given).

In any case I don't think that I'm going to implement automatic T-junction detection since it seems to vary case-by-case whether it's a problem or not.

[*][*][*][*]

Teemu,

any idea how this can be integrate into ldraw.org o is a link in the PT Tools enough?

w.

I understood that the idea was to integrate this to the parts tracker. It can be run from the command line so I think hooking it up shouldn't be such a problem. I can also put together some other interface if that is needed.

[Chris Dee]

I understood that the idea was to integrate this to the parts tracker. It can be run from the command line so I think hooking it up shouldn't be such a problem. I can also put together some other interface if that is needed.

What language is it written in? Does it run on Linux?

[Santeri Piippo]

What language is it written in? Does it run on Linux?

It is written in Python 3, so it runs on Linux.

[Philippe Hurbain]

I had some time to work on the checking tool and I put up a new version up at the usual location, roughly doubling the amount of detected issue types. I've attached here a table of the current implementation status of the tool:

Just made a few tries, like the speed of your tool!

Problems I found so far:
- The file name is not checked against header name field
- Got "Line 139: hairline polygon (smallest angle 0.24°) — WARNING" while hairline threshold is 0.025°
- There is currently a problem with the new parts update, checker complains about missing files included in the last update.

[Orion Pobursky]

Just made a few tries, like the speed of your tool!

Problems I found so far:
- The file name is not checked against header name field
- Got "Line 139: hairline polygon (smallest angle 0.24°) — WARNING" while hairline threshold is 0.025°
- There is currently a problem with the new parts update, checker complains about missing files included in the last update.

Can we spit discussion about Santeri’s checker out into a new thread?