LegoCAD - job descriptions, details
Alex Devries
Sorry for being late in my response, but I've had a lot of
work to do on the LegoCAD project. This is going to be the first
posting on the exact standards of LegoCAD. Anything written in
here can be changed, though, just mail me with your concerns.
Just so all the real Lego freaks don't get angry at us using
all this bandwidth for the LegoCAD project, there will be a mailing
list to help communication. This iwll probably be set up by next
week. For anyone who'se mailed me before, I'll put you down as
a subscriber. I'll also post messages as to how to subscribe after
it is set up.
So far, I've had over 25 people volunteer for the project, and so
I want to say thanks. I should mention, though, that I think we're
missing a few people who could take care of a few things. First,
I'd like to see more programmers. Also, I'm missing someone with
X programming experience (surprisingly). I may have assigned
people the wrong role inthis project, and I'd like to hear from
you if you have a better idea of what role you'd like to play.
I hope you'll forgive the lack of postings on my part. I've been
responding to letters individually, whcih has taken up a lot of time.
I'm hoping you'll also ignore my "reply to a reply's". Anyway, if I
have somehow misunderstood any of you, let me know. If I've left you
out completely, or (as I did to Anne) assigned you to something you've
no idea about, talk to me. Some of the simpler tasks require little
experience, and I'm sure I, or others can help them out.
Now for the nitty gritty details. Only worry if you don't
understand what I'm talking about if the details pertain in some
way to you. Also, these are merely suggestions, and any modifications
can be made, but we must all hear about them. I'll be in charge of
maintaining the requirements list.
Here are all the people in LegoCAD. If I got your address wrong, let
me know.
Bjorn Augustsson d3a...@dte.chalmers.se programmer
Anne Carasic cir...@elm.circa.ufl.edu Libraries
Nathan Clegg 25...@ef.gc.maricopa.edu Dos porting
Bob Cowling ------ ? -------- Programmer
Alex deVries adev...@ccs.carleton.ca Head Programmer
Jeff Findley jeff.f...@heimdall.sdtc.com Libraries
Paul Gyugui p...@parint.esl.com Ray tracing
Teemu Hakala te...@krkmoon.krk.fi Amiga porting
Hayes Harper ha...@amiganet.chi.il.us Libraries/Beta
Colin 't Hart ha...@tartarus.uwn.edu.au Libraries
Jess Kvatek dz...@cleveland.freenet.edu Libraries
Tom Leber le...@panther.warm.inmet.com Beta
Andre Lipinski ----- ? ------- Mac porting
Scott McWilliams slowpu...@delphi.com Resources
Peter Murray pe...@table76.demon.co.uk Beta/Libraries
Joe Olbinski olbi...@hurrican.seas.ucla.edu Dos porting
Chris Osborn fozz...@marquader.nvc.cc.ca.us Porting/NeXT
Joel Plutchak ----- ? ------- Mailing list
Jim Robinson rob...@BBN.com Programmer
K. Tatro (RAT) kta...@mcrel.org Mac porting
Peter Selkin pase...@unix.amherst.edu Libraries
Ian Stephenson i...@ohm.york.ac.uk NeXT porting
Amy Stoklas-Oakes sto...@gold.tc.umn.edu Libraries
David Turner dtr...@crl.com Beta (Windows)
Erik Wilson erwg...@uxa.cso.uiuc.edu programmer
Sam Yates s...@iagv.itd.adelaide.edu.au X porting
If your address isn't on the list, let me know too.
A note on dimensions: in order to keep all measurements in
integers, the standard unit will be a 16th of an
inch. I know all the Europeans will cringe at
this, but on the suggestion of Peter Murray, I've
been told all measurements are multiples of this:
a 1x1 is really 5 x 6 ; a stud is 3 in diameter;
a board is 1.
Porting
-------
Chris Osborn
He'll work with us to help us code to a standard format.
His experience in multi platform programming will be invaluable
in guiding us to only having to write code once.
From what I understand, the plan of attack should be as follows.
There will be a set of libraries that will be standard. Any of the
I/O functions or interface functions will be in platform dependant
libraries. So, all of these platform dependent libraries will contain
the same functions, just with different platform dependant code. Am
I wrong?
Core Code
---------
Alex deVries (3d rendering)
I'll be incharge of designing the system that actually draws out
the parts on the screen. It will involve the co-operation of Bj|rn,
who will be designing the internal dynamic data structure of the
current design (ie. how the actual bricks will be stored). I will
design the controls for setting zoom level, viewing angle, etc
(in fact, I've already completed them.)
Basically, the system is as follows: There is a coordinate system
that is similiar to coordinates on a globe. These two numbers
(theta and phi) will determine where the viewer is looking from.
Then, there is a less important number, L, which determines the
radius the viewer is looking from.
What I've already done is to figure out the different translations
for a point. So, given its x,y,z coordinate, it can be translated
into an x,y based system, given theta and phi.
I should be a little more clear, perhaps. Because the system
involves different parts which will be drawn differently (more on
this later), I will only provide the translation. The actual
drawing is dependant on the class of part, and how it chooses to
draw it. More on this later.
(Parts Placement)
There will be two modes to LegoCAD. The first is a simple
editing
screen. I believe that the best way to handle viewing is as follows:
For
the most part, editing will be done in a sort of wire frame, with
filled
panels. The parts will be placed using a combination of keyboard and
mouse (I haven't figured it out yet). It will involve selecting a
part
from one of the library files (figured it out already), with an
optional preview. I'll be working with Anne so that I can use each
new parts Paint method to draw the part itself.
The internal structure of the data structures will be as follows:
the system will consist of a stream or collection of objects (or
classes).
Every time you add a part, it will be added to the collection. Each
part
will contain the following:
1. A part number, as placed in the figure
2. Dimensions, depending on the class
3. A location in the figure (x,y,z)
4. A list of the parts it connects to, and how (see below)
5. A colour
6. Simulation info (see below)
a) current location (x,y,z)
b) current angular velocity (x,y,z)
c) current linear velocity (x,y,z).
7. The current "control points" (x,y) that let you select the
part
This will be updated everytime you choose a different view,
and
is valid for that view only.
8. A description of the part's volume. This will be done so that
intersections (illegal) can be found. Obviously, you cannot
have
more than one part in any location in space. I haven't
figured
out how to do this. However, I do know how to do this on
paper
(using algebra). Maybe I'll use a similiar method.
There will be some neat aspects to the placement. Basically,
you'll choose your part, and then move it through your diagram, moving
it sideways, forwards, and being able to turn it in any direction.
When you're done, LegoCAD will let you "place" the part. There are
a number of ways of different connections possible, which proves to
be important. The first is just a simple system whereby two pieces
are connected through standard Lego "bumps" (static). Also, an axle
with a gear wheel is also static. The dynamic connections that I've
figured out are: an axle (or similiar) through a "hole" (angular
and linear), a "pin" through a hole (angular), "sliding" on smooth
pieces (linear), two gear wheels touching (angular), and a few others
I can't think of. These connections all be stored while you place so
that you can enter the second mode:
(Simulation)
This whole section will probably be incomplete by version 1.0,
but I'd suspect that a system would be working by version 2.0 in its
entirety. I think I'll concentrate on the moving of gear wheels
mostly, as they presentthe most difficult part of the system
(angular movement).
Paul Gyugui (expansion to raytracing)
As Paul has written raytracing programs before, I hope he'll guide
us towards designing the intenal data structure of the Lego design
so that it is compatible with his code. As raytracing will only be
an option, his original code will hopefully fit in easily.
Bj|rn Augustsson (saving) Erik Wilson (retrieval system)
Bj|rn and Erik will work with designing a system that will load
files
from disk and into the predefined data structures (see above). The
.LGO
files will be text based, and will begin with a header, something like
"LegoCAD file starts here". Anything before will be ignored, so that
the
files can be mailable. He will design the structure of these files.
In the file, the following should be stored:
1. The title of the diagram
2. The current viewing angle/zoom level
3. The list of parts:
a) The part's name
b) The part's library name
c) The part's number (in the figure)
d) The part's location (in the figure)
e) The part's connections, how, where and to which part
(using
the part number as a reference).
f) The colour of the part
The following details can be calculated:
1) The part's volume (see above)
2) The part's dimensions (from the library)
3) Control point info (after the figure has be 3d rendered)
4) Simulation info will be set to zero.
Jim Robinson (class based library system)
Since Jim has experience in C++, I will ask him to design the
library system. I think the best way to have a base class (call it
TPart), and then each subsequent part will be some derivative of it.
Each part must have the following method: Paint - this draws the
part with the proper zoom level, viewing angle (see Alex for
translation info) and at the proper co-ordinates. Alex will provide
here with a simple translation library that will change the x,y,z
coordinate system into an x,y plane, providing theta and phi (see
above).
Hopefully, he will work with Bob Cowling to develop these classes.
I think the libraries data files should contain the following:
1) A library name
2) For each part:
a) the part number (as printed on the part). This will
help you quickly access the part you want.
b) the dimensions of the part (depending on the type of
part)
c) The different connections possible onthe part, and
where they are.
d) The colours the part is available in.
There will also be different methods for each class. The first one
will be a paint method (as described above). The next is a "load"
constructor which will load the part from disk. This will be
essentially what Bob Cowling will design, for each different class
of parts. All these declarations and definitions will be set in a
DLL (dynamic linked library). I'm assuming (naively) that all
platforms support these in some way. This will allow the libraries
to be expandable.
Bob Cowling
With the C++ experience he has, I'm hoping Bob will design a
sytem that will load predefined library files into memory. He should
work with Jim on this so that he know what the class is that the part
will be loaded into. He should design a system that ultimately loads
in the parts of each library into a collection, or stream of objects.
The following people will be in charge of porting the code to
their platforms:
Amiga
-----
Teemu Hakala
NeXT
----
Ian Stephenson
Chris Osborn
Windows
-------
Alex deVries
MAC
---
Andre Libinski
K. Tatroe (RAT)
X
---
Sam Yates
DOS
---
Nathan Clegg
Joe Olbinski
They have the undertaking of designing a front end for DOS.
Libraries
---------
Amy L. Stoklas-Oakes (castle pieces)
Hayes Harper (standard blocks)
Jeff Findlay (technical - blocks)
Anne Carasic (technical - wheels, gears,etc.)
Peter Murray (space)
Peter Selkin (misc. technical)
Colin 't Hart (anything I've forgotten)
With the help and guidance of Jim Robison and Bob Cowling, they will
develop simple text files that can be loaded by the constructors Bob
designs. They will be in a standard, predefined format. They will
also help Jim in suggestions as to how the parts are to be drawn (ie.
what they look like).
Beta Testers
------------
David Turner (Windows)
Tom Leber (XWindows, Mac)
Jeff Findly (XWindows)
Hayes Harper (Windows)
Peter Murray (Mac)
Resources
---------
Scott McWilliams (icons)
Jess Kvatek (help files)
NewsGroup
---------
Joel Plutchak
Official Kick-in-the-Asser
--------------------------
Hayes Harper, who started this whole thing.
--
--------------------------------------------------------------------
Alex deVries I email: adev...@ccs.carleton.ca
Editor, Vena Contracta I home: (613) 228-2997
Technical Director, CSES I work: (613) 233-7989
Consultant, Faculty of Engineering I All spelling and grammar is not
LegoCAD Head Programmer I necessarily that of the author.
--------------------------------------------------------------------
Hans Gerwitz
anyone has tried contacting Lego regarding this project. It seems they
might be interested in seeing it (perhaps even licensing it) and perhaps
give their stamp of approval for using their logo on screens...
How complete are the libraries intended to be? Are strange pieces like
the dragon, etc. going to be bothered with?
Depending on how long this project runs, I may join in if I am welcome...
maybe I'll do a PowerPC port when I get the 604 I've been saving my
pennies for :)
Hans Gerwitz
Virtual Persona
Daniel LaLiberte
Core Code
---------
...
Basically, the system is as follows: There is a coordinate system
that is similiar to coordinates on a globe. These two numbers
(theta and phi) will determine where the viewer is looking from.
Then, there is a less important number, L, which determines the
radius the viewer is looking from.
There is also an angle which says which way is up, from the viewers
perspective. Also, instead of always looking at one point, the center
of view could be adjusted. Together, these would be useful for
looking at an object from all angles.
I have been working on a language for describing Lego constructions.
Here it is so far. Please comment.
Dan LaLiberte
lib...@cs.uiuc.edu
(Fight interface copyrights and software patents.
Join the League for Programming Freedom: l...@uunet.uu.net)
-------
This is a description of a Lego description language (unnamed as yet).
The language can be used to compose Lego pieces from primitives, and
to hierarchically compose these pieces into constructions. This is an
ASCII text language.
Units
-----
There are two kinds of units to specify sizes, positions, and other
values. Standard units are in 1/16th of an inch multiples, since
that is a convenient measure for many Lego blocks. Block units are
multiples of the 1x1 flat block size, which is 5x5x2 in standard units.
Numbers in block units have a "u" at the end.
Objects
-------
There are two kinds of objects in the language: simple objects and
groups of objects. A simple object is either a primitive or it is
constructed by calling a parameterized object definition. Any object
may be named, and naming is necessary to refer to objects elsewhere in a
group.
The notation: {<objects> ... } is for creating a group of objects.
Things contained in the brackets are any objects separated by spaces.
The notation: <name>(<parameters> ... ) is for calling an object
definition named by <name>. The <parameters> are comma separated,
e.g. block(2u, 4u, 3u). Any parameters not supplied use the default
value given in the definition, if any. Primitive objects are also
called in this fashion.
The notation: <name> = <object> is for naming objects. The <name> is
any alphanumeric sequence (that doesnt conflict with a number
notation). The <object> is either a group or an object call. For
example, 2x4 = block(2u, 4u, 3u). The <name> is only known within the
group that it is defined in, and it may be shadowed at lower levels
within the group. Names may be referenced outside of a group to make
connections between pieces, as described below.
The notation: <name>(<parameters> ...) = <object> is for defining
objects. Object definitions are not objects until the parameters are
supplied in an object call. The <parameters> are comma separated, and
the <object> may reference any of the parameters. Each parameter is
either just a <name> or a default value may be supplied with <name> =
<default-value>. e.g. block(sx=2u, sy=4u, sz=3u) = { ... }, which
could be called with block(). The <object> in a definition is
typically a group, but may instead be an object call. e.g. flat(sx,
sy) = block(sx, sy, 1u)
Note that the notation for naming an object is very similar to that of
a definition without parameters. But object calls always have
parentheses.
Any name reference in an object should either be a previously defined
named object or definition or a parameter at a higher level.
To do: Can the <object> in a definition be another definition? How
does the system know whether <name>(<parameters> ...) starts a
definition or is an object call?
Some typical parameters are as follows:
color - red, yellow, clear-red, clear-yellow, etc. "invisible"
means the object is not displayed at all. If a color is not
given, the color is inherited from the containing group, or
grey if no inherited color is available.
size - depends on the piece.
at - give the position in block units relative to the origin of
the containing group. Also see connections.
rotate - give the orientation of the piece relative to the
orientation of the containing group.
Connections
-----------
Instead of using "at" and "rotate" parameters, you can specify
connections between pieces. You can also redundantly specify
connections, positions and angles for pieces, but they must all be
consistent.
Each connection point within an object is a named component inside the
definition of the object. These names may be referenced outside the
piece using the notation: <object>.<component-name>, where the
<object> contains a component named <component-name>. (Actually,
an object may be used directly in forming connection. The position
of the object is used instead of the position of a component.)
Connections between pieces are specified by using == between the
connecting components of the pieces. The positions of the connected
components are made the same as each other. So you can connect the
studs of one 2x4 to the bottom of another with:
{
piece1 = 2x4(red)
piece2 = 2x4
piece1.stud00 == piece2.bottom00
}
or without naming the pieces:
{
2x4(red).stud00 == 2x4.bottom00
}
To do: gear and axle connections.
Primitives
----------
The primitive pieces used to compose all other pieces are solids:
box - a volume.
The size is three numbers: sx, sy, sz.
Position is three numbers: x, y, z.
Rotation is in degrees around x axis, y axis, z axis.
cyl - a cylindar.
The size is the radius and height.
Position, rotation.
A 1x1 block can be constructed from these primitives as follows:
1x1 = { face(px, py, rz) = box(5, 1, 6, px, py, 0, 0, 0, rz)
front = face(0, 0, 0)
back = face(0, 1u, 0)
left = face(0, 0, 90)
right = face(1u, 0, 90)
top = box(5, 5, 1, ...)
stud = cyl(3, 1, 2.5, 2.5, 6)
bottom = cyl(0, 0, 2.5, 2.5, 0, invisible)
}
To do: need negative space too for cutouts.
Repetitions
-----------
Most Lego blocks are essentially the same kind of block scaled to
different sizes with repeated subcomponents. (The underside of small
and thin blocks varies, however.) A wall of similar pieces could be
constructed by specifying repetitions of one piece.
Arithmetic
----------
Some simple arithmetic would be useful with repetitions and to compute
values from parameters.
Brian Paul
FYI, Last spring I wrote a program called V-Blocks (Virtual Blocks) as an
entry in the SGI Indigo games contest. Basically, it's a simple, interactive,
3-D LEGO CAD program. There are 3 kinds of pieces: bricks, plates and angled
roof pieces. Each kind of piece is available in several sizes and there are
9 colors to choose from. Using the mouse you can interactively build a model
and change your viewpoint in 3-D. There's also a virtual reality "walk-through"
mode in which you use the mouse to fly through or around your model.
The program can be found on the SGI IndiZone CD ROM which is supposed to ship
with all new SGI workstations. I don't think the source code was put on the
CD though. I'll have to ask someone at SGI if it's OK for me to disclose the
source (I might have signed away that right on the entry form).
Anyway, those of you interested in making a LEGO CAD program may want to look
at V-Blocks for ideas. Bear in mind that this program was designed for an
SGI with high-speed 3-D graphics. I don't think this program would be usable
on a PC or Mac for example.
-Brian
David Karr
>
>A note on dimensions: in order to keep all measurements in
> integers, the standard unit will be a 16th of an
> inch. I know all the Europeans will cringe at
> this, but on the suggestion of Peter Murray, I've
> been told all measurements are multiples of this:
> a 1x1 is really 5 x 6 ; a stud is 3 in diameter;
> a board is 1.
According to the data provided by the MIT class and cited in the FAQ,
the common denominator of these dimensions is not 1/16 of an inch but
rather 1.6 mm. But you will have to use rather careful techniques to
find out which is which since these two measurements differ by less
than one percent. (Specifically, 1/16 in = 1.5875 mm, conversely
1.6 mm = 1.0079/16 in.)
I dragged out my old vernier caliper for this task -- it reads in
units of 1/100 mm, but as usual the last digit is not totally
reliable; I figure my error of reading is +/- 0.02 mm. I also picked
up a couple of large Lego blocks: a 4x12 from my daughter's set
(vintage 1993) and a 10x20 from my old collection (vintage c. 1970).
I wanted to estimate distance between centers because the actual brick
width is always slightly undersized and so does not scale properly
(i.e., a 1x8 will generally not be four times as long as a 1x2).
To do this I measured the diamters of knobs and then measured the
distance between the edges of two distant knobs. All measurements
are in millimeters. The goal was to estimate w, the spacing between
knobs.
First the 4x12: I measured two knobs at 11w apart.
d1 = 4.87
d2 = 4.89
d = (d1+d2)/2 = 4.88
L = 92.76 between the furthest points on each knob, i.e. this is 11*w + d
w = 7.989
% diff from 1.6 mm = -.136%
% diff from 5/16 in = .649%
Now the 10x20. My caliper couldn't span 20 knobs, so this is measured
across just 19 (i.e. knobs 18w apart) along one edge by angling the
jaws in; this is the least accurate of the three techniques.
d1 = 4.88
d2 = 4.86
d = (d1+d2)/2 = 4.87
L = 148.60 between the furthest points on each knob, i.e. this is 18*w + d
w = 7.985
% diff from 1.6 mm = -.188%
% diff from 5/16 in = .598%
I made a second measurement on the 10x20 by measuring knobs 19w apart but
measuring the inside distance (closest points):
d1 = 4.88
d2 = 4.84
d = (d1+d2)/2 = 4.86
L = 146.90 between the closest points on each knob, i.e. this is 19*w - d
w = 7.987
% diff from 1.6 mm = -.158%
% diff from 5/16 in = .624%
Now I note that in all cases I detected a deviation from the MIT claim
w = 8 mm -- in fact I got consistently less -- but the error is much
less than the error from 5/16 in, in fact the error from 1/16 is always
at least 3 times as great, and on the most modern piece (with the best
technique) was more than 4 times as great. So my bet is that 8 mm is
the spacing designed by Lego, not 5/16.
Incidentally, *all* the knobs I measured were larger than the MIT claim
of 4.8 mm (and consequently even larger yet than 3/16 in.), which also
leads me to believe in a 1.6 mm basic unit.
However, as far as the LegoCAD project goes, it doesn't really make a
difference. There is no intention (as far as I can tell) of ever
comparing Lego to some non-Lego object in any drawing with a tolerance
of less than 1 percent. (In fact I don't see where any non-Lego
object ever gets introduced.) So you can pick any reasonable nominal
measurement as your basic unit; 1/16 is certainly close enough.
Unless you use exceptionally accurate equipment to create "full size"
drawings, when are you going to care about a 0.79% difference in size?
-- David A. Karr (ka...@cs.cornell.edu)