This post explains the small history line "BFC rationalisation" which appears
in the bunch of updated official files that Chris just has uploaded to the PT for me, thanks, Chris!
I had recently done a systematic syntax check of all currently official files.
Through this I discovered these files having some common glitches, which I ironed out.
They were:
Having previously created a number of animations using POV-Ray for rendering the frames I thought I would try using LDView to render the frames required instead. (Thanks to Travis (author LDView) for answering a number of my questions in this forum which helped me to get this working).
First online result of this can be seen at the folllowing link:
The 'falling parts' code (my software) is new and rather than one part falling at time (which is how I have done these animations previously) now multiple parts are in motion in any one frame. The 'algorithm' is not perfect yet, some parts still 'fly through' other parts - work in progress ...
I was wondering if there is a complement primitive for this file? I tried flipping and turning the 1-8cyls2.dat file. But that does not work. Could somebody please help? Thank you in advance.
Reason for this was that in the current implementation,
when you use that part in a model,
and you assign some color to it,
all edges on metal appear in that color,
this makes that part look weird.
Reason for that is that all edges and optional edges in that file
are coded in color 24, regardless whether they bound plastic or metal parts.
My problem is now this:
I can easily identify quads and triangles of color 494 (metal) and move them to a separate file.
Second step should have been to also move their bounding edges and optional edges there.
Would I have finished that, then the color problem would be gone, because in that new file X.dat,
I would use color 16 for quads and triangles, and 24 for edges and optional edges,
and then reference that file from 2859c00.dat, using color 494. This way, both the surfaces and
the edges would appear in correct color.
However, identifying which edges to move to X.dat is terribly difficult.
There are tons of such edges, and manual selection will introduce lots and lots of errors.
To accomplish this task, I would need help of a tool which doesn't exist yet.
It would let me specify some color, by which I would like to identify affected quads and triangles
(here: 494).
The tool should then run through the file and identify all edges and optional edges which bound
these, i.e., which share coordinates with them.
Using such a tool, it would be easy to find all edges in 2859c00.dat which need to be moved to a separate file.
(Of course, from a logic point of view, each own metal portion should probably go into its own,
separate ~part file, but to me that's second priority. Solving the miscolored edges problem has first.)
Unfortunately, without this tool, I sadly have to give up on this task for now :-(
This afternoon I've been looking at the cool 'unofficial parts library', they looked good on the website but when I opened them in Bricksmith I cept getting 'Bricksmith couldn't find all of the pieces in this file. The following are missing: s\xxxx.dat, s\xxx.dat', (those filenames are just an example) and realized why this was, it's because all of the file 'scripts' / contents when opened in a text editor have an '\' in them when it should be an '/', replacing all of them allows Bricksmith to find the subparts (located in the 's' directory).
Now, the problem was editing these thousands of files so I found a program called textmate ,when I went back the parts opened fine with no errors and had no changes to the file extention.
Here's how to fix this:
Download the unofficial parts library and extract the 'LDRAWUNF' directory to the bricksmith folder so you have the folders 'LDRAW' and 'LDRAWUNF' (LDRAW should already be there as it comes with bricksmith).
Find the 's' subfolder in 'LDRAWUNF'>'parts' and move it onto the desktop (make sure it is moved not just duplicated).
Download 'Textmate' then after installing. goto 'file', 'open'.
Locate the 'parts' folder in 'LDRAWUNF' and in the parts folder select all of the dat files and hit 'open'. (there should be nothing but .dat files in that folder since we moved the 's' folder).
Goto 'edit' and click 'find', then 'find in project'.
Type in the 'find' bar '\' (with no quotes) and hit 'find'.
In the 'replace' box, type in '/' (no quotes) and hit 'replace all'
Close the box and go to 'file', 'save all'.
Now go ahead and move the 's' folder back into the 'parts' folder in 'LDRAWUNF'
All or most parts should now return no errors when being opened.
***NOTE*** the 'parts' or 'p' folder containing official parts that comes with bricksmith should not be touched for this fix.
Note to mods, Im not sure what category of the Ldraw forum this should be located in.
Quote:Each model in the OMR will consist of several files that are packaged together into a single MPD file. For sets that include instructions for multiple models, each model will have its own MPD file. Each MPD for the set will be named in the following manner:
<Set Number> - <Set Name>[ - <Sub Model Name>]
Where:
<Set Number>: The number assigned on the container of the set.
<Set Name>: The name of the set printed on the container in English.
<Sub Model Name>: This is Optional in most cases. This is required for alternate models that are detailed in instructions (e.g. the Creator theme). In this case the naming is left to the discretion of the author but should be descriptive of the model contained in the MPD.
to (additions in italics):
Quote:Each model in the OMR will consist of several files that are packaged together into a single MPD file. For sets that include instructions for multiple models, each model will have its own MPD file. Each MPD for the set will be named in the following manner:
<Set Number>[-<Optional Qualifier>] - <Set Name>[ - <Sub Model Name>]
Where:
<Set Number>: The number assigned on the container of the set. <Optional Qualifier>: Is a sequential number, starting with 2.
<Set Name>: The name of the set printed on the container in English.
<Sub Model Name>: This is Optional in most cases. This is required for alternate models that are detailed in instructions (e.g. the Creator theme). In this case the naming is left to the discretion of the author but should be descriptive of the model contained in the MPD.
The <Optional Qualifier> is not mandatory and gets added only if there is more than one set that could be assigned the same <Set Number>. The first set using a given number would be understood to never contain the qualifier however numbering should start with the oldest set and some investigation should be done in existing set databases.
Example:
6901 - Mobile Lab.mpd (Produced in 1980)
6901-2 - Space Plane.mpd (Produced in 1998)
Hello, I try the step 1 download for mac. Nothing happens. With the help link (http://www.ldraw.org/article/96), answer "not found". Small temporary outage?
This is a repost of something I just put up on Flickr. Hopefully this image works; if not, the link to Brickshelf should at least be active...
Here is something that has been bugging me for ages, and I was wondering if anyone could shed some light on it.
These images show the POV-Ray output for various rendering conditions. Three colour definitions are used - MLCAD standard, LGEO and Koyan's list. For the standard MLCAD colours, POV-Ray checks the list of pre-defined colours (I am assuming this – please correct me if wrong) and uses those, leaving everything else as “color 7” (lt grey). For example, the reddish brown and lt flesh plates are both lt grey, as these are newer colours and not on the standard list. For the modified “solid” and “24-bit” colours, POV-Ray defines each colour itself, rather than referring to a list, so every colour is included. The down side is that they do not look very realistic in POV-Ray, with the exception of the 24 bit colours (I have been using these recently).
When using LGEO, POV-Ray first checks each colour against LGEO's list and then defines that colour if it is not there. However, having done this, it goes on to associate “color 7” with those parts which have colours not on the MLCAD standard list, even though new definitions are available. Again, this can be seen for the reddish brown and lt flesh plates. The same thing happens if you use the “koyancolours” file – apparently all it does is redefine the colours on the standard list, even though it includes many more. Adding new colours to the list does not work, but reassociating existing colours to ones that are not working (e.g. changing a bizzare purple to lt flesh and calling the bizzare purple colour code) does work – the lt flesh plate is now the right colour. Now for the weird bit – if you go into the POV-Ray file and change the remaining “color 7” tags (Koyan added reddish brown to his list, so this plate is no longer an issue) to colours on the koyancolours list, which were the originally intended ones, they come out fine. The case here is the lt and dk bley, colours 71 and 72 – these do not work in standard MLCAD, LGEO or unmodified POV files for koyancolours.
In short, does anyone know why on earth this is happening, or is this a more general concern for how MLCAD does its thing?
This is a proposal for changing the scoping rules for TEXMAP:
Add bolded text:
Quote:This texture will remain in effect until:
An END is given within the current file
The file in which the START is located ends
A STEP command is reached
The texture will remain active when processing an included file unless overridden within that file.
and change:
Quote:The END command stops using the current texture and restores the previous texture to current status. This means that nested commands with START will form a stack of textures and the END command will pop those textures. However, END cannot appear in a different file from START. If an END command is given in a sub file without a START having been given in that same file, the ENDstops the use of a texture specified in a calling file, then that texture will be restored to use when the sub file is exitedhas no effect.
These scoping changes are critically important to implementing a hierarchical, object-oriented model to textures. It will be impossible for me to implement the standard as it currently exists. I already have a working implementation of the changes described above (*).
Allen
(*) with the exception of the stack behavior for nested textures, which is a simple enough addition
Just for backup, but also for anybody interested, I'm posting here my current MLCad parts tree setup
which I over some years now found convenient to use.
This is especially useful for me still since MLCad doesn't know of the !CATEGORY keyword yet,
and thus will not show parts in their categories initially.
I'm attaching the MLCad.grp file here to this post (rename it from MLCad.grp.txt to MLCad.grp after download),
so you can directly use it to replace your default one if desired.
![[Image: colours_complete.png]](http://www.brickshelf.com/gallery/Becheman/LDraw/colours_complete.png)
