You could have a look at my version of the importer in #69. I corrected this and some other stuff.

from ldr-importer.

I would like to but where to download your version? When I open that link there is not link to your file

from ldr-importer.

I think I understand your issue. For example, if you rotated a brick on it's side in MLCad (or another LDraw program), you want the brick to be set to that rotation in Blender. Basically, Blender is applying the rotation of the brick so it says 0. (I guess that's right?) We will look into this. Currently, we are working on a new rewrite (look in the rewrite branch of the repo) and it should fix lots of issues. I think I'll label this to be fixed in the rewrite. :)

from ldr-importer.

@rioforce yea, you got it right, that is what I meant, see: as I said elsewhere I made addon that works together with your importer and part of it was that it automatically replaces all bricks from my array with bricks from external .blend file having for example grain on skew part on slope bricks etc., but I was facing this proble mthat bricks were replaced very fine except the rotation

from ldr-importer.

Sorry, I assumed you knew github.

Here's the link to my fork: https://github.com/Banbury/Blender-2.6-LDraw-Importer/tree/rewrite

Copy the io_ldraw folder into the addons folder:
c:\Users\AppData\Roaming\Blender Foundation\Blender\scripts\addons\

from ldr-importer.

Banbury, I tried your importer on Car.dar, and the headlight 1x1 rounds plates are set to the 90 degree rotation, unlike what bublible was talking about. He wants the rotation to not be applied to the brick.

from ldr-importer.

yea, what we need actually to do is just SET THE ROTATION NUMBER VALUE to the corresponding field in Blender GUI WITHOUT REAL RE-ROTATING...so I think you can rotate it in the script so it becomes prerotated "wrongly" by the amount needed as value for GUI rotation field AND AFTER THAT actually physically rotated it by setting the right value to the Blender GUI ;) ...that way the bricks will be rotated as they should + they will have also the right rotation value in the Blender GUI

from ldr-importer.

hey guys, to me just as a concept, it looks quite easy:

• when taking rotation data from .ldr file save it to temporary variable - maybe even array, then set rotation to 0, so when placed to scene they will be wrongly rotated for a while...
• after physiscal placing the model to Blender scene APPLY those variables for all bricks and that will make the magic for us having our bricks still rotatetd right but having their real rotation values in Blender GUI... ;)

See I would do it for you myself like no problem,,it is quite easy part, BUT I am really new to Python so I do not know which part of your importer deals with .ldr rotation values...actually Imsaw something as matrix which values looked to me as it could have rotation to it but never figured out how it works, but I guess you know so here are my two cents...

from ldr-importer.

Yes, I struggle at times with Matrix. Like I said, we'll look into this. This could be a valuable feature. I'll see if I can look into it maybe tomorrow. :)

from ldr-importer.

@rioforce great, just let me know if you will then, please

from ldr-importer.

I forgot to tell you, I looked into the Matrix rotations in the normal script (not the rewrite), and I couldn't get it to stop applying the rotation. Too many things rely on it. :P I'll have to look into it again, and see if I can fix it in the NextGen rewrite script. :)

from ldr-importer.

pitty there is non one who would be able explain me how the Matrix thing work, maybe if I understand it I could play with it too

from ldr-importer.

guys question: how can I print to console or Blender info panel from my script if I want check some variables? If I use print(someVariable) there is no output anywhere...?

BTW: big thing: SET BRICK ROTATION TO BLENDER GUY - DONE ;) well, it looks like I made it for you/us again... :)

from ldr-importer.

@bublible You have to bring up the Blender console to see anything displayed using print(). Either run Blender from the command line or (the easy way), after opening Blender, click Window>Toggle System Console.

Also, if you are running the importer, you can use our homespun debugPrint() function to help better identify your messages. 😉

from ldr-importer.

@le717 no, it does not work, no output, I did try exactly this in the first place but there is no output

• right, I am updating script of your importer, as I said above from this point on I achieved what is written as headline of this post: brick rotation interpretation is set exactly as it should to Blender GUI rotation field under object menu, just for some reason your code treat some stuff very strangely therefor I need to see what it actually do with variables during runtime...so any other solution how to display my output?
• also even your debugPrint does not work for me...I am using portable Blender but it definitely should have no effect on this

P.S.: using official version 2.70a

from ldr-importer.

well, now as I actually write my own kind of debugger (write to file, the only solution that wrosk, gee) I am trying to understand your importer code but from what I see in mymdebugger I am a bit messed, for example: I needed to load .ldr, read it and save every line as new index in array, so I searched your code tought I understood what you are doing and grab the part where I thought you parsing that .ldr but my debugger showed me that only 1st iteration actualy read from that file and all next iteration rewrites it to like info about every single brick (I am testing with 4 skew bricks)...wtf? :D:D:D:D:D (fun intended)

I reused this part of your code:
[code]

my global variable

linesG = []

fname, isPart = locate(filename)
file_encode = checkEncoding(fname)
if os.path.exists(fname):
with open(fname, "rt", encoding=file_encode) as f_in:
linesG = f_in.readlines()

my debugger

