[LDCad] Make 572c01 flexible

[Jaco van der Molen]

Hi all,

I have a model that has the part 572c01 in it.

LEGO part 14210: String with End Studs and Minifig Grips 21L
Bricklink Item No: 63141
String with End Studs 21L overall with Climbing Grips (16.1cm)
Alternate Item No: 76065, 14210

Is there a template for LDCad for this yet?
If not, can someone make it or tell me how to do that.

In the end, I need this part to go to Stud.io too to make render of the model.
Thanks!

[Philippe Hurbain]

If not, can someone make it or tell me how to do that.

Here it is...
  stringStudsBarsLQ.ldr (Size: 3.7 KB / Downloads: 22)

In the end, I need this part to go to Stud.io too to make render of the model.

That's where there's a problem. For some unknown reason, bar segment renders badly (some stupid scaling...). Found no way to get round
Problem solved, see below

[Jaco van der Molen]

Here it is...
That's where there's a problem. For some unknown reason, bar segment renders badly (some stupid scaling...). Found no way to get round

Great! Thanks so much.
For now the gaps for the render will have to do. I'll Photoshop if I have to.
I will follow your tutorial to export the generated string to Stud.io!

[N. W. Perry]

Here it is...
That's where there's a problem. For some unknown reason, bar segment renders badly (some stupid scaling...). Found no way to get round

Custom version of the 572c donor part, perhaps? That is, assuming you could figure out what Studio is doing weird with the scaling and adjust it in the file. I just have to wonder if there's something broken in Studio with respect to circular prims, since they're also rendering incorrectly in static parts, since earlier this year.

Other than that, I see have a little more to learn about how LDCad uses groups in path parts. :-)

[Philippe Hurbain]

Custom version of the 572c donor part, perhaps?

I supposed that, but couldn't find anything wrong, except that file type was wrongly set to shortcut. I corrected, and updated the part in standard Studio library (two times, in official AND unofficial parts!). Nothing changed

Other than that, I see have a little more to learn about how LDCad uses groups in path parts. :-)

Yes, that's something Roland explained to me recently. Very useful here...

[N. W. Perry]

I supposed that, but couldn't find anything wrong, except that file type was wrongly set to shortcut. I corrected, and updated the part in standard Studio library (two times, in official AND unofficial parts!). Nothing changed

Yeah, my thought was just to artificially adjust the scaling factor on the cylinder primitive, to offset whatever Studio is doing wrong. Even just by raw trial-and-error. But that's cumbersome as you have to keep re-launching Studio to refresh the custom parts.

Yes, that's something Roland explained to me recently. Very useful here...

I'm essentially aware of auto-grouping for the start and end caps, but as I recall it's not fully explained in the documentation. Anyway, that's a whole separate topic! :-)

[Philippe Hurbain]

So... I got the bugS!
First one was mine, I let the option "inline donor references", so the cylinder got inlined, and that scaled cylinder triggered Studio render bug that scales fake seam gap by the same amount...

As for snapping on cylinders, with current LDCad version you have to manually inline flex part (and loose LDCad editability). Loosely related to https://forums.ldraw.org/thread-23840-po...l#pid36311

Template corrected in my first post!

[Jaco van der Molen]

So... I got the bugS!
First one was mine, I let the option "inline donor references", so the cylinder got inlined, and that scaled cylinder triggered Studio render bug that scales fake seam gap by the same amount...

As for snapping on cylinders, with current LDCad version you have to manually inline flex part (and loose LDCad editability). Loosely related to https://forums.ldraw.org/thread-23840-po...l#pid36311

Template corrected in my first post!

Great! Thanks again.
One thing though: the color of the donor part 572e should be 16 too, not 0 black. This string comes in 4 colors.
Black, brown, green and white. I am using a white one now and the string pieces are hardcoded black.

Thanks for pointing out how to do snapping.
I will model my string accordingly and when it is good, I'll make a copy and inline that one.
So, if I have to modify a bit, I can easily take the original flex part in my model ;-)

[Magnus Forsberg]

I want to renumber these parts.

   

572d and 572e have recently been deemed obsolete and are now deleted.

Should the base parts have the -f1 suffix, or not?
Can I go ahead, or do anyone see a problem with this?
The LDCad template need to be updated too.

[Orion Pobursky]

Go ahead and do whatever makes sense.

[Magnus Forsberg]

Go ahead and do whatever makes sense.

To me it make sense to replace the code of 572b with the shorter string segment found in 572e. 
That one is better suited and made for easy use in LSynth.

   

Or do I need to make 572b obsolete, and then place the content of 572e in my new flex_section file?

[Magnus Forsberg]

Or do I need to make 572b obsolete, and then place the content of 572e in my new flex_section file?

Help me think here.

I think we should obsolete the old files 572a, 572b and 572c. They have been official and can't be changed, and 572b is not good to use in the template.
So, should I obsolete all three, or only b?  The other 2 could be Move to-files.

572c01 and c02 could be Moved to-files, to the new partnumbers.

[Orion Pobursky]

I'd go bold. Just obsolete. If we decided otherwise later it can change before we make it official. 

I'm also not a fan of the lines as string pattern for these parts.

[Roland Melkert]

For now the gaps for the render will have to do. I'll Photoshop if I have to.
I will follow your tutorial to export the generated string to Stud.io!

I think the studio scaling problem is because of the 5% tolerance of the 572c segment.

Setting it to 0 shouldn't change the end result much, as the other segments have overlap.

[Magnus Forsberg]

I think we should obsolete the old files 572a, 572b and 572c. They have been official and can't be changed, and 572b is not good to use in the template.
So, should I obsolete all three, or only b?  The other 2 could be Move to-files.

572c01 and c02 could be Moved to-files, to the new partnumbers.

I just uploaded reworked parts using flexable section sub-parts.

[Jaco van der Molen]

I just uploaded reworked parts using flexable section sub-parts.

Thanks!