Thoughts about flexible parts

[Roland Melkert]

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?

[Tim Gould]

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.

Tim

[Roland Melkert]

Thanks,

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).

[Steffen]

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.

[Steffen]

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 -

[Tim Gould]

That's all it can do 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.

Tim

[Roland Melkert]

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).

[Roland Melkert]

Ah and here I was thinking to just 'stop' drawing when the static length is reached, and let the user fiddle until it 'fits'

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.

[Steffen]

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
http://www.ldraw.org/cgi-bin/ptreviewsum...ctricplugs
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......

[Roland Melkert]

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.

[Orion Pobursky]

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'd like to interject that LDDP's flexible part generator (which is based on the LDraw Major Mode for EMACS) does fixed length hoses. My understanding of the math is fuzzy but from what I can gather it does a 2 control point bezier curve. It sets the control points out a bit from the end points and then moves them linearly out until the curve length is a close to the specified length as possible. Both LDDP (Delphi Object Pascal) and the LDraw Major Mode for EMACS (Lisp) are open source so you can have a look if you want. Here the code LDDP uses:
DATFlexObject.pas

[Roland Melkert]

My understanding of the math is fuzzy but from what I can gather it does a 2 control point bezier curve. It sets the control points out a bit from the end points and then moves them linearly out until the curve length is a close to the specified length as possible.

Seems like a reasonable effective method, but I would really like to let the user influence the 'shape' somewhat in order to avoid other parts etc. Maybe I could apply something similar to parts of the curve, I will certainly take a closer look at that unit.

Thanks.

[Tim Gould]

I'm away on holidays right now. Will get in touch when I get a chance.

Tim

[Chris Dee]

I agree that any synthesis should be generated with multiple references to files in the official library, rather than native LDraw syntax generated by the tool.

The status of those files has long been a thorny problem for the library administration. Really they are subparts, but I believe previous tools needed to be able to locate them in the Parts folder.

I think we can make a case for a new optional qualifer for the "0 !LDRAW_ORG Part optional_qualifier" line, which would allow tools to identify those files.

[Steffen]

Let me put my 0.02 EUR into this discussion:

(a)

> but I believe previous tools needed to be able to locate them in the Parts folder

No, they didn't. They would have searched the usual folders, thus would have found them as s\... when referencing
them that way, or even as primitives.
The only reason that these files previously got put into the Parts folder was that people
wanted them to show up in MLCad's tree.
My opinion always was against that because doing so was just a workaround for a shortcoming of MLCad's GUI.
The files *are* subparts IMHO.

(b)

I don't think we need another new header line or type.
Subpart is just fine for these files.

[Philippe Hurbain]

That's not really a shortcoming - there is no reason to have subparts appear in any editor. But flex element access is needed if you want to manually place them (eg. tread tracks elements). So I like to have them carry the part status, but with a special qualifier (or simply a common new category to group them together?)

[Roland Melkert]

I there a list of the (official) related subparts?

I would like to use official (sub) parts as much as possible, but I still think 'very' flexible stuff (like rubber hoses, string, bands) should be generated smoothly using type 2..5 lines.

[Steffen]

I still don't think so, here are my reasons:

(a)
Doing so would mean that you hard-code the geometry of those parts into your tool,
and this way the tool wouldn't be any longer independent from geometry changes in the library.

(b)
Using the "sweeping" technique doesn't bring bad images.
It's a common technique people use in e.g. POVRay scenes, known from the beginning of 3D rendering.
The key is 2 things:
- (i) Have the element that gets swept available at a standard orientation and position, extending from 0 to 1 vertically, so it can easily be scaled etc. - just like the 4-4cyli
- (ii) Choose a good interval by which to sweep that thing. The interval will determine how to scale it, and how many copies to use. This interval can be chosen from "very rough" to "very smooth" and this way can easily be influenced by your tool. You can achieve very smooth images using this technique.

[Roland Melkert]

Doing so would mean that you hard-code the geometry of those parts into your tool,
and this way the tool wouldn't be any longer independent from geometry changes in the library.

I don't see why that's a problem, with the backwards compatibility going on at the moment I don't see e.g. type 3 lines change any time soon. Also if it would to change many other parts of the tool will need updates anyway.

Or do you somehow think those parts will only be visible in LDCad? If so that's not my goal, I plan to generate separate LDraw files containing the mesh, so any LDraw tool will display it just fine.

Using the "sweeping" technique doesn't bring bad images.
It's a common technique people use in e.g. POVRay scenes, known from the beginning of 3D rendering.

In povray objects are 'merged' and so it wont matter, but in LDraw it will cause visual gaps at close inspection. This always bothered me while using LSynth so I will try to prevent that in my own editor.

But don't worry I will support the sweeping method in such away you could choose not to use the hard coded versions if you really want to.

[Travis Cobbs]

I can sympathise with both sides of the argument, but I have a counter-proposal. What Roland wants to do is standard 3D graphics behavior, which is extruding a flat shape along a path. It seems to me that the best solution is to have the end cap stored into a separate sub-part, and he can use that to produce the extruded shape. Then all the polygons along the "side" of the tube would be generated directly, but the end cap itself would be a sub-part. That way, if the geometry of the end cap changes, his program would automatically get the change. This only works for shapes that have flat ends, but since he's talking about doing this for pneumatic tubes and flex tubes, those both have flat ends. It has the additional advantage that it would work for arbitrarily complex shapes, as long as they are smooth in the extruded direction. (So it obviously wouldn't work for chains, treads, etc.)

[Chris Dee]

Thanks Travis, for another viewpoint.

I do agree that it is essential that the end-caps are part of the library. Currently we provide the mid-sections as 3D components, probably because the first to be modelled had some repeating structure (ribbed hoses, treads). In these cases, the generation of a flexed version is not a pure extrusion action and some deformation (or overlap) of the repeating sections is needed.

