Steffen Wrote:Of course our library should be error-free.
It simply isn't yet, because humans make errors and because we lacked time to find all.
However, over time these errors will be gone.
I like it that your post has triggered us to cure these problems.
When 2 years ago I wrote a quick LDRAW parser myself, I also ran it on all official and unofficial files for testing,
and found many BFC syntax errors in official files.
I took the effort to cure all of them and uploaded them to the PT.
However, what I do not like is that you're attacking the file format itself so fundamentally.
Yes, the files have errors like bowtie quads etc., but it still is up to your program to be robust against such.
You don't even have to correct them there.
You can simply skip broken things.
This responsibility cannot be taken from your shoulders. Otherwise your program would require that all its input
is error-free, which does not happen in real life. If you feed a broken JPG image to your painting program,
it should report an error or ignore certain parts of the file, but it certainly shouldn't crash.
Your program needs to be robust against broken input.
Regarding using BFC CCW everywhere, of course, this is trivial to do for all our parts and subparts,
and I like doing that - simply for simplicity.
However, we still need the full BFC syntax like 0 BFC INVERTNEXT so we do not have to duplicate
all our primitives. So changing all parts and subparts to 0 BFC CCW is a nice-to-have, but I would regard
that a low-prio task. We should more focus on fixing the remaining [few!] errors in official files
like bow-tie quads and unknown colors.
The discussion about normals is more complex and already in a different thread.
I'd like to add to that discussion maybe in another post.
I like the simplicity of the LDRAW file format a LOT over other formats, especially binary ones.
The file format has made us very productive, the library has grown HUGE over the past years,
and although there are quirks and problems at some places, many, many, many parts have been created.
There's 2 sides of our library: authors are working a lot with the files and producing parts,
and consuming applications parse them. Bringing both worlds together sometimes needs balancing.
For example, yes, it might be difficult for brigl to fix a bowtie quad - but, hey, then simply ignore it.
It anyway is broken in the input file. On the other hand, curing that quad is easy for a part author,
and it is not the fault of the file format that the bowtie quad is present. Would we choose another file
format, then there would be other errors in it, and your application again would need to be robust against them.
Well first off let me say that i appreciate all the effor that have been put in ldraw, you guys did an incredible job in putting all of this together. I hope this is clear, i'm grateful and i use ldraw programs regulary to do my stuff (mostly instructions). I don't want to appear ungrateful.
About input problems, i think a program should be robust enought not to crash and report any error, but should never try to "autofix" things. HTML parsers of the previous decade showed this very clearly: the first browsers tried to autocorrect erratic html, and what they caused was more erratic html being created, no consistency in how different browsers rendered things, and an hell for anybody trying to implement a renderer.
It looks like ldraw had the same problem, with lenient softwares that caused erratic parts to go unnoticed and even slip uncorrected into the official library.
Btw, as you said, the existance and the fixing of broken parts have nothing to do with the file format itself, they're separated issues, we could have broken part in any other format
About the format itself, i already expressed my opinions. I think it has a lot of unnecessary fuss in it. It's hardly "simple", a simple 3d format usually only have vertices, triangles and normals. Nothing else. It doesn't need to invent new concepts. I think the library has grown huge thanks to your endeavour, not thanks to the format. I admit i don't know much about how part designers work, but i got that they use a suite of custom tools and often correct things manually directly in the text. It would be very, very hard to convince me that this process is more effective than working with any modern cad software. Maybe they're accustomed to it, and became proficient, but that doesn't mean it's ideal.
Being text or binary based makes no difference, it's the content that is important and the same content can be stored indifferently in binary or text.