Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





Search Forums

(Advanced Search)

Forum Statistics
» Members: 9,373
» Latest member: NobleCan72
» Forum threads: 4,815
» Forum posts: 42,250

Full Statistics

Online Users
There are currently 16 online users.
» 0 Member(s) | 13 Guest(s)
Applebot, Bing, Google

Latest Threads
Han Solo in Carbonite (Br...
Forum: Part Requests
Last Post: Orion Pobursky
3 hours ago
» Replies: 8
» Views: 188
Technic 2022
Forum: Official Models
Last Post: Jens Brühl
9 hours ago
» Replies: 17
» Views: 6,655
Small Sail
Forum: Part Requests
Last Post: Takeshi Takahashi
Yesterday, 14:07
» Replies: 1
» Views: 1,865
Castle - Wolfpack
Forum: Official Models
Last Post: Takeshi Takahashi
Yesterday, 13:53
» Replies: 2
» Views: 727
Parts you would like to s...
Forum: MOCs (My Own Creations)
Last Post: Thom Kok
2022-08-12, 18:31
» Replies: 9
» Views: 9,368
Using LPub3D with Ubuntu
Forum: LDraw File Processing and Conversion
Last Post: Manfred Schaefer
2022-08-12, 17:14
» Replies: 0
» Views: 39
Atlantis Head Minifigure ...
Forum: Part Requests
Last Post: Neme287
2022-08-11, 22:42
» Replies: 4
» Views: 142
[Tool/Web] Get specific p...
Forum: LDraw File Processing and Conversion
Last Post: Christoph Reum
2022-08-11, 17:50
» Replies: 10
» Views: 1,124
Castle - Black Knights
Forum: Official Models
Last Post: Takeshi Takahashi
2022-08-11, 16:27
» Replies: 3
» Views: 260
Technic Control Interface...
Forum: Part Requests
Last Post: Rene Rechthaler
2022-08-10, 12:42
» Replies: 1
» Views: 1,103

 
  12V Train Sets (Grey Era)
Posted by: Steffen - 2011-08-01, 6:29 - Forum: Official Models - Replies (28)

Sigh, those were the days...

You have built a train set from that time in LDRAW?
Post it as reply here, if you like :-)

Print this item

  color codes for silver vs metal ?
Posted by: Steffen - 2011-08-01, 4:27 - Forum: Parts Authoring - Replies (32)

There always has been confusion about which color codes need to be used
for silver(ish) things or metal in our library.

I would like to sum up my state of knowledge and would like to discuss this here,
so the usage of color codes can be tidied up in our library.

Causing this post is the ongoing discussion at
http://www.ldraw.org/cgi-bin/ptdetail.cg...144485.dat
(, there had been some before already at other parts)

This is my (personal) state of knowledge,
I may be wrong in one or the other point of course.
When replying, please just don't assume that I or you are "just right",
because the library sometimes has inconsistencies.

color 179:
means "printed silver".
that is a color being used in patterns that get printed onto parts

color 383:
from the beginning was a "special color", used for physical metal parts
which appear "silverish" or "chromish" :-) ,
thus, do not use this for copper or other metal things

color 494:
another very special color.
it has been introduced for "electric studs",
which show up in historic LEGO instructions as studs with a yellow portion.
some tools for this reason used to render or code this color as yellow,
but nowadays most render it similar to 383, which frequently leads to confusion.
IMHO, this color code should ONLY be used for electric studs, and not used
too liberately, because it carries not only the semantics "made of silverish/chrome metal",
but also "shall show up in instructions as yellow" and
"is somewhat related to electric studs"

color 80:
I didn't know much about this color for long time and have never used it.
But I think it is for silver plastic parts like this
http://media.peeron.com/pics/inv/custpic...848722.jpg


BrickLink has a very good, visual color comparison table
http://www.bricklink.com/catalogColors.a...itemType=P
, but sadly without LDRAW color codes.

IMHO, we definetely need such a table with visual part examples for our LDRAW library.

