legolijntje

Members
  • Content Count

    757
  • Joined

  • Last visited

  • Days Won

    27

Posts posted by legolijntje


  1. Lately I'm often frustrated about the (lack of?) sorting of the quick-search results in the search bar. I'm not sure if this is a regression because I feel like I'm only annoyed about this for a couple of months now. But maybe I just never noticed earlier.

    Anyway, my problem is that search results are sorted in a weird way. For example, when I search for part 3023 (plate 1x2) this is what I get:

    image.png.14cd3261f0c81cfe4a4207a2c88c18ba.png

    The part that has actual part number 3023 is the 6th result (and in this case that means that I even have to scroll to see it).

    And this is just an example, it happens with a lot more parts that parts that are exactly what I'm looking for are not at the top of the list. I would appreciated it if the search results would be the other way around as how they currently seem to be. In my opinion, this would be the best quick-search sort-order:

    • Part number
    • Set number
    • Part name
    • Moc name
    • Set name

    So, in the case of 3023 that would mean that 3023 is on top, followed by 30230 (which is currently 7th), followed by set 3023 and then set 30230 and then parts and sets containing 3023 in the name of the part.

    But, at the very least, I'd like to see results matching the actual part number (or set number for that matter) on top no matter the rest of the sort order.

    I hope that makes sense :)


  2. 3 hours ago, LegoOri said:

    Hi Simon

    Thanks for the reply, and I am sorry I only saw it now. The reason I didn't pursue the matter is I went back to desgining with LDD ( Comfort zone - and also easier to design alternates because I can limit the inventory). When I have a new wholly-Stud.io design I shall definitely try your work arounds 

    Thanks!

    LegoOri

    I believe the stud.io importer was recently updated so maybe you don't need any workarounds anymore. But I'm not sure about that, I don't use stud.io.


  3. For me it looks perfectly fine. I have enough in my inventory for all the Any Color parts :huh:

    Kinda unrelated, but I just had a thought: @Nathan is the system smart enough to give priority to colored parts when calculating building percentage? E.g. if a MOC uses 6 2x4 bricks in red and 6 2x4 bricks in any color and I happen to have 6 2x4 bricks in red it should give priority to the red parts and not the any color parts. Does it do that?


  4. The most popular CAD tools nowadays are:

    • LDD
    • LDCad
    • Stud.io

    LDD is made by LEGO itself, though it's not really maintained or updated anymore nowadays (it does sometimes get a sudden Brick update). It has brick-snapping and collision detection which makes it really easy to use and learn, but it can sometimes be a pain to work with (especially with more advanced models and Technic models) due to that same system. Cause it's a proprietary system there's not a whole lot of tools that use the LDD file format (but there are a few).

    LDCad is based on the LDraw parts library which is open-source and thus has many, many more parts than LDD. LDCad has become the go-to LDraw CAD nowadays (there are many more such a MLCad, LeoCad, BrickSmith etc. etc.) because it's modern, fast and has brick-snapping (no collision detection though). The opinions about the UI are mixed; some hate it, some don't mind at all. LDCad does have a steeper learning curve than LDD or stud.io but it's also more advanced. The file-format is open source and thus there are a bazillion of tools out there that support the LDraw format.

    Stud.io is the new kid on the block. It's made by Bricklink and is a hybrid between LDD and LDCad (or any other LDraw CAD). It has both brick-snapping and collision detection and it can connect with the Bricklink database to show which parts exists in which colors and what the price is. The file-format is a bit weird though. It is proprietary, but based on LDraw. The .io files itself can thus be easily exported to LDraw.

    If you want to build Technic models, I'd recommend you use either LDCad or stud.io with my personal preference going to LDCad (disclaimer: because I'm using LDCad and all other LDraw tools for years and years now :P).

    4 hours ago, Totoolm said:

    Is there any program in which you actually can test your technic-model and se if it works?

    In the past, there was a great tool called SR3D-Builder. It was a bit like LDCad, but its main focus was (Technic) simulation. You could move gears, open doors, extend/retract pneumatics etc. etc. It was a great, great tool! Sadly the author passed away a couple of years ago ?


  5. 21 minutes ago, TobyMac said:

    It works! Awesome!!!!!!!

    takes about 3 seconds per part (standard bricks). Is it also ok with you if I share this?

    Some examples:
    https://www.bricksafe.com/pages/TobyMac/div/ldview

    Nice!

    It does about 2-3 parts per second for me :huh:
    Btw, if you want a little 'rounder' studs you should up the curve quality in LDView a bit.

    Feel free to share it, no problem, but note that it's untested and optimized code. Like I said, the best idea is probably to use LDView's builtin batch functionality ;) 


  6. On 10/29/2018 at 4:38 PM, Simon said:

    but you can't set parameters from the command line

    You certainly can. Not sure if you can set all options through parameters, but there's always the option to pass your own .ini file with parameters which can include any setting.

    On 10/29/2018 at 7:16 PM, TobyMac said:

    I'm getting these errors

    Ugh, no idea why. I shouldn't have included those threading stuff without having used it before :P

    Try this one without any multi-processing:

    import glob
    import subprocess
    
    LDRAW_PATH = 'C:/Users/Merlijn/LDraw'
    LDVIEW_PATH = 'C:/Users/Merlijn/LDraw/Software/LDView/LDView64.exe'
    OUTPUT_PATH = 'E:/tmp'
    MAX_WIDTH = '200'
    MAX_HEIGHT = '200'
    PART_COLOR = '0xFFFFFF'  # Color format standard HEX RRGGBB
    
    
    def main():
        ldraw_part_paths = glob.glob(LDRAW_PATH + '/parts/*.dat')
    
        for path in ldraw_part_paths:
            part_number = path.rsplit('\\', 1)[1].rsplit('.', 1)[0]
            print(part_number)
    
            subprocess.call([
                LDVIEW_PATH,
                '-AutoCrop=1',
                '-SaveWidth={}'.format(MAX_WIDTH),
                '-SaveHEIGHT={}'.format(MAX_HEIGHT),
                '-DefaultColor3={}'.format(PART_COLOR),
                '-SaveSnapShot={}/{}.png'.format(OUTPUT_PATH, part_number),
                path
            ])
    
    
    main()

    I think LDView's own batch feature is probably better than such a script anyway, but I couldn't quickly find its documentation :P 


  7. 54 minutes ago, TobyMac said:

    To save time, I could drop all .dat files from which I need an image (only 100 or so) from LDraw in a different folder and change to that path in this line?

    Yeah, I suppose you could :)


  8. Ok, I made something that goes through ALL your LDraw parts and renders an image for it. The only stuff you need to change are the CAPS variables at the top.
    Also note that I tried multi-threading which I've never done in Python. It seems to work, but I'm not sure if it actually makes the thing go faster :P You can define the number of threads yourselfes.

    Note that I made this one real quick and there's little testing or optimization of whatever :P

    import glob
    import subprocess
    import threading
    
    LDRAW_PATH = 'C:/Users/Merlijn/LDraw'
    LDVIEW_PATH = 'C:/Users/Merlijn/LDraw/Software/LDView/LDView64.exe'
    OUTPUT_PATH = 'E:/tmp'
    MAX_WIDTH = '200'
    MAX_HEIGHT = '200'
    PART_COLOR = '0xFFFFFF'  # Color format standard HEX RRGGBB
    THREADS = 1
    
    
    def create_chunks(seq, num):
        avg = len(seq) / float(num)
        out = []
        last = 0.0
    
        while last < len(seq):
            out.append(seq[int(last):int(last + avg)])
            last += avg
    
        return out
    
    
    def worker(paths):
        for path in paths:
            part_number = path.rsplit('\\', 1)[1].rsplit('.', 1)[0]
            print(part_number)
    
            subprocess.call([
                LDVIEW_PATH,
                '-AutoCrop=1',
                '-SaveWidth={}'.format(MAX_WIDTH),
                '-SaveHEIGHT={}'.format(MAX_HEIGHT),
                '-DefaultColor3={}'.format(PART_COLOR),
                '-SaveSnapShot={}/{}.png'.format(OUTPUT_PATH, part_number),
                path
            ])
    
    
    def main():
        ldraw_part_paths = glob.glob(LDRAW_PATH + '/parts/*.dat')
        chunks = create_chunks(ldraw_part_paths, THREADS)
    
        threads = []
        for i in range(THREADS):
            t = threading.Thread(target=worker, args=(chunks[i],))
            threads.append(t)
    
        for thread in threads:
            print('starting thread')
            thread.start()
    
    
    main()

     


  9. 1 hour ago, TobyMac said:

    OK, I have LDView and the LDraw Library. How do I make a bulk render? I've found a .bat script, but that is incomplete (print-screens are half-screen).

    I never really took a look at the batch feature. I believe it's also pretty new so there might be a lack of documentation and examples. I can take a look when I get home.

    Alternatively, you can just create a super basic Python script that runs through all your LDraw parts and calls LDView for every part separately. Should be pretty simple, only a few lines.


  10. EDIT: Whoops, I misread the question. I thought it was for singular parts. For a coloring book, I would recommend the same settings is above, except:

    • Always black lines
    • Show edges only

    That way you get a white image with black lines:

     

    Knipsel.PNG


  11. You can batch-render LDraw parts yourself with LDView. To get a proper, good line look like they also kinda look in LEGO instructions use the following settings:

    Tab General:

    • FSAA: 8x or 16x (depending on your hardware you can't choose 16x)
    • Antialiased lines: ON
    • Background color: White
    • Field of view: 0.1

    Tab Geometry:

    • Edge Lines: ON
      • High Quality: ON
      • If you want, you can turn Always black ON too. I personally don't.
      • You gotta experiment a bit with Thickness. It's dependent on your final image size what looks best. I generally use the 2nd notch (from the left).

    Tab Effects:

    • Lighting: OFF

    Tab Primitives:

    • Primitive substitution: ON
    • Curve quality: whatever you like. Since the goal here is small images, it probably doesn't need to be very high but if you're rendering single parts the processing time is probably negligible.
    • Use hi-res primitives when available: ON

    -------------

    Furthermore, the LDraw -> Blender plugin I linked a week or so ago also has a line option I believe, but not entirely sure about that.


  12. Are you sure 'Star Destroyer' is an official trademark though? I can't find any European trademark on boip.int and on the global search engine wipo.int I can only find a US trademark (which can also be found on US trademark database uspto.gov ). But that one US trademark has been cancelled/rejected in 1989 ?

    Furthermore, that one trademark is in category 022 for 'Games, Toys & Sporting Goods' and if you'd be very literal, building instructions (without any bricks) alone aren't toys ? 


  13. When I add parts to a Bricklink wanted list (using the automatic API version, not the manual export/import) from a custom list, all parts are doubled. I have a list with 391 lots, after adding to wanted list the popup shows 'Added 780 lots to wanted list'. When going to Bricklink, there's a looooong warning that I have double lots in my wanted list which is not allowed. The warning is so long, cause it lists all doubled parts which is essentially the whole list :P

    Side question: which Rebrickable color exports to Bricklink's 'Not Applicable' color?


  14. 47 minutes ago, Simon said:

    The peeron_to_MLCad link turned out to be pretty interesting, have you ever checked LdSetsConversion?

    Now you mention it, I can vaguely remember using LdSetsConversion a few years ago. But I forgot about it, completely missed it on the peeron_to_MLCad site too :rolleyes: When googling it, I even found posts from myself on the LDraw forums. :lol:
    Thing is, it converts to LDraw and not to LDD which the original question was. Of course, you can import LDraw into LDD, but in that case you gotta be sure there are no clashing parts.

    47 minutes ago, Simon said:

    I am using an older Ubuntu version on my notebook (Trusty Tahr) which has lots of problems with Wine - on my desktops I use Mint 18.3 (Xenial Xerus) with much less problems. One of these days I'll try LDCad there, see what it does.

    There is a native Linux version available, so you don't need Wine right? But, I'm not really a Linux guy, so what do I know? ;)
    It's completely off-topic anyway.


  15. 21 hours ago, Simon said:

    However, there is LDCad Parts Bin PBG export option in Rebrickable, and I would guess there has to be a way (presumably thru LDCad) to turn that into a genuine LDraw file which can be imported into LDD.

    Not really. The pbg files are only a parts list. So you can build a model in LDCad using a limited number of bricks (for example if you want to build an alternate model, or if you just want to digitally recreate an existing model). There isn't a way to turn that list into an LDraw model.

    LDD Manager used to be able to turn a parts list into an LXF file, but that software has been abandoned. There is (was) also peeron_to_MLCad which creates an LDraw file from a peeron inventory, but A: that software is ancient by now and B: Peeron is ancient too :P Ah well, this is all a bit useless.

    21 hours ago, Simon said:

    cause I am running Linux, and, for some reason, LDCad refuses to work.

    It should work on Linux though... If you have any problems, you can always come by the LDraw forums to ask for help :)