LDraw.org Discussion Forums
[split] Teemu's Part Checker - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: Parts Author Tools (https://forums.ldraw.org/forum-24.html)
+--- Thread: [split] Teemu's Part Checker (/thread-23521.html)

Pages: 1 2 3


[split] Teemu's Part Checker - Chris Dee - 2019-06-24

(2019-06-16, 9:06)Steffen Wrote: 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.


RE: What requires a HOLD vote on the Parts Tracker - Chris Dee - 2019-06-24

(2019-06-16, 4:31)Chris Dee Wrote: 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.


RE: What requires a HOLD vote on the Parts Tracker - Roland Melkert - 2019-06-24

(2019-06-24, 7:34)Santeri Piippo Wrote: "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.


(2019-06-24, 7:34)Santeri Piippo Wrote: "Wrong BFC command found." What is a wrong BFC command?
Illegal combination of meta keywords.


RE: What requires a HOLD vote on the Parts Tracker - Roland Melkert - 2019-06-24

(2019-06-24, 7:34)Santeri Piippo Wrote: "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 Smile

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.


RE: What requires a HOLD vote on the Parts Tracker - Philippe Hurbain - 2019-06-25

(2019-06-24, 17:39)Roland Melkert Wrote: T-Junctions can cause seams during rendering so I would prefer them gone Smile
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!!!


RE: What requires a HOLD vote on the Parts Tracker - Willy Tschager - 2019-06-25

(2019-06-24, 7:34)Santeri Piippo Wrote: "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.


RE: What requires a HOLD vote on the Parts Tracker - Roland Melkert - 2019-06-25

(2019-06-25, 6:45)Philippe Hurbain Wrote: 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.com/questions/1461/why-do-t-junctions-in-meshes-result-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.


RE: What requires a HOLD vote on the Parts Tracker - Orion Pobursky - 2019-06-25

(2019-06-25, 17:24)Roland Melkert Wrote: 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.com/questions/1461/why-do-t-junctions-in-meshes-result-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.cgi?f=parts/3004p0d.dat

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


RE: What requires a HOLD vote on the Parts Tracker - Roland Melkert - 2019-06-25

(2019-06-25, 17:55)Orion Pobursky Wrote: Ok, but take this part for example:

https://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/3004p0d.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.


RE: What requires a HOLD vote on the Parts Tracker - Philippe Hurbain - 2019-06-25

(2019-06-25, 17:24)Roland Melkert Wrote: 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.com/questions/1461/why-do-t-junctions-in-meshes-result-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)