mfeldt

This! And if I really could dream - availability of all the parts in Ldraw in all the colors you could think of...

Indeed, the coordinate fields do the trick, thanks. I noticed it's also helpful to place the part flat on the grid and make sure the edges coincide with actual grid points. Then, the numbers in the coordinate fields usually have to be nice and round, 9.475 or the likes. It's a bit strange however, that when moving connection points by mouse, part designer apparently prefers to snap at such odd numbers...

Has anyone used the part designer for stud.io? I find it a pretty interesting and potentially powerful addition (even though it's a bit ridiculous to have to "design" parts that have been in LDD for a decade) to stud.io, But I can't figure out how to use it properly. So far I've simply been importing unofficial ldraw parts and tried to add connectivity information, which is indeed a great possibility! However, the part designer would let me move the connection points only by rather chunky steps, so they cannot be adjusted properly to match the actual holes and snaps of the parts...

Simply sprayed the brown Lego triangles with a glossy gold paint...

Small video...

Back in 2017 Andrijan94 posted a model of the JWST on Lego Ideas. He was so kind to give me the LDD file (an older version than the one now shown on ideas), and it took a while but now....: The LEGO space agency LESA was able to beat NASA when building their JWST copy! In fact, the Lego Brick Space Telescope was already secretly launched, although mysteriously it missed the orbit entry and is now flying in some office space deep in a forest near Heidelberg in Germany:

Not ideal, but as an intermediate solution - what about part 6575? https://www.bricklink.com/v2/catalog/catalogitem.page?P=6575#T=C

I've played around with studio 2.0 recently, attempting to generate some instructions, but it still feels like alpha stage software. I'm running under wine on Linux, where LDD does an excellent job. Studio is dead slow, incredibly heavy on the CPU even if doing nothing, buttons that can be clicked but show no effect... unusable for anything productive.

Interesting - doesn't seem to work for my current model, the "download result" remains grey. Any way to gather useful information what's wrong?

So far I found stud.io way more resource hungry than LDD. It's actually hard to get it work reasonably on hardware ~5 years old. Plus it cannot handle LDD groups when importing -> no incentive to switch.

I did. You can find the new version on Github. It's handling lxf just the way as it does lxfml, and additionally it checks that there are no un-grouped parts in the file! It's now however much less elegant and readable, so next I'll do some refactoring before proceeding to reporting *which* parts may be un-grouped by changing their material to something really rare in the output!

OK.... thanks for the feedback! I didn't see the lxfml as a problem so far since LDD reads and writes these directly - no need to unpack or repack anything! The zip step wouldn't be over-complicated, but personally I work with lxfml anyway since they're simply more comfortable! I'll follow the idea with the executable once I've implemented more checks to enhance usability. Of course the script handles subgroups! As many as you wish... and this is actually used for creating the substeps in the BI! I tried to have LDD auto-generate BIs on finely sub-grouped models, but they didn't seem to follow the grouping in any way.

Just to let everyone know, I made a python script that does exactly as proposed before by hrontos. It operates on an exported lxfml and uses the group information to create building instructions. It also directly creates a new lxfml file that can be imported into LDD, so no more copying and pasting by hand. So far, it works fine. More refinements are conceivable, such as checks that the groups are well-formed and all parts are actually in a group and only in one group. I'll get to these as the need will arise. You can find the script here: https://github.com/mfeldt/GS2BI And a somewhat lengthy video tutorial how to make instructions with it here: https://www.youtube.com/watch?v=mbef20mRTrI

Really! I'm curious how that could work, because for me the inability to move the camera view port renders any attempt to make readable instructions for a model of such dimensions futile

And - anything you can recommend to get at least recognizable results?

Newly found: PyBrick https://github.com/burggraaff/PyBrick brickrake: https://github.com/duckworthd/brickrake There seem to be more interesting things out there... simply try to search for bricklink on guthub.

Sorry, I don't have an answer - but I do have the same issue. And in large, complex model it's really annoying as the only solution I came across is to reduce the magnification factor for assemblies. This will put more of the complete model into view, but either tiny or at completely crappy resolution. So I second a request for being able to - either allow larger output images completely used for the model - or the ability to point the camera to a specific section. I would guess the first solution is probably easier to implement - maybe some invisible window is generated where the content is copied from and one just needs to increase the hard-coded size of that?

It's about as cumbersome as it can get. It starts with the "easybuy" button, which is anything but easy. It finds a nice combination of stores and gives a quote. However, next you discover that the quote is not worth the bits its made from, because store rules imply heavy surcharges due to small lot sizes. Next come some additional charges for certain payment methods. In one case a Polish seller wanted 5% extra for paypal, where paypal already quoted a crappy Zloty exchange rate. Next you have to agree to buy without knowing the actual shipping fees - ridiculous. The site is great in principle, but totally impracticable to use. Nice design, but purchasing a large inventory from different stores is not any easier than on bricklink.

I just wanted to follow up and note that this was solved by making Blueprint use an updated version of the db.lif. Now I have another question: Blueprint can highlight the current parts added in a particular step. Is there any way so influence the color used to highlight? I don't particularly fancy the pink....

Yep, I know there are tools out there that can do part of the job... let me maybe describe the use case: You design a model in your favourite digital design software. Next step is to generate instructions and actually build it. Now you realize there are parts in the model that actually do not exist, in 99% of the cases because of color issues. But then, replacing individual parts can actually spoil the whole design, as color is quite important! So my vision: A tool that reads the model file (lxf or ldr), comes up with a list of all parts unavailable due to color (I know this exists) When clicking on a specific unavailable part, it shows all the other parts in the model of the same color. In the resulting list, I can mark parts that I want to be of the same color The tool comes up with a suggestion of colors that are available for *all* the parts now selected The tool modifies the source file. Of course I can do that already, but with a combination of tools, and usually the "modify the source file" part is pretty tedious and must be done in the design tool.

Yes, but simply buying the parts is not the goal. I'd ultimately like to modify the lxf-files to only contain parts that are actually available. In this way I hope to get around the gaps that usually occur when exporting to ldraw, or devising building instructions. Sigh, I guess I'll have to make my own attempt then.

Just about to start work on something similar, I could as well ask here: What about checking the availability of a part on bricklink? Mostly in terms of color - and if unavailable, list the available colors? As a very advanced feature: Find all parts with the same color, and check in what *common* color they would all be available on bricklink...

Done that. I'm running Linux, btw.

stud.io looks good when regarding the specs, but once I started trying to use it... First of all I couldn't get it to run on 2 older machines, nor on a virtualbox. Apparently the requirements - which are nowhere to be found by the way - regarding openGL are too high for those.Once it does run on a modern PC, it creates a CPU load beyond belief, hardly aver responds fluently and is simply no fun to work with. Importing a model from LDD seems to destroy the sub-model grouping completely, although I read otherwise somewhere. stud.io seems to follow the step-logic known from ldraw editors, which I personally simply hate. In fact, using these groups one can create great instructions rather easily. The only sever ddrawback of LDD is that TLG strictly prohibits any commercial use, so you can't sell anything created in LDD. In principle, you can't even upload pictures to a web site that has advertisements, as that's already commercial use. So for me stud.io is a promising alternative that might become the tool of choice one day, but it still needs a lot of improvement. For the rest of ldraw, it's somewhat like the usual story with "free" software. It's great and one can achieve stunning things, but it usually lacks professionalism, the latter meaning that it's not so easy to do all the great things without doing a lot of other things first, like finding the right version of library X, piling through config file Y, or figuring out the meaning of GUI element Z. For implementing ideas LDD is still without alternative!

Crash when using part 76302 OUTERCABLE 80MM Well, in fact blueprint 0026 crashes quite frequently, but by some workarounds (e.g. pressing ctrl+i instead of clicking "Load model" in the menu...) I can at least get it to work decently on most models. Except if there's this damn cable inside, which leads to New version! Yuhu! (1x1564.2) Caching brick aliases.. OpenGL version: 3.2.0 NVIDIA 340.104 OpenGL vendor: NVIDIA Corporation OpenGL renderer: GeForce 605/PCIe/SSE2 OpenGL shading lang: 1.50 NVIDIA via Cg compiler Loading brick 76302 OUTERCABLE 80MM Flexing element 76302 OUTERCABLE 80MM Exception in thread "JavaFX Application Thread" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1774) [...many more error lines...] Caused by: java.lang.RuntimeException: java.lang.NullPointerException at blueprint.b.b.a.a.b.b(Unknown Source) at blueprint.b.b.a.a.b.a(Unknown Source) at java.util.HashMap.computeIfAbsent(HashMap.java:1127) at blueprint.b.b.a.a.b.a(Unknown Source) at blueprint.b.b.a.a.a(Unknown Source) at blueprint.b.b.a.d(Unknown Source) at blueprint.b.b.a.b(Unknown Source) at blueprint.b.b.a.a(Unknown Source) ... 48 more Caused by: java.lang.NullPointerException ... 56 more Closing db. That's really a pity, because to my taste, blueprint is the only tool which enables the efficient production of instructions that can really be used!