We also might or might not have to introduce new colors in ldconfig.ldr, or phase out some confusing ones
(and map them to others for downwards compatibility).

Print this item

  7181 - UCS TIE Interceptor
Posted by: Orion Pobursky - 2011-07-31, 16:54 - Forum: Official Models - No Replies

This model holds a special place for me since creating it is the reason I became a parts author which eventually led to me becoming part of the LDraw.org leadership.



Attached Files
.mpd   7181.mpd (Size: 16.42 KB / Downloads: 11)
Print this item

  8652 - Enzo Ferrari 1:17
Posted by: Orion Pobursky - 2011-07-31, 16:43 - Forum: Official Models - Replies (1)

Note: Uses unofficial parts which are included in the MPD file



Attached Files
.mpd   8652.mpd (Size: 142.44 KB / Downloads: 8)
Print this item

  5521 - Sea Jet
Posted by: Orion Pobursky - 2011-07-31, 16:26 - Forum: Official Models - No Replies

Part of the Model Team series

Edit: Now OMR Compliant



Attached Files
.mpd   5521 - Sea Jet.mpd (Size: 20.54 KB / Downloads: 8)
Print this item

  render LDR or DAT attachments to posts like on parts tracker
Posted by: Steffen - 2011-07-31, 0:25 - Forum: Website Suggestions/Requests/Discussion - Replies (18)

Currently it appears sad to me that posts here in the forum
which contain a dat or ldr attachment are not visible graphically.
Can we add a feature that they get rendered on the server and get an image?

Print this item

  Inclusion of LSYNTH parts in the official LDRAW library
Posted by: Steffen - 2011-07-31, 0:05 - Forum: Parts Authoring - Replies (10)

I would like to open the discussion here for including elements in our official LDRAW library
which allow synthesizing/generation of e.g. flexible parts like LSYNTH does.

The topic is chosen a bit unlucky, because of course LSYNTH is not the only program capable of that
now or in future, so we should not be tool-specific here (as always. our library is generic.)
I just chose the title of the thread, so the basic principle is clear.

I would like to suggest the following ideas and discuss them with you to get them
to a consensus for a future official library release.

Generation of flexible parts like cables, hoses etc. is usually something a user of our library would like to do.
The generation usually takes place by placing some start and end pieces, plus some constraint files,
and then sweeping some parts along some path to generate the flexible part.
The sweep can be smooth/continuous, or discrete, like for chain elements.
So we have different kinds of elements which come into play here:
(a) start / end parts (like chain elements)
(b) start / end subparts (like hose ends)
© constraint definition files
(d) sweeping primitives (like cable or hose)
(e) sweeping parts (like chain elements)

SUGGESTION 1: we should include all of these in the library.

Question is: which of (a)-(e) should go into which folder?
What is a part or a subpart or a primitive?
In the past there has been this suggestion:
put all into the PARTS folder, because otherwise MLCad won't show them
However, I do not like this idea at all, here are the reasons:
1. This is a tool-specific problem. Just because MLCad today only shows parts, this should not affect our library design.
2. The logic if something is a part, subpart or primitive applies to LSYNTH elements the same way as to normal files.
This especially becomes important when software needs to decide where to add gaps etc.
So my next suggestion is:

SUGGESTION 2: apply the usual part/subpart/primitive logic to LSYNTH files as for all other library files. Do not put them all in PARTS, just to let them show in MLCad. To solve the MLCad problem, many other solutions are possible, e.g.: put "helper" files into the PARTS folder which are shortcuts to the real places. These helper files should be a separate download, as they are a workaround for a specific tool (MLCad) and not part of our library. Maybe not even that is necessary, read on:

Some people have suggested to add a new category for syntesized parts.
Of course, we should not use "!CATEGORY LSynth", because that would be tool-specific.
Instead, something like "!CATEGORY Parts Synthesizing" comes to my mind.
However, I would like to doubt the necessity for such a category.
Reason: normally, tools like LSYNTH (and LSYNTH does) do contain specific lists of combinations of
start/sweep/end combinations, which you can conveniently select.
So there is not really a necessity to be able to browse the synthesized part elements.
So we get

