Now with better connection to LDFind (version 1.3.0.0 is needed).

Website

A number of people have mentioned that minor edits should be fast tracked on the PT. I agree. Here's my proposal:

I'm going to split this off as a new thread since the old one is unwieldy...

When we develop a list of points (via check and snap), there will be (hopefully only a few) remaining points that have not been snapped to each other and remain with only _one_ tri or quad accessing them. We can exploit this as these points must be:

• Part of a t-junction
  
• A point that has not been snapped properly
  
• An edge point (but this should be illegal in an LDraw part)
  

Hi Y'all,

Roland and I have been tossing around part numbers, looking at smoothing results. One thing that surprised me is that we needed a rather large 0.05 LDU error margin to 'snap' the segments of the 6x6 webbed dishes together. (The part is built via 8 sub-sections rotated 45 degrees.) 0.05 seems like a 'big' error because part authors can specify vertices to the 0.001.

Today I cracked open the part and took a look at the numbers, and the large error margin now makes sense.

The fundamental problem is absolute error amplification: if the error on a matrix ratio is 1/1000 (0.001 precision) then the actual error in the position of a rotated part is 0.001 * R where R is the approximate radius of rotation. In other words, a part that extends 60 LDU from its center will have an absolute error of 60/1000 (0.06) after rotation. (In fact, the real results are up to 3x worse because error accumulation is additive and we add the X, Y, and Z components of the matrix).

The actual numbers of the 6x6 dish show that the worst case error could have been much worse than this actual part. The bottom line is: 0.001 just isn't _that_ precise for a rotation component that's going to be used for a moderately big part. :-(

This matters because the rounding tolerance for welding rotated part segments for smoothing defines the smallest 3-d detail an author can make without having their triangles collapsed.

I realize that we have a gajillion parts and my going "we should do X" isn't going to actually change the library, but I wonder if this perspective should result in some kind of updated practices for authoring.

Naively, I would suggest two possible changes...

1. We could allow higher precision for matrices. For example, the part is using 0.707 for a 45-degree rotation. If I go into the text file and replace it with 0.707106781186548 I can cut my error margin down by 4x. (Clearly BrickSmith isn't using all of 0.707106781186548 - I just typed a big long number into the text file...BrickSmith is using 32-bit float.)

2. Authors could avoid angle rotations that aren't 90 degree increments. At 90 degrees, the rotation matrix can be _exactly_ represented - all rotational coefficients are 0, 1, or -1. :-) So the 'lock-up' of vertices around 90 degree rotations should be pretty good - certainly in the same ballpark as the geometry itself.

This would mean 'bigger' parts - 90 degree swathes of dish instead of 45 degrees, but the precision would be a lot better.

Cheers
Ben

Version 0.2.1 of LDForge is now out, fixing a bug causing LDForge to skip every 300th line of a given file. See release document and downloads here

• BFC red/green view, albeit present, isn't always right; it assumes everything is CCW and it fails to catch INVERTNEXT in subfiles. Also it has to draw everything twice so there's a bit of a performance hit.
  
• The camera suffers of gimbal lock. I'm going to try address this for future versions.
  

• List view ala MLCAD with multi-selection. One object per line, one line per object. Items not colored main or edge color (16/24) have their color reflected in the list view for identifying.
  
• Parse error recovery, if a line/object cannot be parsed properly it will be displayed as an errorneous object. This object can be selected and its contents edited and have it reparsed, so you can fix these errors within LDForge.
  
• 6 camera modes plus a free-angle one.
  
• Drawing mode that allows you to literally draw polygons and lines into the screen.
  
• Object hiding
  
• Select by color or type
  
• Quick edge-lining, takes any number of polygons and creates edgelines around them
  
• Ability to edit object's LDraw code directly
  
• Inlining, plus deep inlining which grinds down to polygons only
  
• Auto-coloring (sets color to the first found unused color), uncoloring (sets colors to main/edge color based on type)
  
• Coordinate rounding, inverting, coordinate replacing, flipping, quad splitting
  
• Screenshotting
  
• Vertex object, generic radial primitive object
  
• LDConfig.ldr parsing for color information
  
• Ability to launch Philo's utilities and automatically merge in output
  
• BFC red/green view (incomplete)
  
• Wireframe mode, axis drawing
  
• Image overlays for getting part data from pictures
  

Hi,
first thank you for your work.

After a lot of years of utilization, I developed the dream of to do as many as possible of official sets with the correct parts.
I know that this dream is quite impossible and that there is similar part that can be used, but I want to try to achieve my dream.

With humility, I ask if there is someone with spare time to create some of the following parts to help me (I have tried with a conversion from LDD but the result is visually good, but in reality I do not succeed to optimize the parts so to use them properly).

Best regard and still many thanks for the part made in this year
CL

The list:
6014b Wheel 11.5mm D. x 12mm, Hole Notched for Wheels Holder Pin (the actual version is very different)
58088 Wheel Cover 7 Spoke with Axle Hole (for the set 8145 Ferrari 599 GTB Fiorano)
60032 Window 1 x 2 x 2 Plane, Single Hole Top and Bottom for Glass (for set 4997 Transport Ferry)
30625 Hinge Panel 1 x 4 x 3 2/3 with 6 holes, 2 studs on top, Locking 2 Fingers
3245c Brick 1 x 2 x 2 with Inside Stud Holder

Since some years we have beneth the designid.dat files also itemid.dat files in our /parts folder.
This will be ok if there is never a conflict between design id number and item id number.

Joshua Delahunty now identified such a bad situation.(Please read his comments: http://www.ldraw.org/cgi-bin/ptdetail.cg.../74333.dat).

We need to stop immediately the usage of item-id.dat files in our standard /parts folder.

Any suggestion how to solve this issue is highly wanted.

Is there a limit on how many part I can have in a Shortcut?

I've put together the Horntail Dragon, but think is just too many.
I dislike the idea of all ready-made part shortcuts in the library. I have noticed the attempt from Steffen to add wheel and tyre shortcuts, but have been ignoring them so far. What do you think?

The idea of lego is the fun of putting them together yourself.

Attached Files

  52258c01.dat (Size: 2.07 KB / Downloads: 0)

So I was working on my little parts authoring tool (ldforge) again and ran into a little problemo: is there required to be a whitespace after the numeric code for comments? Is a line like "0// edge lines" valid or are they considered errorneous?

I would assume it's illegal but assuming is bad, so yeah. The specification doesn't seem to mention anything about this, maybe I am blind as usual?

Hi Y'all,

I'm sorry to start a third thread on part smoothing, but I wanted to step back and ask a process question; I haven't been involved in LDraw long enough to know how this gets sorted out.

There are a few ideas that have been thrown out on how to solve part smoothing problems, but they involve different groups of people and perhaps different standards bodies:

1. We might say that no change to the LDraw format or any parts or any change to authoring guidelines will happen, and programs need to take the most drastic steps while smoothing, e.g. code for the worst case.

2. We might intentionally modify the parts library, perhaps with mechanical transformations (E.g. run a program that splits T junctions over many parts). This would require some kind of approval.

3. We might intentionally introduce new syntax features into the LDraw file format (and then apply them to some parts) to simplify the process of smooth rendering.

Where do we go from here? Would it be useful for me to write up an RFC, just so we have a straw man?

I can continue coding assuming case 1, but such code will be non-optimal (e.g. we'll have to put in a part cache that we don't otherwise have just to make things performant) and such code would be obsolete if either 2 or 3 happen. If either 2 or 3 are on the table, it would be nice to plan for them.

cheers
Ben