LDraw.org Discussion Forums
Introducing a second HL library? - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Introducing a second HL library? (/thread-14432.html)

Pages: 1 2 3 4 5 6


Introducing a second HL library? - Roland Melkert - 2014-11-04

With all the recent commotion I'm thinking it might be useful to introduce a second 'official' LDraw library.

It would be identical parts wise as the master one, but all parts will be formatted in a single .dat using universal winding etc. We could also add normals to those single files without polluting the master LDraw library.

I would basically be a collection of pre calculated cache files. This library could even be made available in e.g. .obj format.

Anyone think this is worth a second look / go ?


Re: Introducing a second HL library? - Willy Tschager - 2014-11-05

Going for a second library would be better than trying to fix the existing one. We would have to have:

* A new file extension such as .prt to be distinguishable from the old library
* Normals and all the fancy things you want in
* Contain connection points
* An automated conversion process with one or a bunch of progs in place before the conversion starts on the whole. We surely DON'T want to recycle some 10000 files through the PT. Anyone remembering the workload for the new header?

My 2 cents,

w.


Re: Introducing a second HL library? - Nicola - 2014-11-05

I kind of like the idea. It permits to depart from the ldraw format without breaking compatibility. You could put all needed info inside (normals, edges, condlines, etc) and the developers could take full advantage of everything.
Were you thinking about "flattening" che hierarchy, or keeping it? maybe it's better if a single .prt file contains all the data for a part without dependency (ie, all subparts are "inlined"), to mantain the concept of "one file, one part".

The only problem i see is that ldr and mpd file are themselves in the ldraw format. So opening and ldr file would mean parse both the "old" (current) and new format, also, nothing stops an ldr/mpd file from having tri/quads/lines directly inside, which would be a problem. Designing a new format for "models" too would mean that programs based on the new library will be unable to open old files out in the wild (effectively creating some kind of fork). Indeed one of the characteristic of the current format is that there's no precise boundaries between model, submodel, part, subpart and primitive.

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..


Re: Introducing a second HL library? - Merlijn Wissink - 2014-11-05

I've been thinking about this for the past few days, a second new and updated LDraw library. I can see no disadvantages for the library iteself.

However, everything else based on the first library will become, well, useless. Unless the software is being updated of course.
For example, the golden combination of MLcad + LPub (both aren't being updated anymore) for making instructions will become "useless". So, someone will need to make new software for making instructions and the question is if there will be. If not, people keep using the old library (for making instructions in this case) and then the part authors don't see any reason why they should make parts in the new format and also stick with making new parts for the old library.
And, this is just 1 example.

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).


Re: Introducing a second HL library? - Nicola - 2014-11-05

If i understoor correctly the idea, the current library will still be the one that get updated and receive manteinance, while the new library will simply be calculated from the first one (i imagine it will be automatically periodically aligned), so the current one would not be useless at all. Indeed all the work will still happen on the current one until new softwares come around taking advantages of the new one. (this if i get roland proposal right).

I agree that LPub is currently one of the primary reason for using LDraw, being the only option available for building hi quality instructions. It surely is for me at least


Re: Introducing a second HL library? - Roland Melkert - 2014-11-05

I was thinking to ether keep these flattened files in normal LDraw format but using new meta/line types for adding normals etc. Or using a completely new (or existing 3d) format.

End user tools still need to understand basic LDraw (type 1, mpd format) to use the library but instead of having to recursively and process the raw library files they use the pre processed ones from the new library.

Any older software just keeps using the original files directly. Also new software can decide them self's if they (also) support the raw format (needed for unofficial files for example) or take the 'easy' way and only use the extended files.

If in the long run people (part authors) like creating the single file parts better or prefer a reduced recursive nature we could reassess things concerning the master library.


Re: Introducing a second HL library? - Roland Melkert - 2014-11-05

Yes, I was thinking when ever a new library is released some program basiclly does what a modern viewer does (calculating normals, fixing errors, etc) and generate the flattened files from the 'raw' LDraw files into e.g. complete-ext.zip.


Re: Introducing a second HL library? - Willy Tschager - 2014-11-05

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).

As for LPub someboby will have to fix it and some of the current bugs right away:

http://sourceforge.net/projects/lpub4/

Then there is also LIC:

http://forums.ldraw.org/showthread.php?tid=13871&pid=13871#pid13871

w.


Re: Introducing a second HL library? - Willy Tschager - 2014-11-05

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..

Not necessarily. Get some geeks, make the tools and see what happens.

w.


Re: Introducing a second HL library? - Chris Dee - 2014-11-06

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.