LDraw.org Discussion Forums

Full Version: Feedback Request: Table of Offests for Related Parts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Hi Y'all,

Some official parts have origins that favor easy rotation along their hinge but make them (relatively) difficult to place. For example:

3853 (window 1x4x3) and its shutters/panes (3854, 3856)
60596 (door frame 1x4x6) and its doors (e.g. 60623, 30178c01).

I saw that one author had written a help comment into a proposed part that stated the relative offset ot place the part in its parent. Unfortunately, the comment is not machine-readable. So my idea is to make a table of relative placements that would describe where to place the child part (e.g. the door) relative to the parent (its frame) to align the hinge mechanism. Since the parts are official, it's too late to change origins (and in some cases an origin that favors assembly would have other problems) but the table could allow a 3-d editor to insert the part directly.

A few questions:

- Has anyone already done this/is there an existing system that could be leveraged? I am sure i'm not the first person to consider this.
- Would such meta data better be stashed in the part itself or kept in a side table?
- Is there interest from other app developers in having access to relative placement table?
- How to handle parts that can be connected in multiple ways (e.g. the shutter can go to the left or right of the window)?
- Does this come too close to a "connections database"?

On that last point, my view is that even if such a scheme were stop-gap in the bigger picture, it would still be useful and could be replaced with something more thorough later. "Placement" info is simple enough that it could be done now, and it's useful even for 'fixing' a small number of part placements.

You are talking connection information here, there is a standard in the works for that (although it seems pretty much dead at the moment).


On the main issue, I've setup such a db years ago for use in my LD4DStudio project. You could take a look at the coordinate information contained in the *.4sp files.


Haven't updated them to the latest LDraw library in quite some time though.

If you go on collecting this information more deeply I would be interested in it for use in future LDCad versions (I'm planning snapping for 1.3 or 1.4). Since the LCD thing seems pretty dead, I'm all open to any shared approach on this or maybe refire the LCD thing.
Thanks for the links; the .4sp files seem like a production version of sort of what I had in mind.

The full connection db proposal did get me thinking about how much 'more' we would want, either now or later. I updated to the latest LDD and noted that they have both positive suggestion (e.g. they seem to know when a part has 'snapped' into another, more or less) and negative (you can't overlap two bricks in space), and they seem to understand hinged vs non-hinged connections.

Let me think a little bit about how much functionality would really be useful...the LDD hinge tool is useful enough that it made me go "I wish I had that for BrickSmith". :-) At the same time, we could go so far as to make something impossible to code. :-)

Possible features:
- Identification of good connections (snap together).
- Identification of bad connections (e.g. a lack of snap).
- Identification of illegal placement (overlapping bricks).
- Identification of legal rotations (e.g. rotate this hinged thing).
- Identificaiton of illegal rotations (e.g. you can't rotate this hinge past 90 degrees).
- Identification of structural failure (e.g. if you slide the clip past this point on the antenna, the clip is no longer attached).
- Combinations of these features (e.g. if you rotate this hinge, you'll stop at X degrees because any further and part Y and Z will overlap...(!)

I'd be happy with just good connections and a hinge tool, but it would also be nice to have a file format that we won't have to throw out later if someone wants to do more.

(The hinge tool basically rotates an entire snapped together collection of parts around a known hinge, using the hinges degrees of freedom. For models that use hinges to create particular angles or shapes, this is significantly faster than doing a manual "rotate around point" by coordiante with a multi-part selection.)
SR3DBuilder does that so may looking at it's files give some further info.

But I would like to see an publicly thought-out / official standard like LCD supporting this kind of stuff.
That would indeed great, but as long as we only have one application (SR3D) that supports these things, I fear that the consens will always be - how does SR3D solve this. And that is not what I think about our rules.

But I am very fine with adopting SR3D technology as our base standard (first step).

Is there any IP problem with using SR3D as a reference for any part of a connection db spec? Would Sergio be okay with that? (Is he here on the forums? :-)

I'll take a look at SR3D later...I'll have to install it on a PC to get access to the data files.

Michael Heidemann Wrote:That would indeed great, but as long as we only have one application (SR3D) that supports these things, I fear that the consens will always be - how does SR3D solve this. And that is not what I think about our rules.

I agree with you on this, although it might even be better to start from scratch (even forget the lcd doc).

First step would be to gather some more people/authors interested in this and set up some basic 'must have' / 'nice to have' lists.

Second most important thing is to decide how to integrate any new information into the existing library. For example are we going to edit hundreds/thousands of official files (I doubt it) or use some kind of companion/include file system. Or maybe even a single xml.

With LDCad I'm mainly thinking / doodling about a way to generate (most) of the information from the existing parts without having to manually add info to them. If this could be done fast enough it would just become part of the loading/prepping process, if it's heavy work generate some sort of cache.
Although he is quite open about the format of the files, I don't think you should blindly copy any of his information without consulting him first.
I think that generating from already existing files will be ok for max. 50% of the connection points. Leaves 50% . That is too much. Maybe it has been at LD3Modeler (sorry, i do not remember the name well ) where all the connection points are stored in another directory but with the same name? I like that approach. I would also be fine with a file beneth the current dat file but with a different extension (maybe ldc for ldraw connection). The benefit with the separate directory / folder will be that we do not just double the files in our main folders.

To start from scratch is in my opinion not the best way, because we have already a system that works. So we have also a lot of data already that can be used.
I think there are applications of a conncetion DB that can only work when the entire library is correctly and completely annotated.

But there are other applications that can provide value to users even when only a few parts are annotated.

I think this second point is important because I think the motivation for the community to work toward completing connection data will be stronger if there is at least some immediate benefit to partial completion of the work.

So I would say that technology used to "seed" a connection database would be valuable. For example, if it was possible to pre-populate 50% of the database with programatic analysis of existing parts, that's a great start. As a user of LDraw, I'd rather contribute to finish the second 50% of connection information than start from 0%. :-)

It may also be possible to get leverage by putting connection annotation on parts at the sub-part level. For example, if studs are built by referencing sub-parts (rather than hand modeling) then tagging a few sub-parts with stud connection information would effectively add studs to a large number of parts.
Pages: 1 2 3