Inclusion of LSYNTH parts in the official LDRAW library

[Steffen]

I would like to open the discussion here for including elements in our official LDRAW library
which allow synthesizing/generation of e.g. flexible parts like LSYNTH does.

The topic is chosen a bit unlucky, because of course LSYNTH is not the only program capable of that
now or in future, so we should not be tool-specific here (as always. our library is generic.)
I just chose the title of the thread, so the basic principle is clear.

I would like to suggest the following ideas and discuss them with you to get them
to a consensus for a future official library release.

Generation of flexible parts like cables, hoses etc. is usually something a user of our library would like to do.
The generation usually takes place by placing some start and end pieces, plus some constraint files,
and then sweeping some parts along some path to generate the flexible part.
The sweep can be smooth/continuous, or discrete, like for chain elements.
So we have different kinds of elements which come into play here:
(a) start / end parts (like chain elements)
(b) start / end subparts (like hose ends)
© constraint definition files
(d) sweeping primitives (like cable or hose)
(e) sweeping parts (like chain elements)

SUGGESTION 1: we should include all of these in the library.

Question is: which of (a)-(e) should go into which folder?
What is a part or a subpart or a primitive?
In the past there has been this suggestion:
put all into the PARTS folder, because otherwise MLCad won't show them
However, I do not like this idea at all, here are the reasons:
1. This is a tool-specific problem. Just because MLCad today only shows parts, this should not affect our library design.
2. The logic if something is a part, subpart or primitive applies to LSYNTH elements the same way as to normal files.
This especially becomes important when software needs to decide where to add gaps etc.
So my next suggestion is:

SUGGESTION 2: apply the usual part/subpart/primitive logic to LSYNTH files as for all other library files. Do not put them all in PARTS, just to let them show in MLCad. To solve the MLCad problem, many other solutions are possible, e.g.: put "helper" files into the PARTS folder which are shortcuts to the real places. These helper files should be a separate download, as they are a workaround for a specific tool (MLCad) and not part of our library. Maybe not even that is necessary, read on:

Some people have suggested to add a new category for syntesized parts.
Of course, we should not use "!CATEGORY LSynth", because that would be tool-specific.
Instead, something like "!CATEGORY Parts Synthesizing" comes to my mind.
However, I would like to doubt the necessity for such a category.
Reason: normally, tools like LSYNTH (and LSYNTH does) do contain specific lists of combinations of
start/sweep/end combinations, which you can conveniently select.
So there is not really a necessity to be able to browse the synthesized part elements.
So we get

SUGGESTION 3: Do not add a special category like "!CATEGORY Parts Synthesizing", as this seems not to be necessary.

The last question to answer is "origin and sizing etc".
There the answer is simple: I suggest that for sweeping primitives we use the same origin/placement/sizing policy as for our other primitives:
this means: origin on top, height 1. 4-4cyli is a good example. So for example, to generate a two-wire-cable, you would sweep 2 merged cylinders along some path. The sweeping primitive should have height 1, and should have its origin at its top.
The benefit of this suggestion is:
(a) the sweeping primitives have the same origin policy as the other primitives in our library
(b) LSYNTH directly will be able to use them without modification, as it follows that principle as well
So we get:

SUGGESTION 4: For sweeping primitives, put origin at top, and make them height 1.

The situation for non-sweeping primitives is different. Let's go away from the electric cable and instead to a chain
made of discrete elements of fixed length. My suggestion there is:
let's apply the usual origin placing logics there. The reason is simple: these elements are normally parts with a tilde ~ prefix,
and sit normally in the PARTS folder. LSYNTH needs anyway a configuration file which tells it how to assemble such elements.
It for example today has such for chain elements. So we get:

SUGGESTION 5: For non-sweeping synthesizing elements, apply the usual origin paradigms.

---

Summary of suggestions:

SUGGESTION 1: Let's have files for part synthesizing in our library.
SUGGESTION 2: Put them where they belong. I.e.: into the P, PARTS or PARTS\S folder, depending on what they are.
SUGGESTION 3: Do not create a dedicated category.
SUGGESTION 4: For sweeping primitives, put origin at top, and make them height 1. Sweeping will take place along Y axis.
SUGGESTION 5: For non-sweeping, i.e. discrete parts like chain elements etc. apply the usual origin and orientation paradigms as for normal parts.

[Willy Tschager]

Steffen Wrote:
> SUGGESTION 1: Let's have files for part
> synthesizing in our library.

No, keeping them apart gives us much more freedom to change something is needed. I don't wanna wait 2-3 year to see some modifications certified through the PT. Also because they are more likely to change - we are not talking about shapes like LEGO part which are set in stone (better, molded in plastic) but something more organic. Kind of the pneumatic hose end pieces I just changed back in June after seeing them at J.C. Tchang's site.

> SUGGESTION 2: Put them where they belong. I.e.:
> into the P, PARTS or PARTS\S folder, depending on
> what they are.

Reading my tutorial you'll see that they don't get mixed up in the Parts o P folder but end in <Ldrawdir>Unofficial\Lsynth

w.

[Steffen]

Thank you for your opinion, Willy,
I know your tutorial, and it has helped me very well in learning to use LSYNTH.

Maybe I can weaken my suggestion a little:

For many flexible parts, its constituent components are anyway available in our library:

