Superkalle

LDD Manager uses the build in zip-functionality in Windows to extract the LXF-files. It could have been that this functionality was lost somehow. Can you try this: 1) Open a command prompt (Start Menu > Run > cmd) 2) Paste this into the command window and hit Enter: regsvr32 %windir%\system32\zipfldr.dlli

The files actually originated from this forum (or more specifically from the LDD Team in Billund). Here you can find the entire selection. In any case, in this case it would have been better if you started a new topic instead of bumping a 2 year old topic. I've taken the liberty of breaking your post out and made a new topic of it.

Renders can look a lot better for sure, but they can also vary a lot depending on setup, lighting, shadows, color definitions etc. I suppose in this kind of "reference" topic it's better to have a more standardized and neutral look. I think in the Ldraw topic however it makes more sense to allow renders since there are so many different editors anyway. But let's hear what Calabar says also.

I fully see your point, but because of the limitations in how colors have been handled at BL it's not trivial in all cases. But, I'll have a look at mapping LEGO 315 also to BL Flat Silver. The problem though is that then you start doing a lot of "magic" behind the scenes, people may be confused why both color 315 and 179 will transform to Flat Silver in BL. At the moment, LDD Manager simply exposes an underlying problem that is already there from the start. After all, the problem is really the fact that the AFOL community at the moment is caught between two "systems". The BL one for ordering, and the LEGO one for LDD and/or Brickset lookup. The only long term solution would be that BL starts using LEGO-ID's (which is now possible, since all the data is published, for example at Brickset). So, in any case, your best bet (at the moment) is to do as follows: 1) Look at BL what color the piece have there (for 4655241 this would be Flat Silver) 2) In LDD Manager check what that color that corresponds to in LDD (which will be 179 Silver Flip-Flop). 3) Use LEGO color 179 Silver Flip-Flop in your LDD model even if it says 315 in Brickset. In the meantime, I'll think about some kind of solution to what you wrote, because you do have a point.

LDD Manager actually uses the "correct" mapping as established through a long a tedious detective work (in great cooperation with Aanchir). Even so there are off course times when there isn't a straight one-to-one mapping between LEGO and BL, mostly because members at BL have not detected a new color, even when TLG introduce one (or similar cases). So the mapping in LDD Manager is actually the best we have at the moment (and I'm not saying that to brag ). The easiest solution to your problem is without a doubt to re-color the parts in your LDD model (or you can use the feature in LDD Manager to do the same thing) to make them map to the "correct" BL color. LEGO color 179 Silver Flip-Flop maps to BL 95 Flat Silver LEGO color 315 has no current accurate BL color, so don't use that.

Excellent work. Looks really nice

Good question. You can start the topic here in the Digital Design forum, and then we can see how it evolves. Oh, and speaking about ultra high realism, I just saw this. It's so good it's almost scary. And it's in realtime.

No, I don't think it ever worked. I was just wrong, simple as that I'm not sure if it's legal or not. But could well be legal actually.

Wow, that is weired. Are you sure? I'm not in front of LDD right now, but I was pretty certain that connection worked.

That is true And to add to that, in industry, renders are often used to eliminate the need to take real product photos, which can be very expensive. For example, the entire production of images used in most product configurators are rendered, down to the stitches in the leather seats.

Good question. So, in the spirit of geekyness, I decided to start this FAQ Q: Why do people want to make renders of LEGO models? A: I suppose they want things to look like as close to reality as possible. Q: Why do they want that? Why not just a simple screenshot? A: I guess because they want their model shiny and nice (i.e. like in real life). Q: So, how close to reality can we get then? A: Not sure, that's why I started this topic Q: But is it really interesting to get a render to look exactly like reality, i.e. with slight color differences, wheels that are randomly rotated, camera blur, dust speckles etc (i.e. that you introduce imperfections)? A: Don't know. Maybe it's enough that it looks shiny and nice, like traditional renders. Q: But you think there is a trend towards even more realistic renders? A: I would guess so. You know - Moore's law and everything. Q: So, what will the consequence be if the renders become so good that you can't even tell them apart from the real thing (i.e. a photograph)? A: I don't know that either, that's also why I started the topic. But one immediate consequence would be how to judge MOC contests.

You are right about all the illogical connections allowed today in LDD, but I think for the future we will see that more and more of those will be fixed. My main idea was a little bit that it goes both ways. Physical allows some things that digital doesn't and vice versa. The advantages and disadvantages of physical vs. digital evens out. Anyway, my conclusions is that for the main judgement critieria (which I belive are Object, Design & Presentation...i.e. a) what it is/the scene/idea, b) does it look good/cool, and c) is it presented in an nice way) it really doesn't matter if it's physical or digital. (Ugh, I get an uneasy feeling myself when I read what I just wrote, because I like physical! ) On topic: Question: Is the battle damage, scratches etc done in movies, games etc done with a "randomizer" function, i.e. you can apply "damage" and it will appear on the surface in a random pattern, i.e. if you re-apply it, it will appear differently etc. Or is the damage applied "manually" on the model (i.e. you "paint on" the damage exactly where it should be). and then the image/movie is rendered?

