Hello there, i'm nicola80 (aka msx80 aka msx, depending on username availability 
), author of brigl.
I don't want to sound harsh, but since i frequented this forum i've seen many people lamenting on the file format of LDraw. Some people even went on to create their own library, such as mecabricks (with normals). I've adressed the issue many times in the forum, without receiving much response. I'll restate some of my points here:
About the error in the library (quads etc), i think this is a minor problem. I think i could spend a day or two implementing some correction code, but i really think the problem is on the part library. They can be easily corrected as soon as they're discovered. But you have many different "correction" code already available, why not run them on the whole library and sanitize once and for all? LDView, MLCad, and many other programs already do this and their code is already pretty solid. This is so straightforward i really think there's no reason no to do this.
About CCW/CW/Invertnext/double sided poly: for all i can see, this is completely superfluous. No other file format i know (and i know some), has things like this. This is not a big issue, but again is an arbitrary and useless thing we have on top, it's a mix of legacy and solutions from a time where saving a single triangle was a big gain. Now video card can pump out gazillion triangles with ease. Just stick with a direction, and convert the library.
About conditional lines: well this is something really messy. It's some kind of cell shading algorithm, but it is implemented in a way that contast with modern rendering tecnique where you build a bunch of vertex and give them to the graphic card. Nowadays, this kind of problem are solved with shaders. There's no problem in leaving the cond line there of course (except that some parts have errors), one can always ignore them. Except that they're basically used for smoothing, and this bring the BIG problem:
Normals. No other single file format i've seen leave out normals to be computed by the user. There's absolutely no reasons not to include them. They're integral part of a geometry definition. Why forcing every single developer to reinvent the wheel, to spend countless hour on a custom smoothing algorithm. Algorithms that are already usually complicated, but more so for ldraw where definitions are sparse in multiple files, and one have to take into consideration hard and cond lines. I'm not a newbie of 3d programming (not a genius either by all means), and yet i've spent days trying to implement this algorithm and have yet to succeed. Of course i could spend some other weeks and do it, but why? And even if i did, we'll end up with many different programs, each one with its own algorithm, all slightly different, all buggy in a different way and with no consistency at all.
Implementing normals is actually very easy, just prepend every single quad/tri with a new command/comment:
0 NORMALS v1x v1y v1z v2x v2y v2z v3x v3y v3z [v4x v4y v4z]
There. No compatibility broken at all. Sure it's not an easy task, but as i said above all the software is already there, it just need to be glued together in some "smart" sanitizing scripts. Unfortunately it's all C, and i don't know the language, otherwise i would have already tried myself.
Again i don't want to be polemic, but i think it's time to update the format. It seems to me that there's a strong sentiment to hold things like they're now, just as if people were afraid of changes. Brigl is currently used on three major sites, Brickset, Rebrickable and Bricklink. It could be a good chance to promote LDraw over competing formats. As i said mecabricks looks wonderful, they have grown a library incredibly quickly, and the results are both performant and gorgeous.
Please take this the good way and try and consider my suggestion.
), author of brigl.I don't want to sound harsh, but since i frequented this forum i've seen many people lamenting on the file format of LDraw. Some people even went on to create their own library, such as mecabricks (with normals
). I've adressed the issue many times in the forum, without receiving much response. I'll restate some of my points here:About the error in the library (quads etc), i think this is a minor problem. I think i could spend a day or two implementing some correction code, but i really think the problem is on the part library. They can be easily corrected as soon as they're discovered. But you have many different "correction" code already available, why not run them on the whole library and sanitize once and for all? LDView, MLCad, and many other programs already do this and their code is already pretty solid. This is so straightforward i really think there's no reason no to do this.
About CCW/CW/Invertnext/double sided poly: for all i can see, this is completely superfluous. No other file format i know (and i know some), has things like this. This is not a big issue, but again is an arbitrary and useless thing we have on top, it's a mix of legacy and solutions from a time where saving a single triangle was a big gain. Now video card can pump out gazillion triangles with ease. Just stick with a direction, and convert the library.
About conditional lines: well this is something really messy. It's some kind of cell shading algorithm, but it is implemented in a way that contast with modern rendering tecnique where you build a bunch of vertex and give them to the graphic card. Nowadays, this kind of problem are solved with shaders. There's no problem in leaving the cond line there of course (except that some parts have errors), one can always ignore them. Except that they're basically used for smoothing, and this bring the BIG problem:
Normals. No other single file format i've seen leave out normals to be computed by the user. There's absolutely no reasons not to include them. They're integral part of a geometry definition. Why forcing every single developer to reinvent the wheel, to spend countless hour on a custom smoothing algorithm. Algorithms that are already usually complicated, but more so for ldraw where definitions are sparse in multiple files, and one have to take into consideration hard and cond lines. I'm not a newbie of 3d programming (not a genius either by all means), and yet i've spent days trying to implement this algorithm and have yet to succeed. Of course i could spend some other weeks and do it, but why? And even if i did, we'll end up with many different programs, each one with its own algorithm, all slightly different, all buggy in a different way and with no consistency at all.
Implementing normals is actually very easy, just prepend every single quad/tri with a new command/comment:
0 NORMALS v1x v1y v1z v2x v2y v2z v3x v3y v3z [v4x v4y v4z]
There. No compatibility broken at all. Sure it's not an easy task, but as i said above all the software is already there, it just need to be glued together in some "smart" sanitizing scripts. Unfortunately it's all C, and i don't know the language, otherwise i would have already tried myself.
Again i don't want to be polemic, but i think it's time to update the format. It seems to me that there's a strong sentiment to hold things like they're now, just as if people were afraid of changes. Brigl is currently used on three major sites, Brickset, Rebrickable and Bricklink. It could be a good chance to promote LDraw over competing formats. As i said mecabricks looks wonderful, they have grown a library incredibly quickly, and the results are both performant and gorgeous.
Please take this the good way and try and consider my suggestion.