LDR-Importer 1.1.5 is five times slower about ldr-importer HOT 14 CLOSED

Confirmed.

from ldr-importer.

What Blender version are you using and what is the file size of the model? I personally use 2.69 on Windows and models/car.dat and models/pyramid.dat for testing. I know they are valid working models, so I errors I encounter are isolated to the script. car.dat is 2.7 KB, and pyramid.dat is 664 Bytes.

I have not noticed a slowdown in the script except when #47 was merged, and I fixed that in 45e71e6. However, as Tribex confirmed, it apparently is much slower.

Off the top of my head, I do not know what could be wrong here nor how we can improve the situation. This could be a simple indentation error as the above commit was, or it could be caused by any of the LDraw Part Library path fixes we had to make in v1.1.5. I'll try to check on this soon. In the meantime, anyone else have an idea what could be going on here?

from ldr-importer.

I am using Blender 1.69. Today I had to stop the import of the Millennium Falcon after 6 hours due to this slowdown. I am now importing it again with 1.1.

BTW: thanks a lot for that awesome script. It helped me to convert good looking LEGO models into SOFTIMAGE via Blender and .fbx export. Here's a research test with a complex model and a basic simualtion:

https://vimeo.com/84670417

There's unfortunately an issue with MLCad where some models using multiple materials on polygon-groups like the Star Wars Minifig R2D2 model. The issue happens when I load a .mpd and have to export this into .ldr. The original .mpd will look fine. Once it's exported to .ldr (I use the largest file for the whole model) the colors of those kind of models are wrong. I have sent a mail to the programmer but I doubt he will fix it soon because it looks like he's inactive for a while now.

I also got in touch with the programmer of the LDD to POV exporter. POV is the only tool supporting nice bevels, seams and the LEGO texture on the studs by displacement. Unfortunately LEGO doesn't give permission to convert the .lif data into another open model format. With POV-Ray it's a legit way. I am also wondering if the LDD data is some kind of resolution independend data like NURBS?

from ldr-importer.

The .ldr of the 928 - Galaxy Explorer I used for the test is 29 KB.

from ldr-importer.

I won't be on much today, but I have my laptop with me, so I'll try (I have prior obligations to do first) to look into what could be causing the slowdown this afternoon.

I probably didn't notice the continual slowdown because the aforementioned bug was present for so long and the impact was so enormous that fixing it initially appeared to restore all the speed.

from ldr-importer.

Yes, I was importing a simple model (just a cloud and a few plants), and it takes a while, but not 9 minutes. Maybe disabling cleanup would help? The slowdown seems odd, because we didn't change much, in fact, we removed a cleanup option. But then again, maybe it has something to do with the config.py and the path look up, or the un-official models having priority over official ones (because it keeps searching to see if an on-official exists, then looks for official). This is strange. Hopefully the re-write will speed things up. :)

from ldr-importer.

I was able to import the massive Millennium Falcon UCE with 1.1 in a decent time. I also received a beta version of MLCad by the developer what fixes my export issue.

from ldr-importer.

I think that if you set the render engine to Blender Internal instead of Cycles it is faster. Not really tested it officially, though. :P

from ldr-importer.

Assigning to v1.3 milestone. Hopefully the root of this issue can be tracked down.

from ldr-importer.

Using the magic of git bisect, I found this bug originated between eff7232 and 7313681 (most likely in the latter). @tribex @virtualrepublic Will you run the models you were importing earlier though the script from that first (working) revision and tell me if the speed has been restored for you as well? Now that I know what commit the issue came in, I can work on reverting the change in the master.

from ldr-importer.

Alright, I've published the restore-speed-take-2 branch. Be sure to compare that one too (I will be myself shortly). Hopefully this will be the first (code) step to restoring the lost speed (and time). With it, models/car.dat imports in 6 seconds and 13 milliseconds.

After writing that last sentence, it still doesn't sound like everything is fixed.

from ldr-importer.

I will look into this when I have the time, kinda swamped at the moment.

from ldr-importer.

No problem, Tribex. We are all volunteers here. No one thinks you don't do anything outside this. ;)

I did test the patch myself and added the updated debugPrint to the last good revision (as I identified earlier), and they both import cat.dat in 6 seconds and something milliseconds, where as the master does it in about 10-11 seconds. It's not 5x "faster", but it seems to be fixed now. I can see on larger models how the speed from the master would degrade even further and be 5x slower than v1.1.0 though. I still need to run it against the actual 1.1.0 release.

from ldr-importer.

This should be fixed (hopefully for good) now that #73 has been merged. Please, please, test it out and make sure it works. I really want to fix this (it also messes up development).

from ldr-importer.