I just downloaded the latest LDConfig.ldr from http://www.ldraw.org/library/official/LDConfig.ldr
Its header reads:
0 !LDRAW_ORG Configuration UPDATE 2011-06-03

But I already have a copy of LDConfig.ldr, and its header reads:
0 !LDRAW_ORG Configuration UPDATE 2010-06-19

This is supposed to be newer, but in the currently official but older(?), there are four more colours compared to the one I already have on my hard drive.

83 Metallic_Black VALUE #1A2831 EDGE #000000 METAL
87 Metallic_Dark_Gray VALUE #6D6E5C EDGE #5D5B53 METAL
321 Dark_Azure VALUE #078BC9 EDGE #088DCD
323 Light_Aqua VALUE #ADC3C0 EDGE #AFC9C2

What is this file dated 2011-06-19? I don't know where it comes from.
And are those four colours official standard? (I guess so since they are there in the ufficial version.)

/Tore

I wouldn't complain so much about every new step in the LDraw format evolution, if it wasn't that I'm 100% depending on good old L3Lab. There is absolutely no viewer or editor that comes remotely close to its speed and its resource economy. Sorry, Roland's new editor included.

But L3Lab doesn't support colours in "the forbidden zone" as I call it. This is a growing problem for me.
And L3Lab doesn't support space characters in file references either.
And almost every change in the LDraw file specs is done without the least consideration to programs like L3Lab.

I would of course compile a fast and frugal renderer myself if only I had the programming skills to do it, but that's impossible. I'm not even close to that.

Apparantly, it seems to me all focus is on nifty details and impressive effects when it comes to viewers made today. But if it was possible eleven years ago to make an LDraw viewer that still is able to produce fast renderings, wouldn't it be possible to make the same today? And support for LDConfig and the latest LDraw file specs shouldn't slow down things noticable, should it?

If somebody could produce such a viewer, I will (most likely) no longer protest against the other LDraw programs and utilities we leave behind as we "develop" (hmm?) the LDraw standard. But like I said, I still see no real alternative to L3Lab when making huge LDraw models.

/Tore

Since yesterday I've seem to gotten moderator privileges in the LSC section, I think this is by mistake cause this wasn't so during the last committee.

Travis Cobbs Wrote:
-------------------------------------------------------
> Michael Heidemann pointed out that the newly created OMR spec requires that filenames contain spaces,
> while the pre-existing LDraw 1.0.0 spec strongly discourages spaces or tabs in filenames.
> He (quite rightly, in my opinion) felt that this was inconsistent.
>
> So, the way I see it, we have three choices:
>
> 1. Ignore the problem.
> 2. Remove the discouragement text from the LDraw standard.
> 3. Change the OMR standard so that the filenames don't include spaces.
>
>
> My vote is to do go with option 2, at least for spaces.

I very strongly disagree. The space character is the way LDraw separates arguments.

Before taking such a giant leap in the LDraw evolution to accept spaces in file names (if so only in OMR MPD's) has anyone ever considered the consequences? How many of our programs and utilities in use will be rendered useless by this reform? Just because maybe noone in the LSC is using them doesn't mean that noone else uses and needs them.

And what if a space character is accidently placed at the end of a type one line, invisible for us humans but how will various softwares handle it? Is "3001.dat " equal to "3001.dat"? And I have this habit of normally add an extra space before the file reference, in order to make it easier to read. Will that lead to a reference to the non-existing " 3001.dat"?

/Tore

I am a guy making LEGO CGI films and every time when i tried my ldraw file to Blender 3D It fails. I've tried every method :

1. Download the LDraw import Python script for Blender from http://web.tiscali.it/ALV/blender/ but It didn't work niether 2.5 and 2.4 version It just have weird dots where the bricks should be.

2. I used leocad to make LDraw files to 3ds file. It worked but LEOCad didn't have that much of an color pallet that MLCad has. All the color that leocad didn't have just turned to black and it was just chaotic to fix every color close to what I anticipated.

3. It turns out that LDview had 3ds export script and I was delighted of it. However when I tried to import in Blender it won't let me do it. Blender stops functioning and responding.

Furious of these bugs and glitches I threw my mouse and it 's broken. Would somebody help me please!!!
By the way Ldraw.org, please put WORKING 3ds export format in MLCad and LDview. Please I beg you!!!!!!!

If anyone has a solution or has simillar problems please answer this message NOW PLEASE!!!!!!!!

It would be nice if any one could take on this one:
http://www.bricklink.com/catalogItem.asp?P=6158

There is a LDD part shape existing.....

Whilst building the Super Star Destroyer, a thought occurred to me: we have no way of specifying what faces of a brick (if any) required the slope texture. I see 2 solutions:

• Use the existing !COLOUR specification to set a new main color for linetypes that need a slope texture. The disadvantage to this being that it would break MLCad. Yet another reason why Micheal should open source the program.
  
• Make a new meta, something like !SLOPE_TEXTURE, that would go before the linetypes that need slope texture.
  

Looking for an LDRAW model for the new 92438: 8x16 plate. Unofficial or in progress is fine. Anyone got one?
Thanks!
-Bill

Anyone here a seasoned Linux desktop user (with some programming experience)?

With LDCad 1.0 beta out, I'm playing around with getting a Linux version going. But having only experience with Linux server systems I'm a bit lost with all the desktop options out there.

I'm currently downloading Ubuntu wubi (I use Ubuntu server for work so this is at least some what familiar) to get a look, but maybe people think I should use something other for the base development environment.

The goal is to get a (set of) pre compiled binaries to add to the LDCad download site covering most used desktop stuff. I'm figuring when it compiles in Ubuntu 11, it would also go in most other recent distro's.

I'm just hoping to avoid pitfalls by using any info people can give me.

ps: this might be more of a 'dev' thing, but there is no section for that (yet).

Hello all after a long absence. I started a new job last summer, and it has taken up a lot of my time.

I am revisiting a pet project of mine - a Java API to parse and represent LDraw files.
This was started a few years ago when I wanted to create .dat files from AutoCAD .dxf files.
I had a working prototype that got lost in between computers, and am starting to recreate it.

Well, I'm starting over, and was wondering if any one is interested in the effort. If there are any programmers out there that want to see the preliminaries, I can start a project out on SourceForge. The source itself will be initially be in my name, and I need to make sure that anything I put out there conforms to the licensing agreements for the Java3D and the Apache commons APIs. I do plan for the effort to be able to be used for creating Java applications in accordance with the Creative Commons Attribution Licence.

The intent is to:
- Fully represent the part file specification including the standard meta comments.
- Support the Java3D and the commons-math APIs for representing vector and matrix data.
- Actually give me some time doing development work in an area that also interests me.

Once I'm at a point that this is complete, tested, and documented. I'll be going back to that DXF parser and DXF-DAT app I started.

Why Java? I like and respect what Java has become. I know bytecode can be slower than optimized compiled code, but it's not that bad, and my experience is that sloppy programming is what makes a Java (or any) application perform badly.

Why bother? Why not. I'm a programmer and I enjoy programming and even if it never gets accepted or used, I'm enjoying the journey.