LDraw.org Discussion Forums

Full Version: LDraw file generation
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
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
(2019-07-29, 15:41)Ed Bardet Wrote: [ -> ]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.


(2019-07-29, 15:41)Ed Bardet Wrote: [ -> ]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.
(2019-07-29, 19:30)Roland Melkert Wrote: [ -> ]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.
(2019-07-29, 19:30)Roland Melkert Wrote: [ -> ]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.
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]
Ed, your attachment did not make it into the post.
(2019-07-30, 20:24)Ed Bardet Wrote: [ -> ]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.
(2019-07-30, 22:10)Gerald Lasser Wrote: [ -> ]Ed, your attachment did not make it into the post.
Sorry, would you try it now. Should be two pngs and two files.
(2019-07-30, 22:13)Travis Cobbs Wrote: [ -> ](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.
Not so easy indeed, as there are many constraints... I'll post later some details on the method I used.
Pages: 1 2 3