For the smooth flexible parts (pneumatic tubes, flex tubes, flex cables, fibre-optic cables, electric cables, string?) the flexed version really is a 3D extrusion of a 2D object. If we provided that 2D object as an LDraw file it would avoid the need for a tool to infer that information from the end caps, or hard code it internally. In reality for circular parts that would just be a 4-4edge definition, but by making it part of the library it allows us to tweak the dimensions of the end-caps AND the extrudable section in synchrony, if we make a dimensional mistake or need greater precision in the future. The tool would only need to store (probably in a tool.ini file) the filenames of the end-caps and their matching 2D extrudable part, although I would also favour that being part of the LDraw deliverables (in the way that the minifig generator metadata in MLCad.ini probably should be).

Chains are a special case, and probably deserve a different solution because they are not really flexible but a combination of rigid parts following a path.

[Travis Cobbs]

Just to clarify, any app using the geometry inside a flat endcap file would have to pay attention to the triangles and quads in order to generate a BFC-compliant extrusion. If it paid attention purely to the edge lines, this wouldn't be possible. It could use the edge lines, then look for an adjoining triangle/quad for each one to determine the proper winding.

[Roland Melkert]

Thanks Travis and Chris,

This is a very interesting (and universal) approach, I could setup a special mpd for the flat shapes and additional information so it's completely extendable/customizable. And if the shapes ever become part of the library it will act like a fallback.

All this makes me want to go directly to the generating part of coding, but I have to make some changes to the internals of LDCad to allow for general path editing first.

I was thinking of using 'segments' in means of you place an additional point and assign a type to it e.g.: 'circle arc' (to go around a poly etc), 'free arc', 'straight line', 'bezier curve' or 'pass through' (LSynth like markers) . You could off-course change the type afterwards or split a segment into two etc. Finally the first and last point (in meta wise) then automatically become the end caps.

Any thoughts on that?

[Steffen]

wow, maybe we can merge both approaches.

we agree on that the ends should be subparts, present in the library.

when doing the sweeping technique advocated by me, a "middle" segment of unit length in Y dimension
extending from 0 to 1 would be sweeped along some path.
For example, for a hollow pneumatic hose, this would be two 2-4cyli's.

When the "smooth" method should be applied, those VERY files could be used to infer
the geometry. the only thing that needs to be done is scaling them to zero height (Y).
What you then have is the flat geometry which needs to be smoothly traversed through a certain path.
WOW! ME LIKEY!

[Roland Melkert]

I like thiis idea, but it will only work if the shape uses the same xz coordinates for vertices along the y axis, otherwise it will result in an increase of points in it's flattened state.

Although I'm also thinking about a way to use non flat 'donor' shapes in order to account for things like rope (where the edge lines rotate around the 'tube'). The resulting algorithm should then be able to handle repeat patterns based upon the donor shape. Might keep that for the next next version though

[Don Heyse]

The standard lsynth rope (string) is a bit of a hack so I wouldn't necessarily try to duplicate it for your extrusion method. A better looking rope can be made by starting with 3 co-planar touching circles, and extruding with a twist. Go here and check out the "cordage torsade" picture in section 12a.

http://jc-tchang.philohome.com/manuel/Lsynth3.htm

Say, would it be possible to re-use any of the lsynth meta commands to make it easier for certain lazy programmers to duplicate the extrusion functionality in a standalone tool, by enhancing the existing lsynth code?

[Roland Melkert]

The standard lsynth rope (string) is a bit of a hack so I wouldn't necessarily try to duplicate it for your extrusion method. A better looking rope can be made by starting with 3 co-planar touching circles, and extruding with a twist. Go here and check out the "cordage torsade" picture in section 12a.

http://jc-tchang.philohome.com/manuel/Lsynth3.htm

If I get patterned donor shapes working, such a shape should be possible, could take awhile though. I have to get basic path editing and normal LSynth like 'sweeping' going first.

Say, would it be possible to re-use any of the lsynth meta commands to make it easier for certain lazy programmers to duplicate the extrusion functionality in a standalone tool, by enhancing the existing lsynth code?

I'll will try to support those metas were possible or at least offer an import and or export setup at some point. Biggest difference being my approach will be submodel based, and LSynth meta's are weaved in the model it self.

[Don Heyse]

Actually, I've always thought it makes sense to put the lsynth bits in submodels because then you can distribute a separate file (or files) of the submodels with the final synthesis bits already done up for people who don't want to bother running lsynth.

I wonder, do people make "library" mpd files with many handy subfiles, but nothing in the main file?

[Sergio Reano]

Hi Roland,
due to my little experience in programming bezier curves (as you can see in SR3DBuilder), here is my approach:
- define start point, ending point, tensors and parameters
- compute the curve as a series of points at a convenient distance depending on the curve type segment
- compute the matrices for orienting each curve segment in the convenient direction
- perform some kind of function(s) that close gaps among curve segments along the curve

You should not need any start point/end point marker since a flex is most usually connected to an existing model part connection you can use as starting point. If you implements connections, also the curve tensors will be automatically defined by the connection itself.
If you decide that you flex part is not displayed during placement/definition in your model, then you can easily define some addictional points to define a path the curve MUST follow.
I cannot help in the metacommand directions since I've used my own sintax to store FlexParts definition in my model files.

Maybe this can help you someways...
Good work !!

Sergio

[Roland Melkert]

Thanks for the insight.

I do plan to add snapping and kinetics add some point but I tend to think I'm writing my editor for a different kind of user group than your SR3D so it will always remain optional. So I will be needing manual start and end points, but other from that your approach sound similar to what I have in mind at the moment (working with different kinds of segments, see also above posts).