LDraw.org Discussion Forums

Full Version: Auto correcting (some) defects in the official library
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
Roland Melkert Wrote:Initially I only intended to process these files to help kick start the cleaning process no need to credit me etc. Hence the request (in the first post) for some one else to do something with them in regards of the pt etc.
This is your work, so to incorporate that work into the LDraw library you do need to affirm the Contributor Agreement (CA). You don't need to (and for official parts that are not alrready being re-worked, you cannot) submit them to the PT yourself. I can handle that but the new HISTORY lines need to contain your LDraw userID, as a recognition of your affirmation of the CA. Otherwise the files become non-redistributable - and we don't want that.
Among the PT Tools there is now a dynamic list of non-bfc parts.
It shows all the current parts that have a missing or 'nocertify' bfc statment.
If I understand it correctly, that list will adapt it's content when a bfc-fixed official or unofficial part is uploded to PT.

Is it time for a recap?
What are the errors you have fixed?

What is the next step?
1.)
Upload all of these files to PT and a normal review process?
2.)
Not recycling them through PT, but sending them to PT admin and a release without review?
3.)
Am I expected to review them as they are?

If I remember it correctly, it started with a 'broken display' in webgl rendering.
Is this all an effort to make our parts look good in those renderers?

I've now had a quick look into some of the parts, and can't help but wonder What has been changed? I see the same flawed part, but maybe software don't get confused. I don't know. I'm not a programmer, only a part author.

The major issue for making a good rendering in webgl is all the files that are not BFC'd.
I can't see that any of the auto fixed parts has become BFC'd. Or have I missed them?

Don't get me wrong. This is an atempt as good as any, but personally I'd rather pick files from that list at PT to work on, and improve them one at a time.
They need to go through the Parts Tracker. That is the safest way to get them packaged into a release without broken dependencies.
Magnus Forsberg Wrote:What are the errors you have fixed?
These are the things whom are detected and fixed during loading of LDCad and thus end up in these patches.
  • "0 BFC CERTIFY INVERTNEXT" -> "0 BFC INVERTNEXT"
  • type 1 ref name case mismatch
  • all zero matrix in type 1 line -> id matrix
  • all zero row or col in type 1 line matrix -> tries to correct by adding 1 or -1 at suitable position.
  • type 1 line with color 24 -> color 16
  • type 4 line with hourglass sequence, tries to fix by swapping/rotating points around
  • type 4 line with duplicate points -> degrades to triangle (but only if the other 3 are unique).
  • non flat type 4 line (0.0015 dotprod diff -> ~3deg) -> degrades to two type 3 lines.
  • type 5 line using a control point which is equal to one of it's line points -> degrade to type 2 line.

Most made corrections are the case mismatch, the hourglass or non flat quads though. But all these corrections where added to LDCad because it caused problems in one way or another at some point (in the past).


Magnus Forsberg Wrote:I've now had a quick look into some of the parts, and can't help but wonder What has been changed? I see the same flawed part, but maybe software don't get confused. I don't know. I'm not a programmer, only a part author.
Some parts might still look weird because they have many more flaws (like e.g. 206b.dat) but at least all/most invalid formatted LDraw lines should be corrected (like all the zero row/col matrix errors in 206b).


Magnus Forsberg Wrote:Don't get me wrong. This is an atempt as good as any, but personally I'd rather pick files from that list at PT to work on, and improve them one at a time.
Just use the ones you like and ignore the others, I'm doing these mass corrections only to help not to hinder.
Thanks,

I'll put them in a single file and prevent saving on matches.
additionally, the added history line makes it easier for us parts reviewers to quickly grep for
all those parts affected by that batch change.
Ok, I've made a new archive this time I also changed the headers and excluded the files on Philio's lists.

It resulted in a 2MB 7zip

or a version which preserves the Physical_Colour tags in cap only files (also a 2MB 7zip)


It again holds separate lib trees for files having just cap fixes, and files with the other fixes (also incl caps if they needed any other fix). Also included again are the relevant LDCad logs. Do note the 2nd pass one is now much larger as it still finds errors/problems with the excluded files.

It's a lot smaller as I discovered the previous one also included the unchanged \s files, sorry about that so it's best to completly forget about the previous .7z (I removed it on my site too).

I've also requested a pt account like Chris asked.

And again feel free to only use a subset or just a hand full, The whole point of this exercise is to help clean the library not to hinder or annoy the part authors Smile.
Thank you very much.
The "LDraw-1401-autoFixExclCapOnly" now only contains a fairly "small" bunch of files:

1 primitive
232 parts
53 subparts

I would find it tolerable to simply put these on the PT now and let them sink through there as usual,
so we can find the remaining errors like this

800.dat (Brick 2 x 4 with Wheels Holder for Car Steering-Gear Axle)
WARNING "800.dat" Line 168: Identical to line 165: 4 16 -36 16 -8 -36 4 -8 -8 4 -8 -8 16 -8
NOTABENE "34b.dat" referenced by "800.dat": Moved to 3110
NOTABENE "34d.dat" referenced by "800.dat": Moved to 3111
NOTABENE "ring2.dat" referenced by "3111.dat": Moved to 4-4ring2

and maybe others.
maybe we should update the quite outdated
http://www.ldraw.org/library/tracker/ref/reviewfaq/
sometimes Smile)))

what I do [usually] is:
- check syntax with l3p (yes, the ancient one Smile
- look at the file header manually (does it have correct part type, license etc.)
- check the part title if it fits consistently into the library
- check the part with DATHeader
- open the file in LDView with turned on coordinate axes to check proper origin and orientation
- visual inspection with LDView to look for missing lines
- visual inspection with LDView, turning BFC red/green/blue coloring on and off to find BFC errors
- visual inspection with LDView, turning on random color mode to find overlaps
- staring at the part some more
- if I find problems, some closer inspection or running additional tools like edger etc.

Would be interesting to hear other people's check routines
My routines aren't really as sophiscated.. I usually just look at the header as displayed by the parts tracker and inspect the part in LDView with the BFC red/green/blue mode on, check the origin, orientation, check in edges-only mode to find missing edgelines and, for patterns, check in random colors too. DATHeader doesn't work on my linux system at all so I just have to hope someone else scans the part.

My rule of thumb generally is that if the origin/orientation is good and the part doesn't show visual deficits and it's technically correct then it's good enough.
Pages: 1 2 3 4 5 6