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

I'd like to see an official, web based, part validator in the vein of Mike Heidemann's DAT Header program. A simple web interface where a part author can submit a part and be served back an error list and possibly a fixed, error free part. I would gladly host such an app on the LDraw.org servers.

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

(this is nost strictly about specifications, so feel free to move this thread)

So, there are some parts in the library that contains errors of various nature. Some of them must be solved by hand, others should be easy to solve "en mass" with minimal work. The problem about crossed quads is an example. Many viewer have built-in correction code, which made the problem more hidden and probably made it easier for mistakes to slip in the library. I think there's no reason not to address the issue directly on the library, so i suggest this:

- find a routine that correct quads. I'm sure there are many, for example it can be inferred from this post that some detection & correction tool already exists. In LDView the code looks like in here.
- put it into a programs that scans all .dat file in the library searching for quad lines. Pass the vertex to che correction function and eventually update the line. If the file has corrections, overwrite the original one with the correct one, maybe reporting which files have been modified for later review. The program appears to be simple as it operates on single lines, it doesn't need any context whatsoever on the 3d model beside the single quad. Actually it's mostly opening and rewriting files.
- review the modified files. I guess there are not that many, so we can probably manually verify one by one
- commit all changed files to the official library. I don't know how it is stored and who has access to it, but i don't think there are problems in a "mass commit", or are there?
- either forget about the script or somehow schedule it to run on new parts/periodically to detect new error.

Of course this doesn't break any compatibility, updating the library will have no visible difference in already existing software.

I'm no good in C, so i'm not able to help with the code (unless you want it written in other languages), i can offer my help to review corrected parts, if it's needed.

A couple of ground rules before you post:

• If you have a gripe, suggest a way to fix it. Be specific.
  
• We will only consider breaking backwards compatibility for really good reasons. All suggestions need to keep that in mind.
  
• We are not going to covert the spec to XML, binary format, etc. (See above.)
  
• More detailed suggestions will most likely get more responses. Please avoid overly general suggestions
  
• Posts on this thread may get spun off into their own threads. If you're using the flat view (i.e. not threaded or hybrid), try not break threading.
  

May I request to have part 98371 created?

Thanks,
Marc

Hi all.
I'm working on a simple builder in Java, derived from JLDraw Java viewer, but now I wonder if we really need yet another building software

My program will have a building mode with "autoconnect", i.e. new part will "snap" to nearest connection on line of sight (it is already done for studs, tubes, some technic pin and pegholes, but needs lots more work for other connections).

It is in Java, so we have "one version is good for all". Some drawbacks are the "rough" rendering (You must optimize a lot if you want some accettable speed in Java...), and probably the maximum size of a model, that will be in the order of 5k-10k parts (i'll not tested yet).

The coming of "MOC Builder" from Bricklink will make my program useless, I think.

So, I'm here to ask for your opinion: we need another building software? Please talk frankly and be direct: I'll survive to your criticism :-p ;-)

Thank you in advance.