___

Well, not sure of, I just tried that one brick, but today I'll try some others and let you know immediately afterwards...

:) ok, second try: - I made model in LDD which has hose flexible 8.5L brick in it - I need to export it to .ldr because of conversion to .obj in LeoCAD to be able importing it into Blender 3D...uffff :D - hose flexible, as Classicsmiley exactly said, isn't normaly exported from LDD to .ldr file, BUT there is a workaround by modifying file called ldraw.xml in LDD main directory, by adding corresponding code that translates normaly before unsuported bricks so that they are exported, better said written into .ldr file exported from LDD, because every brick in LDD has their own respective number that is writen into the .ldr file - PROBLEM: for some reason the hose flexible IS NOT EVEN KNOWN BY THE EXPORT - I mean it is not outputed at all cos normaly all bricks should be outputed and those that are not translated in that ldraw.xml file are not written into that exported .ldr file...or at least I understood the process like that, maybe I am wrong. ...so, and I think it is because during export from LDD it does not output the brick number correctly (hose flexible 8.5L number should be according to LDD "64230"): simple check can prove it >> put in you model brick lets say "3005" (BRICK 1x1), in the ldraw.xml find the row with its number and change the .dat file number for LDraw beside it to LDraw number 73590a.dat which is our hose...now export that one brick from LDD as .ldr file and load it in MLCAD...you will have our hose loaded. Hope you understand what I am saying now (sorry english is not my native language but I really try so bear with me :D ) Sumary: can anyone confirm that LDD miscorrectly outputing hose brick number and therefore that workaround via ldraw.xml does not work for it (cos simply there is no "64230" outputed, maybe LDD outputing it under some other number???)? sorry, but you did not understand what I write...I wrote it again while ago in a more detailed way... P.S.: yea, I understand that the flexicity will not be there, but just the brick itself...I want to know the principle if it is outputed thru ldraw.xml or not at all

not sure if it can be considered as error but see this post of mine (having no reaction yet) http://www.eurobricks.com/forum/index.php?showtopic=95280

can someone clarify if brick #64230 aka "spiral tube w. tube stud" aka "hose flexible 8.5L without tabs" (in real LEGO sets it is numbered "73590c01a" http://www.bricklink.com/catalogItem.asp?P=73590c01a) is actualy realy interpreted as #64230 during export from LDD? What I mean is that when I try to export it from LDD to .ldr it simply isn't there at all although I did edit ldraw.xml in LDD directory to implement it...and yes, my added one line script is implemented ok cos if I change 64230 for anything else it works like a charm. Simply to me it looks like real internal interpretation of the brick inside LDD is different than it should be, it is "64230" - can anyone test it, please? cos I am like completely mad about it now...

Hi Does anyone knows how to bend hose in LeoCAD? I did search web but there is so little about LeoCAD there, almost nothing, just some simple short basics, nothing else...no mention about bending anywhere at all. So does anybody know how to do it, please?

