Orientation of flex parts

[Roland Melkert]

Hi all, I'm making good progress implementing flexible parts in my LDCad



But now I'm wondering if I chose the right default orientation (namely positive z direction). I did notice most donor shapes (e.g. 166.dat) use y, but I felt that was 'weird' when I started out, but now I'm wondering if z is really all that great.

So my question to the part modeling experts is what are the considerations for choosing an (internal) base orientation for (flexible) parts.

Also what's a logical part center to use as a default (starting point, center of arc, etc) ?

Any thoughts / pointers would be appreciated.

[Steffen]

I think that the only possible "natural" orientation and placement should be taken from the existing
4-4cyli primitive.
This means:
- the Y axis is the "sweeping" axis, along which the primitive will be "swept" along the desired path
- the swept thing should have its top at Y==0
- if possible, analogously the bottom should be at Y==1
- the same should be used for non-swept (static) START and END files

This exact standard placement and usage is also what LSYNTH uses,
to which a maximum compatibility should be tried to achieved IMHO.


PS I'm used to the term "sweeping" here because in my wild youth I took over this term from
the POVRay documentation, e.g. at http://www.povray.org/documentation/view/3.6.1/63/

[Tim Gould]

I think that the only possible "natural" orientation and placement should be taken from the existing
4-4cyli primitive.
This means:
- the Y axis is the "sweeping" axis, along which the primitive will be "swept" along the desired path
- the swept thing should have its top at Y==0
- if possible, analogously the bottom should be at Y==1
- the same should be used for non-swept (static) START and END files

This exact standard placement and usage is also what LSYNTH uses,
to which a maximum compatibility should be tried to achieved IMHO.

I agree with Steffen about this, y is a better axis to use for another reason: it matches with the existing straight flex parts

On which topic that is some splendid output

PS I'm used to the term "sweeping" here because in my wild youth I took over this term from
the POVRay documentation, e.g. at http://www.povray.org/documentation/view/3.6.1/63/

Seems a better name than most Sadly I can't remember the technical name for it from when I was working on slender rod theory.

[Roland Melkert]

This means:
- the Y axis is the "sweeping" axis, along which the primitive will be "swept" along the desired path
- the swept thing should have its top at Y==0
- if possible, analogously the bottom should be at Y==1
- the same should be used for non-swept (static) START and END files

This exact standard placement and usage is also what LSYNTH uses,
to which a maximum compatibility should be tried to achieved IMHO.

I still find the y-axis kinda weird, because most flexparts will be used horizontal, I ended up using Z (instead of x) thinking it would make for easier to understand math. But during (manual) defining the needed meta's for the parts in the preview picture above, I started thinking (rotating to x (front view) most of the time) z isn't that user friendly ether.

As for the used donor shapes and LSynth compatibility, That shouldn't be a big problem, cause I will add an LSynth import at some point and the donor shapes can be used with additional corrections. For example the loop part from the preview is generated from the following code:

Code:

0 Pneumatic tube test
0 !AUTHOR LDCad
0 !CATEGORY flexable

0 !LDCAD DOCINFO [contentType=flexPart]

0 !LDCAD PATH_CAP [position=start] [part=165.dat] [posOri=0 0 0 1 0 0 0 0 1 0 -1 0] [ color=14]
0 !LDCAD PATH_CAP [position=end] [part=165.dat] [posOri=0 0 0 1 0 0 0 0 -1 0 1 0] [ color=15]

0 !LDCAD PATH_SKIN [type=deform] [part=166.dat] [ori=1 0 0 0 0 -1 0 1 0] [ color=16]

0 !LDCAD PATH_POINT [type=basic] [posOri=10 0 -110 1 0 0 0 1 0 0 0 1] [nextCPDist=50]
0 !LDCAD PATH_POINT [type=basic] [posOri=10 0 0 1 0 0 0 1 0 0 0 1] [prevCPDist=50] [nextCPDist=50]
0 !LDCAD PATH_POINT [type=basic] [posOri=0 -96 0 -1 0 0 0 1 0 0 0 -1] [prevCPDist=50] [nextCPDist=50]
0 !LDCAD PATH_POINT [type=basic] [posOri=-10 0 0 1 0 0 0 1 0 0 0 1] [prevCPDist=50] [nextCPDist=50]
0 !LDCAD PATH_POINT [type=basic] [posOri=-10 0 80 1 0 0 0 1 0 0 0 1] [prevCPDist=50]

Normal users don't have to worry about those meta's, the final LDCad version will let them manipulate existing starting situations loaded from a template library.

So if you consider all this is it still preferable to use the Y-axis over e.g. X-axis? Because like I mentioned when do one ever need a tube or something pointing up.

PS I'm used to the term "sweeping" here because in my wild youth I took over this term from
the POVRay documentation, e.g. at http://www.povray.org/documentation/view/3.6.1/63/

I'm not sure what's the official name for it, but I like to think about them like curved space where the center of the tube or whatever you using is actually (from the tube's perspective) a straight line. So the main question of the thread is where do you place the starting point of the line (and it's orientation) in the host document (part file) modelspace.

