Inclusion of LSYNTH parts in the official LDRAW library
2011-07-31, 0:05 (This post was last modified: 2011-08-24, 2:15 by Willy Tschager.)
2011-07-31, 0:05 (This post was last modified: 2011-08-24, 2:15 by Willy Tschager.)
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.
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.