again not MY-own-creation, but SOMEONE-ELSE's-own creation (SOEOC):
a minifig made of wood, carved with a CNC wood cutter. beautiful!

http://www.therpf.com/f11/3-1-lego-minif...nc-134975/

I think that when a forum post gets edited,
it should be shown as "unread" again to all readers.
Currently, that read/unread status doesn't seem to be affected by an edit.

Looks like LDraw is loosing one of its strongest advantages over LDD...
LDD to POV-Ray™ Converter

While testing links in the new LDraw File Format Standards section of the web site, I noticed that every time I click on one of the links in the table of contents, it apparently reloads the page. (It definitely communicates with the site, and that communication introduces an extremely noticable delay). The same thing happens every time I hit the back button immediately after having navigated one of these in-document links.

Doing a little digging, I discovered that this is caused by the main site menu URL for the document being blahblahblah/218.html, while the table of contents links are all blahblahblah/218/#yadayada. If I point my browser directly at blahblahblah/218/, instead of blahblahblah/218.html, the problem goes away. Is there any way to use the blahblahblah/218/ version of the URL as the one from the menu, and make that the official URL, instead of the blahblahblah/218.html one?

Hi,

all articles belonging to the LDraw.org File Format Standards section have been transferred to the new CMS.

I would appreciate if someone could browse the articles under:

Home > Documentation > LDraw.org File Format Standards

and check if there are broken links (internal and external).

Many thx,

w.
(LDraw.org Content Manager)

Hi again,
another version has just been released and is available from http://sr3dbuilder.altervista.org/

No significant improvement this time, just some fixes, most around the UI.
Here is a list of changes.
Enjoy!

Sergio
________________________
Fixed
- Some issue in the standard user interface introduced with last version
- Some issues in the new experimental UI
- Selecting a brick connected to a hidden one can cause application crash or image corruption
- Some useless connections were added on some rounded parts
- Preferences about Seams and AntiAliasing quality were not saved

Changed
- Image quality should be a bit better with a little high contrast between lighted and shadowed zones
- Some changes in determining face lighting

Added
- U key shortcut to switch UI mode

well, not MY own creation, but Megx's:

http://www.themarysue.com/lego-bridge-in-germany/

There seems to be something wrong with ether 32068 or 32069 (i'm using them in set 5533), they won't fit together (latest lib).

The beam seems to be 4 units to small.

The header of 32068.dat states "reduce size 20 to 18 LDU" so that might be the cause of the problem (reduction instead of inc) ?

I've recently obtained a new computer and therefore reinstalled all my LDraw programs and library from scratch. It is a good thing to clean house now and then. However, I've run into a serious problem caused by progress. I'm very happy to see that so many unofficial parts have finally been moved to official in the many recent library updates. However, many parts have changed part numbers over the course of many updates. I have hundreds and hundreds of LDraw models archived on my computer, and I find that a great many of them are now broken. I don't mind updating them, the problem is that there is no easy way to find out what happened to an old part. When an old part doesn't load, it doesn't show up in the parts tracker and it doesn't show up in the official library either. I am left scouring the Internet trying to find out what 30039.dat was (for example) so that I can replace it with the current part. Is there any kind of database which tracks old part nnumbers when they change? This would be really useful. I've got my own table now with about 30 parts in it.

Hello all,

I was playing around (testing) in my dev versionof LDCad this weeked when I noticed this:



(You can look through the IR receiver)

In the header of 58123 BFC is enabled, so are the subparts, but then I noticed the comments in some of the subfiles ("Needs Work: inner side not modelled").

This made me think, my rendering loop is correct after all, but when I open the above little test ldr in LDView 58123 seems to be rendered without culling.

Am I missing something here? In short what's the (by authors) expected correct behavior here.