LDraw.org Discussion Forums

Full Version: Thoughts about flexible parts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Hi all,

With LDCad 1.1 in the beta stage, I'm starting to gather information/ideas for flexible part support (pneumatic hoses etc) in 1.2. I'm mainly thinking about using bezier curves for editing, the generated parts them selves will probably be submodels using official library subparts were available and generated type 2..5 lines for the rest.

I myself have very little experience with LSynth and the likes so if anyone has some different suggestions/ideas?
Hi Roland,

My biggest suggestion would be to make it modular (eg. details go in, vector of positions and matrices comes out). That way you can always add new ways to do it.

I still have plans to use my theoretical work on rod theory to make a better hose generator. But it's not going to happen quickly. Sadly I seem to have lost my demo.


I was planning on creating a general way of placing/manipulating the path (which code wise doesn't know anything about LDraw lines etc). And when all is ok on that end make a collection of specialized classes whom generate the actual part. So in the end I only have to add such a class for new type's of parts. It could even account for a 'general' custom a b b b b b c references kind of part like LSynth use.

Did your demo support static length curves (e.g. length 8 flexible axle)?, because that's something I have no clue on how to implement (auto fit wise).
I best like the idea of publishing all necessary files (end1 / middle / end2) officially as part of the library,
together with a "straight" version of such parts.
The bent ones then can get created by sweeping, like LSYNTH does.
I definetely suggest to get your fingers wet with LSYNTH, it looks much more complicated from outside
than it really is.
BTW, LSYNTH does it similar: it also defines the path, but not by a specific formula,
but instead just by the sequence of 3D points through which the sweeping must pass.
Then, later, _different_ formulae can be used to run the path through these points.
For example, a different algorithm is needed to make a chain link sequence move through them
than a rubber band or a cable. The formula can later be exchanged, which is nice.
And it depends on the material being swept. So both can be changed later,
while maintaining the order of 3D points to pass through. A Very Nice Thing ™ - IMHO.

LSYNTH uses some private meta statements for itself.
Maybe your solution could re-use those and only add such which are special for you.
I'd like to suggest to not reinvent the wheel...

- just my 0.02 EUR -
That's all it can do Smile It's a theory of fixed length rods. So you specify the ends and angles at the ends and the length and it does the rest. I can even do kinks in principle.

You can see some examples in the original paper (http://iopscience.iop.org/1367-2630/8/8/137) but I also did a demo version on a raytraced train.

I'd have to write a C++ version of it, but it's something I've always wanted to try anyway. However it does rely on having free time which is something distinctly lacking in my life. That's why I was hoping you'd make a modular interface so I could test elsewhere and slot it in when I get a chance.

I will be using parts in the library as much as possible, but not all needed things are available in a useable way in the current library, So I'm planning on generating that what's not available (like hose skin) by placing a bunch of type 2, 3 and 5 lines in a submodel, which will be regenerated (in realtime) whenever you change the path control information.

With chains no meshes need to be generated, but still the type 1 lines are placed in a submodel and are regenerated whenever something changes.

I'm not sure if I could use the LSynth meta's though, but I like your suggestion so I will be keeping that in mind (or at least as a import method).
Ah and here I was thinking to just 'stop' drawing when the static length is reached, and let the user fiddle until it 'fits' Smile

I don't know if the setup I currently have in mind will give you a way to test your work efficiently (unless I add scripting). My current plan is:

Create a submodel with some specialized header meta's (e.g. 0 !LDCAD GENERATED PART).
Add a bunch of additional meta's describing the general path.
Then in a/the model referencing this special submodel, you can manipulate the path of the part using the mouse etc much like normal placement of parts.
When ever the path changes LDraw content for the special submodel will be regenerated.

If you have any ideas on how to improve this so it might help your intentions better, let me know.
The hose skin then definetely should be made available as a subpart, placed at the usual default LSYNTH
position (which matches the positioning and scaling of our 4-4 cyli primitive) and which should be also
perfectly useful for your purpose. The advantage of doing so is that BOTH tools will be able to use that file,
and that that position is mathematically ideal because it has the hose skin primitive extend from 0 to 1
and this way it can reliably scaled and positioned easily.
"Generating on the fly, interactively" sounds just *great*, this is something I had always missed from LSYNTH.
However, you can still do, by simply sweeping that "hose skin primitive" over the intended path at an interval
you can define freely (as opposed to *synthesizing* those surfaces on the fly).
The advantage of doing so will be that your algorithm will work for ALL kinds
of "sweepable" things like hoses, cables, etc.pp, just anything WITHOUT hardcoding their properties
into your software. The only things you will have to know are:
(a) where's the start (---> can easily be stored by using the existing LSYNTH syntax for a "begin" constraint, it is not LSYNTH-specific!)
(b) where's the end (dito)
© while going from (a) to (b), through which points should the sweep pass (dito)
important is:
(d) for the sweeping, use a LDRAW file which has standard 4-4cyli placement

Ensuring point (d) will make all your stuff compatible with LSYNTH, which FORTUNATELY adheres to the
standard primitives placement.

I'd like to humbly suggest you have a look at
where all the cables are modeled in this form.
I'd very much like to be able to sweep the existing cable primitive along its path
(maybe even interactively, how cool's that!?) using your tool......
Steffen Wrote:The hose skin then definetely should be made available as a subpart

Maybe but I'm planning to smoothly generate hose skin, e.g. no seams because of 'sweeping' like you call it.

I will also support the sweep method but it will more be for chains and such, and as a fallback if no 'native' version is available (yet) for other stuff.

I will take another good look at the LSynth meta's to see if I could use them instead/along side new meta's, thanks for the insight.
Pages: 1 2 3