le717 / ldr-importer Goto Github PK

As originally reported in #36 (comment):

Hi
Sorry to bother you again.
I have fixed some other problem and now was playing with the export to Blender again.
But suddenly I get these errors in the consol window in Blender

[LDR Importer] ERROR: Reason: UnicodeDecodeError. - 17:43:28
[LDR Importer] Attempting to import C:\temp\DS Exp 2013_00001.ldr - 17:43:42
[LDR Importer] ERROR: UnicodeDecodeError
Traceback (most recent call last):
File "C:\Users\Petter\AppData\Roaming\Blender Foundation\Blender\2.68\scripts\addons\import_ldraw.py", line 766, in create_model
LDrawFile(context, file_name, mat)
File "C:\Users\Petter\AppData\Roaming\Blender Foundation\Blender\2.68\scripts\ addons\import_ldraw.py", line 126, in __init__
self.parse(filename)
File "C:\Users\Petter\AppData\Roaming\Blender Foundation\Blender\2.68\scripts\addons\import_ldraw.py", line 244, in parse
lines = f_in.readlines()
File "C:\Program Files\Blender Foundation\Blender\2.68\python\lib\codecs.py", line 300, in decode (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 92: invalid start byte - 17:43:42
[LDR Importer] ERROR: Reason: UnicodeDecodeError. - 17:43:42

I have restarted blender, reexported the file but stil I get this problem right a way after select the file and start.

I also have got the Lsynth to work with the export. I needed to copy the Lsynth parts files to Ldraw\parts dir.
May be something for later that it check the unofficial\Lsynth catalog if it cant find the file in main Ldraw dirs ?

Petter

This is caused by the model saved in UCS-2 encoding.

Fix

Update the script to read models in this encoding. Detect UCS-2BE, UCS-2LE, or standard UTF-8 encoding and return value for proper reading by open().

I found a page on the Blender wiki describing major changes to the Python API, and it had a list of Cycles node names. The current required version is 2.63, but the list was under a 2.67 header.

Thus, update minimum Blender version according to this page and testing.

Targets for version 1.1.5. Items can be pushed back if needed.

v1.1.5 is more of a intermediate release to provide bug fixes and patches for v1.1 and tide users over until v1.2.

• Always save config.py in user's AppData on Windows (#38)
• Remove Video Game Cleanup option (#47)
• Better part path searching (#50, #40 (comment), #40 (comment))
• UCS-2 BE & LE model encoding breaks script (#36 (comment), #37)
• Fix tooltips on import settings to be clearer
• Give unofficial files precedence over official ones; correct usage of p/8 primitives folder (#52, #54)
• Global variable "paths" overflows (#55)
• Make mention of MPDCenter in Readme to workaround lack of MPD support
• Multiple edge split modifiers from CleanUp added to single brick (#57)
• Any other open issues for this milestone

Quote @Banbury

Also the recursive constructor is probably not a good idea.
This looks like a major rewrite is necessary. Fun :(.

And quote @tribex

Okay, I think this entire thing needs to be redone. Period.
If only I could understand it enough to get all the recursion right.

Currently the structure appears to be:

1. Create a new object - >
2. Parse the main file, then all sub files, and append to the sub file list - >
3. go through the subfile list and create a new object for each subpart - > Step 1

It really needs to use functions, not while recursions, lists, and objects.

As it has been established, the script needs a rewrite very badly. I think it needs to be done ASAP to not only fix any bugs present but to also make any new development much easier. Yes, it is Christmas time so we won't have too much time to work on it right now, but release milestones do not have deadlines until after they are released, so there is not a huge rush. By doing it now rather, we will have less new code to salvage and features to restore from the old version.

I know we already have issues assigned to v1.2 v2.0, but I propose to push these back to v1.3, and let v1.2 v2.0 be the rewrite. We would not have to add new features, a rewrite should be enough to warrant a new release (and it may overall be faster when it is all said and done).

We can work out all the details later (I've enabled the wiki for us to put the plan on), but I propose Banbury take the lead (as he identified the need for a rewrite), and by lead I mean lay out the new script structure and guidelines we should implement and follow. Obviously this is a team project so ideas/concerns can be expressed and added, but we still need someone to oversee the operations.:wink:

We would more than likely make a branch off master (I'll call it rewrite in this issue) to hold the new changes. If it is possible (and I know it is), we'll branch off that branch to work on our our assignments, and those would be merged back into rewrite. When the script is complete, rewrite will be merged back into master.

Like I said, all details can be worked out, This is simply a proposition to proceed with the rewrite before too many new features (such as implementing the Cycles LEGO Materials @rioforce actually created for us) are added, making it harder to redo.

Are there any questions, concerns, comments or something I need to clarify? Do you think we should go ahead with this?

the path search order in import_ldraw.py is again wrong.

you have now correctly relocated the initialization code outside of the locate()
function, but while doing so you broke the order of elements.

The current master codeline reads:

    # The unofficial folder exists, search the standard folders
    if os.path.exists(os.path.join(LDrawDir, "unofficial")):
        paths.append(os.path.join(LDrawDir, "unofficial", "parts"))
        paths.append(os.path.join(LDrawDir, "unofficial", "p"))

        # The user wants to use high-res primitives
        if WhatRes == "HighRes":
            paths.append(os.path.join(LDrawDir, "unofficial", "p", "48"))
        # The user wants to use low-res primitives
        elif WhatRes == "LowRes":
            paths.append(os.path.join(LDrawDir, "unofficial", "p", "8"))

This is broken. It effectively renders the 2 switches "HighRes" und "LowRes" useless.
The correct order would be

    # The unofficial folder exists, search the standard folders
    if os.path.exists(os.path.join(LDrawDir, "unofficial")):
        paths.append(os.path.join(LDrawDir, "unofficial", "parts"))

        # The user wants to use high-res primitives
        if WhatRes == "HighRes":
            paths.append(os.path.join(LDrawDir, "unofficial", "p", "48"))
        # The user wants to use low-res primitives
        elif WhatRes == "LowRes":
            paths.append(os.path.join(LDrawDir, "unofficial", "p", "8"))

        paths.append(os.path.join(LDrawDir, "unofficial", "p"))

Note that this bug only is present for the unofficial folders.
The official folders search is implemented correctly, i.e.,
the searching in "48" and "8" takes precedence over "p".

If a .dat does not exist, the script crashes with a FileNotFoundError rather than skipping it and moving on. Currently, the line it stems from is wrapped in a try… except Exception block. I anticipated this type of error but did not know what exactly would be raised, hence Exception. I can fix this by either changing the exception or (if possible) doing a os.path.exists() check on the variables before opening them for reading.

Image

I'm pretty sure I know how I can write a function to detect the LDraw System of Tools installation path and use it to complement the preset option. It would work only under Windows, as I am not sure if there are multiple (almost standard) installation paths on Mac OS X and Linux (though I could be wrong).

Basically, it would check for the existence of a some file at

1. C:\LDraw
2. C:\Program Files\LDraw
3. C:\Program Files (x86)\LDraw

If it could not be found, then give error message and fall back to C:\LDraw. The only issues is, this is performed every time the script is run, rather than only once. If you installation is in a different place, it always falls back to the default upon every re-run, rather than retain the right path/ However, you can still save a preset to your actual path, as it work's now, and hopefully the process doesn't overwrite the preset.

Any thoughts on this before I begin work on separate branch?

I have a model with LSynth parts (flexible hoses) what can't be loaded.

The .dat files are loacted in "LDRAW > Unofficial > LSynth". But I need to copy them into the "parts" folder otherwise they can't be found. LDView and MLCad will load the model without errors.

When I have copied the files into "parts" I will get the following error when loading my test file with a small LSynth model:

//

[LDR Importer] Attempting to import M:\140000_LEGO\MODO\ISSUES\LDR-Importer\UnicodeDecodeError.ldr - 13:16:57.41

[LDR Importer] ERROR: UnicodeDecodeError
Traceback (most recent call last):
File "C:\Users\michael\AppData\Roaming\Blender Foundation\Blender\2.70\scripts\addons\import_ldraw.py", line 781, in create_model
LDrawFile(context, file_name, mat)
File "C:\Users\michael\AppData\Roaming\Blender Foundation\Blender\2.70\scripts\addons\import_ldraw.py", line 165, in init
self.parse(filename)
File "C:\Users\michael\AppData\Roaming\Blender Foundation\Blender\2.70\scripts\addons\import_ldraw.py", line 291, in parse
lines = f_in.readlines()
File "C:\Program Files\Blender Foundation\Blender\2.70\python\lib\codecs.py", line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 92: invalid start byte

• 13:16:57.43

[LDR Importer] ERROR: Reason: UnicodeDecodeError. - 13:16:57.43

//

Here's the test file with the LSynth parts from the LDRAW installation. You need to copy them into the official "parts" folder:

http://lego.virtualrepublic.org/issues/LDR-Importer/LDR-Importer_UnicodeDecodeError.zip

Improvement suggestion:

As far as I can see, currently each and every single LDRAW file
gets imported into a Blender scene without creating references.

For example, if a primitive 1-4cyli.dat is used, it is repeated in each
and every instance as a separate mesh.

I think that Blender supports re-use of objects.
I cannot really imagine that it does not.

My suggestion is to search for that feature and modify the loading script
to not repeat and repeat and repeat each mesh, but instead only load it once,
and then in all places where it is used, make a reference to that one instance,
just applying transformation matrix, i.e., rotation and translation and coloring.

This should dramatically reduce the resulting blender scene size,
rendering time, importing time etc.

I cannot really imagine that Blender does not have such a feature...

Also: the already loaded files should be cached inside the importing script.
Currently it seems to me that a file like 1-4cyli.dat gets repeatedly parsed
each time it is used. That's not necessary. It should get read just once,
and its parsed contents saved in some python object.
When the next occurrence of it is met, and it is already parsed,
then the parsed version will be used. This should save a LOT of loading time.

As @MinnieTheMoocher strongly recommends and it seems as if #36 may be caused by these parts, LSynth model addon support should be added.

The Low-res primitives do not actually import when you select the option. They import as normal-res primitives. High res works though. Any thoughts on a fix?

When creating a .ldr file, it sometimes references other *.ldr files
lying next to it in the same folder.

This is seemingly not supported in LDR Importer 1.1:
It fails importing my 6372.dat file which references 6372-Minifig-2.ldr
which is lying next to it.

This should not happen. LDR Importer needs to check folders for files
in the following order:
(1) first see if the referenced file is lying next to the current one
(2) if not found there, check the ldraw\models folder
(3) if not found there, check the ldraw\parts folder
(4) if not found there, check the ldraw\p folder

Step (1) is seemingly missing from the LDR Importer implementation.
I guess that Step (2) also is missing.

As a workaround I currently inline all referenced files into my .ldr file,
but that's something I do not really want to be forced to.

As far as I can see, only the LDRAW directory option of LDR Importer
gets persisted.

Expected behaviour:
when I quit and restart Blender and then re-use LDR Importer,
its options should be as from the last run.
I.e, the value of options

• LDRAW Directory
• Scale
• "Use High-res bricks"
• Model Cleanup
  should be written to somewhere and be loaded on the next program run.

May I also ask to re-title the option "Use High-Res Bricks"?
It is very confusing. What it actually does is:
"Replace all Primitives by Hi-Res (48ed) Primitives".
This will be much clearer to LDRAW users.
It should be OFF by default.

May I also ask for a different default setting for the "Cleanup"?
The default IMHO should be "original LDRAW mesh".
Only when a user explicitly chooses to modify that mesh,
that should be done.

If anyone here has used Cycles, you know that viewport color and material color have separate boxes. Is it possible to use diffuse color (of the diffuse node or glass node) and set it as the Viewport Color? It would help a whole lot. :)

"Redirect bricks" meaning .dat files that point to the proper file name and location of the actual brick. Currently the parser claims the bricks do not exist (which is only half true), gets stuck on that file, and finally continue on with the import.

An example redirect can be found at http://www.ldraw.org/library/official/parts/3626.dat.

@Banbury Can you handle this one? I'm currently working on other (as of yet unpushed) changes, and I haven't that much of an idea of how the parser works or I'd do it myself. I think it may be fixed by checking if the coordinates given match the coordinates in a redirect brick, and if so append the current path to the path stated, then importing it. At least, that is my theory. How it would go I am not sure, what with this recursive parser and all.

Hello folks

I'm playing around with BLENDER and LEGO since a few months
I'm only a PHP programmer and I don't understand much to python

LDRAW to BLENDER import is really difficult and I really appreciate your work to make it easier.

I'm also playing with the PHYSICS engine in BLENDER.
If you import a model, for example a car, and you setup all bricks on 'RIGID BODY : ACTIVE", the car just explodes.

I found a way to avoid this behaviour by creating some RIGID BODY constraints between the bricks. I can get very realistic result by tweaking the mass of the bricks and the breakabke threshold of the constraint. For example, I achieved to create a scene where the car crashes on a wall. Some bricks are detached, some not, like in the real world.

However, creating the constraints is a very time consuming process, even for a little model.

Do you think there could be a way to create the constraints using some scripts ?
For example, the script could detect if 2 bricks are attached and create a constraints
It could then tweak the strength of the constraints by counting the number of studs involved in the connection.

Do you think that the mass of the bricks could also be set up by scripts automatically ? Is it possible to calculate the volume of an object in Blender ? You could then multiply by the density of LEGO ABS plastic, which is equal to 1.06g/cm3

These are just ideas.
I don't know if this is possible.
I would like to know your programmer opinion about that

Regards

Affects both current and Next Gen script, though it might be added for Next Gen only.

I became aware of this issue after #75 was reported. That issue reports that LSynth parts are not fully supported, and rightly so. However, there is a larger issue exposed here, as revealed by the cause of the issue.

As it turns out, the LDraw part header is read and dealt with as part of the import process. The error thrown was caused by the Python UTF-8 decoder not properly decoding a character in the part header. However, part headers are not even used in the import process (although it probably should take into account BFC... however that should be done). Therefore, I think it would be best if the header information was discarded before the construction process begins.

This, however, will take some work, as there is no "end of header" META command (though one is being debated [1]), so detecting the header end requires a bit of work [2]). In addition, the original script deals with part of the header in the process (I'm not sure about the Next Gen), so this change is not as straightforward as replacing the open() calls with a call to the header-stripping function. However, I think it should be done, even if it takes a bit of work.

Are there any comments or thoughts on this?

References

1: [LSC Request] End of header meta command
2 End of file header indicator?

I just tried to open a *.ldr file with LDR Importer 1.1.

It failed doing so because that file used a file lying next to it.
(I'll file a separate bug report for that in a different issue).

However, the tool reported "import succeeded" althouth it in fact failed.

Here is the output LDR Importer generates on stdout:

[LDR Importer] Configuration file found at
c:\Blender 2.69\2.69\scripts\presets\io_import_ldraw\config.py - 20:25:11

[LDR Importer] The LDraw Parts Library installation path to be used is
D:\LEGO\ldraw - 20:25:11

[LDR Importer] Attempting to import D:\LEGO\playbox\scenes\houses\6372.ldr - 20:25:28

[LDR Importer] Could not find file 6372-Minifig-2.ldr - 20:25:28

[LDR Importer] File not found: 6372-Minifig-2.ldr - 20:25:28

[LDR Importer] CleanUp option selected - 20:25:28

[LDR Importer] D:\LEGO\playbox\scenes\houses\6372.ldr successfully imported! - 20:25:28

Hi.
I have exported a big model from MLCad and when i import the file that shall contain the whole model, Blender just show a small part of it,
I have been successful doing this with another file.
The model was an big multi part model saved as MPD

If an item is selected when you import a model, and a model cleanup option is selected, the cleanup will subsequently be applied to that selected item in addition to the model.

Fix: select only the items imported. How to do that, I'm not quite sure...

Targets for version 1.1. Items can be pushed back if needed.

• Load preset upon startup (Can not be done; Blender does not support it; no longer needed; see #30)
• Set each brick's origin to geometry - Added in a4f4ee6
• Metallic colors
• Support for "redirect bricks" (see #10)
• Skip (or gracefully handle and display error message as a quick patch) non-existent bricks. (Delayed for a later release due to script issues, workaround applied in the meantime; see #11)
• Blender for Mac OS X and Linux support (patch submitted, never worked. See also #13, added in #14)
• Better installation instructions (mention installing straight from the .zip archive) and Readme overall
• Any open issues for this milestone

Currently, import_ldraw.py reads:

paths = []
paths.append(file_directory)
paths.append(os.path.join(LDrawDir, "models"))
paths.append(os.path.join(LDrawDir, "parts"))
if HighRes:
    paths.append(os.path.join(LDrawDir, "p", "48"))
paths.append(os.path.join(LDrawDir, "p"))
paths.append(os.path.join(LDrawDir, "unofficial", "parts"))
if HighRes:
    paths.append(os.path.join(LDrawDir, "unofficial", "p", "48"))
else:
    paths.append(os.path.join(LDrawDir, "p", "8"))
paths.append(os.path.join(LDrawDir, "unofficial", "p"))

This gives official files precedence over unofficial ones.
This is not what you usually want.
Your usual usecase is that you download corrected or updated parts
from the LDRAW parts tracker to that "unofficial files" folder
and want them to take precedence over the official ones.

Thus, the above lines need to be reordered to:

paths = []
paths.append(file_directory)
paths.append(os.path.join(LDrawDir, "models"))
paths.append(os.path.join(LDrawDir, "unofficial", "parts"))
if HighRes:
    paths.append(os.path.join(LDrawDir, "unofficial", "p", "48"))
else:
    paths.append(os.path.join(LDrawDir, "p", "8"))
paths.append(os.path.join(LDrawDir, "unofficial", "p"))
paths.append(os.path.join(LDrawDir, "parts"))
if HighRes:
    paths.append(os.path.join(LDrawDir, "p", "48"))
paths.append(os.path.join(LDrawDir, "p"))

Additionally, the implementation of the p/8 folder is wrong:
(a) it must be searched both in official and unofficial files and
(b) it needs its own "LowRes" flag instead of depending on HighRes

Applying this correction, the above lines become:

paths = []
paths.append(file_directory)
paths.append(os.path.join(LDrawDir, "models"))
paths.append(os.path.join(LDrawDir, "unofficial", "parts"))
if HighRes:
    paths.append(os.path.join(LDrawDir, "unofficial", "p", "48"))
if LowRes:
    paths.append(os.path.join(LDrawDir, "unofficial", "p", "8"))
paths.append(os.path.join(LDrawDir, "unofficial", "p"))
paths.append(os.path.join(LDrawDir, "parts"))
if HighRes:
    paths.append(os.path.join(LDrawDir, "p", "48"))
if LowRes:
    paths.append(os.path.join(LDrawDir, "p", "8"))
paths.append(os.path.join(LDrawDir, "p"))

Note that in addition to the existing HighRes flag, a new flag LowRes flag needs to be introduced.

I made some stuff as addon for Blender that works in close cooperation with your LDR Importer adding things you didn't add, like automatic seam effect, repairing strange shadowing on sloped computer bricks that happens after your import, replacing nodes of material with nodes of color from external linked file instead of making new material (therefore there is no need to iterate thru all objects searching for a material and then replacing everyone of them, you just replace nodes from the material itself which leads to automatic change in every instance of the material in every object having it that is much quicker and better way), parrenting etc.

So my question is: if you will we can join our efforts and implement my stuff to your LDR Importer...hm?

It would be very useful and important if there's an option for creating instances of objects. That means that bricks of the same type (not color) have one master and the rest are instances. This would be a huge difference when loading bigger models. I am not familar with Blender but I think it should support instances.

there is no real reason to scale a LDRAW file when importing it to Blender.
LDRAW users, especially part authors are very used to the coordinates
of ldr files, so their native expectation is to have them kept through all
toolchains unless otherwise stated.

so it is good to have a scaling option in LDR Importer in case someone needs it,
but its default value should be 1.0.

When importing, there should be operator presets with the settings. This could be added in either the rewrite or the current script.

Using the latest code (2335b1d) from master, if you import a model (for example pyramid.dat) in any quality, it will add 12 Edge Split modifiers to each brick.

Some parts contain custom colors in the format '0x2RRGGBB' in hex code. Importing one of these files would produce an error.

Example: 973pr0.dat

Targets for version 2.0.0 Beta 1. Items can be pushed back if needed.

Merged from #60:

• Implement Optional lines
• Add back clean-up options
• Apply transformations as necessary (scale set by user on import, and rotation to match blender's coordinate system)
• Implement materials (make a dict mapping colour indices to bpy.types.Materials in the LDrawParser class?)
• Guess library path
• Search appropriate paths according to chosen LoD
• Handle incorrectly-formatted lines properly
• Think about how to catch circular references
• Any open issues for this milestone

@Banbury, remember what you said about avoiding global variables? While I was reviewing the script looking for a way to remove them I got an idea, and I'd like to hear your thoughts.

The majority of the script is wrapped in classes (LDrawFile, IMPORT_OT_ldraw). There are not variables within these classes, even in the functions, that are prefixed with double underscores to make them a private attribute. So to me, using global is contrary to OO.

My idea is when the script is run (ideally under if __name__ == "__main__":), two constructors for each class is created, then we use them to access what lists, dictionaries, and import options instead of global. If it sounds good to you, I'll do my best to work on it before I have no internet from Friday-Sunday (maybe Monday) due to a big event.

Well, today I successfully found out why the rotation does not work in my script if I try to replace some brick: it is because of LDR Import script - although it places all the bricks in the exact right rotation to the scene it states brick's rotation values wrongly in Blender's GUI in object rotation fields where all bricks are stated as their rotation is always 0, but it should correspond to .ldr brick's rotation (which is not), and therefore newly replaced bricks are always not rotated (rotation = 0) simply because of this fact alone I am not able make my script rotate replaced bricks right upon old bricks rotation values...and I think this could be clearly taken as a bug in LDR Import addon scrip

Currently, all primitives are imported as any normal LDRAW file.
This means for example that a 1-4cyli.dat always is a polygon mesh.

There already exists a boolean option to replace all primitives
by their "48ed" (high-res) versions if the user wants that.
That option could be extended to replace all primitives
by their "8ed" (low-res) counterparts if the user really wants that.
However, he most probably will not, as the rendering quality will be just poor.

What would be much, much more interesting would be to add a
"substitute primitives by native 3D objects" value of that substitution option.
If the user sets the option to THAT mode, it should work similarly as it
works in LDView. There, the tool internally has a lookup table for LDRAW primitives.
It knows that a 1-4cyli.dat models a quarter cylinder, and substitutes
a real 3D OpenGL quarter cylinder for it, instead of importing simply the polygon
mesh.

Currently the pivot point is simply moved to the center of mass. But LDraw parts have a pivot point already. By building the mesh at (0,0,0) and then translating it, the correct pivot point would be retained.

The script does not properly support Bricksmith models.

I have often been asked if the script supports Bricksmith models, and with good reason. Bricksmith is the only LDraw CAD program for Mac OS X. Supporting Bricksmith models is a must-have, much like supporting MPD models (#7).

The parser doesn't support multi-part files (MPD).

Currently it gives an technical and not at all user friendly FileNotFoundError message with little details in the console. Obviously the error message displayed needs to be more understandable, and the console give proper details.

I was refactoring future milestones after the rewrite was moved to 2.0, but I didn't finish my work. Finish it so current issues can be properly assigned and completed.

Hi guys! I cooked up some Blender Cycles materials for all the LDraw types of materials. If you'd like to see them, click below. :)

http://rioforce.wordpress.com/2013/10/10/lego-materials-in-blender-cycles/

Hi. I tested the 1.1.5 Version and gave up for a while when i still have the problem that blender onlly gives error when importing the ldraw file. Yes it is the same model as last time but i have done following. I have imported it into LDD and then exported it as an Ldraw file. Now it looks like one file for the Whole model. No submodels in it.
I getting a file not found error. It loads OK in Ldraw.

the current master codeline (up to commit f3a7dd4) to me appears to have a bug at the global variable "paths".

It gets initialized ONCE as empty array paths = [], but EACH call of the function "locate" appends more and more values to it.

The fix is easy.
Simply initialize it ONCE, BEFORE all the part loading stuff starts.

the installation process of import_ldraw.py currently
requires a user to manually edit that script and hack in the ldraw
installation directory, despite this option is available in the Blender GUI
and also is persisted in config.py.
Thus, the requirement of patching the script can easily be dropped:
before starting the real import, simply check if the ldraw installation path is valid.
you can do so by checking

• if it exists at all
• if a file named ldconfig.ldr is present there
  If it is valid, do the import.
  If it is invalid, show a messagebox to the user, asking him to edit the path
  in the GUI options.

There is no real need to patch the script on installation.

Is it possible to use the un-official stud with the LEGO logo on it to import? Someone on my blog wanted LEGO studs, but the importer wouldn't support it.

http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/logo.dat

http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/stud-logo.dat

The LDRAW models seem to have a texture information for mapping the LEGO logo onto the studs. This UV information should be supported by the importer because it will give us the possibility to use a picture as a bump or displacement map.

Targets for version 1.2.0. Items can be pushed back if needed.

• Add "Spaces between bricks" import option (92d510f)
• Beta support of LSynth bendable parts (#79)
• v1.1.5 is five times slower (#61, #73)
• Add operator presets to save import settings (#42, #65)
• Import options for spaces between bricks for added realism (92d510f)
• Any open issues for this milestone

I realized that 1.1.5 takes really long to import. I made a test with a not that complex .ldr.

In 1.1 it takes 1:45
In 1.1.5 it takes 9:45

I have completed some rough code to do this, but it is not very safe, and I doubt that it is multiplatform. Please review and comment. Please post errors if possible!

https://github.com/Tribex/Blender-2.6-LDraw-Importer/tree/configuration_testing

Config file is located in BLENDERCONFIGDIR/BLENDERVERSION/scripts/addons/LDraw_Importer_Config/config.py

It should use the correct path separators on other OSes, but in WINE, I can't type in the blender window (Anywhere), so I can't change the value to test it.

It does start correctly on WINE though :3

How it works:

1. When first starting up, it fills the ldraw dir box with the standard OS paths like normal.
2. Once the user changes a value in the ldraw dir box, it saves it to the file mentioned above.
3. The box remains the same through the whole session unless changed, in which case it saves again.
4. When blender is restarted, it uses a naughty bit of code to basically insert the contents of config.py into ldraw_importer.py at runtime, and fills the ldraw dir box with the user selected path.

In Readme.md, the contributors list needs to be in a uniform pattern. Either by date order of contribution, or alphabetical. Currently, it is sorted by the importance of the contribution. Not that I'm complaining that I'm near the bottom of the list ( 😉 ), but it needs to be in a standard order, because there could be a lot more contributors since this is gaining popularity (a little bit).

Also, the contributors list in the script is too long. It either needs to say "See website for full list", or "David Pluntze, le717" (because it does say Author, not contributor).

Since Blender is going into it's 2.7 line soon, and obviously nobody uses Blender 2.5 or 2.4 (if they do, the original script will work for them), we should rename this project from

Blender 2.6 LDraw Importer

to

Blender LDraw Importer

(The Blender in the front is just for clarity on GitHub, the official script name should be LDraw Importer).

The current LDR Importer 1.1 contains some "IsPart" flag return value
of function "locate".

However, that information isn't really useful currently as far as I can see,
because it is only used for some internal logic of the importer program,
which I suggest to abolish completely.

The only use for that information is to add a visual gap between parts.
This can be easily achieved by scaling down each part by a tiny, tiny amount.
The important thing is to only do that for parts, and not other files like
primitives or models.
You cannot determine what is a part and what not from its file location.
Instead, the only reliable information what is a part is contained INSIDE
a ldraw file in its header. There is a special header line
0 !LDRAW_ORG ...
for that purpose. It states the file type after this prefix.
There are only 2 syntaxes which inform you about that a LDRAW file is a part:
0 !LDRAW_ORG Part ...
0 !LDRAW_ORG Unofficial_Part ...
Note that the ... stand for an arbitrary text following.
So if a file contains this header, it is a part.
And if it is a part, and the user has enabled the option to create visual gaps,
then you can scale down the part a tiny, tiny bit to create that gap.
This will add a lot more realism to your imported scene.

I am running Blender 2.69 32bit on Windows 7.
I unpacked its .zip file to C:\Program Files (x86)\Blender 2.69
and can run it fine there.

I added the LDR Importer script to it and can execute it successfully.

However, I cannot import files using it.
The script seems to try to write to files below the C:\Program Files (x86) folder,
which it isn't allowed to. Here is the output Blender generates on stdout:

Traceback (most recent call last):
File "c:\Program Files (x86)\Blender 2.69\2.69\scripts\addons\import_ldraw.py", line 1083, in execute
saveInstallPath(self)
File "c:\Program Files (x86)\Blender 2.69\2.69\scripts\addons\import_ldraw.py", line 1101, in saveInstallPath
os.makedirs(config_path)
File "c:\Program Files (x86)\Blender 2.69\2.69\python\lib\os.py", line 266, in makedirs
mkdir(name, mode)
PermissionError: [WinError 5] Access is denied: 'c:\Program Files (x86)\Blender 2.69\2.69\scripts\presets\io_import_ldraw'

I think the script needs some fixing. On Windows, it should not try to write to the tool installation path. Instead, a tool's options are stored in a special folder per-user, and that is below

C:\Users\YourUserNameGoesHere\AppData\Local\LDRImporter

or

C:\Users\YourUserNameGoesHere\AppData\Local\Blender

As a workaround, I am moving my Blender installation folder outside of
C:\Program Files (x86), but that's not something I really want to do.
All my programs shall be below that.