LDraw file generation

[Ed Bardet]

I draw and build a lot of cylindrical structures. The builds turn out good but the drawings are not worth much (IMHO). The cylinders are always made up of two brick segments, a 1x2 brick followed by a 1 round brick, with the second and subsequent rows off set by 1 brick. Pretty standard approach.

I would like to programmatically ( spreadsheet ) develop an LDraw file that has better resolution than I can obtain by tweaking individual bricks in a drawing.

Am studying files that I downloaded of small walls both straight and the same wall curved by a specific number of degrees per segment and am working on how the coordinates are computed. Not as straight forward as I had expected.

I am not a math person so the translation matrices throw me. I was hoping that I could find a way that I could calculate the various values for each row. I was wondering if there was an explanation somewhere of how the translation is done. The actual trig would be wonderful.

One other thing,that I was not able to find, was where do the coordinates refer to. The geometric center of the brick? or someplace else.

It looks like there is no spacing between bricks in the computations. Is that correct?

Any help would be appreciated. If anyone else has tried this please let me know. If this is a Don Quixote situation also let me know.
Thanx,
Ed

[Roland Melkert]

I am not a math person so the translation matrices throw me. I was hoping that I could find a way that I could calculate the various values for each row. I was wondering if there was an explanation somewhere of how the translation is done. The actual trig would be wonderful.

You could do this with LDCad's scripting, that way you won't need to worry (much) about the matrix math.

One other thing,that I was not able to find, was where do the coordinates refer to. The geometric center of the brick? or someplace else.

The matrix in the type 1 lines always works with the abs origin (0,0,0) of the part/submodel it references.

[Travis Cobbs]

The matrix in the type 1 lines always works with the abs origin (0,0,0) of the part/submodel it references.

To add to that, for the most part, each part has an origin that is believed to be the logical place for the origin to be for that part. This will rarely be the center of the part. If you load a part in LDView, and enable the "Show Axes" option in the Miscellaneous section of the General preferences page, you will see where the origin is for that part. For those axes, bright red is positive X, dark red is negative X, bright green is positive Y, dark green is negative Y, bright blue is positive Z, and dark blue is negative Z.

Also, note that "up" in LDraw files is along the negative Y axis, and that LDraw's coordinate system is left-handed instead of right-handed like in most 3D formats.

[Ed Bardet]

You could do this with LDCad's scripting, that way you won't need to worry (much) about the matrix math.


The matrix in the type 1 lines always works with the abs origin (0,0,0) of the part/submodel it references.

 (MUCH)!!!
I'm also thinking along those lines.
But the same problem arises and that is computing where the center of the brick that you just turned is located. I believe, once you turn the brick (in the connected row), you have to know where the new center of the next brick is located and adjust it slightly, before you do the next rotation.
I have found that when I manually turn a brick wall, of lets say 32 segments, the computed amount (11.25 degrees) for each segment, the final result needs editing to accurately join with the originating segment.

[Ed Bardet]

I still need help as some of the previous answers are not borne out by experiment. 
I, in Stud.io, made a small 4 tier wall (starting wall.png), turned the second brick on the bottom row, which turned the rest of the wall (10 degree wall.png).
I then exported both the original and turned wall in ldraw format, and reviewed the files.
I noticed that the Z coordinate of the second round brick on the second row did not change. The Z coordinate of the second 1x2 brick did change. So the brick was turned.

The question is. Several posts have said that the rotation takes place from the center of the brick. If this is the case the round brick connected to it should have moved. If the round brick does not move, the center of rotation must be at the center of the selected stud on the 1x2 brick, not it's geometric center.

I am beginning to think that the procedure for Stud.io is different than that of the LDraw community.

Anybody want to jump in?

[attachment=3904]
[attachment=3905]

[Gerald Lasser]

Ed, your attachment did not make it into the post.

[Travis Cobbs]

The question is. Several posts have said that the rotation takes place from the center of the brick. If this is the case the round brick connected to it should have moved. If the round brick does not move, the center of rotation must be at the center of the selected stud on the 1x2 brick, not it's geometric center.

(Note that your images didn't show up for some reason. So I'm not sure I understand what you did.)

I can't find any posts in this thread stating what I italicized above. Both Roland and I stated that each part has its own origin, and I stated that the origin is not likely to be in the center of the part. Roland stated that the matrix is applied relative to the origin of the referenced part. To the best of my knowledge, all of these things are true.

Each LDraw file (be it a primitive, a sub-part, a part, a sub-model, or a model) has its own coordinate system. Aside from the top-level model, that coordinate system is modified by the matrix in the type 1 line that specifies the sub-file. Based on what you say, it sounds like the LDraw file generated by Stud.io is in MPD format and contains sub-files. I can't see any other way that rotating one brick could rotate "the rest of the wall". If that is the case, then the matrix that is applied to that sub-file accomplishes the rotation, and all of the contents of that file would then be un-rotated internally.

[Ed Bardet]

Ed, your attachment did not make it into the post.

Sorry, would you try it now. Should be two pngs and two files.

[Ed Bardet]

(Note that your images didn't show up for some reason. So I'm not sure I understand what you did.)

I can't find any posts in this thread stating what I italicized above. Both Roland and I stated that each part has its own origin, and I stated that the origin is not likely to be in the center of the part. Roland stated that the matrix is applied relative to the origin of the referenced part. To the best of my knowledge, all of these things are true.

Each LDraw file (be it a primitive, a sub-part, a part, a sub-model, or a model) has its own coordinate system. Aside from the top-level model, that coordinate system is modified by the matrix in the type 1 line that specifies the sub-file. Based on what you say, it sounds like the LDraw file generated by Stud.io is in MPD format and contains sub-files. I can't see any other way that rotating one brick could rotate "the rest of the wall". If that is the case, then the matrix that is applied to that sub-file accomplishes the rotation, and all of the contents of that file would then be un-rotated internally.