Example 1: electric cable: http://www.ldraw.org/cgi-bin/ptdetail.cg...567c03.dat
The ends are plug parts plus cable end.
The flexible portion is made from sweeping x993.dat

Example 2: hose: http://www.ldraw.org/cgi-bin/ptdetail.cg...rts/75.dat
1 subpart for the end and beginning,
and the flexible portion made by sweeping s/75s01.dat

After some more thinking, I agree with you that the lsynth tool itself, or its helper / constraint files
are maybe a separate project, and need an independent release cycle.

However, the real goal of my suggestions above is just to
standardize about how these constituent elements are structured within our library.
And for that standardization, a way which would be directly usable by LSYNTH would be the optimal solution in my eyes;
that solution especially is nice because the positioning I suggested match the cyli primitives.

[Willy Tschager]

Steffen,

I'm always open to improvements. Just drop me a line (and CC: Don Heyse and J.C. Tchang) telling me what's needed to do to harmonize the constraints to the library.

w.

[Steffen]

that's a misunderstanding.

I was talking not about the LSYNTH elements, but of the elements within the LDRAW library.

There, the sweeping elements should follow the same principle.
That's my suggestion.

They currently do not. Example:

http://www.ldraw.org/cgi-bin/ptdetail.cg...124s02.dat
is perfectly fine IMHO: has origin at top (like cyli primitive), and vertical size 1.
so it can directly be used by LSYNTH

http://www.ldraw.org/cgi-bin/ptdetail.cg...s/x993.dat
is different. It has the origin not at top (unlike cyli primitive).
so it cannot be directly be used by LSYNTH, and is inconsistent with the above.


My sole goal of this thread is to achieve systematics within the LDRAW library
for these sweeping files.

As a side effect of my suggestion, the files will immediately be usable by LSYNTH,
and that's another benefit IMHO.

[Travis Cobbs]

Well, then any program that makes use of these types of parts needs to have a separate "synthesis parts" package that can be downloaded and installed standalone. I have bad memories of LSynth refusing to install on my computer; plus, it's ridiculous that users wanting to look at a file that contains these parts is forced to install the authoring tool.

[Don Heyse]

Wow, that looks like some harsh criticism. Am I reading it wrong?

Personally, I think the inflexible hard plastic chain bits should be official parts that someone with a great deal of time and patience could place by hand if they so desired. I'm ambivalent about the various rings and tubes used for the flexible parts. I don't think the lsynth part orientation matrix math is all that intuitive, so I'd like to be able to fix it someday without the worry of modifying a bunch of official parts. On the other hand, it is handy to use generic ring and tube subparts that are already installed and perhaps used in other part files.

I'm not sure how to create a flexible part solution that's not "ridiculous". Synthesized parts can create rather large files, so it's easier to distribute the pre-synthesized files. But nobody is forcing anyone to do that. Also, the synthesis code is available, fairly compact, and hasn't changed for 2 years. I could say it's ridiculous that LDView hasn't incorporated the code (or something similar) so users can look at the files without installing extra tools. But that'd be ridiculous...

Anyhow, are those bad memories old and hazy, or do you remember enough detail for a bug report? There's not much to the installer so I could probably do something to fix it. Or, maybe what you really want is a relaxing break from all that LDView programming. Perhaps you could take a turn updating a small abandonware project that hasn't been touched in 2 years or so?

Whatcha think?

[Travis Cobbs]

Don Heyse Wrote:
-------------------------------------------------------
> Wow, that looks like some harsh criticism. Am I
> reading it wrong?

I'm definitely not happy with the current state of LSynth synthesis parts. Just within the past few weeks a user (Willy, actually) reported a bug in LDView that related to where he had the synthesis parts, and while he sent me his model for testing, the fact that I didn't have the synthesis parts meant that I couldn't test with his model without first installing LSynth (which I have no need to have installed, since I'm not doing synthesis). As it turns out, I was able to track down the bug without needing the sample model, but since LDraw models are intended to be shareable, LSynth's lack of a "synthesis parts" package is unfortunate.

Having said all that, LSynth seems to do an awesome job of doing what it does. (Note: I say "seems to" here because I've never used it, not because I'm doubtful.) And things are most certainly better with it being available in its current form (no synthesis parts package) than if it didn't exist at all. But it doesn't seem like it would be that difficult to simply make the synthesis parts available in an official zip download for people who want to look at LSynth'd files without having to install LSynth.

[Travis Cobbs]

As far as I know, the LSynth installer was fixed. As for LDView supporting synthesis, nobody's ever asked for that, and it never really occurred to me to do it. It does indeed sound like a potentially useful idea. The main difficulty would be keeping things in sync, but if the synthesis code hasn't changed in two years, it sounds like that's not too big a deal. (Of course, LDView hasn't had a release in over a year and a half, so two years isn't perhaps so long.)

I apologize for the "ridiculous" statement.

[Don Heyse]

So I took a peek at the lsynth distribution site and you're right, there's no synthesis parts package there. I remember now that we decided it was best to have Willy host that on his site with the documentation, because he updates the parts far more often then the actual code. I suppose I should add a note on the lsynth site to look there for the Constraints_3-1.zip file if you just want the parts to view someone else's synthesized constructions. Or better yet, maybe I should add the current file and a note to visit the documentation for the most recent version.

[Willy Tschager]

And I should finally take all those files and pack them into an installer or link to the AIOI.

w.