SUGGESTION 3: Do not add a special category like "!CATEGORY Parts Synthesizing", as this seems not to be necessary.

The last question to answer is "origin and sizing etc".
There the answer is simple: I suggest that for sweeping primitives we use the same origin/placement/sizing policy as for our other primitives:
this means: origin on top, height 1. 4-4cyli is a good example. So for example, to generate a two-wire-cable, you would sweep 2 merged cylinders along some path. The sweeping primitive should have height 1, and should have its origin at its top.
The benefit of this suggestion is:
(a) the sweeping primitives have the same origin policy as the other primitives in our library
(b) LSYNTH directly will be able to use them without modification, as it follows that principle as well
So we get:

SUGGESTION 4: For sweeping primitives, put origin at top, and make them height 1.

The situation for non-sweeping primitives is different. Let's go away from the electric cable and instead to a chain
made of discrete elements of fixed length. My suggestion there is:
let's apply the usual origin placing logics there. The reason is simple: these elements are normally parts with a tilde ~ prefix,
and sit normally in the PARTS folder. LSYNTH needs anyway a configuration file which tells it how to assemble such elements.
It for example today has such for chain elements. So we get:

SUGGESTION 5: For non-sweeping synthesizing elements, apply the usual origin paradigms.




Summary of suggestions:

SUGGESTION 1: Let's have files for part synthesizing in our library.
SUGGESTION 2: Put them where they belong. I.e.: into the P, PARTS or PARTS\S folder, depending on what they are.
SUGGESTION 3: Do not create a dedicated category.
SUGGESTION 4: For sweeping primitives, put origin at top, and make them height 1. Sweeping will take place along Y axis.
SUGGESTION 5: For non-sweeping, i.e. discrete parts like chain elements etc. apply the usual origin and orientation paradigms as for normal parts.

Print this item

  "Export to LDraw" plugin for Google SketchUp
Posted by: Jim DeVona - 2011-07-30, 12:29 - Forum: Parts Author Tools - No Replies

Just thought I'd share this again here for anyone who might be interested - my version of a script to convert Google SketchUp models to LDraw format. It is very rudimentary and not particularly user-friendly, but I found it useful to be able to take advantage of SketchUp's various modeling features to get started on a part. You'll have to edit the output manually to incorporate any existing LDraw primitives.

The script is available here: http://code.google.com/p/sketchupldraw/downloads/list
Pasted below is the documentation, such as it is (which also appears at the top of the script file):