I think I get what you mean.It's internally making a sub-model based on the stud selected and connectivity data, rotating and then releasing the sub-model. That would explain how. But the resulting exported file is ldraw type one entries, so I'm probably on the right track.

[Philippe Hurbain]

Not so easy indeed, as there are many constraints... I'll post later some details on the method I used.

[Ed Bardet]

Not so easy indeed, as there are many constraints... I'll post later some details on the method I used.

PLEASE!
That wall is like I want mine to look.
E-mail me if you want.
Thanx,
Ed

[Philippe Hurbain]

So... here is the spreadsheet I used to find wall solutions (at least some of them!). Problem is that for most diameters you'll need approximations (a circle that is not really a circle). The method I use works only in the case where we are "close enough" of circle.
"Rounded Nseg" is the number of segments needed to approximate a given circle diameter. This number must be at least divisible by 3 (to close the circle), in orange, better by 6 (yellow) to have a full diameter 'on grid', even better (green) divisible by 12 to get two orthogonal diameter 'on grid'. "Effective R (studs)" gives the radius (distance from origin) for the first 1x2 brick. "EffectiveAngle" is the rotation around origin of the next 1x2 brick. "Diameter error" show precision of diameter. Closest to 0 (green) is best, but higher values are acceptable (orange), this is the case for D=23 circle attached.

[Ed Bardet]

So... here is the spreadsheet I used to find wall solutions (at least some of them!). Problem is that for most diameters you'll need approximations (a circle that is not really a circle). The method I use works only in the case where we are "close enough" of circle.
"Rounded Nseg" is the number of segments needed to approximate a given circle diameter. This number must be at least divisible by 3 (to close the circle), in orange, better by 6 (yellow) to have a full diameter 'on grid', even better (green) divisible by 12 to get two orthogonal diameter 'on grid'. "Effective R (studs)" gives the radius (distance from origin) for the first 1x2 brick. "EffectiveAngle" is the rotation around origin of the next 1x2 brick. "Diameter error" show precision of diameter. Closest to 0 (green) is best, but higher values are acceptable (orange), this is the case for D=23 circle attached.

Thank you very much. It looks like my experiments leading to using a 32 unit circle is pretty close.(for the base of my blast furnace) The drawing you showed looks like each row was twisted a little bit and that was what made it so smooth. Not sure how that was done - manually?
I am still working on the idea of generating a ldraw file for drawing program import.

[Ed Bardet]

(Note that your images didn't show up for some reason. So I'm not sure I understand what you did.)

I can't find any posts in this thread stating what I italicized above. Both Roland and I stated that each part has its own origin, and I stated that the origin is not likely to be in the center of the part. Roland stated that the matrix is applied relative to the origin of the referenced part. To the best of my knowledge, all of these things are true.

Each LDraw file (be it a primitive, a sub-part, a part, a sub-model, or a model) has its own coordinate system. Aside from the top-level model, that coordinate system is modified by the matrix in the type 1 line that specifies the sub-file. Based on what you say, it sounds like the LDraw file generated by Stud.io is in MPD format and contains sub-files. I can't see any other way that rotating one brick could rotate "the rest of the wall". If that is the case, then the matrix that is applied to that sub-file accomplishes the rotation, and all of the contents of that file would then be un-rotated internally.

Travis-
I have been asking on several forums, that is why the confusion arose, not specifically this thread.
No disrespect meant.
Sorry
Ed

[Willy Tschager]

Philo,

any suggestions for this?

   

w.

[Orion Pobursky]

Philo,

any suggestions for this?



w.

You could use LDCad's chain templates.

[Max Martin Richter]

Philo,

any suggestions for this?



w.

Simply calculate the angle between the chain parts. I assume it is made by 12 parts. So 360 divided by 12 is 30. Afterwards you just need to rotate them one by one.

[Philippe Hurbain]

You could use LDCad's chain templates.

Sorry Willy, missed your post. Like Orion I would have used LDCad chain template. Problem is that you can't directly snap tiles on the generated chain. The solution is to build the chain part, when it's fit is perfect, save and edit the mpd with a text editor to remove or comment out LDCad flex part metas and leave only the fallback code. Reopen the file in LDCad and snap the tiles.

Otherwise, I tried to create a brick circle using LDCad templates, but it doesn't seem to be practical (next to impossible to find the right diameter manually to let the bricks at the exact required spacing).

[Willy Tschager]

I tried the chain template but because of the perfect symmetry it is not very practical. I also thought that rotating it by 30 degrees as Martin suggested would be the - though laborious - best way to go.

w.

[Johann Eisner]

I tried the chain template but because of the perfect symmetry it is not very practical. I also thought that rotating it by 30 degrees as Martin suggested would be the - though laborious - best way to go.

w.

Or the old way with LSynth and MLCad.
Chain fit not excatly,but easy to made.
Code:

  chain.ldr (Size: 314 bytes / Downloads: 2)

Finished:

  chain_finish.ldr (Size: 1.19 KB / Downloads: 2)

Picture:
   

[Willy Tschager]

This was my first choice but when you start counting the threads you'll see why it is not a practical way.

w.

[Johann Eisner]

This was my first choice but when you start counting the threads you'll see why it is not a practical way.

w.

That's true.

If the chain is longer, the count of chain treads is not correct.

[Evgenija Zakharova]

Hello! Can someone help me with hub wedo 2.0/ I cant find parts to get the full hub. Thanks!