- This topic has 72 replies, 9 voices, and was last updated 10 months ago by
.
-
Posts
-
Thanks, I took a look through the Elf House. Mostly I just wanted to see the step-by-step process for something that might be considered a typical Studio file. The projects we worked on for class were on the small side, and the projects I did last fall (the Mysterious Planet landscaping and the pine tree file) I suspect are somewhat atypical compared to what I imagine people commonly use this program for.
I’m also checking out how the instructions look, since I noticed in the step view that there’s some big submodels that just pop in all at once. (I am noticing there’s still some cleanup necessary in the instructions – for example, in step 10, the parts window is blocking the view of where some of those parts go on the model, something I seem to recall was frequently a source of frustration for us in class. Oooh, see also, step 18 :P)
I’m still on my computer from 2010 and I still have Studio set to the lowest render quality in order to minimize sluggishness, and the arches in the 1x6x2 arch bricks are basically just a few straight lines, which means they appear to not even remotely fit over the tan window pieces underneath them. I’m assuming that really they fit snugly. Ugh, it’s so primitive at times that it wasn’t immediately clear to me what the red, lime, and bright light orange parts are in the tree. Even after I guessed (correctly) that they’re Technic ball parts, I went and released the tree submodel to confirm it. (I was also a little disappointed that they weren’t some cool new part unfamiliar to me.)
One of the first things I noticed when I opened it is that in the model view, it’s not coming in as true isometric. It’s more of a forced perspective look, or at least I assume that’s what Lego is going for, because to me it looks less ‘forced perspective’ and more ‘Salvador Dali distorted’. It’s especially noticeable on opposite ends of the big white plates, where the sides of the landscape aren’t drawn parallel on the screen. I wasn’t sure if there was something Krista deliberately did to this file to make it look that way, so I opened my pine tree file from last November, and sure enough, it’s doing it there too. I have trouble believing I accidentally changed the settings on Studio (I haven’t really used it since last November), and I’ve also let the program do updates a couple times since then. So I’m not sure if it’s always been like that and I never noticed before (I actually find that to be highly unlikely), or if it’s a new ‘feature’ somebody came up with at Studio headquarters. I can’t say that I like it. I did notice that when I go to the instructions view, it’s back to true isometric.
I’m also noticing in the instructions that when there’s a submodel assembly, the submodel doesn’t have its own numbering starting with 1 like they do in Lego sets, and then picking back up with the master numbering count when the submodel is added to the main model. I’m not sure if that’s a deliberate choice by Krista, or if that’s how Studio always does it. I can’t remember from last fall, even though we must have played around with that in class.
On the roof, in the model view, a bunch of the window parts are coming in as wireframe, which Studio does if they’re hitting something else. I can’t figure out why it’s doing that though, since in the instructions view, everything appears to be fine.
That’s all I got for now, thanks for sharing, I had fun going through it. If there’s an updated version, I’ll be interested in seeing it.
I’m also checking out how the instructions look, since I noticed in the step view that there’s some big submodels that just pop in all at once. (I am noticing there’s still some cleanup necessary in the instructions – for example, in step 10, the parts window is blocking the view of where some of those parts go on the model, something I seem to recall was frequently a source of frustration for us in class. Oooh, see also, step 18 :P)
So admittedly, I got sidetracked with work stuff and didn’t get a chance to clean up the instructions as I wanted. It’s on my list of things to do.
One of the first things I noticed when I opened it is that in the model view, it’s not coming in as true isometric. It’s more of a forced perspective look, or at least I assume that’s what Lego is going for, because to me it looks less ‘forced perspective’ and more ‘Salvador Dali distorted’. It’s especially noticeable on opposite ends of the big white plates, where the sides of the landscape aren’t drawn parallel on the screen. I wasn’t sure if there was something Krista deliberately did to this file to make it look that way, so I opened my pine tree file from last November, and sure enough, it’s doing it there too. I have trouble believing I accidentally changed the settings on Studio (I haven’t really used it since last November), and I’ve also let the program do updates a couple times since then. So I’m not sure if it’s always been like that and I never noticed before (I actually find that to be highly unlikely), or if it’s a new ‘feature’ somebody came up with at Studio headquarters. I can’t say that I like it. I did notice that when I go to the instructions view, it’s back to true isometric.
Can you post a screenshot? I don’t think that’s happening on mine.
I’m also noticing in the instructions that when there’s a submodel assembly, the submodel doesn’t have its own numbering starting with 1 like they do in Lego sets, and then picking back up with the master numbering count when the submodel is added to the main model. I’m not sure if that’s a deliberate choice by Krista, or if that’s how Studio always does it. I can’t remember from last fall, even though we must have played around with that in class.
That wasn’t deliberate on my part. I think what we may have done was a workaround by changing the page layout and adding text to each step, but I feel that there’s a setting somewhere that’s just not coming to mind.
On the roof, in the model view, a bunch of the window parts are coming in as wireframe, which Studio does if they’re hitting something else. I can’t figure out why it’s doing that though, since in the instructions view, everything appears to be fine.
I tried so hard to get that to fit and in theory it works, so I’m not sure why that’s showing as wireframe. There’s a brick on the chimney as well. I used snap so there’s no reason anything should be that way. I’m going to play with it when I’m using a mouse.
That’s all I got for now, thanks for sharing, I had fun going through it. If there’s an updated version, I’ll be interested in seeing it.
It’s good practice for sure! It was a fun challenge. I’ll post the updated version soon. 🙂
@bengood921 I remembered how to pull out the submodel steps. You’ll want to use Convert to callout.
>> Can you post a screenshot? I don’t think that’s happening on mine.
I can, I think, hopefully soon. A week ago I was in Lancaster, and I was using Studio on my laptop, and it was doing it there too. But I just had the program open on my desktop, and I’m not really seeing it right now. I’m not sure if it’s reverted back, or if it’s a specific set of circumstances the creates it. I’m sure it was not just an optical illusion, at times it was rather dramatic looking. I’ll make sure I get a screenshot next time there’s an opportunity.
I’ve been using Studio a lot in the last several weeks, both for my BFPA project, and for my GBC module (the current version of which needs to be done in less than two weeks). It’s been helpful and I’ve gotten a lot done, but I’ve run into a lot of issues as well, and I’m finally getting around to posting, because I ran into a repeat issue today that’s especially annoying.
I’ve created a bit of a logistical nightmare by procrastinating on posting about issues; instead of posting as they’ve come up, I’ve let them pile up, and discussing them all in one post isn’t looking like a good idea, so I’m gonna break them up into multiple posts.
Recently I’ve been thinking that I should start getting on forums and doing research and asking questions there myself. I plan to keep posting here, but it has occurred to me that it’s not reasonable to assume that Krista has literally all the answers just because she taught the class. She did discuss forums during class time, and she probably sent us some links, but I’m not sure where they are now. And I’m thinking it would be good to have them posted here for anybody who is looking for them. I know there’s a way to pin a post to the top of the thread on this website (but I don’t know how to do it, and I’m not sure I have access), and so I’m thinking we should do that here, with the first post containing useful Studio links.
Ben’s June22 Post #1 – Rotating
I’ve run into more problems trying to rotate parts or submodels at angles other than 90 degrees.
Part 1
I’ve long been interested in using Pythagorean triples as a way to break the Lego grid, and in fact have already done so in various GBC modules. Making a Pythagorean triangle in Lego is not as easy as drawing it on paper, because the parts have to overlap at the vertices, and so all three sides have to be in different planes (or change planes from one end to the other). I thought it would help to have some samples made in Studio to help me picture them and that I could possibly import into other builds, and last month I attempted to do so.
I found it difficult to even get started. So I made an AutoCAD file first (this is, in fact, important to the story). I drew 2D versions using Technic bricks of every primitive triple with numbers under 100. (There’s sixteen of them, they’re listed in the Wikipedia entry for Pythagorean triple.) I got it done pretty quickly, it helped that I’d made blocks for Technic bricks years ago, and used the drawing as a reference going forward.
Then I went to Studio, and attempted to make a 5-12-13 triangle. This part didn’t go as well. Screenshot attached. The short side is the red bricks, studs up. I put in pins and added the long side vertically, studs forward, these are the blue bricks. Studio does not like building in empty space or placing parts adjacent to one another without a reference part to click to (more on that in another post). So since it’s a virtual build, I don’t actually need the 2×4 plates on the back of the blue side to hold the Technic bricks together, but they’re there because without them I couldn’t get the the bricks to place correctly. I put in the Technic pins at the top so the hypotenuse would have something to click in to.
The hypotenuse I left LBG. I know of no way to build it in place like that. Instead, I also assembled it vertically up from the red bricks studs forward (also requiring 2×4 plates), turned it into a submodel, and then rotated it into place. We learned about how to rotate in class.
Or, at least, attempted to rotate it into place. Because this is where I ran into trouble. Presumably because the hypotenuse submodel is connected by a pair of Technic pins, Studio didn’t have any trouble finding the correct axis to rotate around. But when I got it going, the submodel flailed all over the place like a hyperspastic fish, and I couldn’t even remotely control where it was going or what it was doing. I tried from all different viewing angles, at various zoom distances, and clicked in just about every place and way possible. I couldn’t get it to work.
I suspect part of the problem was that Collision Detection was on. We talked about it a little bit in class. Krista said that she’d rarely had need to turn it off. Until now, I hadn’t thought of any reason to ever turn it off either. And in fact, it didn’t occur to me at the time; I only thought of it more recently when I ran into a different situation where I needed to turn it off (more on that also in another post). The problem was that in the Studio file, I had the parts arranged in such a way that if it had been real life, the hypotenuse couldn’t’ve swung into place without magically passing through the Technic pins.
Now that I do have it in place (see below for how I did it), I’m not able to test this theory though. Because I can’t get the hypotenuse back out. Now that it’s pinned in at both the bottom and the top, I can rotate it – from either set of pins, since Studio sees them both as a rotation axis – but when I do so, the blue and red bricks rotate with it. It’s important to note here that turning off Collision Detection does not change this. And yet, if I simply drag the hypotenuse to the side, it comes away just fine, even though again, the gray Technic bricks are magically passing through the pins.
So the next test is drag the hypotenuse to the side, rotate it vertically, replace it on the end of the red bricks, see if I can rotate it back into place with Collision Detection turned off. And no, it’s still not working. I do have more control over it, and I can pass through the pins, which I couldn’t do before (I also couldn’t swing around the other way and pass through the red bricks). But I can see the degree readout and it’s only adjusting in increments of 5 degrees. Is there a way to change that? For this application, five degrees is not even close to being precise enough.
When I originally did it, my workaround was to type the necessary angle into the degree field that comes up when you rotate. But this assumes that you actually know what that number is. In this case, for the Pythagorean triples, I don’t actually know any of them. But in my AutoCAD file, I was able to put in angle dimensions, and that gave me the numbers, screenshot attached. But even using that wasn’t good enough, in the attached view, all numbers are rounded off to the nearest digit. When I entered it into Studio, it still wasn’t aligned well enough and it grayed out.
Fortunately, I can set the precision on the dimensions in AutoCAD, which I did to the maximum amount, which for angles is five decimal points. And entering that number worked. I did run into something strange – as I typed in the number, which was seven digits plus a decimal point, Studio did not expand the entry field to accommodate it. Instead, it shrink the size of the font so that the whole thing fit in the space, which meant by the end I could not read it at all, it was like typing in an eight-digit password where they don’t give you the eyeball option. And zooming in didn’t help, the parts grew larger, but the rotation information didn’t change. And in retrospect, I don’t know that it was necessary. Once it worked, I moved on, so I didn’t do any tests to see what the minimum number of digits was necessary to get it to the work. But in using Studio since then, I’ve noticed that Studio always rounds angle numbers off to two decimal places. I doubt there’s any way to change that, since I doubt it’s really necessary for greater precision than that.
But the real important thing here is that I was only able to get it to work because I happened to have that angular dimension, which I was able to obtain because I happened to make a relevant AutoCAD file just beforehand, which I’m gonna assume is something most people don’t do. Without it, I would have had to resort to figuring out the angle myself – which would have required some research since I haven’t really done any trigonometry in about 30 years – or I would have to search the internet for tables containing that information to the desired level of precision. Had I gone down either of those roads, there’s a good chance that I would’ve encountered significant frustration or even failure.
Part 2 after my walk, it’s nice out.
Ben’s June22 Post #1 – Rotating
The attachments for Part 1 have been added. Hopefully all that text makes sense with them included. I also realized that I’m *still* saying ‘subassembly’ when I mean submodel. I thought I’d broken the habit, but clearly not, cause I see three instances of it in the previous post. I will edit it when I’m done here.
Part 2
The past week I’ve been using Studio to design part of my GBC module. The main section is a vertical tread elevator. I built it last June, before I learned Studio, and to assist the planning I made a 2D AutoCAD file (also relevant to the story), which I’ve been doing for GBC since 2016, so it wasn’t unfamiliar territory. But once I realized it wouldn’t be done for BFVA21, I set it aside, until the last couple weeks.
The standard for GBC is that I must start with a container at least 10 studs by 10 studs, and at most 10 bricks high, to receive the balls from the previous module. I’ve been using Studio to design a new starting container, and it’s basically just a glorified box with a ramp towards the top to direct the balls into a mechanism (not yet designed) that will then put them onto the tread elevator one at a time.
I’m attaching a screenshot of the container so far. The ramp is just slopes and tiles held together by layers of plates. On the upper end, there’s a hole on each side for pins to go in. The idea is that those pins will be fixed in holes in the sides of the container, and then gravity will cause the lower end to drop until it hit a support built to hold it up. The problem, of course, is that ‘Turn on Gravity’ is not an option in Studio (although it would be totally awesome if it were).
So I have to rotate the ramp manually. Since it’s just a visual aid for designing, it doesn’t have to be exactly precise, but it helps, because I need to make sure when the balls roll off of it, they properly enter the next section. And the angle of the ramp is actually pretty shallow (which is why we’re not using Pythagorean triples, a small angle means an extremely large hypotenuse), because I only have so much vertical space before I hit the table, so I need to max out what I have to make sure everything’s working properly. So the more accurate I can get my ramp in Studio, the better.
When I’m rotating the ramp, I basically just have to eyeball it by trial and error, and if it grays out, adjust it upwards. Because I have an AutoCAD file of the design, I’m able to use that to figure out precisely what the actual angle is based on the current setup. The problem is, when I enter that angle into Studio, it grays out, and the eyeball test makes is clear that it’s not even close. Thus far, I have not been able to figure out what’s going wrong. And actually, it seems unlikely anybody’s gonna be able to diagnose it from afar, but I’m still gonna explain it in case anybody has any ideas.
Part of the problem is measuring exactly what angle the ramp is currently at. Because the foundation of the ramp is just basic plates, I assembled it by laying them flat on a baseplate (later deleted out) and building from there, and then converting the whole thing to a submodel. So at the point, the ramp is horizontal, and the rotation angle is zero.
Later, when I went to install it in the container, I discovered it worked better if I also made the pins and the container bricks part of the submodel. Complications in editing submodels is a topic for another post, and in retrospect maybe I should have done it differently, but my solution was to create a new submodel that consisted of the ramp (which is still its own submodel) plus the pins and bricks. So there’s a submodel within a submodel, which Studio handles just fine.
The problem is that at some point, something weird happened with the rotation that I can’t explain, and I’m not sure if the submodel-in-a-submodel combined with changing the rotation at different points in the timeline is contributing to that. At some point, when I went to adjust the rotation, I realized I couldn’t figure out exactly what rotation I was currently at, which made it difficult to be sure that I was truly matching the rotation given to me by AutoCAD.
So I figured that the best thing to do was to get it back to zero, and then go from there. But when I entered zero as the rotation, the plates of the ramp were no longer horizontal. As best as I could tell, to get them to be horizontal, the rotation number I had to enter was 4. Even with side view and such, it’s hard to eyeball it in Studio and be sure it’s exactly precisely horizontal, but I did a test where I built a custom platform for it to rest on and click in at various spots, and I was able to do so without anything graying out. So again, I can’t figure out what’s going on and where 4 came from, and I’m not sure I have a better option than remaking the drawing from scratch at some point, which I don’t really have time to do between now and BWC.
Ben’s June22 Post #2 – Editing old steps
Suppose you’re designing a building at minifig scale. Nothing unusual: green baseplate, rectangular footprint, 1-wide bricks for the four walls. And the color scheme is that timeless classic: multi-colored stripes.
This one’s easier to picture, but I’m attaching a screenshot nonetheless. Each step is a layer of brick, starting at the bottom. So Step 1 is the black bricks (and also the green baseplate), Step 2 is the blue bricks, etc. Experienced BrickLink buyers may notice that I went in alphabetical order using BrickLink color names, in case this helps anybody: black – blue – lime – magenta – orange – red – white – yellow.
But oh no! You’ve done all that in Studio, and then you realize there’s actually supposed to be nine layers, you forgot to put a layer of lavender in between blue and lime. The future of the free world ABSOLUTELY depends on putting this in, and so you need to fix it. The question is, how do you do it?
Between my GBC module and my BFPA project, I’ve been doing quite a bit of design work in Studio lately. The key word here is ‘design’: none of these things are built yet, they’re large and arguably quite complex, and so I’m using Studio to help plan out exactly how they’re going to look, and exactly how they’re going to be built so that they hold together both effectively and efficiently (those parts don’t pay for themselves). So I have a starting idea, and I build from there, but I’m not somebody who can visualize every detail in my head ahead of time, and so I’m making decisions as I go. And eventually, I’m going to reach a point where I realize that in order to make Step 15 work the way I want it, I’ve got to go make some changes in Steps 3 through 5. And what I’ve discovered is, Studio is not really designed for this.
I hate to dis Studio too hard (it’s got a lot going for it and I’m still using it), or the developers who made it, but I can come up with lots of ways to improve it. I do realize that unlike something like AutoCAD, which is an expensive program designed for professionals, Studio is a free program designed for a broad audience, including children. I don’t know if Lego has an official statement about what the intended age range is (if it had existed when I was ten, I certainly would’ve used it then) or how they expected it to be used (this is less likely, I’m guessing they give out the usual cliches about there’s no limit to what you can create other than your own imagination and creativity, which technically is not actually true). It’s also possible that the Studio developers have come up with all kinds of awesome ideas, even beyond the awesome ideas I have for it, but they haven’t been able to implement them because somebody higher up in the food chain decided that the cost of implementing those features couldn’t be justified for a program that’s free to use.
But for quite some time now I’ve had the sense that the programmers expected that people would enter the parts in building order. Either they would already have an existing model, which they’d refer to in order to make instructions for it for other people, or they’d make it up as they go along like you did when you were a kid and you just picked up the parts and clicked them together. But if you’re doing large, complex AFOL projects, this method isn’t adequate. It would be kind of like designing a real-life house, or a roller coaster, or a car, in assembly order. Nobody does that. Or else it would be like writing a finished ready-to-publish novel in a single draft. Nobody does that either.
In my attempts to work around these issues, I’ve made some observations about how Studio likes to operate, and it can basically summed up as: Studio dislikes having parts hidden, it especially dislikes having hidden parts not all be in a block of steps together, and it will turn hidden parts back on for almost any reason it can come up with. In class we learned about Step View – you check the box next to where it says ‘Step view’ above the list of steps, and it turns on. Suppose you have six Steps, and you turn on Step View, and you select Step 3. Steps 1 through 3 are now visible, and Steps 4 through 6 are hidden. Studio is okay with this. But suppose you want Steps 1, 3, 4, and 6 visible, but Steps 2 and 5 hidden. Studio doesn’t like this. There’s really no good way to do it.
For one thing, Studio doesn’t have a way to manually hide an individual step. If there is, I can’t find it. You can hide individual parts, by clicking on the eyeball next to each part as it’s listed in the steps. But it’s always one at a time. Even if you shift-click to highlight a group of parts, clicking an eyeball will still only hide the actual part you clicked next to. And so if you need to hide and unhide possibly hundreds of parts quickly, this isn’t gonna work.
For what I’m building, it’s frequently practical to have a lot of parts in a single step. For reference, think of some of the sets from the modular building series, where they often have you tile the entire sidewalk in just a couple steps. So one workaround might be to turn steps consisting of large numbers of parts into submodels, which can then be turned off with a single click. I haven’t tried that one yet, it seems like there could be a lot of unintended complications in doing it that way. But really, if I could get the developers to implement just two changes, this would be one of them – hide a step with a single click, regardless of what else is going on in other steps, AND it would stay hidden until you manually turn it back on. (And if there’s already a way to do this, somebody please please please tell me.)
Because that’s another problem. Studio loves to turn hidden steps back on. Let’s go back to our striped house. My first idea for solving the problem of the missing lavender parts would be: First go into Step view, and select Step 2. Now the baseplate, the black bricks, and the blue bricks are visible, but everything else is hidden. Now I can add the lavender bricks on top of the blue. But Studio also doesn’t like to add stuff in the middle of the build list, more on that below. For now, we’ll let Studio default to its preferred choice, which is to add the new part to the last step in the list, which in this case is Step 8, and which is currently hidden. The newly added parts will be visible in the model area. And from what I can tell, as long as we stay in the model area, we’re okay.
But suppose that for whatever reason, I click on one of the lavender parts where it appears listed in Step 8. Now Studio says ‘Oh, you’re doing stuff with Step 8, well then you need to see all of it and every single step before it’ and it turns everything back on. Now literally nothing is hidden. I can’t tell you how many times already I’ve had Studio turn stuff on, and most likely everything, when I didn’t want it to. I’ve been trying to get better at avoiding it, but it’s a work in progress.
The next problem is adding new parts to an intermediate step. Studio doesn’t like this either. In the case of the lavender bricks, we don’t actually want them in Step 8. We want to create a new Step 3 and put them there, and let all the other Steps shift down a number. But this isn’t easily done, because, as previously mentioned, Studio defaults to putting new parts in the last Step on the list. There’s an override, but it’s very limited. If I create a new Step 3, and then single-click on it, highlighting the top line, and then select a 1×6 brick from the parts menu on the left, and then place it on the model, Studio will in fact put that 1×6 brick into Step 3. But it’s a one-time thing. If I go select a second 1×6 brick from the parts menu on the left, but this time I don’t click on Step 3 a second time to highlight it, the second 1×6 placed on the model will now revert to being placed in Step 8. You have to do it every single time for each part. In this case, I need eleven lavender bricks, which means I’d need to highlight Step 3 eleven times if I’m going to use this technique.
Additionally, the copy command doesn’t work with this method. If I highlight the top line of Step 3, and the select a part in Step 3 to be copied, I lose my highlighting on Step 3, and the copy will default to Step 8. It doesn’t matter if I hit ‘c’ first and then select the part. (The only way it works is if I double-click Step 3, highlighting every part in the step, and then hit ‘c’. But this only works if you want to copy every single part in the step, something with rather limited application.)
And so, if I could get the developers to implement just two changes, this would be the second one – make it so that the user can manually select a step to be the Active Step, and all new and copied parts go into that step until the user selects a new Active Step, or manually tells the program to revert to defaulting to the last step on the list. (And once again, if there’s already a way to do this, somebody pleeeeeeeeeeeeeeeeeeeeeese tell me.)
I’ve found the ‘highlight Step 3’ technique to not be worth it unless it’s just one or two parts. My workaround is to not even create Step 3. Instead, I create Step 9. I add all the lavender bricks to that Step (cause they’re gonna default there anyway), which in this case Studio will let me do even though Steps 3 through 8 are still hidden. Then I drag Step 9 up and slot it below Step 2. It becomes the new Step 3, and everything shifts down. This method has some drawbacks. Once the steps start to really pile up, it can lead to a lot of dragging and spinning the mouse wheel at the same time, which for me requires two hands, which makes me feel like I look like somebody who doesn’t actually understand how to operate a mouse. That’s another feature I’d like to see: you can bring up a dialogue box for Move Step # to Step #, where you enter the two numbers, and then it does it for you. Again, if this already exists, I don’t know how to do it.
In my design process, I’ve found all kinds of reasons to move steps all around, delete steps, and create new steps at various locations. It gets chaotic quickly, even though you can quickly check a step by highlighting it and seeing what parts are highlighted in the model. My solution for this has been effective, but one that is probably not appealing to most people: I make an Excel spreadsheet listing what’s in every step, and edit it as necessary. It’s worked well for me so far. (For those truly interested, I have just four columns – Step number; description of parts in the step, which can be as general or specific as I want; date the step was last edited; and a column for any additional notes I’d like to add on the step (which you can do in Studio as well, but I haven’t used it). There’s a lot of cutting and pasting as stuff moves around, which is a better method than deleting and inserting rows, which messes up the Step count column.)
Once again, back to our striped house. (Incidentally, I came up with this example because I did something similar in my GBC container discussed in the previous post. After I had almost everything in place that you see in the screenshot, I realized I’d done the recreational math wrong – it involves counting to ten – and that the height of the container was a brick short. And so I had to add the second row of bricks towards the bottom.) The next issue is that after we’ve added our lavender bricks in Step 3, all the other bricks in Steps 4 through 9 need to be moved up. I’ve discovered that this kind of thing isn’t necessarily as easy as it sounds.
For one thing, the lavender bricks and the lime bricks are now occupying the exact same space and are gonna gray out once both steps are turned on. Sometimes moving them up is easy. If I turn on Step 4 and then double-click the top line to highlight every part in the step, I can now grab any part in the step in the model area and drag it, and all the rest of the parts in the step will move with it, maintaining their relative positioning. If it works, I can reposition all the lime bricks at once quickly and easily.
For this example, I actually shifted all the bricks up one step at a time, and it worked every time, although I did have to try a couple of them twice because it grabbed the wrong brick the first time. That’s the problem here: because you have two bricks occupying the exact same space every time, Studio really has no way of knowing which one you want and is just guessing. With the GBC repair, I wasn’t so lucky, for one of the steps, I could not get it to grab the right parts no matter what I did. The solution for that was to create a ‘handle’. I added a new part to the step that’s not colliding with anything so that I can easily grab it, which can be literally anything – in this case the Master parts list had reset to the top, so I chose something from the ‘Aircraft’ category – then when I highlight the entire step, I can use that part to drag the other parts to safety and to their correct spot. Then I just delete the handle.
The second problem I ran into with the GBC (but not the striped house), and is one I’d run into multiple times on other files over the last several weeks and which I haven’t figured out. When the two overlapping steps are both turned on, they’re grayed out. When one step is moved so that they’re both free and clear, they should revert to being solid. But sometimes, for reasons I can’t explain: **** The parts moved out of the way remain gray even though they no longer should be. **** And so that’s my BIG QUESTION FOR THE DAY – if I only get one thing answered in everything I post here, this is it – why is this happening, and how can I manually reset them to not be grayed out? (I do realize there’s a good chance that there’s no answer for either part of this question, but I’m still asking.)
I’ve come up with a few workarounds. If you right-click on a part, there’s a ‘Split’ option. All it does is turn regular bricks and plates into 1×1’s. (I can’t think of any application for this option other than in a mosaic situation.) The 1×1’s will revert to being solid, and then will remain so even when you undo the Split command. But this is a very limited fix. For one thing, you have to do one part at a time. But more importantly, as far as I can tell, Split only works on rectangular bricks and plates. So most parts can’t be split.
Another workaround is to copy the parts. The best way to do this is to use the ‘highlight the entire step’ method, cause you can copy them all at once and maintain their relative positioning. If you copy them one at a time (which I did a few times before I figured out that it wasn’t the way to do it), it’s really not any better than the third workaround, which is completely redo the step from scratch, which is one we want to avoid.
A fourth workaround is to close the file and then reopen it. When you do so, the parts that had been grayed out will revert to being solid. I discovered this one by accident. I don’t know how often I’ll use it, since it’s a bit tedious, but it works.
One of the most frustration things about the Shouldn’t Be Gray problem is that not only can’t I explain why it’s happening, I can’t explain when it’s happening. It doesn’t happen every time. In fact, it doesn’t happen most of the time. It didn’t happen once when I fixed my striped house even though I’d expected it to. So far, I’m not able to detect any pattern or logic to when it happens and when it doesn’t. From my current perspective, it is completely random. In my GBC, the yellowish green panels all grayed out even after they were all safely shifted to the side of the build, which is what prompted me to finally start posting about my various issues with Studio. But it didn’t happen on any other step when I fixed the GBC container.
Back to the striped house. No doubt some of you (‘some of you’ may be wishful thinking, I’m pretty sure the only person who’s going to read this whole thing is Krista) are thinking at this point ‘You know Ben, you could save yourself a lot of hassle and avoid problems like overlapping steps and grayed out parts by simply moving all the upper layers of bricks BEFORE you add the lavender bricks.’ And this sounds good in theory. In practice, there may be complications.
As mentioned in my Pythagorean triple post earlier today, Studio doesn’t like to build in empty space. If you highlight the yellow layer of bricks in the house, and try to drag it directly up one brick, Studio will never put it in the place you want it; when I tried it, Studio tried to put it in pretty much every single possible location except for the one I wanted. I did have success using a guide brick. I moved the yellow bricks to one side, then put a 1×1 brick on top of a white one, and then dragged all the yellow bricks at once so that the correct one landed on top of the 1×1 brick. Then I deleted that brick out, and was able to shift each layer of bricks up one at at time without issue. But I’m not sure this is a good example; the striped-house build is ridiculously simple. In real builds, there’s a good chance you won’t actually know where to move the existing steps to until you have the parts in the new step placed as reference, or even as something to click to.
I think this is as far as I can take this particular example. I do still have a couple of other issues to address, but those posts (which should be shorter) will have to wait til tomorrow.
Ben’s June22 Post #3 – In Praise of Studio
Despite my recent lengthy posts, I still have a couple issues to ask about. They’re not as urgent though, and they might have to wait til after BWC, cause I’m feeling the pressure here. But I wanted to post today because my experience with Studio last night was good, and I wanted to point out some of the benefits of using it, especially since if you’ve been reading here lately, it probably seems like all I do is complain about it. Also, this post can double as an endorsement of ‘If you don’t know Studio yet, you should totally sign up for Krista’s class next time it’s offered.’
I hadn’t really thought about it until today: I’ve been using Studio off and on since last fall to design stuff and make grandiose plans, but until yesterday, I have never actually built anything that I’d designed in the program. I put together what I have so far for my GBC starting container, described a few posts earlier. The experience was good, but not entirely what I’d expected.
For one thing, my design isn’t complete. Such is the nature of GBC. I Was afraid my ramp was too shallow to get the balls to roll adequately, and so the only real way to be sure is to build it and test it, and I thought I’d better do so before I went further on planning the rest of the module. (So far, the balls are rolling just fine, it doesn’t take much.)
I thought I’d just go through the steps one by one, find the parts for each step, assemble it as I went. And mostly that’s what happened, but of course it wasn’t entirely that simple. Once I got started, I realized that the build needed more structural support, and I worked that in. But already having a Studio file made it easier to make changes on the fly, and be confident that they were going to be efficient and fit in properly with the rest of the design. I was, in fact, disciplined about adding my changes to the Studio file as I modified the build (and also making changes to my corresponding Excel file, which really does help). It was slow, but I believe that in the long run, it actually saved me time. There was a lot less trial and error, the file lets me see what parts are there that may be difficult or impossible to see in real life without lots of disassembly, and it also means there was a lot less Lego mess, because mostly I was only getting parts out of the containers when I was sure I needed them.
At some point I realized there was some minor damage to a part on the ramp (I can’t explain it, it should be a new part), and so I had to take it out and replace it with an identical part. Removing that part turned out to be very difficult, and I had to dismantle a significant part of the ramp in order to get it out. Normally, I would’ve had to do it slowly, because I’d have to pay attention to what was coming out from where, so that at the end, I could properly put everything back together again. With the Studio file right there, I could just rip it apart and be confident that my Studio file would guide me in the reassembly, which it did (I couldn’t’ve done it without it). That might sound like I’m stating the obvious, but it’s a benefit that I had failed to anticipate (mostly because I’m the type of person who makes plans then assumes nothing will go wrong).
As previously mentioned, using the Studio file made it easier to not make a mess. I think we all know that one, where you think ‘I need parts A and B’, and then you try it and it doesn’t work, and you toss parts A and B on the table and go get parts C and D, and by the time you’re done building, there’s so many discarded parts on the table it looks an episode of Lego Hoarders. Studio really helped me reduce this (although when I did make changes, I was also more disciplined than usual about putting the rejected parts away).
For the main build, I would advance one step at a time if it was a large step, or several if they were smaller, write down the parts I needed on a 3×5 card, and then go get the parts. (Not that you asked, but right now I have Lego containers in the basement, on the first floor, on the second floor, and in the attic, so I got my steps in.) For the ramp, the steps are generally much shorter. I moved the ramp to its own file to make things easier, and decided it would also be easier to just get all the parts for it at once. I once again started going through one step at a time writing everything down, and realized I’d screwed up the list somehow, and then I realized that I was being a dummy. All I needed to do for that one was open the Model Info window and go the parts list tab, and it’s all right there for me. So that’s a big help too.
Now that I’ve built what I have so far, it’s time to design more. Having it on the desk instead of just virtual is in fact helping me visualize where I need to go with it next. But some of what’s assembled is gonna need to change going forward, and I’m feeling confident that having the Studio file to assist me is going to make it easier, even if again it’s slow going. So we’ll be getting back to it soon.
@bengood921 I’m still working my way through all of the posts and may be able to offer some insight, but I’ve only been able to skim and really want to give it a good read. Life gets in the way sometime! 🙂
My Studio course didn’t get picked up for fall, so I was thinking that if we wanted to do a workshop for those interested in learning more about Studio or anyone who has questions, I’d be happy to do that.
>> I’m still working my way through all of the posts and may be able to offer some insight, but I’ve only been able to skim and really want to give it a good read.
Okay, good to know. I figured even if only one person reads them, they’re still worth posting. They’re not gonna mean much to anybody who doesn’t know Studio. I’m not sure if Renee or anybody else here is reading them or not. But yeah, I figured you’d get to them when you get to them. Although I have to admit, part of me was wondering if I’d finally reached a threshold where even Krista looked at them and said ‘Yeah, I’m not reading that.’
<< My Studio course didn’t get picked up for fall
🙁 You didn’t tell CCAC that I’ve been telling literally everybody that they should take the class?
For anybody not subscribed to the BrickWorld Chicago 2022 thread, I did in fact get my GBC built in time. And despite all my complaints about it, Studio let me do it with a level of efficiency, and minimal mess, that would have not been possible for me without it. Unfortunately, of all the things I build, GBC lends itself the least to Studio, because it requires so much real life testing. For example, I used two motors to power all the parts of my module. Originally, I thought I could do it with one motor, and I designed an elaborate gear train to connect everything. I spent hours figuring out how to do it, designing it in Studio, and assembling it. And then it took me seconds to realize that it was too much strain for a single motor, and I ripped it all out. But if I’d done it without Studio, it probably would’ve taken even longer to reach the same conclusion, and if it had worked, it would have already been in an ideal state because it was carefully planned.
I think I’ve already noted here that Studio seems very oriented towards an end result of making instructions for the build, and we talked a lot about that in class. In this case, I was only making the Studio file for my own benefit. So one thing I wondered about leading up to assembling it: would I need do the instructions side of the file in order to be able to build it? Or could I just build it straight off the model, using Step View? Fortunately, the answer to the second question is yes, which I think saved me a lot of time. (Boring side story: Unfortunately, my Lego room is a disaster right now, so my parts are scattered all over the house. Without the instructions giving me a parts list for each step, I had to just pick them all out in the model, and then write them down on a 3×5 card, and then go collect them all. Which means sometimes I missed one that needed to be on the list, or sometimes I forgot to grab one, and it was an extra trip down and up two flights of stairs. Which might not seem like a big deal, but I happened maybe a dozen times, and by the time I was done building, I had sprinted up and down one or two flights of stairs dozens of times in a 48-hour period. I am not in shape for that. Two days later, when I was driving to Chicago, I stopped at a rest stop and I strained a bit just to get out of my car. And I thought ‘Holy crap, am I so old now that I can’t drive for 8 hours without issue?’ But then I realized it wasn’t that, I still hadn’t recovered from all the stair-running.)
Also for those of you who don’t read the BrickWorld Chicago 2022 thread, my GBC failed in the convention hall. So I’m designing a new one for BrickFair VA, based on all the same fundamental ideas, but hopefully executed better. So I’m back at it in Studio. Mostly I’m redesigning from scratch, but there’s at least a few parts I can transfer over directly, and a lot stuff I can still refer to in the old files when designing the new stuff. One thing that hindered me on this last module was that I had actually built the main elevator back in June 2021 – I’d hoped to complete it for BFVA21, but I set it aside when I realized I wasn’t going to finish it in time. And in June 2021, I hadn’t learned Studio yet (the class was last fall), so I was attempting to integrate sections I had Studio files for with a section that I did not have a Studio file for. It did lead to some complications. At one point I had to follow my Studio steps in reverse order as the only viable option for assembly. So the fact that that particular section is getting a complete redesign is not completely a bad thing.
I’m still doing the Excel thing, which is definitely working for me. One thing that occurred to me just this week: We learned about submodels in class. They’re very useful. As Lego builders who’ve built lots of sets over the years, we have an intuitive idea of what a submodel is. It’s either something that repeats a lot in the build, or more commonly, it’s a section of the build that’s more easily assembled away from the main build rather than assembled in place, and then added to the main build. But I realized that if the Studio file is only for my use, I’m not really restricted by that kind of logic. In previous posts, I complained a *lot* about the difficulty of rearranging steps, turning off steps, editing steps, etc. And I’ve started to wonder if I’ll make my life easier if I essentially turn every major step or groups of steps into a submodel. If I need to make changes later, I can edit the submodel, or release it. This may turn out to be a dumb idea, but I’m gonna try it. So I’ll post the results at some point in the future.
@bengood921 Yes, Renée is reading this, and she would like to know where the video of your GBC is 🙂
I saw my first GBC display at BrickUniverse Rochester and I thought it was awesome.
I expect your proposed use of submodels for major sections will make your life a lot easier. It reminds me of how we used functions, objects and classes when coding large programs back in my programming days.
>> Yes, Renée is reading this, and she would like to know where the video of your GBC is
>
>> I saw my first GBC display at BrickUniverse Rochester and I thought it was awesome.Sweet, I have two readers. I was trying to not treadjack here, so I was only discussing my GBC as it relates to my Studio use. I posted yesterday and this morning to the BrickWorld Chicago 2022 thread, including a link to the BTB GBC video for the event. I also just posted twice to the ‘What is Ben Doing’ thread (although they’ve basically just long-winded ways of saying ‘I have nothing to post right now, but I hope to have something soon’). So I’d check those out.
>> I expect your proposed use of submodels for major sections will make your life a lot easier. It reminds me of how we used functions, objects and classes when coding large programs back in my programming days.
I haven’t done any real programming since 1991. But I do have some idea of what you’re talking about. In the 80’s, I wrote an Infocom-style text adventure on the Apple IIe where the main program was only about ten lines, it just kept cycling through five or so major subroutines that made up the bulk of the program.
One thing I meant to mention in my previous post (it was there and then got edited out), was that on the final day of building, I had to make a bunch of last-minute adjustments to get things to work right, and I no longer had time to make the corresponding fixes in the Studio files. There was no point anyway, they were quick fixes that weren’t meant to be permanent. So I never did make a final file where it showed everything together all at once, and even if I had, it would’ve been missing that major section that was built before I learned Studio. But I didn’t really need it, the sections were designed to be combined easily because I learned way back in 2014 (at the Cranberry Library) that on-site assembly needs to be as uncomplicated as you can possibly make it.
For me, the main benefit to designing in sections is that it makes rotating and panning easier. When I was first learning Studio, I was lamenting that the program frequently attempted to put parts where I didn’t want them and it was frustrating. But at some point, I’d realized that in not that much time, I’d gotten quite good at getting the parts where I wanted them, and it was really just a matter of having the right viewing angle for that particular part on that particular build. And it hadn’t been that difficult to learn, cause I hadn’t thought a whole lot about it. But what it does mean is that panning and rotating are fairly constant, which is fine, but more importantly, they’re unavoidable. You’re unlikely to find a view that works for the whole build and then just stick with it for the duration.
For my BFPA project, I started doing all these major sections in one file. And the problem is, I eventually reached a point where I was working on one small section, but there’s all this more massive stuff off to the side, including a bunch of tall towers, and so when I try to rotate around that one small section, Studio is moving all that other stuff too and it doesn’t rotate the way I expect it. Or stuff just keeps blocking my view of what I want to be actually looking at. That was when I realized I was doing it wrong.
The real reason though that I wanted to discuss building in sections is because during the design of the BrickWorld module, I did combine two sections at a time in a file, because I needed to make sure they lined up properly. And I did run into some problems, and I’m wondering if anybody else has noticed this. I’m also aware that this may be another problem that’s best solved by ‘Hey Ben, buy a new computer already’, but I’m not sure.
I have not done rigorous tests for comparison here, it’s admittedly based on gut feeling from working with various files of various sizes. But here goes: Suppose you have two sections, we’ll call them A and B, and they’re about 1000 pieces each. In the first scenario, they’re designed from scratch in the same file. A is converted to a submodel, but B is left open because we’re still designing it and making sure it lines up with A. We’ll call that file C1.
In the second scenario, you design the same sections, A and B, but in separate files. A is then imported into B, and we’ll call the resulting file C2. At this point C1 and C2 should be mathematically equivalent files. But my experience is that Studio struggles mightily with C2 in a way that it does not with C1. I had big freezing and lag problems with C2. My workaround in file C2 was to release A after importing it, and then delete out all parts not relevant to aligning it with B in order to minimize the number of parts Studio had to deal with. I didn’t work that well though. And actually, I’m hoping the solution really is to buy a new computer, because otherwise I’m not sure what we do about it.
We’ll how it goes with the current GBC project. Importing them all to a master file at the end is still gonna be less important, because it’s a limited number of sections with fairly easy assembly. For my BFPA project, it’s gonna be more important. It’s a much bigger project overall, and that one, like most Lego builds but unlike GBC, has no function other than sitting there on the table and looking good. And so I’ll want to see it all together to make sure it looks the way I want it to, because again, I am not one of those people who can picture things perfectly in their head ahead of time.
So we’ll see how it goes. I need to stop posting and get back to Studioing, I hope to make lots of progress by the end of the day.
Ben’s June22 Post #4 – Renaming Submodels
I thought I was done for the day, but this one has bothered me for a while also, and I just ran into it again. As far as I can tell, there’s no way to rename a submodel once you’ve made it. (As I side note, I also connected to the Studio online help pages, and they’re really bad. They’re questionably written, they leave out all kinds of information, and I found one page that said ‘Coming soon’.)
So this means that you’d better get the name right the first time. I’ve been using very descriptive names, with as much useful info as possible, to help avoid confusion. But if things change and the name is no longer accurate, I have no way to change it. (By comparison, AutoCAD has a ‘rename’ command for exactly this kind of thing.) Option 1 is to live with it. Option 2 is to release the submodel, at which point all the parts in it are automatically highlighted, and you can easily remake it, and give it the correct name at that time. As a once in a while thing, it’s okay.
But it would be a huge hassle if I was in a situation where I had to rename dozens of submodels. I’m not sure how often something like that would ever really come up. But a bigger concern would be if I just want to rename one submodel, but it already appears in the file twenty times. Because once you release one to remake it, it’s unlinked from the other nineteen, and so not affecting them. So you’d have to repeat the process another nineteen times. It seems like there could be a better way. Like a ‘rename’ option when you right-click on a submodel.
Ben’s July22 Post #1 – LDU coordinate system Part 1
I figured some stuff out recently, so I thought I’d post about it in case it’s helpful to anyone, or if anybody has any additional insight or commentary. Some of it may seem rather obvious to some people, but right now I’m wishing I had figured it out sooner, so maybe it’ll shorten the road for somebody else. Also, there might be some mild complaining on my part (this should surprise no one).
In class last year we learned how you can select a part, and when you hover over the minifig hand icon that comes up, you get two options: one for rotation, and one for linear motion. If you select the latter, you can slide parts along an axis, and you get coordinates, which you can manually adjust. Krista probably told us that the coordinates are in LDU, but I couldn’t remember for sure, and even though the result wasn’t going to be surprising, I wanted some kind of confirmation. So I did a quick build test.
A 1x1x1 brick is 20x20x24 LDU. Which means that in Studio, if you put two 1×1 bricks adjacent to each other, two of the numbers in each set should be the same, and the third pair should differ by 20. If you stack a 1×1 brick on top of another one, again two of the numbers in each set should be the same, and the third pair should differ by 24. And that’s the results I got. (I also discovered that a baseplate is half a plate in thickness, which I somehow never knew. It was always some mysterious random amount to me.)
The coordinate system isn’t without some curiosities and complications that are, at least to me at this point, typical of Studio. When you open a new file, they give you that fake refence grid, the one of 2×2 squares, so there’s a clear ‘up’ and ‘down’ right from the get go. And when I put down a white baseplate, it did give me a vertical number of zero. But that’s where things like logic and common sense ended. Two things in particular stood out:
1) I think of the ordered triple that Studio gives as the coordinates for each part as X, Y, and Z. And like a lot of people, I think of Z as the vertical number. But Studio doesn’t do it that way. Y is the vertical number. I can probably get used to that pretty quickly. (Rachel told me that MineCraft does it the Studio way also.)
2) But what I found much stranger is that when you build ‘up’, the Y numbers go down. In fact, if you place a 1×1 brick right on the starting grid, because it’s measuring from a point in the middle of the brick, your Y number is already -14. Put a brick on top of it, it’s at -38. I don’t have any explanation for that.
I don’t have any way around it either. This is veering into a separate issue, but unlike other 3D programs I’ve used, Studio doesn’t always let me freely rotate the model around to any view I want. From what I’ve seen, it really wants you to keep the up side up in the view, and seems to deliberately force me into that perspective. Because sometimes I’ll be rotating, and I keep rotating, but the view doesn’t keep rotating, it starts going the opposite way. It can be very frustrating, and either I don’t have a workaround, or I have to come up with some creative ones. It’s arguably one of the program’s biggest shortcomings.
I finally got around to sorting out the details of how the LDU coordinates work because of Technic parts, especially the axles. When it comes to clicking together bricks and plates and other things with studs, Studio is generally good at lining them up properly at one-stud intervals, because in real life, that’s your only option. With axles, it’s more complicated. Because the bricks, beams, gears, bushings, etc can slide freely on an axle, Studio lets you do this also, even though the vast majority of the time, you’re still thinking of the axle in one-stud or half-stud increments, and placing your parts accordingly. Studio has some ability to click the pieces into place on one-stud increments, but it’s a lot fussier than it is with bricks and plates. The most problematic example I can think of is as follows:
Imagine a red 2×2 brick. On top of it is a blue 1×2 brick that holds an axle, so that the axle extends over the other half of the red 2×2 brick. You want to add a yellow 1×2 brick, with a Technic hole, on top of the other half of the red brick, so that it both clicks down on the red brick, and has the axle extending through it. This is easily achieved in real life, although you’d assemble them in a different order. But in Studio it’s a problem, because it sees the axle, sees the Technic hole in the yellow brick, and so it lets the yellow brick slide freely on that axle, even though this couldn’t be done in real life because the studs of the red brick are in the way. I have had little to no success in similar situations, getting the yellow brick to click to the red brick without being a little bit off.
I’ve had a similar problem with the angled axle connectors, the ones numbered 1 through 6. Suppose to you put an 8L axle into a #1 connector. The #1 connector can take 1L of the axle into it, leaving 7L exposed. In real life, you’re gonna push it the whole way in every time. But because you can, in fact, if you really really want to, slide it freely so that it could be part way in, in any amount you want, Studio lets you do this. And again, sometimes it clicks into place the way you want it, but often it’s a little bit off, and it’s hard to get it just so. And additionally, I’ve had situations where no matter what angle I put the camera view at, Studio struggles to recognize that I’m even trying to put the axle into that particular connector.
It was a big problem a couple weeks ago when I was designing GBC ramps using the connectors and axles (I ultimately came up with much better ramps that don’t use them). More recently, I put a giant Technic cube into Studio. I’ll do a separate post on it when it’s done, including screen shots and photos. For now, it’s a 9x9x9 cube made entirely of #2 axle connectors, and 3L axles to hold them together, to form a grid that overall makes up a big cube. The edges are made up of #1 connectors and blue axle-pins. There’s no other parts in it. The total part count is close to 10000.
I made the 9x9x9 cube more than five years ago, and put it on display with my GBC, starting with BWC17. I still have it, so the design is not in question. But I think I may finally have enough parts to expand it to 10x10x10. Since it’s only four types of parts that form a simple, but finite, repeating pattern, I can (and have) simply done the math by hand to come up with the parts total. But now that I know Studio, I figured I would put the 9x9x9 version in, read the inventory off the Model Info, and then expand it to 10x10x10, and compare the new inventory list to the old one. I thought it would be easier to do it this way. Maybe.
Because of the aforementioned problems with axles and connectors, my 9x9x9 cube has a *lot* of grayed out parts. Some it’s hard to see why, and some are clearly not lining up. Some of the ones that aren’t lining up, it’s easy to see what’s going wrong, and for some of them it’s like some Escher paradox, they look like they should be lining up and I can’t figure out why they’re not.
(As an aside, it’s worth noting that this project also brought up issues raised in my previous post about renaming submodels. Because it’s a repeating pattern, the Studio file is heavily submodel-based. In the 9x9x9 version, there’s submodels with names like ‘Row of 9’. When I started the 10x10x10 version, it quickly became clear that the easiest way to do it is to edit the 9x9x9 version submodels, without releasing them. But it results in things like a submodel that’s a row of 10 parts, but is still named ‘Row of 9’.)
I haven’t gotten far on the 10x10x10 version, and might not be able to get to it for several days. I had left all the grayed out parts in the 9x9x9 version, because the real point of it was to get an inventory count, so it didn’t matter if it was perfect or not. But once I got going on the 10x10x10 version, I discovered that there’s axles missing in the 9x9x9 version. And the reason is – because of the axle and connector issues discussed, it’s easier to put the connectors in place first and the axles second, even though you can’t do it that way in real life. But it also means that you can’t see the axles as soon as you put them in place, which means it’s easy to accidentally miss some, which I did at least once, which is making my inventory count inaccurate. So I started thinking about ways to clean up the file.
And that takes us back to the LDU coordinates discussed at the beginning. It occurred to me that if I know what coordinates a part is supposed to be at, I can check them, and if they’re not correct, manually adjust them. It’s gonna be pretty tedious, but I also think it’s gonna work. It means I’ll get good at multiplying by 20 and by 24 in my head. I’ve found that the coordinates are not always easy to edit, or even read. Sometimes the part or the X-Y-Z arrows are blocking part of the first number. As the numbers increase in digits, the physical size of the numbers get smaller, instead of expanding the display area. They insist on including a decimal point and a trailing zero, even though it’s hard to imagine you’d ever need half an LDU, although I have had such numbers appear in the past.
The other issue with the coordinate system is that Studio is measuring from an arbitrary point on the part. As far as I know, there’s no way to choose it yourself, or manually adjust it. It’s kind of sort of the geometric center of the part, but with the 1×1 brick, it looked to me like the vertical location of it is somewhat towards the top – specifically, 14 LDU from the bottom and only 10 from the top. I’m hoping this won’t create any problems, parts that are lining up will, as far as I’ve seen, have numbers that line up along that axis. If you make stuff into a submodel though, it complicates things, cause now you can’t get coordinates for the individual parts, only for the entire submodel, which again, is basically going to be the geometric center of something that might be very complicated, so who knows how things are going to line up at that point.
If you right-click on a part, there’s two options at the bottom of the menu that comes up: ‘set as origin’, and ‘reset origin’. I’ve tried both of them, and I haven’t been able to get them to work. I would think if I did ‘set as origin’ on a 1x1x1 brick, its coordinates would become 0,0,0, but whenever I did it, there was no change. And so ‘reset origin’, which presumably puts it back to some predefined spot where it started when the file was created, didn’t do anything either. My parts had the same coordinates no matter what I did. This one is less of a big deal, since in Studio files it’s all relative, but the lack of control still makes me uncomfortable, and is less than what I’m used to.
I also noticed that we’re still on page 2 of the Studio thread on this website, despite all my posts. That’s making me think that WordPress is going strictly by number of posts. I had always thought it was by cumulative length, but I’m starting to think that that’s not it.
Ben’s July22 Post #2 – LDU coordinate system Part #2
There’s been some developments since part 1, even though progress on the Technic cube is almost zero. But I wanted to post, because it inclues a Big Discovery, although it’s possible that this is also one that Krista told us in class and I just didn’t remember. And in fact, I might be telling everybody stuff they already know. But it was a big breakthrough for me.
In my previous post, I claimed that the handle for each part seems to be in approximately the geometric center of the part, but also seems a little arbitrary. I specifically cited the 1x1x1 brick as having a vertical coordinate adjusted slightly towards the top. It turns out that neither of these claims are correct.
From what I can tell:
1) every single handle position is determined by taking each of the X, Y, and Z distances from one side of the part to the other, and choosing the midpoint.
2) When determining the extreme edges of a part, Studio will always include the studs. (You can thank Rachel for suggesting to me that this might be the case.)That means that the vertical distance for the handle of a 1x1x1 brick is in fact centered. For that particular brick, we consider the height to be 24 LDU. So I expected the Y-value to be 12, and was surprised when it was 14. But we also know that the height of the studs is 4 LDU. That gives an overall height of 28 LDU, and if you do the recreational math and divide by 2, you get 14. Everything works out now.
So I was confused when I was checking to see if my #1 connectors were lining up properly in the cube. They certainly looked like it, and they all had the same Z value, but it was not what I was expecting. It was off by .5 LDU. And so I did a check where I placed a #1 connector over a 2×1 brick, and then did a top-down view so I could see exactly how they line up. And sure enough, one end of the connector lines up with the edge of the 1×2 brick exactly, and the other is just a bit short. So as far as I can tell, it has a length of 39 LDU instead of 40. I might have to do another check to make sure it’s not 37 LDU.
So that got me wondering, if they’re simply dividing the X, Y, and Z values by half, what happens if the handle is not actually on or in the object? Will Studio make an adjustment? Or will it let the handle float in empty space. I wasn’t surprised to discover that it was the latter. The easy piece to test on is the 4×4 plate with a 2×2 cutout. The expected handle location is in the center of the hole, and that’s where it is.
Finally it got me wondering about the other angle connectors, specifically, numbers 3, 4, and 5. Because they’re angles that don’t traditionally fit the Lego grid (157.5, 135, and 112.5 respectively), they’re going to have irregular X and Z values, and a seemingly random handle. And that’s confirmed as well, including X and Z values that include numbers after the decimal point other than 5.
I got into it more in part because Rachel and I were using the Model Info window to try to get more information on specific parts. Model Info, as we learned in class, gives us the overall dimensions of our build in studs, inches, and centimeters, in all three directions. (Measuring studs vertically seems a little lazy on their part, since you’re much more likely to be concerned about the height in bricks, but you can easily convert from studs to vertical bricks by multiplying by .8333333.) Since you can convert from studs to LDU easily enough, as well as from centimeters to LDU, you can simply open a new file, put a single part in it, and read the model info to see what Studio considers to be the overall dimensions of the part.
We did it because Rachel had read somewhere – she thought maybe in the ‘illegal build’ presentation that Krista sent us – that a tile actually has slightly less height than a plate (not including the studs). We thought we could feel it a little bit when we put the relevant parts next to each other. But Studio doesn’t make that distinction. It considers a plate to be 12 LDU in height (8 for the plate, 4 for the studs), and a tile to be 8 LDU.
We did something similar for the boat stud. Rachel thought it had a height (again minus the studs) of slightly less than a plate. That one was easier to confirm. If you put a stud under a plate, and then support that plate on either end with other plates, and rest the whole thing on the table, you can see that the boat stud is not actually touching the table, it’s easy to see light coming through from behind it. But again, Studio isn’t interested in all that. It considers a boat stud to also be 12 LDU in height, just like a plate.
Hopefully that’s all clear. I considered posting some screenshots to help clarify things, but I find going through that on my laptop way less fun than doing it on my desktop. I can post pics if anybody really wants them. In the meantime, I will be back to working on the Technic cube.
LDU coordinate system Part 2 – PS
Ooh, but I forgot to mention… there’s a serious limitation to using the Model Info to determine part size. Namely, Studio rounds everything to one decimal point. (The exception is for ounces, where they use three decimal points.) I no longer remember the specifics (even though it was 24 hours ago), but we had a situation where we determined the total length in centimeters must be .48, but Studio gave it to us as .5. So you do have to take all those numbers with a grain of salt.
I’m doing another check on the #1 angle connector. It’s the same problem here. It does list the width, in studs, as .9, because it’s also not quite as wide as a brick. But it still lists the length as 2.0, even though it’s clearly not. But I think the length is actually 1.95 studs, and Studio is rounding up. I’ll have to use relative coordinate positions to nail that one down for sure.
I also noticed that we’re still on page 2 of the Studio thread on this website, despite all my posts. That’s making me think that WordPress is going strictly by number of posts. I had always thought it was by cumulative length, but I’m starting to think that that’s not it.
There’s always 25 posts per page. It can be a handy fact if you want to make sure a post sits at the top of a page.
Interesting that the coordinate system is the same as Minecraft. I had a bit of trouble getting used to that one back when my daughter and I would play it after school. Maybe it’s a European convention?
>> Interesting that the coordinate system is the same as Minecraft. I had a bit of trouble getting used to that one back when my daughter and I would play it after school. Maybe it’s a European convention?
Sweet, so you really *are* reading my posts 😀 😀 😀 Rachel watches (mostly listens to) a YouTube channel called ‘Ask a Mortician’, where she talks about death in a fun, whimsical way, with a focus on history and current events. Recently we watched one that she calls ‘Everybody’s Asking / No One’s Asking’, where in the first half she answers a question that a lot of viewers have written to her about, and in the second half she discusses a topic that she wants to talk about even though she’s aware that it may not be of interest to a lot of viewers. I suggested to Rachel that my Studio posts could be called ‘No One’s Asking / No One’s Asking’.
The ‘European convention’ is an interesting idea, we hadn’t thought of that. So shortly after you posted, I did a Google search to see if I could confirm it. The results were disappointing. I found a lot less on it than I’d expected, and – and this may shock you – there were some comments about it on Reddit where the people were very vocal and opinionated but not actually informed. So I wasn’t able to confirm it, but I certainly didn’t disprove it either. Maybe somebody can get better results than me.
I don’t have any new updates on my Studio projects. (It’s been a busy couple weeks and we’re currently traveling for a wedding.) I hope to make good progress after I return to my house on Monday.
>> There’s always 25 posts per page. It can be a handy fact if you want to make sure a post sits at the top of a page.
Yeah, I clearly wasn’t smart enough to figure that out. Rachel was amused by your ability to game the system though.
From June 24, 2022:
>> Yes, Renée is reading this, and she would like to know where the video of your GBC is
>
>> I saw my first GBC display at BrickUniverse Rochester and I thought it was awesome.I just posted two videos to the ‘What the heck is Ben doing’ thread, I don’t know if you’re subscribed to that one (it’s also full of unnecessarily long-winded posts). The full BTB tour of the event has yet to be posted. I don’t wanna post the video links here cause I want to keep everything as Studio-related as possible here.
The short version, for those of you not following my thread or the BrickFairVA 2022 thread, is that for the first time ever, I had a module that worked and worked well. And Studio made a big difference, I’m not sure I would have made it without it. The module was just too complicated to have been designed and built otherwise. After my failure in Chicago, the module got a redesign, and it turned out to be a much more significant undertaking than I’d expected. The majority of the old one was disassembled as soon as I got back, but because I had pretty accurate Studio files of it, I could refer to them when designing the new one so I could decide which parts to keep, which parts to modify, and which parts to completely redo. It was a big help. Like in June, once we got close to deadline, I started making modifications without updating in Studio or the associated Excel file (and it’s much worse in my AutoCAD file, which is a huge mess). But the Studio file for this one is still pretty darn accurate, and will be the starting point when I start planning for next year.
I’m not sure if I’ve mentioned this before, but one thing I started doing shortly before BWC was marking certain BL categories as favorites over on the left side. We learned about this in class. We’d also learned about making your own custom parts palettes, and at the time, I was super excited about that and thought I would be using it all the time. But I’ve found it to be less useful than I’d expected, and in fact have yet to successfully come up with a truly helpful palette. In June, I noticed, not surprisingly, that my building was dominated by just a few categories – bricks, plates, slopes, Technic, and tiles. The BL categories are listed alphabetically, and the last four on that list are close together, but it was a lot of scrolling up and down to get to the bricks. Finally, shortly before BWC, I wised up and clicked the star for a bunch of them, so that they automatically appear at the top of the list. I should have done it sooner, and I recommend it for anybody who’s considered it but hasn’t tried it yet.
You can also set BL categories to be Hidden. I did a lot of that too, and if you do end up needing them, going to find them and/or bring them back is easy enough. But the real breakthrough for me was the favorites list. Studio puts the favorites at the top in the order you’ve selected them. Seriously, that’s it. It is helpful that they don’t force the favorites list to be alphabetical, so you can prioritize the order of the list as you like. But strangely, they don’t let you drag them to reorder them. If you want to change, for example, the second item on the list, you have to delete them all off except the first one, and then redo them all (and if there’s a better way to do this, please tell me, because I couldn’t figure it out). In June, my list started out organized, but as I went along, there was ‘Oh I forgot about this one’ or ‘I need that one after all’, and so the end of the list was a little more convoluted. After I got back from BrickFair, I deleted them all out and redid them with better planning.
Once you set your favorites, Studio remembers them and they stay in place every time you open the program until you manually change them. Which is good, because if you had to redo them every time you opened the program, it would be awful. But it doesn’t, as far as I know, let you attach different lists to different files. Which might be helpful, although it would essentially require you to make some templates so you’re not redoing the favorites every time you start a new project. For my GBC, you may not be surprised that I had a lot of Technic categories starred. Now that I’m back and working on my BFPA project, I am hardly using Technic parts – I starred a few of the categories, but they’re last on the list and I have yet to use any of them, although I expect that I’ll need at least a few eventually. I went from the beginning of June to the beginning of August doing nothing but GBC. I don’t expect to return to GBC until November. So it hasn’t been a problem yet. But if I start flipping back and forth between GBC and non-GBC files all the time, it’s gonna be a hassle to keep reordering the faves list every time. I’m not sure if there’s anything I can do about that.
I have not worked on my grid cube file, discussed in posts in mid-July, since making those posts. I thought it would be a fairly quick design – and it probably will be now that I’ve figured a few things out – but I ended up having less time to work on it while I was traveling than I’d expected, and once I got back to my house, it was all GBC all the time until BrickFair. And now that I’m back, I’m planning for BFPA and I don’t wanna take time to do the grid cube until I’m sure I’m gonna be ready for the September convention. But it’ll get done at some point. The LDU stuff that I discussed in previous posts has continued to be helpful though. On my GBC, it helped me line up gears and axles and bushings when Studio struggled to put them in the right spot.
Since BrickFair, I’ve been working in Studio on my project for BFPA. I’d started working on it in May, before I had to switch over to GBC. I’m definitely taking Renee’s advice and breaking the sections into as many separate files as I can, instead of designing a whole bunch of different sections at once in one giant file. The master file I created in May is a huge disaster and I’ve abandoned it except to copy stuff I want to keep into other files. The landscaping is to be 27 MILSed baseplates (designed specifically to fit an eight-foot banquet table) and in May (and also last fall on a separate project) I was doing the entire landscape in a single file. But there’s really no need for that either. The landscape is designed to break down into 2- and 3-baseplate sections for easy transport and storage, and I already know how they’ll fit together cause I laid out a 2D version in AutoCAD, so there’s no need to put them all in one file together until the very end, to make sure they still line up the way they’re supposed to.
Ben’s August 2022 Studio post #1 – Studio is better than it was, I think
So in June and July I specifically did a lot of whining about two topics, both of which are now, as far as I can tell, fixed to my satisfaction. Studio has updated several times this year. I’ve lost track of how many times (and because I never update my laptop and desktop at the same time, it gives me a false impression that there’s been twice as many as there really has been), but I’m pretty sure it’s two or three this year, and at least once in the past two months. I always look at the list of what’s being updated, but it’s mostly technical stuff about bug fixes, the details of which are far beyond my understanding. Sometimes there’s changes to the program in the form of additional or improved features, but they’re also often described in such a way that I don’t really know what they mean by them. (Edit: it also just occurred to me that there might be a record of all that stuff on the website that anyone can view.)
1) At some point I went on a big tirade about parts colliding, being grayed out as a result, and then remaining gray even after the collision had been resolved. I discussed workarounds at length. Recently, I thought it was happening again, but I realized it actually wasn’t after I found and removed additional parts contributing to the collision. And that made me realize that it’s been quite a while since I’ve seen it happen, despite the fact that there’s been plenty of opportunities for it during my use of the program. And while it may be premature, it’s making me wonder if they were aware of it and they fixed it. Since it was definitely happening before and I’m confident it wasn’t any kind of user error, I’m thinking that it’s the best explanation. Until I see it happen again, I’m considering it resolved and done with. Sweet.
2) As recently as mid-July, I was complaining about the fact that submodels can’t be renamed. I haven’t had time to thoroughly go back and check the thread for what was discussed about it, but I mentioned it multiple times, and I found an older post where Krista suggested a workaround for it, although unfortunately it was of limited application.
A few days ago, I discovered that the program has a rename function. And now I’ve been second-guessing myself as to whether or not it’s a result of a recent update, or if it’s been there all along and I somehow just missed it. But unless I missed something on the thread, nobody else has pointed it out to me either. One key thing I only recently noticed is that if you right-click on a submodel in the design space, the menu that pops up as a result is different from the menu that pops up if you right-click on that same submodel where it appears in the Step View list on the right. Only the Step View menu has the rename option.
So I don’t know if I missed it all this time because I was always right-clicking on the submodel in the design space in an attempt to find it, or if it’s the result of a recent update to the program. If it’s the former, it still represents a big oversight on my part, because I’ve been right-clicking on parts in the Step View list all the time ever since Renee (I think) pointed out that there’s a ‘move to’ option for shifting parts around (which, as an aside, has been helpful, but still can involve a lot of scrolling once the number of steps reaches a certain number, and is still not as good a solution as the Active Step feature I at one point declared to be the most important improvement I’d like to see made to the program). And in fact that’s how I noticed it, I was moving a part, right-clicked on it, and I saw ‘Rename’ right there on the screen, and then the clouds parted and the sun shined down and the angels sang.
My next question was – if there’s multiple copies of a submodel in the file, and I rename one of them, will it rename them all, or will it unlink the submodel from the rest of them, and only rename the one? So I did a test, and fortunately, the answer is that the program specifically gives you the option to do either one, and asks you which one you want to do. I did successfully get it to rename eight copies of the same submodel all at once. So that’s a big win for me.
I do have some thoughts on editing submodels, now that I have a lot more experience with it. That’ll have to wait until another day though, cause it’s bedtime.
In my last post I discussed the problem of parts staying grayed out even after the collision has been removed, and stating that I thought it most likely that the problem had been solved. Apparently I spoke too soon, I ran into it again tonight. Bleh.
Ben’s August 2022 Studio post #2 – Importing files
I started typing up my ‘Editing Submodels’ post on Saturday morning, but I didn’t finish it before it was time to leave for the party on Saturday, and I haven’t done any submodel editing since then. So that one is on hold. Instead I’m going to talk about importing submodels, and I’m doing it now in part because I just reached a good pause point in my Studio work and I really need a break from it.
At some point I vaguely recall complaining that when you import a model into the file you’re working on, where the imported model actually appears in the model seemed rather arbitrary to me, and it was a difficult to work with. Part of the problem here is that I’m used to AutoCAD, where when you insert a block, it will always ask you where you want to put it, and you can type in coordinates, and you can click on a specific spot to locate it. But I finally figured out that in Studio, where an imported model comes in is not so arbitrary after all. I might be stating the obvious here, and maybe we learned it in class and I didn’t pick up on it, but it took me way too long to figure out, and so a big motivation for this post is to potentially save other people some time and effort. It turns out that: An imported model will appear in your file at the exact same LDU coordinates as it appears at in its original file. So, for a simple example, if your imported file is a single submodel, and the handle for the submodel reads 0,0,0 in the file where it was created, then that submodel will appear at 0,0,0 when you import it into another file.
This is super useful to know. I figured it out while I was doing the GBC redesign in July. For both the BWC and BFVA designs, I made the gearbox assembly at the bottom of the tower its own file, and then imported it into a second file and built the rest of the tower on top of that. I can’t really articulate a good reason why I decided to do it that way, but that’s how I did it. The idea was that I had the bottom portion exactly the way I wanted it and it wasn’t going to change, and so it was easier to have it into a submodel so it’s just a single step. But I still kept it as its own file, juuuuuuuuust in case I needed to change it after all, which it turns out I did multiple times. I would change the original file, remake it into a submodel, and then in the working file, I’d delete out of the old imported file and import the updated version. In June, for whatever reason, after importing the base of the tower, I moved it before building on top of it, and so every time I brought in an updated version, it would be in the wrong spot, and there was more moving stuff around and it was a big hassle. When I did the July version, I figured out that I should leave everything where it was, so that when I imported the updated model, it would pop right into place where it needed to be. It was great, high five.
For BrickFairPA in September, I am bringing a minifig scale display that sits on 27 baseplates – 9 wide and 3 deep, to cover an 8-foot banquet table. For transport purposes, they break into 10 sections of either two or three baseplates per section, the design for how they go together is somewhat irregular. In the past, I had started on landscaping for various projects by laying out all 27 baseplates in a single file, but this time I took Renee’s advice and made ten separate files, one for each section. But I also still wanted a master file, so I could make sure they all look the way they’re supposed to put together, and more importantly, it gives me a total part count all in one location (so I don’t have to open ten files and then do the math), which is important because there’s certain pieces I know I don’t have and I need to BL them and now I need to do it soon so they have time to arrive and I have time to assemble them, and I need to make sure I’m ordering enough.
I created all ten files plus the master right away and started laying down parts. At some point in the process (early on, but not at the very beginning), I realized that I could import all ten files into the master, position them in their relative spots, write down all the coordinates for each submodel, and then reposition each model in its individual file to line up with those coordinates. That way, as I continued to import updated versions of each one, they would automatically appear in the correct spot in the master. Using a pen quickly got cumbersome, so I ended up making an Excel sheet for all the coordinates, and it took longer than I’d expected. But it worked. One thing I finally did was set Section 1 to 0,0,0. I’d hesitated to do that until now, because it didn’t make sense to me to have the center of a baseplate be at 0,0,0, because it then means that the actual bottom left corner (which is what you’d set to 0,0,0 in most situations) is in negative territory. But I quickly realized that since it’s all relative, it doesn’t really matter. What did matter is that if I knew Section 1 was at 0,0,0, and I knew that the on-center distance between baseplates is 640 LDU, it became pretty easy to check the math and make sure I got all the numbers right and that everything’s where it’s supposed to be. My first pass was without using 0,0,0, and it was a bit of a logistical nightmare and stuff kept getting messed up.
Unfortunately, I’d already started putting plates on top of the baseplates before it occurred to me to implement this plan, and it turns out the rotation was wrong for each section based on how I was adding parts to them, so almost everything is imported at 180 degrees rotation, because to fix it would have required redoing a lot of parts already placed. It would’ve been nice if they’d just all been zero, but now it’s at a point where it doesn’t matter, they’re coming in correctly every time without any effort other than remaking a file into a submodel every time it’s time to import it again. It did occur to me while I was typing this post that I could possibly correct the problem by using the ‘Copy & Mirror’ function, assuming I can get it to mirror in the right direction, which presumably I can.
The fact that the submodel coordinates are always halfway between the most extreme points of the submodel along each axis was a hassle too. When I finally assembled the master, most of the sections had a single layer of plates on them and so the submodels were all the same height, but a couple had nothing on them and therefore were a different height and came in not lined up vertically with everything else. Doing the math would have been easy so that I could manually adjust them, but at that point it sounded exhausting, and so I found it easier to stick orange temporary plates on those sections to get them to line up. The moral of the (boring) story is that if you’re gonna do something like this, set it up at the very beginning, not after you’ve worked on it for a couple hours, you’ll be glad you did.
As a bonus observation, I noticed in the past week or so that when you’re working on a file, on the tab at the top where the file name appears, they put an asterisk on it once you make a change to it since the last time you saved the file. In other words, it’s reminding you that you need to do a save if you don’t want to lose the changes you’ve made. As soon as you hit control-S, the asterisk will disappear, and after that, as soon as you make a single change (which could be adding a part, removing a part, adding a step, creating a submodel, etc, although simply panning or rotating the view does not appear to trigger it), the asterisk reappears. It’s a nice feature, and since I just noticed it, I’m not sure if it’s the result of a recent upgrade, or if it’s always been there and I just wasn’t very observant. To my knowledge, I don’t have any other programs that do that; I checked Excel, and I have an up-to-date version, and it doesn’t do that. In school, frequent saving was drilled into us and I have a habit of saving way more often than really necessary, but I’ve found the feature helpful. Especially after I’ve converted an entire file into a single submodel, it has this feeling of ‘Okay you’re done now’, but then the asterisk reminds me that I still need to save it.
Incidentally, I’m finally getting good use out of the Model Info in Studio. It turns out that I am really great at underestimating how many of a part I will end up using, or how many I have used. For example, I tiled my water using trans-light blue tiles, and I have tons of 1×2’s and 1×4’s cause we’ve LUGBulked them more than once. But I had exactly three 1×1’s (courtesy of the Joker Manor, thanks Santa 2017!). So I added 93 of them – which was all the store had – to one of the BrickLink orders that was delivered to me at BFVA, and I didn’t worry about adding more to another order because I figured that 93 was probably about twice what I would end up actually using once I laid it all out. Now that that portion is entered into Studio, I can see that the actual number of 1×1 tiles I used is 304. Which means that I have to order more, and it turns out that the best option in the USA is a guy who also delivered to me at BFVA, and so if I’d planned ahead better I could’ve had him bring them to me then, instead of what’s going to happen now, which is that I’m going to have to pay to have him ship them to me. I have a similar (boring) story for another dozen or so parts on the list. It’s made me realize that expanding this build in the future (which is definitely the plan) will be more difficult than I’d thought, because I’m going to run out of part sooner than I’d thought.
Bonus stat, the current part count for the landscape – which is not actually done, it’s just done enough that I can start ordering parts – is 6215. Fun stuff.
I had a very satisfying Studio experience last night and today.
During May and August, I’ve put in a lot of hours in on Studio designing my build for BFPA. It is twenty-seven 32×32 baseplates (arranged 9×3) that will be landscaping for a minifig-scale display. There will also be buildings, which I’ve also been working on in Studio. Eighteen of the baseplates have at least some water on them. First there’s a layer of tan plates put directly on the baseplates. Then a layer of clear 1×1’s and 1×2’s (LUGBulk 2022 participants may be aware that I ordered 5800 of the latter), and finally a layer of trans-light blue tiles on top (which we’ve also LUGBulked multiple times over the last several years). Then the rest of the green-grass landscape will be MILSed around that.
Despite doing weeks of design work on Studio, I did not click two parts together until last night. I got out the baseplates, and I got out the bags of clear plates. Then I wrote down all the tan plates I would need on a 3×5 card. It was easy to do because I’d made my master Studio file of all ten landscape sections. I opened the Model Info, sorted the inventory by color, and scrolled through the tan and noted the number needed for each type of plate. I didn’t do a count, but it was at least several hundred parts of maybe twenty different types, ranging from 1×1’s to 16×16’s*. Then I went to the tan containers downstairs and collected the parts. They filled up most of a gallon bag, with the largest ones in a second bag.
I used Step View in Studio in the design space to build each section, just like I did with my GBC. For each section, I did the tan plates, and then the clear plates, and then moved on to the next section (I haven’t done any tiles yet). So when I got to the end of section 10 this afternoon, it meant that when I got to the last step of tan plates, the parts required in that step should be the same as the remaining parts in my bag of what had been hundreds of parts. Would it work out? Would there be a screw-up somewhere along the way? The suspense! And behold… it totally worked! And it was sooooooooooooooooooooooo awesome. High fives all around. Studio is great.
I might post a progress pic later tonight, either to the Ben thread or the BFPA thread so people will have an idea of what’s coming. We’ll see.
* Just as I finished typing this post, I saw that the 3×5 card is in fact sitting right here on the desk, so I went ahead and ran the numbers. It’s 19 types of part, for 369 parts total. So my estimation powers didn’t let me down on this one.
- You must be logged in to reply to this topic.