Thoughts on flexible part options

[Roland Melkert]

I'm still working on the flexable parts functionality, I'm currently trying to roundup / implement all needed options for a bendable part.

Thing is I might be overdoing it somewhat, so I was wondering what the experienced LSynth and or part authors might think.

Current meta/option processing allows for something like this:



This 'path' has two sets of options (one of which is displayed in the dialog) that describe how the segments must be placed etc.

The thing I might be obsessing over is the fact the chain links still don't bend 'naturally' in my opinion (because they are actually double jointed in real life), but I might be overdoing it quality wise

Anyone think there need to be additional options to solve this (e.g. possibility to include prev/next segment for cur segment placement in order to account for the double joint etc).

I think the current options are quite understandable, but I'm happy to explain them more if needed.

Just looking for some fresh perspectives

edit: some more examples:

[Jason Smith]

The hardest part of Lsynth was getting it running, I think it's methods were sound though. I liked the ability to use the... I forget what they're called but the guides or pin like things, tust place, point and twist them if necessary and make your part.

What you have so far looks excellent. I guess if you wanted you could get obsessed about the double joint thing but really how often do we use chain link and if we do it's usually not in the fore front of the model, they just make up details so to speak.

The important ones are the chain drive links that wrap around gears but your pic looks great.

How does one with your method actually manipulate the part?

[Philippe Hurbain]

I missed that post... The result is great - even the chain!!! As Jason, I'd like to see the process of flex part creation/usage in model.

[Roland Melkert]

Thanks Jason and Philippe,

The above screenshots are from standalone (sub/mpd) model files you use to define the actual path and overall appearance (end caps, length restrains etc). These (normal ldr) files can also be placed in a special folder which makes them templates.

When you drop a part from such folder (using the bin like all other parts) in your model a new submodel (or standalone ldr) will be created and the contents of the template will be copied into it. You can then use this as a starting situation from inside your main model by 'molding' it to its final shape and location.

So most people never need to configure the dialogs shown in the previews, that's template work which I will do for most common flexible parts in front. Users need only to place the pin like points / and end caps in order to bend the path, this is more or less the same as with LSynth, except the result will be visible directly after any change (and you are forced to use a submodel). All editing will be pretty much the same as working with normal parts. Except the segment between two path points will be a bezier curve with two control points (the red and green spheres).

In the next next version I will also make closed paths possible for use with rubberbands etc, those will need different segment types besides bezier (whom then also will be usable for non closed paths).

I hope this is somewhat like you expect / want for working with flexable parts, if not any thoughts are welcome. I could still make some changes at this point cause the gui part of the 'molding' process from inside a higher model isn't ready yet. I've got the whole template editing / generating part pretty much done though.

[Philippe Hurbain]

I hope this is somewhat like you expect / want for working with flexable parts, if not any thoughts are welcome. I could still make some changes at this point cause the gui part of the 'molding' process from inside a higher model isn't ready yet. I've got the whole template editing / generating part pretty much done though.

It's a bit difficult to be sure without actually trying, but from your description it seems very usable and convenient. And the results are great... BTW, what about file size/number of polys?

[Roland Melkert]

BTW, what about file size/number of polys?

That depends on the type option in the placement panel, for static/dynamic references it's just a bunch of type 1 lines (one per e.g. chain link). But when you use the 'deform' type every vertex of the (flattened) donor part will be transformed using a different matrix and thus the resulting part will 'explode' into type 2..5 lines for each reference of the part.

If size is an issue you could always use the normal references type although personally I think those should only be used for things that are loose parts in real life too (chain links). Pneumatic tubes etc should always be deformed imho, but the option remains.

[Steffen]

I find this highly interesting

[Ignacio Fernandez Galvan]

I'm looking forward to using this feature.

Would it be much harder to make it possible to add middle points to the bezier spline? And have you solved the problem with absolute position (see http://forums.ldraw.org/showthread.php?tid=7507)?

[Roland Melkert]

Would it be much harder to make it possible to add middle points to the bezier spline?

Do you mean higher order bezier curves? I don't think that's necessary (although my bezier class supports it) if you need more curvyness just add path points like so:

And have you solved the problem with absolute position (see http://forums.ldraw.org/showthread.php?tid=7507)?

I'm using double precision (c++ double type) for all internal vector/matrix calculations while generating it's only reduced to float when the end product goes to OpenGL.

I'm still working on the LDraw line generation part (hoping to finish that this weekend), those will be rounded to 4 or 5 digits (based on the GL mesh / ref matrix data) depending on the results.

[Roland Melkert]

Ok, I've finished the raw LDraw lines generation so all 1.0 standard supporting software should render the flexible parts created with LDCad.

It's not completely done yet though, it needs some more fancy auto formatting and comments. I also need to include credits about the donor file authors (anyone has suggestions on how to do this properly (steerCo?))

Attached to this message are the .ldr files resulting from the above preview.

One uses the 'static references' and the other 'deform' method for generating the part, filesize for the deform one seems big but I think it's worth it. also this part is very bendy, normal parts would contain more straight lines I think (allowing for segment merging).

If any one has comments or ideas on how to reduce the file size or thinks I'm missing something important while generating these parts please let me know.

edit: minor bugfix, the deform version was only using a single decimal.

[Travis Cobbs]

Edge lines and conditional edge lines are supposed to be color 24, not color 16. Also, while it's hard to be completely sure, it appears that you don't have conditional edge lines between the segments, just around the segment curve itself.

[Travis Cobbs]

It's very cool to see the segments perfectly joined at their ends as they go around curves in multiple axes. I think the extra time you spent to support true extrusion pays off.

[Philippe Hurbain]

This is indeed great! Random thoughts, issues and suggestions...
- As mentionned by Travis, condlines are missing between sections, and also between adjacent triangles of the same facet.
- You could transform "flat enough" pair of triangles into quads. On your file, this reduces size by 25-30%.
- Keeping numbers of decimals low (say 2 digits) reduces file size and is really not a problem.
- Color of lines/condlines is indeed wrong, should be color 24 instead of color 16
- You have condlines overlapping edge lines in the groove between wires. This makes smooth shading go wrong there.

Attached files
- with colors corrected and precision reduction to 2dp
- With regeneretion of condlines using Edger2
- With triangle to quad conversion using rectifier.
Have a close look on them using LDView, you'll see the quality improvement at each step.

As for the references versions, it would look much better if scaling was done so that there is no gap on outer side of curvature. This will of course increase overlap on inner edge, but overlap is generally not visible. This doesn't solve problem where there is twisting, but it would look a lot better nonetheless. The drawback is that you have to account for width and thickness of donor...

[Roland Melkert]

Thanks for the feedback Travis and Philippe

I'm not sure I understand what's going on with the edges, if the donor file (u9190.dat) has those lines you are talking about, the resulting part should have them (for every segment) too. Because I'm not 'inventing' any actual LDraw content I'm only transforming existing vertices of the (flattened) donor. Could you give me a pointer on which LDraw line(s) from the donor part disappear / got mangled, I''m not that skilled with the part author tools

I think I'm going to add triangle to quad support, I was also thinking about calculating alternative control points (with less fraction but in same line?) for conditional lines (could save up to 30 bytes per type 5 line).

The color 24 seems to be the indirect result of me using col 16 internally for all 'use parent' operations (so I don't have to check two integers everywhere). I will fix that for these outputs.

The ref version could probably be tweaked somewhat by playing with the skin props dialog parameters (see top preview pics), I might add an additional parameter for 'overlap scaling' or something, I'll have to look into that.