Category Archive: “Uncategorized”
Setting up Andy’s LDraw Viewer
Andy has posted the Processing code for the nifty little LDraw viewer I mentioned in my previous post.
Processing gives you a decent among of guidance, but for your reference here’s what I did to get this up and running:
- Download and unzip
ProcessingLcad-Oct2008.zip. - Rename the
LcadTest-Oct2008folder toLcadTest01in order to match the project file it contains. - Move the contents of the
LcadTest01/libs/folder to your Processing sketchbooklibrariesfolder. In my case, it is/Users/anoved/Documents/Processing/libraries/. - Move the contents of the
LcadTest01/models/folder to themodelssubfolder of your LDraw library. Alternatively, you can editLcadTest01.pdeto load a model of your choice. - Open
LcadTest01.pdeand editBaseDirto identify your LDraw library folder. In my case, it is/Users/anoved/Documents/LDraw/.
Lastly, if the capitalization of the LDConfig.ldr file in your LDraw library does not match that specified later in LcadTest10.pde, edit one or the other so they are in agreement.
Now you can take it for a spin. And, yes, this viewer can load files with Unix line endings. ☺
Posted on Monday, January 11th, 2010. Tags: code, LEGO, processing.
Beginning Processing
Processing is a system that makes it as straightforward as possible to do some pretty sophisticated graphics programming. Based on Java, it abstracts enough technical details to let you focus, more or less, on the basic logic of the idea you want to animate. From the web site:
It is used by students, artists, designers, researchers, and hobbyists for learning, prototyping, and production. It is created to teach fundamentals of computer programming within a visual context and to serve as a software sketchbook and professional production tool.
Check out the Exhibition for some examples of what’s possible and the Tutorials to see how easy it is get started. There is a great collection of examples for specific topics, too, most of which include illustrative applets embedded in the page. The ability to export Processing programs (or “sketches”) as applets is particularly appealing, although my understanding is that some features, such as file I/O, are available only in application or development mode. It works cross-platform.
I know I have encountered Processing before, but my current interest began as I read Andy Lynch’s description of a simple LDraw renderer he implemented as a Processing sketch. That lit a fire under some related ideas of my own that have been simmering for want of an optimal outlet.
But there’s more to my interest than digital bricks: if there isn’t already a decent library (which would be surprising, as many useful libraries seem to be available), I might be tempted to write a shapefile loader, if for no other reason than to complement the shapefile parser I once wrote for Chipmunk Basic. I think it could be fun to experiment with some raster GIS and remote sensing ideas in Processing, too. (Just get the spectral signatures – click, click, click – and you do it. That’s all what it is!) Last but not least, per its original intent, I can envision using Processing as a superior tool to visualize certain data.
What sort of Process will you invent?
Posted on Monday, January 11th, 2010. Tags: code, geography, LEGO, processing.
Kitgen Build System for Tcl/Tk
In the past I have written a variety of posts about Starkits and Starpacks. Briefly, Starkits provide a way to package complex Tcl/Tk programs in a single file, and Starpacks allow those packages to be combined with self-contained interpreters to deliver stand-alone applications. However, the Tclkit interpreters I originally used for this purpose have not generally been maintained, at least for Mac OS X (Pat Thoyts has done a good job providing current Windows and Linux versions).
Of course, there are various ways to build your own Tclkit equivalent, but I usually found the process slightly too tedious to sustain my interest (although I did succeed with Pat’s version of kitgen shortly before discovering the method described below).
As it turns out, self-contained Tcl/Tk installations functionally equivalent to Tclkits can quite easily be created with the kitgen build system. This comprises a single Tcl script (kbs.tcl) that automates the process of downloading, compiling, and assembling the elements of a “kbskit”. The script is robust – it worked successfully on the first try, without any knowledge of what options to use beyond those given in the Quick Start examples.
If you simply run a fresh copy of kbs.tcl, it will retrieve the Tcl/Tk sources.
Build a Metakit-based kbskit (like Tclkit) with:
./kbs.tcl -r -mk install kbskit8.5
Build a Vlerq-based kbskit (like Tclkit Lite) with:
./kbs.tcl -r -vq install kbskit8.5
In either case, three executables will actually be built:
- A Tcl-only executable, denoted by
-clisuffix - An executable that loads Tk from an external library if needed, denoted by
-dynsuffix - An all-in-one Tcl/Tk executable, denoted by
-gui
On Mac OS X, these executables are found in the buildDarwin subdirectory relative to kbs.tcl. The subdirectory name will presumably differ on other operating systems.
Happily, the kbskits created with the kitgen build system can be used with Starpacker. Check the “Other” box and select the kbskit you prefer to use as the executable in your Starpack:
You can bundle other packages into your kbskits using the -mk-bi or -vq-bi options (-bi stands for “Batteries Included”). This will ensure that those packages (typically useful extensions) are always available to code being run by that kit. Of course, a different approach, with different advantages and disadvantages, is to bundle packages in your application Starkit, which can be executed with different kits.
Additional topics to explore include building the --enable-aqua option and the best method to update both kbs.tcl and the source code it retrieves.
Posted on Sunday, January 10th, 2010. Tags: code, mac, tcl.
LDraw Files, Line Endings, and an Ecosystem Inventory
The general LDraw File Format specification is silent on the matter of line endings, but the File Format Restrictions for Official Parts requires DOS/Windows (“CRLF”) line endings. A recent discussion caused me to become curious whether there are really any contemporary compatibility reasons for this recommendation. So, I decided to take an inventory of LDraw programs to see which, if any, had trouble opening files formatted with Unix (“LF”) line endings.
Here is a simple sample model, Test.ldr. It was created with Bricksmith, which outputs files with DOS line endings per the official file format restrictions. I used a text editor to convert the line endings to Unix format.
What programs can read the test model?
Bricksmith 2.3.1 can do it.
LDView 4.1 can do it (with no warnings or errors).
LPub 4.0.0.4 can do it.
L3Lab 1.3 Beta can do it.
ldglite 1.0.18 can do it.
Mac Brick CAD 3.0b1 can do it.
BrickDraw3D 0.5b can do it.
LeoCAD 1.75 for Linux can do it.
LeoCAD 1.75 for Windows can do it.
LDraw Design Pad 1.5.7 can do it.
MLCad 3.2 can do it.
LD4DStudio 1.1 can do it.
LDLite 2.4 can do it.
SR 3D Builder 0.4.5.7 can do it.
LEGO Digital Designer is not strictly part of the LDraw system of tools, but LDD can import it, too.
Command-line tools like L3P 1.3, LDTrim 1.1, and LSynth 3.1 can do it (there’s nothing for LSynth to synthesize in this case, of course).
l3p Test.ldr → Test.pov → povray Test.pov → Test.png ldtrim -in Test.ldr -out Test-trim.ldr lsynthcp Test.ldr Test-synth.ldr
As a sample of Philo’s LDraw tools for part authors, I modified some of the example files included with Coverer to use Unix line endings.
coverer arc1.dat arc2.dat myarcoutput.dat
The program ran without any trouble.
James Jessiman’s original LDRAW and LEDIT programs (downloadable here) can’t do it – but they’re worth celebrating anyway, so here’s a screenshot of LEDIT looking at the DOS-formatted version of the test model:
I could not find a downloadable copy of LDAO (LDraw Add-On) to test. According to the discussion that inspired this inventory, it too is at least partly dependent on DOS line endings.
With the exception of the inimitable original, none of the many LDraw programs I could test had any trouble interpreting files formatted without DOS line endings.
My conclusion is that the official part file format recommends DOS line endings solely for backwards compatibility with the program that inspired the system. This is not bad, but it’s worth recognizing. As long as there is no inconvenience to other programs or their users, I see no reason to abandon this situation. We have a format that preserves compatibility with older components, and tools that are robust enough to understand reasonable exceptions to the format.
Anyway, here’s a hearty pat on the back for the folks who have made so many nifty ways to play with virtual bricks.
Posted on Friday, January 8th, 2010. Tags: LEGO.
Saab
Longtime readers may be familiar with space truck, the mayhem machine I have piloted with affection and mortal respect since 2002. Space truck was recently retired, concluding years of honorable service.
As a replacement, I have acquired a far more practical and economical vehicle: a 1996 Saab 900 SE turbo. It is, however, a worthy successor, replete with personality and motive power.
Posted on Tuesday, December 29th, 2009. Tags: car.
Making a Studded Bike Tire
Inspired by a tutorial discovered via BikeHacks, I decided to make a studded bike tire to facilitate pedal-powered winter adventure.
I started with an old spare tire, and six 98¢ bags of screws:
Then I sat down and drove all 84 of those puppies into the tire:
I opted to stick with the points-in approach rather than the less labor-intensive points-out approach. I used a bench grinder to blunt the points of the screws:
Even without points, the screws constitute a threat to the inner tube. Mr. Tuffy liners are recommended for the purpose of extra puncture protection, but I’m trying a cheaper approach – a second layer made of scavenged inner tube:
I installed the tubes in the tire and mounted it on a rim. As I only have one studded tire, I’m using it in the front. I conjecture that steering is more important than acceleration in preventing icy wipe-outs.
It works! On hard pavement, the studded tire rolls with a prickly sound like tearing fabric. I’ll post some some winter action shots soon.
Posted on Monday, December 21st, 2009. Tags: bike.
yjnote
yjnote is a Mac OS X command-line tool for creating note items in Yojimbo. You can use it to pipe the output or usage notes of other programs into Yojimbo for reference or logging purposes.
Download
Download yjnote.zip (1.7 KB)
Tested, minimally, with Yojimbo 2.1 on Mac OS X 10.6.2. yjnote is written in Perl with a pinch of AppleScript. Further testing, bug fixes, and improvements are welcome (and likely necessary).
Usage
You can display this documentation at any time with yjnote -help.
NAME
yjnote − Create Yojimbo notes from the command line.
SYNOPSIS
yjnote [options] [FILE...]
DESCRIPTION
yjnote creates a Yojimbo note by concatenating the contents of the
given files (or by reading standard input, if no files are given).
OPTIONS
−title TEXT
Sets the note item title.
−comments TEXT
Sets the note item comments.
−label TEXT
Sets the note item label. Ignored if the label does not exist.
−tags TAG[,TAG,...]
Sets the note item tags. Separate tags with commas.
−flagged
Flags the note item.
−reveal
Reveals the newly created note in Yojimbo. By default, the new note
is not displayed.
Posted on Sunday, December 13th, 2009. Tags: applescript, mac, perl, yojimbo.
LSynth 3.1 for Mac OS X
I have compiled a Mac OS X version of LSynth 3.1, the recently released update to the program that synthesizes LDraw code for flexible LEGO parts.
Download LSynth 3.1 for Mac OS X 10.5+ (Universal Binary; 85 KB)
This download includes the lsynthcp executable as well as the configuration file (.zip) and the constraint parts (.zip) available at Willy Tschager’s installation tutorial page for MLCad users (which contains some useful information for all LSynth users).
Important Compatibility Note: The executable in the above download may only work with Mac OS X 10.5 (Leopard) or greater. Click here to download a version of lsynthcp that should also be compatible with Mac OS X 10.4 (Tiger), provided by current LSynth developer Don Heyse. Thanks, Don!
Installation
Copy the LSynth constraint parts to the parts/ or Unofficial/parts/ directory of your LDraw part library. Keep the lsynth.mpd configuration file in the same directory as the lsynthcp executable. LSynth is not integrated with Bricksmith, so you can keep these files wherever you prefer. You will need to use the command line to run LSynth.
Usage
To use LSynth, you manually place constraint parts at key locations such as the endpoints of a hose. Then you input the LDraw file to lsynthcp, which generates a duplicate file containing all the hose segments, chain links, etc. necessary to represent the flexible part described by the constraints.
For example, here is the RUBBER_BAND-Constraints.ldr file from Willy’s excellent page of LSynth examples:
With the file in same directory as lsynthcp and lsynth.mpd, run the following command:
./lsynthcp RUBBER_BAND-Constraints.ldr Rubber_band_output.ldr
Here is the output:
For more detailed information about using LSynth, peruse Willy’s troubleshooting page and the pages linked above.
Notes
Here are the minor modifications I made to compile the LSynth 3.1 source package for Mac OS X:
- Edit the comment on Line 69 of
lsynthcp.cto begin with slashes (//) instead of backslashes (\\). - Append “
-arch i386 -arch ppc” to lines 3 and 17 ofmakefileto enable Universal Binary support.
The make command is sufficient to compile the program.
This release supersedes the LSynth Service I made a few years ago.
Posted on Saturday, November 21st, 2009. Tags: bricksmith, LDraw, LEGO, mac.
Drawings
I’ve been cranking them out for NaNoDrawMo.
Here are some other favorites:
Plenty of profile drawings of pretty faces. What next?
Posted on Monday, November 9th, 2009. Tags: art.
NaNoDrawMo 2009
NaNoDrawMo is a drawing challenge started by Steven Frank of Panic software. Inspired by NaNoWriMo’s 50000-word target, the objective is to do 50 fifty drawings in November (a picture is worth a thousand words, so fifty pictures…). My contributions will be visible here.
I’ve started off in familiar territory, but I hope to experiment with different styles over the course of the month.
Posted on Monday, November 2nd, 2009. Tags: art.