What I really need in LDD right now is DIRECT EXPORT TO .OBJ FORMAT pleaaaaaseeeeeeee, because exporting to .ldr, then loading to LeoCAD and exporting back to .obj introducing some real problems of missing parts (!!!)...ah :( And editing/adding those missing parts directly in LeoCAD before exporting to .obj is not solution at all: I will probably never understand why these sw except LDD do not have such highly expected function thing like AUTOMATIC BRICK SNAPING? Gee, and ppl are wondering why so many choose LDD instead of LDraw...well, now you know and it does not help that LDraw have probably the best db of LEGO bricks and has much more editing options than LDD because it really lacks that one essential feature above: like in real LEGO most people want to open it up, select bricks and start building, not thinking 2 hours in nerves about why and how do I need to aligning every single brick by hand like in some laboratory and still not have expected result, most of them grab LDD just for this reason alone, sorry for that but I had to say it being completely frustrated with LDraw compared to LDD - result I make in LDD like to 10 minutes takes me in LDraw whole day and still not there simply because of that strange workflow...LDraw really is not for average people, and THEREFORE I PLEASE FOR THE DIRECT .OBJ EXPORT FROM LDD. P.S.: sorry I did not want to sound rude but I needed to descript my frustration with LDraw (MLCAD) workflow cos if it would work like normally expected (if I move brick in some close distance it snaps pins to each other automaticly, that's it)... :( P.S.2: reason is for importing into Blender3D, I did try technik using .lwo mentioning elsewhere here in the forum ( http://www.eurobrick...ic=35736&st=250 ) but compared to .obj results it was much worse and mainly much much complicated with unpleasant color/material result, to me .obj import is the best way but yes you have to edit materials manually, but that is normal I guess.

I did try updated ldraw.xml v4.40 but had no success with exporting LDD part 64230 aka "Hose, flexible 8.5L"knowing it exists in Ldraw as 73590a.dat: LDD it simply does not write the part into the exported.ldr file...so I edited the ldraw.xml myself adding the part like this: <Brick ldraw="73590a.dat" lego="64230"> //nevermind transformation tag, I just wanted to see if it shows up in MLCad... ...but to my surprise it did not help - LDD still did not write the part into exported .ldr file at all...further observation of the problem showed that it has something to do with the number representing the brick in LDD, like it is not 64230 or something like that cos when I randomly write it as some other part (manualy) it simply works, just not with 64230 - anyone knows what is going on here? :(

Sorry, I know I shouldn't laugh but I can't help it!

Any link to that book or intefview or name or photo (anything would be great )?

no problem

well, what to say... OK, sorry once again for that

487 - Space Cruiser Theme: Space > Classic LDD File (LDD 4.3.6): HERE Known Inaccuracies: - decorations are missing - brick 3430c03 replaced with custom solution - brick 3039p34 replaced with 3039pb45 - brick 3039p23 replaced with 3039pb41 - brick 122c01 replaced with custom solution Extra: - added light grey background instead of transparency (.png -> .jpg)

Oh, sorry for that - my fault, it looks like I am too quick even for my own brain or something

not sure if it's a bug but this brick with name "Brick, Round 2x2" number #3941 (http://www.bricklink...Item.asp?P=3941), has completly different number in LDD, it's #6143 - is it OK? Confused...

OK, got it! Thanx to all for help...this is what I wanted (90% - some adjustment needs to be done but else it's as it should be now)

well, actualy, not quite the right colors etc. BUT I guess I made it (+ as a bonus I added pseudo-milky way in yellow ), see example pic below What I used was this customized code (I customized it from POV-Ray website example about "sky_sphere"): sky_sphere { pigment { bozo turbulence 0.65 octaves 6 omega 0.7 lambda 2 color_map { [0.0 0.4 color rgbt <255/255, 255/255, 0/255, 0.5> color rgbt <1/255, 10/255, 1/255, 1>] } scale 0.05 } pigment { gradient y color_map { [0.2 color rgbt <255/255, 255/255, 255/255, 0>] [0.45 color rgbt <0, 0, 1, 0>] [0.55 color rgbt <5/255, 10/255, 15/255, 1>] } scale .65 translate -1 } } background { color rgbt <5/255, 10/255, 15/255, 0>} I added this into *.pov file after "camera{}" part, and...voila - here we go! P.S.: simply, in LDD2POV-Ray do not include "background", nor "Base plane", and later add to generated *.pov file the code I posted above, and that's it...now the next move is to implement that reflection part from hrontos' code example - basicly what I want is just the reflection without any base plane (will try use "rgbt" instead of "rgb" using full transparency (just a guess, do not know if it'll do what I want it to)

And as for the "background gradient", I edited *.pov file like this background { texture { pigment { gradient y color_map { [0 rgb 1] [1 rgb <0,0,1>] } } } } ...but no success ending up in error I even try to exclude parents "texture {}", and also "pigment{}" (later), leaving just gradient and color_map but also no success

No - I do not have them in the same folder, there need to be some other problem, anyway when I close both programs and then start them again everything is OK until next change - then it needs to be restarted again and after that everything is OK once more (simply: every change needs to be followed by restart of both SW or it will giving those errors and crashes), strange but this is how it is and how it works, probably normal - who knows? EDIT: sorry - first I thought it is reaction to my post, now I see you're reacting on someone ese Thanx a lot - will try that, definitely BTW: where exactly to add that code - to which file? Should I add it somewhere to *.pov file, or should I create some *.inc file and then include it somehow, or...? EDIT: oh, I am really horrible - again, I just realize I managed it myself tommorow (being programmer I did somehow ) - anyway thanx a lot for helping me But what I found is that even I was able to do it (gradient baseplane) it depends on camera if it'll be visible or not and that is what I need to solve now...maybe your solution (scale and translate params) will do exactly what I need, as I said before will try your solution now ... P.S>: well, now I think that what I need is more like "BACKGROUND TRANSIENT" (instead of the one color that is selectable in LDD2POV-Ray GUI), not "base plane gradient", because base plane is basicly "bottom", not background, so it really depends on how I have my camera used and I quite offen using my cammer in "extreme positions", you know - is there an option to set BACKGROUND gradient instead of one color (I noticed that in .pov file there is this code about background: background { color rgbft <5/255, 10/255, 15/255, 0, 0> } ...but when I try to edit it the way I supposed it could work it doesn't - any solution for this (if any at all is possible)?

...anyway, changing the Raidosity preset should help, that is what I needed to know

Well, in my case as Radiosity_FAST took me to render from 2 to 4.5 hours I think no, it cannot...at least not here definitely BTW: I wonder in what case with what PC configuration it could take 1/2 hour with complex models like mine, really? My config is quite good when it comes to what counts in rendering (6-Core 3.4 GHz CPU AMD)

Ok, aha, so if I use FINAL preset it will dissappear, right? But it will be like 2 days of nonstop rendering

Today I noticed some strange artifacts when rendering in "FAST" Radiosity preset: some bricks are like "glued together", and there is sometimes noise in bottom reflections, see picture below

Right, but to me it's a weak excuse, cos that way we end up in the world without any real values where only "what is now/we liv ejust once" counts which is a road to oblivion And as for the "Super-owl tapes" (LOL): who cares anyway except you USA ppl? C'mon!

BTW: can POV-Ray simulate something like "box environment"? I mean as if the model was placed inside a "box" next to the walls, maybe to the corner...?

Well, now I really do not know, completly messed myself up in confusion - maybe it is a bug in LDD2POV-Ray or in POV-Ray itself, but when I change any value in that file, and error occures and then change it back to the one that did work, it still give me error ending in crash. If I close LDD2POV-Ray and also POV-Ray, then change values to those that previously didn't work, now it suddenly works OK until I change any value again, go thru converting process once more and again errors and crashing in POV-Ray - is this behavior normal?