Merlijn Wissink Wrote:I really like the idea of a new library, but if we make a complete new library, we also need to make a complete new toolset (new software) for all the things that can be done with LDraw models (e.g. making instructions, which is one of the most important ones).

Nicola Wrote:Also i get the feeling that this would be some kind of "side project" that will fail to bring any real innovation on the ldraw world. But maybe not, maybe some developer will start using the new library and we can make a smooth transition without breaking anything..

• At first you have to define all needed vertices (optional with normals, uv-map, color, etc). I can imagine that it would also be possible to add new properties later (e.g. bone-weight, render information, etc).
  
• With these vertices you can now define (via indices) lines, triangles, (quads, polygons,) optional lines, etc. Here it might be possible to add new properties later (render information, textures, etc), too.
  

Chris Dee Wrote:I like the idea of the new library being programmatically derived each time the current library is updated, if indeed that is feasible.

So it sounds to me like the existing library could be considered to be conventional "source code" and the new, enhanced version a kind of "compiled" version. Since objects in the new library would never be created manually there's no reason for it to be text format, so it could be binary, and thus possibly smaller (4-byte float numbers support 6 significant decimal digits), although if the complilation inlines all subpart and primitive references that may not be the case. In keeping with the LDraw ethic, I think it should be Open Source or Creative Commons. It also wouldn't need to be 8000+ separate files in one folder, which I'm aware has been mentioned as a scaleability concern.

However, it seems pointless (and ambitious) for us to try and define a new binary graphics file format, if there is already one out there that provides all we need. I don't know enough to evaluate that possibilty myself. I think connectibility might be a missing feature of existing formats, but we haven't really incorporated that into the LDraw file format either, apart from a notional acceptence that studs form a connection point.

Quote:we don't have textures

Quote:Actually i think the brevity of ldraw format is not as great as it is pictured. Sure, the recursive nature saves space, but the vertices are stored in a very inefficient way: they are repeated in each face instead of being listed beforehand and referenced in faces. This makes "complex" parts very verbose and possibly waste all the gain from primitives.

Willy Tschager Wrote:So what?! I love when someone pops in from time to time making a lot of fuss how and what should be change - better WE should change - and then vanishes into thin air right afterwards:

http://forums.ldraw.org/showthread.php?tid=13116&pid=13116#pid13116

w.

Roland Melkert Wrote:I think the first step needed before any other is to get rid of all detectable and auto correctable defects in the existing official library.

Roland Melkert Wrote:I'm willing to try and do that using a dev version of my LDCad, which will then generate corrected files for any file currently generating warnings in it's log as they are already corrected in memory. So I just need to make some (small) adjustments in order to write those files to disk.

But afterwards someone else needs to take those (probably many) files and merge them with the pt etc, anyone interested?

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.

Nicola Wrote:Some people replied but if discussion stops there's no point in talking alone

Nicola Wrote: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

Steffen Wrote:XML to me always appeared too overheading.

..


I write this to argument against XML. I have to deal with it a lot elsewhere, and despite the fact that parsers
for it exist a lot etc. pp., its syntax overhead always is ineffective and annoying.
JSON would be something much better IMHO. Parsers for it exist as well a lot.

Steffen Wrote:We should more focus on fixing the remaining [few!] errors in official files

Magnus Forsberg Wrote:But how do you add normals to a missing surface,

Quote:or connectivity information to a missing primitive?

Magnus Forsberg Wrote:Would a 'simple' tool correct those errors? Can LDCad do that?

Roland Melkert Wrote:I too was thinking .obj, I just don't know if it allows for extension without confusing other software capable of importing 'clean' obj. Because it would be very nice to use standard .obj for the main mesh etc but still have the option to (at least) add conditional lines without breaking the format for other tools to use it as is.

Roland Melkert Wrote:Generating the basic .obj would actually be pretty basic as it's almost the same info/data you need to generate in order to draw the part efficiently in OpenGL.