edit: seems the board doesn't like the '[ color=' strings without the space after '['. Shouldn't bb code be disabled inside a code block ?

[Roland Melkert]

On which topic that is some splendid output

Thanks, you should have seen some of the mutations from my early tests

Might be over doing it though, some of these example parts would generate over 50,000 LDraw lines when saved to mpd. But there is still some optimizing to do.

[Steffen]

Please do definetely consider to switch to my Y suggestion.
The reasons for doing so is that
- (fortunately) ALL sweeping parts use that this way
- all currently unofficial parts on the PT use it this way (for example the electric cables http://www.ldraw.org/cgi-bin/ptreviewsum...ctricplugs )
- our primitives do it this way
- LSYNTH does it this way

As any orientation and placement is equally "right" or "wrong" ("why should Y be better than X? Or Z?"),
the killing argument here is that literally ALL other parts and primitives use it this way.
Introducing a new concept here would be an unnecessary confusion, and to my opinion a Wrong Thing ™ to do.

Additionally, it should be trivial for your implementation to adjust to that principle.


ah, and yes, the preview picture already was promising!

[Travis Cobbs]

In addition to what everybody else has said, remember that "up" in the LDraw coordinate system is -Y, while "up" in traditional 3D is +Z. That's (presumably) why the existing ones use Y instead of Z.

[Roland Melkert]

the killing argument here is that literally ALL other parts and primitives use it this way.

Ok, that's a big argument indeed, I'll change the internal orientation to the y-axis to make creating of templates more natural to the more advanced LDraw users.

But I still find the whole y thing weird, mostly because of the way it looks in part bins using look at some of the current official assembled flex parts etc when compared to e.g. technic (flexable) axles.

I'll probably end up making multiple templates for the same shaped parts, so users don't have to rotate so much upon placement.

[Tim Gould]

To add a little more perspective,

Flex is often used as a substitute for bars, so it makes sense to orient them the same way as bars. Most modern System sets do not remotely use it as flex, just a way of getting bars of arbitrary length.

You could always reorient them in the part bin (eg. so they go across the diagonal). That might be nice for other parts too. Take a leaf out of LPub's book and have an excpetions list for parts that need to be rotated differently.

[Michael Heidemann]

Are looking for the name lathe?
http://en.wikipedia.org/wiki/Lathe_%28graphics%29

[Tim Gould]

No. I was looking for the name of the variable that governs the local 6D position and orientation space And I still don't remember it.

[Roland Melkert]

Thanks for the bin idea, I will definitely consider that.

I could also correct for the ori in the host document (all generated parts will be separate .dat files anyway). The main goal of this thread was figuring out what the expert think about the internal orientation, so neg y it is

Downside of this little experiment is I discovered a small problem with my current code while switching things around and using a more curvy path.



There's a (to me annoying) unintended twist/roll in the path of the curve caused by the way I calculate the individual segment orientations.

Have to solve that at some point, but I'm going to concentrate on the real-time editing part of it all for now.

Thanks for feedback everybody.

[Steffen]

Yes. And after some more thinking, coming back here:
Would you choose ANYthing different here than the rest, then FOREVER a mapping of the two principles would be necessary
to keep, maintain, document, correct and explain. On the other hand: would you not, then simply NOTHING
needs to be done, everything can be interchanged 1:1 without mapping. The simplicity of this just struck me even stronger
today (sorry to annoy by repeating this argument).

Reading the posts above, I would like to also agree that you could always apply some
"better suitable default perspective" for certain sets of parts. For example, the parts tracker shows all 1x4x4 panels
rotated by 180 degrees to better display their usually patterned side, which otherwise wouldn't be visible.
As long as "something" in the file header "classifies" the part as "one of your magic sweepable ones",
you can apply whatever "better" default view you like in the tooling.

Just a last, 3rd thing: to me, these constituent files which get "swept" along some path, to me are PRIMITIVES
or SUBPARTS. A recent habit has established to treat them as PARTS, just because in that role MLCad will display them
in its "parts" tree. I always found that practice not a Good Idea ™, because it put wrong information into a file,
just because of a shortcoming of a tool. I had posted some thoughts on this in an earlier
thread.

[Philippe Hurbain]

There's a (to me annoying) unintended twist/roll in the path of the curve caused by the way I calculate the individual segment orientations.

Indeed, this kind of thing could be even more annoying for "flat" flex parts (electrical cables)!

[Tim Gould]

When you feel like dealing with this issue please get in contact with me directly. I can probably solve the problem for you.

Tim

[Roland Melkert]

Thanks, although I do like a challenge myself

But if I get stuck I will certainly take you up on your offer.

[Tim Gould]

I understand. I used to model flexible rods for a job

Tim

[Roland Melkert]

I think I've fixed the problem.



Some weird (very constricted) bends could still mess things up, but this seems to work just fine when used in a practical / real-life manner.

[Philippe Hurbain]

Very nice! Though realistically such flat cables would not bend in wide direction, they would rather twist and bend on thin side. But I guess that it's a matter of orienting properly constraints?

[Roland Melkert]

Very nice! Though realistically such flat cables would not bend in wide direction, they would rather twist and bend on thin side. But I guess that it's a matter of orienting properly constraints?

The current version compensates for the 'roll' difference between the first and last point (zero in the preview above), but the final version will take all control points roll orientation into account (the preview above has 8 including the connectors). I'm also thinking to let the user control additional roll by letting them place additional 'roll' constrictors anywhere along the path of the curve.

But for now I kinda left the roll part of points / constrictors out of the picture so testing the base generating code is more manageable. I will try to account for all daily modelling usages in the final version (or at least all the stuff I need in my models