- This topic has 72 replies, 9 voices, and was last updated 2 years, 9 months ago by
.
.I have questions:
What’s the learning curve like? How difficult is it to find parts? Can you find parts via part number, or is it better to search by description? What color names are used?
And most importantly: can stud.io import from LDD?
@zaximillian I’m not sure if you ever got answers to your questions, but it’s not too hard to use and pretty easy to find parts. You can search via name, dimension, or BrickLink part number. It uses the color names from BrickLink. Yes, it can import from LDD.
Any model that is uploaded to BrickLink becomes LEGO’s intellectual property in perpetuity, and without credit.
Interestingly that also applies to the wanted lists on the site as well. From BrickLink’s terms:
You may post, display or publish images, captions, titles, materials, information, data, designs, models, build instructions, videos and other content (collectively, “content”) to public areas of the Site, including but not limited to Catalog, Studio Gallery and forums of the Site. You hereby grant to BrickLink an irrevocable, worldwide, royalty-free, non-exclusive, assignable, and sub-licensable right and license, for the duration of applicable legal protection of any intellectual property right attached to the content, to use, modify and translate as necessary, reproduce, publish, communicate and display such content in any manner as BrickLink deems appropriate in relation to the operation of the Site. You hereby waive your moral rights in the content, to the extent necessary to give effect to the above license.
When you upload any content to any private areas of the Site including but not limited to My Studio and Wanted List of the Site, where no other users have access to your content without your explicit permission, you hereby grant to BrickLink a worldwide, assignable, royalty-free, non-exclusive right and license to reproduce, modify and translate as necessary, publish, communicate and display such content solely in your private areas of the Site.
Long-time viewers of the show will be familiar with my Travis-brick pine trees. (And if you’re not, there’s several links to photos at the end, cause none of this will make any sense if you’re not picturing the build that I’m talking about. I may also attach a screenshot of my Studio file, either in this post or a separate one.) It’s a common design and I didn’t come up with it; I’ve been using them since 2014, and the design wasn’t new then either. I have them organized into bags with instruction cards for easy assembly, and I currently have 137 of them of 24 different types. I have a naming system for all of them, based on the height and volume of the tree.
The first thing I did was make a big file containing all 24 types of tree. All the trees were converted to submodels. The trees are arranged in an organized fashion, and they’re all labeled using 1×1 black tiles with letters printed on them.
The second thing I did was make 24 additional files, with one tree each. That way when I’m landscaping, I can simply import the relevant tree file, and I have the whole tree right there, again as a single submodel, that I can easily move around and copy.
I’m hoping that will work well, but I haven’t really done anything with it, except a couple tests. As far as I can tell, when you import an outside model, it doesn’t give you the option of deciding where it’s gonna go; instead, it just appears in the file and then you have to move it. In fact, I had trouble moving it, I had to copy it, move the copy, and delete the original. If there’s a better way to do it, I haven’t figured it out yet, I don’t know if Krista will have advice for me there or not @knb112. Importing was mentioned in class, but we didn’t ever use it for our homework assignments, so I hadn’t actually used it til recently.
One thing I did learn is that Studio doesn’t keep a list of submodels somewhere that you can call up so that you can pick one off the list to insert. I somehow thought that this was the case, probably because that’s how it works in AutoCAD. In AutoCAD, you can use the insert command – which is different from importing a submodel from outside the file – and it will bring up a list of every submodel created in that drawing, even ones were created but currently don’t actually appear in the drawing, and you can then pick a submodel from that list to insert into the drawing.
Studio has nothing like that – or if it does, I couldn’t find it, and I’d definitely like to know where it is. If I make submodel J3, and then I delete it, I can’t call it up later – as far as Studio is concerned, it no longer exists. The only way to bring it back is to undo the deletion, or remake it from scratch. Likewise, if J3 does exist in the drawing, and I want to put another J3 somewhere else, I need to find an existing J3 somewhere in the drawing and click on it and copy it. If the existing J3’s are not easily accessible, especially if they’ve been incorporated into larger submodels that would have to be released in order to copy their component part, then the easiest way is to have an extra J3 off to the side for easy access. I did in fact use this method to make my pine trees.
The basic premise of the design is Travis bricks stacked on top of each other, with stacks of the classic 3-prong flower stem on all four sides of each brick, with the stem stacks ranging from 1 to 6. So the first thing I did was make six submodels, called Stem-1, Stem-2, etc., which were the stacks of stems. I had to rotate each stem part relative to the previous ones in the stack to give a reasonable approximation of how they’re gonna appear in actual trees, but that worked out – I didn’t have any of the rotation problems that plagued me with my Space Plants submodels (which I have not yet gone back to, that’s a conversation for another day). Next I copied and rotated each of the Stem submodels to attach to the four sides of a Travis brick to create six more submodels, Travis-1, Travis-2, etc. (Because I just copied the Stem submodels, they’re all identical and don’t have the variation that inevitably occurs when assembling the trees by hand, which helps give them a more natural and less mechanical look, but it doesn’t matter here; the Studio files are just for planning purposes.) I was happy with how the Travis submodels came out. I then assembled them into the different trees, but for the reasons mentioned above, I had to keep a copy of all six of them arranged off to the side for easy access.
What’s not apparent in the photo is that the trees contain umbrella stands inside the Travis bricks for additional support. (Technically it’s the 6L bar with stop ring, which is actually a different part from the old 6.6L Fabuland umbrella stand, but people still call them that anyway). I don’t really need the umbrella stands in the Studio file – I already have more than I need, so I won’t need to buy more, and they’re already installed in the tree trunks as needed, and of course the Studio pine trees are gonna hold together whether they’re there or not – but I thought I’d put them in anyway (for one thing, it would give me a total count on them, see ‘blowing people’s minds’ in the previous post). But I ran into problems. Putting the part into the first Travis brick, so that it stops at the ring, was easy. But then I would slide the next Travis brick down the umbrella stand until it hits, and clicks onto, the first Travis brick. This seems like it should be easy, but Studio struggled with it. Since you can slide a Travis brick to any point on the umbrella stand, Studio let me drag it up and down as desired, but it did not do a good job of finding the lower Travis brick and clicking to it. Frequently it would go too far, so they’d overlap and get grayed out, and I’d have to move the top one back up a little. Most of the time it did click properly in the end, but sometimes there was a small gap between them, and it happened often enough and was enough of a hassle to detect and fix that I got frustrated with it pretty quickly and deleted out all the umbrella stands. Currently there are none in any of my pine tree files. Is there a way to make that work better? I remember we talked a bit about the collision settings in class, but I seem to remember that Krista was not a fan of messing with them, and I have not looked into what might be accomplished with them, if anything. I also tried putting the Travis submodels together first and then adding the umbrella stand afterwards (which would not actually be physically possible in real life), but that didn’t work either.
After that though the tree assembly was pretty smooth. The basic premise of the tree design is that each Travis brick is rotated 45 degrees relative to the one below it, so that they flip back and forth. (And again, Studio’s ability to hit 45 degrees exactly every time creates very sterile-looking trees; in real life slight variations that are inevitable and can also be helped along deliberately create a more natural-looking tree.) What slowed me down is that every time, Studio wanted to align with the rotation of the Travis-submodel with the one below it, whether it had a 45-degree rotation or not. I can’t complain about that, Studio has no way of knowing which way I want it, and I have to think in most applications, you’re gonna want an added part to align with what it’s clicking to. But it was a bit slow, there was a lot of copying and then manually rotating every other one.
One other minor hassle occurred when I made the individual import files for each tree. First I did a ‘save us’ on the master tree file to create a temporary copy. Then I deleted out every tree except the one I wanted to keep, and saved that under the file name I wanted for it. Then I reopened the temp copy of all the trees, and repeated the process for the next tree. (Every six trees I would eliminate the trees already done in the master copy to reduce the overall amount of deleting.) In doing this, the easiest way of course was to keep the view of all the trees in a generally isometric one. But the minor hassle was that every time I reopened the master copy file, it would revert to a side view, despite the fact that I had never once used that particular view for that file, much less saved it that way. And so every time I would have to manually rotate it to a view that was more convenient (the isometric view button is still not working for me and really never has, which is another issue); it was a small inconvenience, to be sure, but I had to do it over and over, but more importantly, it was perplexing, because I couldn’t think of any reason why this would be happening or anything that I could do about it. So again, I don’t know if Krista has any advice for me on that one or not @knb112.
And of course, now that I have them made, I have not actually gotten around to sitting down and working on a landscape file that will use them. But I have high hopes for them. Both Space plants and Earth plants are a similar situation to the one I described with landscaping in the previous post, where design and assembly are somewhat at odds with each other: my experience with plants has been that it’s easiest to decide where the biggest plants go first, but once they’re in place, they’re physically in the way when you’re putting smaller plants around them, so you’re constantly putting plants in and then removing them and then putting them back in to check that it looks okay and things aren’t bonking into each other and then removing them again to put more plants in, etc., and it’s pretty slow and tedious. I’m hoping that Studio will help make this easier, as well as be useful for coming with an order of operations when it does come time to assemble. Pine trees especially are almost impossible to transport assembled and have to be done on site, and knowing ahead of time what order to place them on the build will be a big help in the convention hall. (You can see it in the Greenberg links attached at the end of this post, which was another build made quickly on the spot, there’s tons of small plants along the water’s edge, but almost none farther back below the larger trees or near the pine trees.)
Additionally, I want to see how far my trees will actually go in a display. The first link below is from BWC in 2019, Rachel had reserved more table space than she could fill, and I improvised a display to use up the rest of the table (it’s easily the least impressive thing I’ve ever put on public display). At the time I had 68 pine trees (of 13 different types) and I was surprised how easily I fit all of them on just nine baseplates, which led me to create more. (As far as I know, though, Lego has stopped making that particular plant stem part, so I’m probably at my limit for that kind of tree, although there’s still unused stems at my house.) But assembling all 68 took hours and hours, so I’m hoping that Studio will streamline that process; it will be nice to know in any given display exactly how much space I can expect to be coverable (not a real word) by pine trees.
Here’s the links. The first, as mentioned, is BrickWorld Chicago 2019. The other two, which give a better views of the pine trees closer up, is from the Greenberg Train Show in Monroeville in November 2017.
Long-time viewers of the show will be familiar with my Travis-brick pine trees. (And if you’re not, there’s several links to photos at the end, cause none of this will make any sense if you’re not picturing the build that I’m talking about. I may also attach a screenshot of my Studio file, either in this post or a separate one.) It’s a common design and I didn’t come up with it; I’ve been using them since 2014, and the design wasn’t new then either. I have them organized into bags with instruction cards for easy assembly, and I currently have 137 of them of 24 different types. I have a naming system for all of them, based on the height and volume of the tree.
The first thing I did was make a big file containing all 24 types of tree. All the trees were converted to submodels. The trees are arranged in an organized fashion, and they’re all labeled using 1×1 black tiles with letters printed on them.
The second thing I did was make 24 additional files, with one tree each. That way when I’m landscaping, I can simply import the relevant tree file, and I have the whole tree right there, again as a single submodel, that I can easily move around and copy.
I’m hoping that will work well, but I haven’t really done anything with it, except a couple tests. As far as I can tell, when you import an outside model, it doesn’t give you the option of deciding where it’s gonna go; instead, it just appears in the file and then you have to move it. In fact, I had trouble moving it, I had to copy it, move the copy, and delete the original. If there’s a better way to do it, I haven’t figured it out yet, I don’t know if Krista will have advice for me there or not @knb112. Importing was mentioned in class, but we didn’t ever use it for our homework assignments, so I hadn’t actually used it til recently.
One thing I did learn is that Studio doesn’t keep a list of submodels somewhere that you can call up so that you can pick one off the list to insert. I somehow thought that this was the case, probably because that’s how it works in AutoCAD. In AutoCAD, you can use the insert command – which is different from importing a submodel from outside the file – and it will bring up a list of every submodel created in that drawing, even ones were created but currently don’t actually appear in the drawing, and you can then pick a submodel from that list to insert into the drawing.
Studio has nothing like that – or if it does, I couldn’t find it, and I’d definitely like to know where it is. If I make submodel J3, and then I delete it, I can’t call it up later – as far as Studio is concerned, it no longer exists. The only way to bring it back is to undo the deletion, or remake it from scratch. Likewise, if J3 does exist in the drawing, and I want to put another J3 somewhere else, I need to find an existing J3 somewhere in the drawing and click on it and copy it. If the existing J3’s are not easily accessible, especially if they’ve been incorporated into larger submodels that would have to be released in order to copy their component part, then the easiest way is to have an extra J3 off to the side for easy access. I did in fact use this method to make my pine trees.
The basic premise of the design is Travis bricks stacked on top of each other, with stacks of the classic 3-prong flower stem on all four sides of each brick, with the stem stacks ranging from 1 to 6. So the first thing I did was make six submodels, called Stem-1, Stem-2, etc., which were the stacks of stems. I had to rotate each stem part relative to the previous ones in the stack to give a reasonable approximation of how they’re gonna appear in actual trees, but that worked out – I didn’t have any of the rotation problems that plagued me with my Space Plants submodels (which I have not yet gone back to, that’s a conversation for another day). Next I copied and rotated each of the Stem submodels to attach to the four sides of a Travis brick to create six more submodels, Travis-1, Travis-2, etc. (Because I just copied the Stem submodels, they’re all identical and don’t have the variation that inevitably occurs when assembling the trees by hand, which helps give them a more natural and less mechanical look, but it doesn’t matter here; the Studio files are just for planning purposes.) I was happy with how the Travis submodels came out. I then assembled them into the different trees, but for the reasons mentioned above, I had to keep a copy of all six of them arranged off to the side for easy access.
What’s not apparent in the photo is that the trees contain umbrella stands inside the Travis bricks for additional support. (Technically it’s the 6L bar with stop ring, which is actually a different part from the old 6.6L Fabuland umbrella stand, but people still call them that anyway). I don’t really need the umbrella stands in the Studio file – I already have more than I need, so I won’t need to buy more, and they’re already installed in the tree trunks as needed, and of course the Studio pine trees are gonna hold together whether they’re there or not – but I thought I’d put them in anyway (for one thing, it would give me a total count on them, see ‘blowing people’s minds’ in the previous post). But I ran into problems. Putting the part into the first Travis brick, so that it stops at the ring, was easy. But then I would slide the next Travis brick down the umbrella stand until it hits, and clicks onto, the first Travis brick. This seems like it should be easy, but Studio struggled with it. Since you can slide a Travis brick to any point on the umbrella stand, Studio let me drag it up and down as desired, but it did not do a good job of finding the lower Travis brick and clicking to it. Frequently it would go too far, so they’d overlap and get grayed out, and I’d have to move the top one back up a little. Most of the time it did click properly in the end, but sometimes there was a small gap between them, and it happened often enough and was enough of a hassle to detect and fix that I got frustrated with it pretty quickly and deleted out all the umbrella stands. Currently there are none in any of my pine tree files. Is there a way to make that work better? I remember we talked a bit about the collision settings in class, but I seem to remember that Krista was not a fan of messing with them, and I have not looked into what might be accomplished with them, if anything. I also tried putting the Travis submodels together first and then adding the umbrella stand afterwards (which would not actually be physically possible in real life), but that didn’t work either.
After that though the tree assembly was pretty smooth. The basic premise of the tree design is that each Travis brick is rotated 45 degrees relative to the one below it, so that they flip back and forth. (And again, Studio’s ability to hit 45 degrees exactly every time creates very sterile-looking trees; in real life slight variations that are inevitable and can also be helped along deliberately to create a more natural-looking tree.) What slowed me down is that every time, Studio wanted to align with the rotation of the Travis-submodel with the one below it, whether it had a 45-degree rotation or not. I can’t complain about that, Studio has no way of knowing which way I want it, and I have to think in most applications, you’re gonna want an added part to align with what it’s clicking to. But it was a bit slow, there was a lot of copying and then manually rotating every other one.
One other minor hassle occurred when I made the individual import files for each tree. First I did a ‘save us’ on the master tree file to create a temporary copy. Then I deleted out every tree except the one I wanted to keep, and saved that under the file name I wanted for it. Then I reopened the temp copy of all the trees, and repeated the process for the next tree. (Every six trees I would eliminate the trees already done in the master copy to reduce the overall amount of deleting.) In doing this, the easiest way of course was to keep the view of all the trees in a generally isometric one. But the minor hassle was that every time I reopened the master copy file, it would revert to a side view, despite the fact that I had never once used that particular view for that file, much less saved it that way. And so every time I would have to manually rotate it to a view that was more convenient (the isometric view button is still not working for me and really never has, which is another issue); it was a small inconvenience, to be sure, but I had to do it over and over, but more importantly, it was perplexing, because I couldn’t think of any reason why this would be happening or anything that I could do about it. So again, I don’t know if Krista has any advice for me on that one or not @knb112.
And of course, now that I have them made, I have not actually gotten around to sitting down and working on a landscape file that will use them. But I have high hopes for them. Both Space plants and Earth plants are a similar situation to the one I described with landscaping in the previous post, where design and assembly are somewhat at odds with each other: my experience with plants has been that it’s easiest to decide where the biggest plants go first, but once they’re in place, they’re physically in the way when you’re putting smaller plants around them, so you’re constantly putting plants in and then removing them and then putting them back in to check that it looks okay and things aren’t bonking into each other and then removing them again to put more plants in, etc., and it’s pretty slow and tedious. I’m hoping that Studio will help make this easier, as well as be useful for coming with an order of operations when it does come time to assemble. Pine trees especially are almost impossible to transport assembled and have to be done on site, and knowing ahead of time what order to place them on the build will be a big help in the convention hall. (You can see it in the Greenberg links attached at the end of this post, which was another build made quickly on the spot, there’s tons of small plants along the water’s edge, but almost none farther back below the larger trees or near the pine trees.)
Additionally, I want to see how far my trees will actually go in a display. The first link below is from BWC in 2019, Rachel had reserved more table space than she could fill, and I improvised a display to use up the rest of the table (it’s easily the least impressive thing I’ve ever put on public display). At the time I had 68 pine trees (of 13 different types) and I was surprised how easily I fit all of them on just nine baseplates, which led me to create more. (As far as I know, though, Lego has stopped making that particular plant stem part, so I’m probably at my limit for that kind of tree, although there’s still unused stems at my house.) But assembling all 68 took hours and hours, so I’m hoping that Studio will streamline that process; it will be nice to know in any given display exactly how much space I can expect to be coverable (not a real word) by pine trees.
Here’s the links. The first, as mentioned, is BrickWorld Chicago 2019. The other two, which give a better views of the pine trees closer up, is from the Greenberg Train Show in Monroeville in November 2017.
Ugh, this post didn’t go through, good thing I knew to save a copy of it first because I’ve run into this before. As far as I can tell, because of the file size limits on the site, it doesn’t like my post because it contained links to Flickr photos that are too big, even though I’m not actually attaching the actual photo files to the post. It’s a giant pain in the butt, I know I’m not the only person who’s had problems with it, and nobody’s come up with a solution. So I’ll have to figure out something out in a subsequent post, but I’m gonna go ahead and post this one before I lose it.
First Flickr link:
Second Flickr link:
Third Flickr link:
@bengood921 Here’s what I got so far. I still have a bit of work on the instructions, especially since some of the torsos aren’t available in Studio.
