iceleftd

I don't think it's a "problem". Here's a comparison image: BlueRender comparison by iceleftd, on Flickr POV has more definition (bevels between bricks, for example) and better shading, but those are white tables and they look light bley in POV. Seeing some other images in BlueRender (by Nachapon, for example), I'm beginning to like the look of BlueRender better. Making the aspect ratio match the resolution fixed the problem (thanks). I think the best solution is to have the aspect ratio default to the resolution size but let it be overridden in the setup file (and then comment out that value in the default file). I don't know if this is the right forum for bug requests, but here's another small one: It really should prompt you before overwriting an existing image file.

Update: I tried getting the standard lwjgl distribution and had the same problem. I decided to bypass Norton temporarily and use the DLLs from the lwjgl distribution. I did a comparison with a recent POV-Ray rendering at high quality. Bluerenderer was about 10x faster (!), but the quality was much lower. What expectations should I have for this project? Is it intended to be a faster replacement for POV-Ray (someday), or just something to make quicker (but less fancy) renderings? A couple of small observations... readme.txt still references Blueprint instead of Bluerenderer When I changed the resolution in the setup to match the resolution of my POV-Ray image (for comparison), the result was that my image was stretched to fit the new aspect ratio (all the bricks were flatter in this case). Not what I expected, and I suspect not what anyone wants.

Same problem Bob reported.

Thanks for the workarounds and this thread in general. I was freaking out as to why I was the only one seeing this problem until I found this. I second the request for a comprehensive list of .ini parameters. While we are on the extended palette issue, high on my list of annoying things in LDD is the fact that LDD does not remember the last color selected on the palette. Every time I start the program or switch themes to extended I see red. It really should remember the last one you picked. Also, I have to hit ALT-1 to get rid of those annoying arrows every single time I start the program. That could so easily be a preference, right? Well, enough ranting for now.

The soccer ball (football) has been confirmed to be the standard old soccer ball mold. Great Ball Contraption fans may begin rejoicing at your convenience! I believe the orange pool ball is also the same part only in an orange color with no markings. Now all I need is the parts list to get the LEGO id for that ball...

Yes, tooltips are there but my point is they don't show the part *number*. Kalle addressed your comment on the issues of molds/part numbers. I don't build from "building instructions" much and I often look up a part I want in the BrickLink catalog or use the mold number on an actual part. I can usually figure out duplicate/similar part number issues on BrickLink but having some knowledge of that in LDD would be a bonus.

That's an interesting point. Take the 2x2 plates, for example. There are two, one for #3022 and one for #94148 which is a newer number from some of the Ninjago sets. I have problems finding odd parts in LDD using the palette and generally look them up by number. I'd hate for them to drop the alternate numbers or the variations (for bricks that have changed slightly over time). That being said, I'm sure they could come up with a solution for true duplicate numbers that allows you to search on both numbers, see both numbers when you click on the brick, but only have one entry in the palette. Oh, and it would be nice to have the number appear along with the name in the tool-tip box when you hover over a part in the palette (at least in Extended mode).

I posted the following bug back in January but it's still there. I've used false colors for some pins to make the issue easier to describe. The blue beam fits quite nicely centered on the green pins or the red pins, but not both the green and red pins. This works in real life, of course. I'm guessing the NXT brick geometry is at fault. If you lay the blue beam on the green pins you can see a slight gap between the base of the beam and the underside of the NXT.

Does the same go for gripes and missing features? If I report them often enough they'll get fixed?

So, where is this list of "known bugs"? It would save some time to not document and post stuff that's already known (to others).

This post is slightly off-topic but still related. I find myself wanting to post about bugs that might just be "illegal connections". I could avoid unnecessary questions if there was a document that codifies the Laws of LEGO Attachment, especially if it had examples with part references. Is there such a thing? Here's an example that is probably an illegal connection. In real life, I created a circle out of #3063 Macaroni and then placed another circle on top of it, rotated 45 degrees. In this image you cannot place the circle on the right on top of the circle on the left without LDD rotating it back to match. You also can't place the yellow macaroni on the green plate in that orientation (although it works in real life). The same issue occurs in LDD with the newer #85080 Macaroni, but I couldn't test it in real life.

Thanks for pointing this part out. The use of a thin liftarm as a substitute permits the shifting axle to be parallel to the driving ring axle and only 2 LU apart. I can't think of a way to do that using 6641 and the same axle orientation without moving the axles 5 LU apart.

Sometimes all that's needed is the germ of an idea - and you gave it to me. Visually, it looks like the part should be halfway between two adjacent grid positions. I thought about it for a second and figured out that I could hack the file. The result is this: The steps I took were: Export the file with the liftarm in both positions (on both sides of the driving ring groove). Edit both files and find the entries for the liftarm. Calculate the averages of the tx, ty and tz values. Replace the tx, ty and tz values in one of the files with the averaged values. Save this file and re-import. The liftarm is now centered on the driving ring's groove and can be rotated into place as shown. This positioning can be saved just fine and the two objects can be moved as long as they are moved together. If the liftarm is moved separately, it snaps back to the grid and you have to go back to step 1. Obviously this is still a bug that should be fixed someday, I'm just not sure of the best way.

Here's another one having to do with the driving ring for a clutch gear. The red driving ring (#6539) has a channel in the middle of it for a lever to move the ring back and forth. The yellow thin lift arm (#6632) fits in this slot very nicely - in real life only! At first I thought there was a geometry problem with the driving ring but visually I just can't seem to maneuver the lift arm directly over the slot. It's always just a bit off. It looks to me like the resolution of the positioning grid doesn't permit the two parts to meet properly. Is this a bug or is there a trick I don't know about?

Over time I've found several bugs in LDD but had no way of reporting them (at least not to anyone who could do anything about it!), so I was happy to find this forum. Here's one that's been sitting in my lap for a while... I've used false colors for some pins to make the issue easier to describe. The blue beam fits quite nicely centered on the green pins or the red pins, but not both the green and red pins. This works in real life, of course. I'm guessing the NXT brick geometry is at fault. (edited to inline smaller version of image - sorry!)