LDraw.org Discussion Forums

Full Version: Orientation of flex parts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi all, I'm making good progress implementing flexible parts in my LDCad

[Image: flexPreview.png]

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.
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/
Steffen Wrote: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 Smile

Steffen Wrote: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 Smile Sadly I can't remember the technical name for it from when I was working on slender rod theory.
Steffen Wrote: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.


Steffen Wrote: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 ?
Tim Gould Wrote:On which topic that is some splendid output Smile

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

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.
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!
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.
Steffen Wrote: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.
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.
Pages: 1 2