Yes, that one was known. I was told that the reason it has not been fixed is that cable functionality is implemented in the SW, not in the brickset. So a new version of LDD is needed. Nope, but it is now

Very good point! Here I think it goes both ways. Physcial models can be cheated with "illegal" connections. Digital with unrealistc physics. Agree, and a very valid point. We actually allready had a case like this at EB a year ago and it was hard to judge if it was fake. So a discussion arised how we should view digital entries. But the problems is also: You could reason that "if people cheat, then let them do so - nothing we can do". But that won't be much of a concelation for those that came in second place when a digital entry came first. So it will be a judgement issue no matter how. The main question is what criteria overall should be used when judging MOC contests - Design/Look - Engineering skills - Using legal techniques - Money/can buy many bricks - Having the energy and stamina to build a huge MOC - etc So, which of those are most important and does it then matter if you do digital or physical MOCs? Anyway, going back to topic: I understand you can do manuall photoshop work, planting dust speckes with a "pair of digital twicers". But my question was more if there was/is any rendering examples (regardless of domain) where this such ultra-realistic renders have been done, more automatically.

True Meth Kingpin....

That is a good point. But I must say I see a lot of really bad MOCs buildt with real LEGO that you can barely touch or they'd fall apart. It is almost like builders try to trumph each other in advanced building technics...and many cases it actually goes to far IHMO. In that sense, a LDD model is more "fair" since it only allows legal connections (i.e. no cheating ). Now it's there

We could put it as a request to the LDD Team to have them as separate halves. It has become easier with these sort of requests now that LDD is disconnected from DbM, (i.e. less important to keep it a kids tool). Question is as always and in any case - will they ever be likely to appear as halves in a real set? The small 2x2 turntable has done so (plenty times), but it's also easier to snap those two pieces apart. The big turntable is much more difficult. If there can be some good examples (also of MOCs) that the parts should be abled to use separtly, it's always easier to take at dialogue with the LDD Team. At least that's my experience.

As you all know, there is often a rule in MOC contests that digital entries are not allowed. In some respects, it's a strange rule. I mean, shouldn't it really be the design and engineering competence that should say who shall win, and not your wallet or ability to put plastic bricks together? And no, before you chop me to pieces - I am an avid ABS lover and personally not overly fond of "digital entries" - there is something about the devotion and dedication in building with the real thing. But an interesting question is off course - if a digital entry can't be distinguished from a non-digital, then what happens? Will/shall the rule of non-digital entries be skipped. I just find the question interesting on a philosophical planeFor reference I'm attaching two photos. One un-touched TLG product image (don't ask where I got it, because I don't remember...but it was on the internet somewhere) and the same one photoshopped (downloaded from LEGO.com). If you look at the original one, you can see the colors are less saturated, and you see shadows on the ground etc. The post-processed version looks better, but you can still see the dust speckles, inperfections in the bricks, injections points etc etc. I'm also attaching the LXF for this set.So the question is: is it possible to make a render that is completely impossible to tell appart from the raw, un-touched TLG product image. 5766 Log Cabin.zip

Yeah, the advancement in computer generated graphics is just awesome these day. But I'm thinking about photographs and if a rendered image can be made so it is ABSOLUTELY impossible to distinguish from a photo. I mean, if you zoom in on a photo you can always spot small blemishes (color deviations in bricks, dust speckles, finger prints etc). So, I'm basically asking for cases where someone would enter a render in a MOC contest, and it would be completely and utterly impossible to spot that it's a render. Has such renders ever been made?

I created a separate topic of this: All I can say is that renders you guys produce in this topic are just plain outstanding. Does any of you know if it's possible to make renders that are so good that it's impossible to distinguish from a photo? So I guess I'm thinking with dust speckles and all. Has it ever been done (also outside the LEGO domain)?

You need to be much more specific if you are going to ask questions. If you just write "I have problem with LDD Icon" it is difficult to help. Can you post a screenshot? Also, please make sure you capitalize sentences and use proper punctuation.

My 9 year old just came into the room when I had the triclotron on the screen. "Wooow, that's cool!" was the spontaneous reaction. So Toa, you've got your first customer.

Very cool model! And really innovative! Sure, all those part doesn't exist in Bright Green, and some of the connections may be a bit fragile, but it's a really nice concept. More like that please

In my experience, the best way to get the automatically BI algorithm in LDD to produce good results is to remove SNOT-bricks (put them to the side of the model) For example the wheels of a vehicle. With SNOT pieces removed, the BI is actually very good. And since the SNOT:ed assemblies are put to the side, they will most oftenly be be treated as separe assemblies and will get their own "assembly" instructions. The only thing you need to do manually is to in the end assemble all parts to the complete model. Then make BI generation and skip to the last image (where the entire model is assembled . Then do a Ctrl-K (note that you can rotate the model also in BI mode) from various angles. This final images you insert into the BI document and add some explanatory arrows as to show where the SNOT sub-assemblies go.

Oh, I should have said so in the first post - naturally you may, that was the idea