dbg(linesG, "a')
[/code]

my logic told me that fname should be name/path of our .ldr that should appears just once in my debugger but it looks like it is executed also for every brick like if there are 4 bricks in my case it executes 1+4=5x...strange,,isn't it? Or I did not understand something, could it be ;)

Guys, simply: what variable in your importer holds actual path to .ldr file and filename name to be able open it?

I placed my code in "def init()" section/function inside your "import_ldraw.py" - shouldn't it be executed just once? It looks like it executes as many times as number of bricks in a set.

• also for some reasons I do not understand I can read global vars but not write new value to them from within your function (def init) in LDrawFile class...why?

very very very very very strange to me comming to Python from FLASH AS2...unbelievable :(

from ldr-importer.

hey guys, please answer me someone this question:

to my opinion you did something wrongly in your script - now please say if I understand this correctly or not: as I gone thru your script many many times trying to understand " what id does and where it and why" I noticed you actually open .dat file containg mesh info for concrete brick and then you construct it in Blender upon those values, right? BUT, THE BIGEST BUT, READ - and this is where you scripted it wrongly, I think, but I cannot figure out where is the section that needs to be changed/rewriten cos I am not able to find it - then you creating mesh RIGHT IN 3D WORLD UPON VALUES FROM .LDR FILE instead of brick mesh, right? Cos this is only logical explanation why you are using position and rotation values from .ldr FOR EVERY EDGE YOU MAKE which is wrong. I don't know still much about Blender nor 3D modeling, BUT what I know is this: every .dat file from LDraw - when we are talking about bricks .dat files (LIKE 3004.dar for example) - contains ONLY COORDINATES FOR ITS MESH NOT COORDINATES OF 3D POSITION OF THE OBJECT/BRICK IN A MODEL, those are only mesh info, e.g. how the object looks and how to build/construct it, not where to put it in 3D of model,,those infos are in .ldr and meant to be for finished brick alone...now please if I understood it wrong please correct me cos I need to understand this section right.

So if its like that and you do exactly that, it is wrong,,that way we never get out real rotation in Blender 3D space. We need to JUST CREATE EVERY OBJECT FROM ITS .DAT IN NULL CORDINATES nothing to do with bricks 3D info in .ldr file, that's all and then we apply those 3D values from .ldr TO FINISHED OBJECT ALONE, it should be that easy. But as I said from what I see and from how I understand it you are placing every edge of mash right away in 3D final place.

Cos I already made somewhat working script implementation into your importer that rotates final brick not mesh but because you did what you did it is strange, brick is rotated right but some of its parts dissapeared or are shifted etc. I was playing with it trying to find a way how to build/reset mesh strictly uppon .dat values not messing with values from .ldr but as I said your code looks to me very messy guys and if I thought I found the section and did my bits and peaces to the script then the bricks were partly missing, sorry - you need to sort it out first, if I would only knew where is exactly the section and why for gods sake you combining brick mesh values with those of brick in .ldr...oh, that Python snake! :):):)

from ldr-importer.

Hi,

I know that the script is broken and slow and really poorly put together. We did not write this script, however. Le717 just improved the script greatly (even though the importing sequence is totally wrong). We are currently working on a re-write of the importer script that should solve a lot of errors. Unfortunately, the old script is very non-expandable, so that's why we are writing a new one. If you'd like, you can look into this script and see if you can solve your issue.

https://github.com/le717/LDR-Importer/blob/rewrite/import_ldraw_ng.py

I don't know a lot about Python, just enough to find my way around the script to add some features, so unfortunately, I cannot answer most of your questions. The reason I think that the brick is importing pre-rotated is that the importer constructs it in it's side instead of just rotating.

from ldr-importer.

@rioforce I know why it does what it does as for the rotation, please read again my,previous post :) I only wonder why it is writen this poorly as ypu said :D OK will check new one and work with that

from ldr-importer.

Hey guys, I do not know in what state is new code of import_ldraw_ng.py but from now on I have functional version of it merging things right (your original code did not), appending colors (this part was completely missing, now implemented), but at this time it only works for Cycles (cos that is renderer I am using but I transcribed parts feom old version and implemented into new code so there is also part for Blender renderer but it actually puts error of encoding so someone from you can check it) + also you probably did something wrong cos upon my merging there left one "p,ain axis" in the scene except the bricks themselves, here:

#87

• this is my quite simple testing .ldr file I am using so you can try it yourself:

http://www.queryen.com/download/testPreRotate.ldr

from ldr-importer.

• BTW if anyone still cares I updated original v1.1.5 so now it sets the right rotation to Blender GUI, I tested with that small testing file I posted above in my previous post...but unfortunately whenntested with "real" model it near the end complaining about indexerror so I need to look into it and find out what's wrong, anyway it works as it should ;)

EDIT:
oh, it looks like Blender does not like too many list values,,my model has 533 bricks so its 533 list values and Blender simply complains about it...or it looks like that to me, so does python/Blender has something like max acceptable number of list values?

EDIT 2:
Definitely...I have narrowed that "IndexError" down to the fact that Blender has some limit of maximum data capacity in every list, so now I need to know if it can be set limitless or should I try makingnit some different way (hope not)

EDIT 3:
Solved it! :D ...problem was slightly elsewhere as always, haha

from ldr-importer.