Subject:
|
Formalizing a method for handling synthesizable parts
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sat, 14 Sep 2002 12:59:23 GMT
|
Highlighted:
|
!
(details)
|
Viewed:
|
495 times
|
| |
|
|
I'm relatively new to the LDRAW CAD world, but am very impressed with all
the work that has been done. It is amazing that we have such a huge parts
database to work with.
I've been working on a tool for publishing LDRAW based designs. It has been
in beta test with a small group of users for the last few months. It is
called LPub. It was created and first used to publish this book
http://www.amazon.com/exec/obidos/tg/detail/-/1931836590/qid=1031919530/sr=1
-2/ref=sr_1_2/103-0463646-2275805?v=glance&s=books
by Syngress Publishing. The robots were designed by Miguel Agullo (a.k.a
technicpuppy), Soren Rolighed, Hideaki Yabuki and myself.
Like all LEGO CAD software it will be free for all to use.
This post is not to announce LPub, but to talk about compound LEGO parts,
and in particular synthesizable (a.k.a flexible) parts.
I'd like a mechanism that formalizes the definition of flexible parts, and
allows for automatic synthesis. I envision the process working like this.
We put a specification about the part we want synthesized into our design
using MLCAD (or LEdit or whatever). The specifications are very specific
about the LEGO part being used (e.g. light grey corrigated tube that starts
here with this orientation and ends here with this orientation). When a
"synthesis capable" program comes along it can replace the synthesis
specification with the LDRAW parts needed. In the case of tubing, an
algorithm (probably bezier curve fitting or whatever) will be used to
specify all the segments' placement and orientation between the end pieces.
There are a number of tube like LEGO parts: electrical cables, pneumatic
tubing, fiber optic cables, narrow and corrigated tubes for example. I
think that all of these can be handled with the same synthesis algorithm,
but the parameters provided depend on the LEGO part being synthesized.
Examples of parameters include flexibility and the length of the LEGO part.
Electrical cables are much more flexible than the corrigated tubing. There
are at least five different length electrical cables. Pneumatic tubing can
be cut to any length.
We will also want to be able to constrain the routes that these tube like
take. For example we will want to be able to control where the pneumatic
and electric cables work their way through our designs.
My Lpub program analyzes your LDRAW design honoring user defined parts as
well as pause and rotation steps. It creates an LDRAW file for each step in
the design, containing all parts up to that step, and then renders each
assembly step in POV-Ray (using that wonderful tool L3P for the conversion.)
LPub also creates part list images for each step identifying all the parts
needed to create that step.
When creating the part list images for a step, LPub gathers up a list of the
parts used in that step, renders each of the unique part type/color
combinations and then pieces them together to make a picture. This
algorithm as it is does not work well with flexible parts. If you
synthesize a corrugated tube using ldraw-mode in emacs, LPub perceives two
corrugated ands and many corrugated segments. The part list image looks
nothing like the straight corrugated tube you get from LEGO ;-)
When we have a formal method for specifying synthesizable parts, LPub can
perceive the part as one part, synthesize an unbent version of the part,
render it and use that to make the part list image.
Once we've agreed on a formal specification for synthesized parts, I'd be
happy to code up the synthesis algorithm in C in a portable way, and make
the source code available for all LEGO CAD programs that want to use it.
Right now, external synthesizers are used and the synthesized results are
placed into an LDRAW file where needed. With a freely available synthesis
algorithm in place, we could switch to a "just in time" synthesis mechanism
where the original LDRAW files never contain the synthesized results. For
example when MLCAD is opening a file and runs across a synthesizable part,
it synthesizes it before displaying the file to the user. We can and should
provide a way to synthesize into the original LDRAW file if desired.
If synthesis support were added to L3P, it could do some POV specific
algorithms to make things look even better if needed.
I perceive two classes of synthesizable parts: tube like parts, and rubber
band like parts. I include rubber bands, treads, chains, string and
conveyor belts in this category. For the simple rubber band we need to
specify the pulleys or pins that are inside the rubber band, as well as any
constraints outside the rubber band, we'd need to provide for bands that
cross over themselves, and non-planar synthesis for situations where the
constraints do not all lie in the same plane.
If we can formalize these synthesizable parts and provide algorithms that
support the specification, we might be able to move "flexible parts" from
the arena of black magic to that of every day users.
One big question is what is the format that the specification takes within
an LDRAW file? At first I thought that it would take the form of
specialized parts that imply synthesis and synthesis parameters. I think
that this works well for specifying physical constraints, I don't think this
will be enough. I suspect that we will want to use special comments for
synthesis to specify attributes about the physical constraints or the
synthesis process.
Input?
Kevin
Furthermore in my case of creating publishable documents
|
|
Message has 6 Replies:
 | | Re: Formalizing a method for handling synthesizable parts
|
| (...) I think this would be very nifty! (...) One other type of flexible part is string. Taut string should conform to the shape of whatever it is wound on, leave tangentially, and have a linear path to the other end. Slack string should conform to (...) (22 years ago, 13-Sep-02, to lugnet.cad.dev)
| | | Re: Formalizing a method for handling synthesizable parts
|
| I'm going to mostly stay out of this discussion for now. I will throw out a few suggestions/requirements, though: 1. The final definition should be renderable by ldraw.exe. 2. It might be a good idea to put each 'synthesizable part' in its own file (...) (22 years ago, 17-Sep-02, to lugnet.cad.dev)
| | | Re: Formalizing a method for handling synthesizable parts
|
| Here is an update on formalizing synthesis. For now, I'v decided to make the synhtesizer a stand alone program that runs at a command prompt like L3P. The program is called lsynth. It takes two command parameters: source LDR name amd destination LDR (...) (22 years ago, 23-Sep-02, to lugnet.cad.dev)
|
37 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
