Like mentioned in some of the other threads, the current official library suffers from a number of defects which can be corrected automatically but can be somewhat of a pain to new software trying to use the library.

It also has been suggested many times most of these errors can be fixed using an automated process.

So I did a quick hack in the LDCad 1.4 code to make it possible to save corrected .dat files back to disk, this resulted in about 116 corrected .dat files.

Only downside I noticed is the loss of some indenting (only for the corrected lines, as LDCad preserves unmodified line content).

I also noticed some minor mixed dos/unix line endings which are indirectly auto corrected for any file that needed rewriting.

This test includes only 'hour glass quad' corrections, but with some additional tweaks I can also auto correct:

case mismatches
non flat triangles
quad with duplicate point (degrade to triangle)
all zero row or col ref matrix
type 5 line with missing or duplicate control points (degrade to normal line)


Should I continue my tweaks, and compile a patch containing all changed files so someone else can double check and merge them into the part tracker?

If so which corrections are actually wanted, and or which additional correction would be needed/wanted.

ps: this topic might be better off in the part authoring forum, not really sure though, admins feel free to move it.

Hi

I have been using Big Ben Bricks Wheels parts in MLCAD for some time now.
When I entered my model into LDView I noticed it complained about a missing part - ring8.dat.
I Can't seem to find it anywhere.
Does anyone know what to do about this?

What ever happened with the "LCD - LDraw Connection Database"?? As seen here.


Seems like this would have been a good thing.

Hi all,

I'm desperately try to find good picture on the net for 2552px2



I've posted a thread in Eurobricks forum, will see the results.

However, is there someone here that own the part, or that know someone who own the part, that can provide my good picture of the 5 surfaces (front, back, right, left and top)?

This is the only part I'm missing to complete the Blacktron II series.

Thanks in advance.

Hi all.

Working on coding some Java libraries to handle LDraw libraries I hit some parts with errors. Following a brief list with errors/typos I found:

* 3842a.dat uses BFC CERTIFY INVERTNEXT
* 3842b.dat uses BFC CERTIFY INVERTNEXT
* s\3068s101.dat uses color 391 (unknown)
* 973psk.dat uses color 391 (unknown)
* 4150p02.dat uses color 354 (unknown)
* 973p7b.dat uses color 354 (unknown)
* s\2528s01.dat at line 385 there is a triangle with 4 vertices
* s\6582a.dat all quads are "bow-tied"
* s\6582b.dat all quads are "bow-tied"
* s\6580a.dat all quads are "bow-tied"
* s\6581a.dat all quads are "bow-tied"
* s\6594a-c.dat all quads are "bow-tied"
* s\6595a-d.dat all quads are "bow-tied"
* 2907.dat some quads are "bow-tied"
* s\6579a.dat all quads are "bow-tied"

HTH
Mario

Following Darats idea exposed here

Quote:I wasn't able to use chrd primitives cause there's no 1-16chrd.
So it doesn't look really nice with primitives substitution.

Hello.
I use the LDD for two weeks now and use the LDView to convert the lego models in a format for 3d programs.

Sadly the .ldr (lego draw) file format doesn't save some blocks and flexible things.

Is there a possiblity to get all blocks and flexible stuff into LDview or a other program where I convert it into a 3d format ?

Is it possible to get the .lxf file in a 3d program or can I convert the .lxf file straight to a 3d format ?

In the LDD, is there a flexible grease band ?

Here is a example how I want to apply the grease band:



Also sometimes if I've rotated a view blocks in the LDD, some parts in LDview are rotated/placed weird.

Here is a picture of it:



I hope some people could answer my questions

I feel guilty for requesting such a rare, complicated, and useless part, but I need it! This is the "Technic Engine Tuneable, Block with Trapezoidal Air Scoop" used in a couple of Racers models.

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 ?

So as I previously said about 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.

Updating all the library in not an easy task, but i think it can be done in a way that doesn't break compatibility and permits automatic data entry.

First off, i propose to add a new comment/command, with a standard sintax as follow:

0 NORMALS v1x v1y v1z v2x v2y v2z v3x v3y v3z [v4x v4y v4z]

It will be prepended to all quads and triangles, and will have three or four vertex definitions. Of course each one is the normal at the corresponding vertex of the face, in a per-vertex, per-face paradigm that is usually the standard.
Being a new comment, it will not cause any problem with existing software. Editors working with parts will not have any problem. Editors that write tri and quads may break the file but should not crash or misbehave themselves, and the user should be able to act on the problem. Hard and conditional lines can (and must) stay there of course.
New software developers can take advantage of the normals to achieve an uniform look across different renderers and saving weeks of head banging.

Now the delicate part: this solution assumes that any face have the same normals regardless of where it appears, or in other words that each single subpart/primitive always assume the same normals. But it may be that the same subpart can have different normals depending on the rest of the part it is attached to. If this is indeed the case, than it derives that it's impossible to add normals to a subpart as it can vary.
I'm not sure about this, intuitively each 3d shape should have its normals regardless of what it has around. Much of this maybe depend on the granularity of the subparts, how much down they break a solid. I remember that the primitives breask down even to 2d figures, which will need to be adressed somehow. In the worst case, the primitives would need to be rethinked with normals in mind.

How to popolate the library with normals

Ok, the problem of course is to inject all the normals in the already existing library. As the previous post, my solution is to take an existing smoothing algorithm, elevate it as the standard, and apply it to the whole library.

Basically it would work on a per-part basic. It will load the part and all the subpart into a canonical 3d model data structure, but mantaining a correlation between each face and the file/line that generates it. It will then apply the smoothing algorithm to the part, then traverse all faces and use the correlation to write them back in the source text. Of course some subparts will already have normals calculated (since they're shared), in this case the subpart can be skipped (or take advantage of the occasion to check if the would be calculated the same way).

Ok course normals are useful only if they're available on the whole part library (if a developer need to implement a smoothing algorithm for a single part, he may as well do it for the whole ), this of course means that the library will grow in size, but i hope this is not an issue. Only subparts with actual faces will grow, but most of them should be reusing already defined chunks so will not grow. Eventually some optimization can be implemented (such as inserting a single vector instead of 3/4 if the face has uniform normals).
I'd love here some feedback for this humble proposal