Lego CAD: bringing bricks to the screen
Alex Devries
Alt.Toys.LEGO, I think there is a combination of skills and interest
in both LEGO and computers (communication anyway). Seeing this, I
think a LEGO Computer Aided Designer would be practical. As a
programmer, I'm taking a serious look at designing one myself.
There are a number of factors to consider in the design:
1. Simplicity of use.
Let's face it: not everyone in this world wants to hammer away
designs into a text file. A GUI (graphical User Interface) is a MUST.
2. Popularity of platforms
Lego should be for the people, not only for the rich. Similiarly,
LEGOCAD would be able to run on a cheap '386 system, maybe even
simpler. No UNIX or P5 stations required here (way too pricey, not
enough people). Also, MAC's only occupy 10% of the computer market,
so PC's it is.
3. CUA (common user access)
This means that it should be as easy to use as your draw package
or spreadsheet. Microsoft Windows 3.1 it is.
4. Reasonably easy to program
As I like BORLAND compilers/development packages, and I need to
learn C in the next term (I'm extremely fluent in Pascal, OOPS, OWL,
etc...), Borland Visual C++ it is.
5. Expandable.
LEGOCAD will be free. It will not cost you a penny, and any
bugs can be cleared up that are brought to my attention. Anyone who
makes suggestions will get their names in the credits.
So, here's what I'm asking YOU for:
- suggestions on how it should work
- a complete list of parts on the market, with drawings
- other programmers (absolutely no experience necessary; I'd love it
if some of the authors who had posted on list of parts could help me
out; also, I'll need someone to draw up Icons (I hate that), menus,
dialogs and other resources)
- someone who knows exact measurements of pieces
My basic plan of attack, if you care, is as follows:
It will be an object oriented program that will consist of one
executable. Then, the parts lists will be contained in .DLL files,
which can be expandable. That way, when another piece comes out, you
don't need to updated the whole .exe, just add a .DLL file, or draw it
yourself.
Anyway, if you have any interest in it, be it superficial or active,
PLEASE LET ME KNOW. I'm not going to write a single line of code
until I get at least 10 responses saying that this might be useful.
- Alex
aka
--
--------------------------------------------------------------------
Alex deVries
Editor, Vena Contracta (News Beacon of the Ottawa Valley)
Technical Director, Carleton Student Engineering Society
Hardware Consultant, Faculty of Engineering
3rd year systems student too!
--------------------------------------------------------------------
Hayes Harper
hey, I can draw icons... I mentioned before that I only had an Apple IIgs and
an "-ancient- Amiga 1000", well.. wonder of wonders... along with a few dinky
Lego sets (some river-rafting thing, dont have the # handy). my family pitched
in and got me a 486dx2/50 for Christmas. Now I can actually execute whatever
you come up with, rather than foaming at the mouth about suggesting such a
thing and then not being able to use it. :)
And to the rest of you (us)... Look, here's a guy that's willing to
begin this project, we've got the ideas, he has the know-how, if not the time.
Let's all pitch in what we can in order to get this puppy off the ground. Maybe
Lego would listen to a software proposal sooner than a magazine proposal.
Someone could even do a write up on the program IN the magazine, how bout it?
-Hayes
Loyal Pawn #36
Please lemme in on it. Unfortunately, my programming knowledge is minimal,but my experience on desktop platforms (macs and windows) is over a year in the work experience.
got some really great ideas tho.. make it much easier to use than autocad..
hell, I'll write the help files :>
Legos and pieces,
--
___________________________________________________________________________
Money does grow on trees.|"Homicidal Psycho Jungle Cat" - Calvin and HObbES
You just have to pay it |email: HOB...@ufcc.circa.ufl.edu
back with interest. | cir...@elm.circa.ufl.edu
Jess Kvatek
alex,
add another response to you list...
i'd like and would use such a lego cad product...
i had a simple basic program for my atari 800 that let me
plot the different road plates but that's where my programming
skills stopped... let me know if i could contribute in
some other way...
-jess
Nathan L. Clegg
: Anyway, if you have any interest in it, be it superficial or active,
: PLEASE LET ME KNOW. I'm not going to write a single line of code
: until I get at least 10 responses saying that this might be useful.
I have definite interest. I have extensive experience with C, dBASE,
BASIC, Assembly, and APL, though I have never programmed for Windows and
don't even own it. I would much prefer a DOS environment. But, if
Windows it must be, I can help out in other areas.
--
Nathan Clegg
25...@ef.gc.maricopa.edu
James Mann
>Alex Devries (adev...@alfred.carleton.ca) wrote:
>I would much prefer a DOS environment. But, if Windows it must be, I can
>help out in other areas.
>
compat 2/386 machines. I would not agree to a Windoze-only project, especially
since I won't come within 10 feet of a machine running Windoze to do anything
that requires more power and thought processing than playing it's broken hack
of Klondike. I do agree that modular extensions should be made for new parts,
and I think that three-dimensional movement of screen items is a must. I do
not have an extensive set of Legos myself, and would much like to see how a
project can be completed, and what it would look like before having to go out
and buy dozens of sets I cannot afford, looking for parts that I have no
immediate use for.
--
| CoH...@hebron.connected.com | "Just remember, you can lead a horse to|
| @Stellar Genesis | water, but your pencil must be lead." |
| (jericho.connected.com 4040) | -Oliver Hardy |
Colin 't Hart
help with resources and dialogs etc for Windows compliance.
Extensibility is the important bit. We have to be able to add things to
the program without releasing a new version every time a new brick comes
out from LEGO Corp. The DLLs for extra blocks is a good idea, but I
think perhaps a bit to much for our needs. A LegoCAD unique library file
would probably be OK without requiring the need for a DLL, although if
extra code is needed to handle the block a DLL would be required.
I'm getting ahead of where we're at. You've got my vote.
+- Colin 't Hart ------------------------+
| ha...@tartarus.uwa.edu.au (preferred) |
| ha...@lethe.uwa.edu.au (alternative) |
| har...@cs.uwa.edu.au (cs related mail) |
+----------------------------------------+
Swiss Cheese
: Having seen the interesting mix of people who subscribe to
: Alt.Toys.LEGO, I think there is a combination of skills and interest
: in both LEGO and computers (communication anyway). Seeing this, I
: think a LEGO Computer Aided Designer would be practical. As a
: programmer, I'm taking a serious look at designing one myself.
{Cut}
Although I don't have MUCH programming experience (PASCAL is the limit
of my knowledge, but I'm trying to teach myself C), and I can't stand
Windows, I'd be glad to help. My dad suggested I do something like this
way back when I had a Commodore 64, but I didn't know how at the time.
When I told him about this article, he said you guys stole his idea :)
Peter Selkin
PASE...@UNIX.AMHERST.EDU
Amy L Stoklas-Oakes-1
I am definitely interested in obtaining a CAD like program for lego
construction. I however "speak" C only barely. I wouldn't mind helping
get info on sizes and possible 3-D orientations of pieces for the program
itself though.
Peter Murray
Subject: Re: Lego CAD: bringing bricks to the screen
References: <adevries.756881126@alfred>
Keywords: LEGO CAD
Organization: Improving
Distribution: world
Just caught up with the backlog that built up while I was away for
Christmas. (Though this is my _third_ attempt to post this by a new
method - actually, I've abandoned the new method, so it should work.)
My <belated> comments on this project:
>2. Popularity of platforms
Count this as another complaint about platforms! Mac! But keep reading,
as the comments get more useful.
[Oh, I've just read further! Good idea, making it multi-platform.]
>- suggestions on how it should work
>- a complete list of parts on the market, with drawings
A _serious_ point: use sixteenths of an inch as your basic unit (at
least for defining the bricks) and you'll be able to use integers
for nearly all your measurements. Strange as it may seem for a Danish
company, the basic design unit of Lego seems to be the sixteenth of an inch!
The standard 1x1 is 5 square by 6 high, the stud has a diameter of 3 and
a height of 1 - quite easy to remember!
>- someone who knows exact measurements of pieces
Really easy to measure if you just use the right units :-) .
> It will be an object oriented program that will consist of one
>executable. Then, the parts lists will be contained in .DLL files,
>which can be expandable. That way, when another piece comes out, you
>don't need to updated the whole .exe, just add a .DLL file, or draw it
>yourself.
In case this idea is taken up by people using different platforms, it
would be nice if:
1) The files defining the parts/bricks were in a format that could easily
be ported (or posted); ie, ASCII-based.
2) You could also define sub-assemblies and use them as easily as bricks.
(Useful for ambitious models which use the same sub-assembly several times.)
3) It would also be nice if the file containing the complete model were
in a portable/postable format that could be loaded into the nice graphic
program at the other end. (Could be combined with (2) if sub-assemblies
were nestable.)
I would rather have a program which creates a 3D model for my 3D viewing
programs - but that's my problem! It does explain why I'd like to be able
to process the CAD files outside the generating program, though.
--
..Peter Murray email: pe...@table76.demon.co.uk
-- (who would like to have _all_ his LEGO models in computer form.) --
Teemu Hakala
>Count this as another complaint about platforms! Mac! But keep reading,
>as the comments get more useful.
>[Oh, I've just read further! Good idea, making it multi-platform.]
Considering the mixed hardware it is actually the only possible way
of getting anything done. And it should be easy, too, C has
standardized versions (ANSI C). Also, the graphical environments are
"used" by doing various system calls/requests, which are quite same
among all the major graphical environments (mswin, X, Mac, OS/2,
Amiga, YouNameIt).
>A _serious_ point: use sixteenths of an inch as your basic unit (at
>least for defining the bricks) and you'll be able to use integers
>for nearly all your measurements. Strange as it may seem for a Danish
>company, the basic design unit of Lego seems to be the sixteenth of an inch!
>The standard 1x1 is 5 square by 6 high, the stud has a diameter of 3 and
>a height of 1 - quite easy to remember!
Surprising.
>Really easy to measure if you just use the right units :-) .
Argh!
>> It will be an object oriented program that will consist of one
>>executable. Then, the parts lists will be contained in .DLL files,
>>which can be expandable. That way, when another piece comes out, you
>>don't need to updated the whole .exe, just add a .DLL file, or draw it
>>yourself.
NO! NO! No .DLL files here. They are mswin specific. It would be easy
to use the "LegoCAD" format in the libraries. There are some quite
good formats for vectored 3D designs, DFX being the most supported one.
>In case this idea is taken up by people using different platforms, it
>would be nice if:
> 1) The files defining the parts/bricks were in a format that could easily
>be ported (or posted); ie, ASCII-based.
Being ACSII-based would probably make it slower (a bit). There exists
an easy way to incorporate binary files in mail/postings, uuencoding
them. I don't know a system without any uu-tools.
> 2) You could also define sub-assemblies and use them as easily as bricks.
>(Useful for ambitious models which use the same sub-assembly several times.)
> 3) It would also be nice if the file containing the complete model were
>in a portable/postable format that could be loaded into the nice graphic
>program at the other end. (Could be combined with (2) if sub-assemblies
>were nestable.)
Yes, this is a good idea. Some rendering programs take DFX files
directly and rendering commands are in another file.
>I would rather have a program which creates a 3D model for my 3D viewing
>programs - but that's my problem! It does explain why I'd like to be able
>to process the CAD files outside the generating program, though.
Probably worth thinking...
--
Eric Perlman
te...@krkmoon.krk.fi (Teemu Hakala) writes:
> Being ACSII-based would probably make it slower (a bit). There exists
> an easy way to incorporate binary files in mail/postings, uuencoding
> them. I don't know a system without any uu-tools.
Using .HQX works perfect for mailing binaries (and mac binary files).
There are decoders for a LOT of platforms, but uuencoding would aslo
work, as there are uuencoders for a lot of platforms too.
--
Eric Perlman
Teemu Hakala
>> Being ACSII-based would probably make it slower (a bit). There exists
>> an easy way to incorporate binary files in mail/postings, uuencoding
>> them. I don't know a system without any uu-tools.
>Using .HQX works perfect for mailing binaries (and mac binary files).
>There are decoders for a LOT of platforms, but uuencoding would aslo
>work, as there are uuencoders for a lot of platforms too.
Tell me more. I've actually never heard of .hqx. I think uu would be
nicest, since everyone knows how to use it (if not, go see discussion
in the pics newsgroups). What actually is this hqx?
--
Dik T. Winter
systems. Files consist of two parts. Data and resources. The last contains
things like menu definitions, alert boxes, dialog boxes and the like (and
also code). Data is just that, unstructured data as far as the OS is
concerned. (Actually there is still a third part I will not go into.)
To transmit a Mac file faithful you have to transmit all parts of it.
Binhex is a program that takes the parts, massages them and creates an
ascii coded text file which can be transmitted and reconverted. This is
the .hqx file. There are sources available to do both conversions on any
platform (I should know because I have written such sources, available on
request). To use this for what appears to be purely datafiles seems overkill.
Uuencode is better (and it is also available for the Mac, it just looks
at the data part). Be aware however that there are quite a few different
uuencode versions floating around. The most basic is the standard Unix
one, its format is recognized by all others. The first line of its
output is "begin" followed by some other stuff. No splitting of files
is available, also no specific translation tables are available. But
it is the most portable format. There is some extension though that is
widely available (in all current versions?) that spaces on a line are
replaced by back-quotes. This is to prevent line truncation problems.
Note however, when your uuencoded file passes an IBM mainframe it is
likely that what comes out is not what goes in (has to do with
multiple ASCII-EBCDIC translation tables, IBM never knows what is what,
but do not query me about that). Uuencode/decode is also availble in
source, although I do not know where from memory.
My opinion: basic uuencode is the way to go. (I could mention atob and
btoa but will not do that.)
Quite technical so late in the night. Something more Lego. I still
have not seen 1994 catalogs overhere in the Netherlands.[
Cheers, dik
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: d...@cwi.nl