Springs

[Roland Melkert]

Hi I'm working on a spring generator for LDCad, and was wondering how far I should take the details.

I've looked at the existing springs in the library, and noticed they don't have conditional lines in the way I would expect them. They also use static lines around the (very low res) wire edges.

Is this on purpose or pure some performance issue ?

Anyway this is what my current code generates (no lines at all).

[Max Martin Richter]

Well, the springs are mostly done by the spring generator which is included in MLCad. And therefore there are no lines at all.
However, I don't like this behavior. I like complete part WITH all lines. See discussion at this (sub-)part s/70181s00.dat

The shape of your springs is incredible. I really like it.

/Max

[Philippe Hurbain]

My opinion is that simplest is best, for performance reasons. You can't see the small details at this scale. Anyway, your rendering looks excellent!

[Roland Melkert]

Thanks to you both,

I can see how file size might become a problem, these test renderings are already using 5000 triangles (or 2500 quads, but I'm not sure they are all flat).

OpenGL wise this isn't a problem, but when I add the wire endings and all conditional lines you are looking at ~15000 LDraw lines Maybe I need to (optional) dial down the resolution for the LDraw output.

[Michael Heidemann]

Yes, please do that. Just such parts can be extremely large if we go too much in detail. Maybe it would be a good idea to create a low res version of such a spring that will be written in ldraw file format and if showing the model you choose how much details needs to be drawn. I do not know how this can be achived, but it should be worth to think about.

[Roland Melkert]

Currently the user can input coil (def 24) and wire resolution (def 8), I'll add second boxes for the LDraw code version.

In LDCad itself it will always regenerate the spring for rendering, and thus use the hq values. But other software will only use the ldraw fallback code and thus render the lower quality version, unless they generate the spring too (based on the spring meta's, it's actually not that hard compared to flexible hoses etc).

[Roland Melkert]

Ok I've added conditional lines.

Attached are two samples. I would appreciate it very much, if someone would take a look at them from a part author's point of view.

Personally I think ~0.5 MB for a spring/shock part isn't that bad. This is using a resolution of 16 for the coil and 8 for the wire.

[Max Martin Richter]

I know that we have some authors who will say: "What 0.5 MB for a Spring?" ;-)
I times, where we are speaking in TB in a normal consumer PC, this is quite OK with me. I did just a very quick visual check of these files and I really like the springs.

/Max

[Magnus Forsberg]

The only issue I can find is incorrect use of colour 80 on a metal part.
All metal parts, like axles, screws, electric contact plates, plugs and springs, must use colour 494.

And why don't you use standard edge colour 24?

[Michael Heidemann]

Generally I am fine with the result. But the question for edgeline colour is a good question. I have changed the colour to value 24 and it still looks goods. I feared that it would be only all black, but that occur only if I go far far away.

[Roland Melkert]

Thanks for the feedback.

And why don't you use standard edge colour 24?

If you give the spring color 16 it will use 24 for edges, but because I wanted the shock to be yellow or grey (old/modern version) I made those color 16, and you can have only one parent color. This means the spring is drawn using normal colors because far as I know you can't say 'edge color of 80'. The current solution for this is encoding the edge color of color 80 in a rgb color code.

Alternative is to split the spring from the shock but this way people need only one separate file/template which is way easier to manage for me code wise.

Users are still free to flip the color code's around off course it's all gui controlled.

And as for the loose spring, I just forgot to set it to 16

[Steffen]

maybe you can save some space by generating just 1 cycle of the spring as a subfile,
and then repeatedly use that?

[Steffen]

The color problem you mentioned only occurs if you put the spring directly into the assembly.

The assembly uses color 16 for coloring the plastic parts, and there color 24 will properly be used to colorize their edges.
However, if you generate your spring DIRECTLY inside that assembly file, using color 494 for the spring quads/triangles,
and color 24 for the spring edges, then of course it will get the wrong edge color.

Your tool in this regards is somewhat wrongly using our files structure!:
The spring should not be generated directly inside the assembly file.
IF you would instead generate it in a way in which it REPLACES the spring part completely,
then your generated spring can use colors 16 and 24 as usual, and would be referenced from
the parent assembly as color 494.
Then everything would appear with correct colors.

May I suggest to modify the generator of your tool this way?

The "trick" of hardcoding the edge color using an RGB value is counterproductive IMHO.

[Roland Melkert]

The color problem you mentioned only occurs if you put the spring directly into the assembly.

Indeed, but the user is totally free to create a loose col 16 spring and reference it from another submodel. But I like to supply the user with complete shock absorber assemblies using templates. Due to a technical limitation my generating code (heavily shared with the flexible (pneumatic etc) generator) can only handle a single submodel containing the fallback code (LDCad it self doesn't use the type 1...5 lines of the spring model).

This has been bothering me somewhat since I created the flexsystem cable templates in LDCad 1.2 (which is a two color bendable part). So I have been thinking on a way to generate multiple fallback submodels while ignoring those in LDCad it self using a 'skip next file' meta or something. Other software will not skip that and thus show the part as intended using multiple submodels.

Anyway it keeps me busy

[Roland Melkert]

That's a great idea, although most springs use a multiple of winding specs in order to have more compressed parts at the start and end etc. So I would have to manage all unique segments separately, this might be a nice optimization for the next next version though

[Roland Melkert]

May I suggest to modify the generator of your tool this way?

Ok it took some doing but I've implemented support for this. It will no put the spring 'mesh' into a second subfile when it's not of color 16. See attachment.

Now I only need the exact measurements of the common springs (wire thickness, etc), does anyone have these handy?

[Steffen]

oh, very nice!
this is definitely the better solution.

a last question:
> It will no put the spring 'mesh' into a second subfile when it's not of color 16

why this? why not always do that?
the spring will always be a standalone part - that property isn't depending on whether it has color 16 or not.

[Roland Melkert]

I was thinking portability, also not all software references mpd's correctly. I could make it an option to always put the mesh in a second model unless it's the only thing (loose spring).

[Michael Heidemann]

Code:

I was thinking portability, also not all software references mpd's correctly.

I think you should not care too much about non working other tools. If they are maintained they should update their applications, if they are not maintained they will gone if there is a better alternative.

[Steffen]

Thank you very much!
Yes, and creating new oddities for broken tools is not a good way to go IMHO.
Tools _have_ to parse mpd correctly, or they simply are broken.