This is a plugin for Google SketchUp (http://sketchup.google.com/). To install, put this file in your SketchUp plugins folder. Where's that? See here: http://sketchuptips.blogspot.com/2008/03...ugins.html (Note on Mac OS X you can also use your user ~/Library instead of your system /Library) Restart SketchUp, and an "Export to LDraw…" item should now appear in the Plugins menu.

Credits:
- Based on Jim Foltz' Su2LDraw script, which has more features, including importing LDraw models to SketchUp. http://sites.google.com/site/jimfoltz02/su2ldraw Check out Jim's blog for other cool SketchUp stuff: http://sketchuptips.blogspot.com/

References:
- SketchUp Ruby API: http://code.google.com/apis/sketchup/docs/
- LDraw File Format Specification: http://www.ldraw.org/specs/fileformat/ - oops, I mean http://www.ldraw.org/Article218.html

Scale & Orientation:
- Per http://www.ldraw.org/Article218.html#coords "Real World Approximations", this script assumes 1 LDU = 0.4 mm and converts units on export accordingly. In other words, model bricks as life-size in SketchUp and they will be exported with correct LDraw units. An example: Brick 1 x 1 (3001.dat) has an 8 mm footprint and is 9.6 mm tall not including stud.
- SketchUp and LDraw coordinate systems are slightly different. In general, for easiest results, rotate your SketchUp model down 90 degrees around X axis before export (or just build that way).

Limitations:
- Too many to list. Don't assume you can just export any SketchUp model and have an LDraw version; it won't work. See code and comments below for details on how it works and what it doesn't do.

Print this item

  LDraw All-In-One-Installer 2011-01 Now Available
Posted by: Willy Tschager - 2011-07-29, 15:41 - Forum: LDraw.org Announcements - No Replies

The LDraw All-In-One-Installer 2011-01, in short AIOI, has now been released:

* It comes with the latest LDraw Parts Library update 2011-01 as well as MLCad.ini file.
* Thanks to J.C. Tchang the installer from now on also "speaks" French.
* Furthermore it detects an old version of the All-In-One-Installer and on request uninstalles it prior copying new files.
* It lets you also decide if you wanna register LDView to generate thumbnails of LDraw files in the Windows Explorer.
* The search for an installation done manually or by third party software is no longer performed. The quick search did not perform as expected and a deep scan would require too much time.

The AIOI supports Windows XP (Home and Pro), Windows Vista (all versions) and Windows 7 (all versions). On 64-Bit Operating Systems it will install in the "Program files (x86)" folder. The Installer will NOT run on Windows 95, 98, ME, NT Ver 4, 2000, or XP below SP2.

You can download the AIOI by going to the download database under the heading Critical Files and Libraries.

w.

Print this item

  Lego States Army - Hardware Lineup
Posted by: Robin Chang - 2011-07-29, 4:13 - Forum: MOCs (My Own Creations) - No Replies

[Image: 5558187422_61616cebe6_z.jpg]
LS Army Hardware Lineup - March 2011 by GreenLead, on Flickr

A POV-Ray rendering of the current range of Vehicles and Equipment used by the fictitious Lego States Army of Alpha Company fame. Most of these models were originally built (with physical LEGO) by other FOLs from the US and Europe, who emailed me step-by-step photos so that I could recreate them in LDraw.

Listed below are the designations of each item (left to right), as well as FOLs who built the originals.

Back Row

M6 Crusader Heavy Armored Truck by Ralph Savelsberg
A HEMTT-style truck primarily used for battlefield logistics, but other interchangeable payload modules are planned, including those used in the MIM-104 Patriot SAM system.

Non-Line-Of-Sight Launch System by Robin Chang
Based on the real-life NLOS-LS proposed for the US Army and affectionately dubbed "death in a box" by some AC Forum members, this is a unattended SSM launch pallet. Give it a launch order with target information and attack profile, it does the rest. Troops can easily pop open the side panel and replace spent missile pods.

M3 Panther Fast Assault Jeep by Aleksander Engvoll
Essentially a futuristic humvee, but don't let the spartan armour and exposed top fool you. As the name suggests, importance was placed on speed and agility, making for a hard-to-hit weapons platform. Can be mounted with a wide range of weapons to support dismounted infantry.

M5 Gremlin MULE by Robin Chang
A fully-autonomous battlefield resupply robot armed with a .50 cal. HMG and TOW AT missiles for convoy protection duties. Can carry up to one metric ton of infantry ammunition and supplies.

Front Row

U62 Eveningstar MAV by Chandler Parker
Inspired by the Honeywell XM156 proposed for the cancelled US Army FCS program. Micro reconnaissance drone able to hover over high-risk areas for extended duration.

U9 Badger SUGV by Chandler Parker
Inspired by iRobot XM1216 SUGVs. Ground drones with a rudimentary AI that allows it to search for IEDs and booby traps on the battlefield, as well as infiltrating buildings to check for hostile before infantry enters. All models have developed child-like personalities due to unexplainable circumstances.

M4 Cobra Hoverbike by Chandler Parker
Hovering scout motorbike. The scout infantryman's assault rifle can be mounted on the side and remotely-fired for self-defense.

U57 Buzzard MAV by Chandler Parker
Inspired by the USMC Dragon Eye drones. Hand-launched and electric duct fan powered micro reconnaissance drone.

For those of you interested, I have available building Instructions for all the models shown, published as PDFs. They are free to download.

C&C welcome Smile

Print this item