| |
I have been watching this thread with interest. Personally I find the
prospect that LEGO is going to potentially open up some of their
intellectual property to the community pretty interesting and not something
you see happen very often.
How they do this remains to be seen and there has been an awful lot of
speculation on what it all means. I am actually somewhat surprised with
regard to the level of skepticism voiced on this topic. The prevailing
thought seems to be that LEGO is trying to take over the area of the
community that has been to date served by L-Draw.
More thoughts below ...
"Todd Lehman" <todd@lugnet.com> wrote in message
news:HE57M8.1rso@lugnet.com...
> In lugnet.cad, Jake McKee writes:
> > I can totally respect that. I would just ask that you give the benefits
> > equal thought too. What do you get by buying in?
>
> Honestly, I don't see any benefits for the LCAD community in supporting • the
> LXF format, unless the LXF format is so many more light years ahead of the
> LDraw format that the effort of supporting LXF would be miniscule compared
> to the benefits.
Not seeing any benefit is a pretty bold statement - cetainly not one that
should be made on the community's behalf based on the limited knowledge we
have regarding what LEGO is really going to do.
Right now there is a group of people in the LEGO community who create L-Draw
fomatted parts. Some of these parts take a long time - see this article -
http://news.lugnet.com/cad/dat/parts/?n=4615. I can't fathom the time and
effort to create this part. I greatly appreciate the fact that people are
willing to do this although to be honest, I wonder if it is sustainable. Is
there a finite number of people willing to be part authors for no pay and
little recognition?
Wouldn't it be nice if it was simply avaible from LEGO is a parts library?
Presumably it wouldn't need to be verified - it comes directly from the
source. Currently L-Draw parts are reverse engineered from real parts (or
they are supposed to be). That has to be an error prone and time consuming
process.
Suppose that LEGO releases a new LXF formatted parts library every month.
Now suppose that new elements are included in the parts library in the same
month that sets that contain them hit the street. There is zero ramp time
for users of CAD tools (assuming they support the LXF format) to start using
these new parts. They don't have to be reverse engineered, they don't have
to be verified, they don't have to live in the Parts Tracker for some
unknown period of time - they are ready to use.
>
> But if that's the case, then why wouldn't the LCAD community just raise • the
> LDraw format's capabilities to the level of LXF's capabilities and forget
> about native LXF support?
Again, maybe, maybe not. Raising the capabilities of the LDraw file format
may be a fair amount of work too. Some of the features in LXF may not be
implementable with the L-Draw format. What if the LXF format supports
collision detection and/or connection points (the ability to define legal
connections)? I have built models where parts were askew by one or two
L-Draw units (LDU) were not obvious until I rendered it with POV. By that
time it is pretty late in the instruction creation process for me - it would
be nice to know that two parts were intruding on each others space.
Imagine if the train track parts were smart enough to understand what a
legal connection is. A replacement for Track Designer might not be as much
work for someone to undertake. Right now no one can update or enhance Track
Designer because no one knows where the source code is! So the choice is to
either live with what we have or write a new one from scratch and
re-engineering all of he connection smartness that Track Designer currently
has. If the LXF library includes connection points, this may not be such a
daunting task.
>
> Additionally, if LEGO releases parts in LXF format, and someone writes an
> LXF-to-LDR converter, what's to be gained by adding native LXF support to
> tools like MLCAD when it would be easier simply to convert all the LXF • parts
> to LDR parts?
If the converter is really good and easy to use, probably not much. If the
converter is cumbersome and produces poorly converted parts, then support
for LXF may provide the application developer quite a bit. Developers want
access to the broadest library of high quality parts. If that library is
the L-Draw based one, they will support that. If LXF looks like it will be
a better solution and/or allow them to solve problems they currently can't,
then they will add support for LXF.
>
> Also, if LXF promises increased modeling capabilities (because it's a lot
> more sophisticated file format), why will developers spend their time
> learning to work with a proprietary format when they could instead be
> developing a free and open format? (I'm not saying they won't, I'm just
> having a little trouble seeing the motivation.)
I suspect the motivation would come from not wanting to re-invent the wheel
simply for the sake of re-inventing the wheel. With a community comprised
of volunteer developers, if they can get their application functioning,
released and and satisfying a need quickly using LXF, I would imagine they
would do it.
Adding more to the development cycle in order to add support for new
constructs to the existing L-Draw format to avoid using LXF doesn't make a
lot of sense from a time management perspective. However, engineering
fields are fraught with NIH and people do things all the time that other
people have already done simply because they want to. Just because you can
do something doesn't mean you should. Freeware and Shareware do not follow
the same rules of development that commerical development does (which can be
both good and bad) and people don't make techncial decision based on
business factors (make vs. buy).
>
> It seems to me that the real gain here for the LCAD community, long term,
> may simply be exposure to cool algorithms and data structures. To really
> benefit from these doesn't require recoding software to support the LXF
> format -- only enough to understand the cool stuff well enough to
> reimplement it in an open and free way. But maybe that won't happen. • Maybe
> enough people will be fine with using a proprietary file format that it • will
> reach critical mass.
I don't understand the requirement/mandate for open and free. I don't see
open and free as joined at the hip either. Something can be free without
being open. There are lots of things people can download and use without
access to the source code and the internal data structures.
We all use LUGNET on a regular basis and we can't go off and look at the
LUGNET internals. We don't know how all of the data is stored and accessed.
We know there is a web interface and how to interact with that. We know
there is an NNTP interface and how to interact with that.
> > I swear that we are not the "big bad company", and we aren't out to take
> > advantage of anyone.
>
> I hope I didn't give them impression that I thought that. I think LEGO is
> acting in what it believes to be its best interests from a business
> perspective. My questions arise from the belief that what's in LEGO's • best
> interest, however, isn't necessarily the same thing as what's in the LCAD
> community's best interest. I think having an additional file format to
> choose from (LXF) sure is a nice thing, especially if it opens new doors.
> But clearly a free and open file format would serve the LCAD community's
> interests better than a proprietary format. Obviously LEGO believes that • a
> proprietary format will serve LEGO's best interests. Time will tell. It
> worked splendidly for Adobe.
While not a public company, LEGO is still a for profit company. The
decisions they make have to be in line with their business goals and
objectives. If they have concepts or projects that are not in line with
their business goals it is highly unlikely they will get funded. Most
companies have some skunk works projects that fly under the radar screen but
at some point (usually when they are exposed to customers) they have to
answer to business people. How will this project help the company make
money? If it doesn't, then it has to be justified with other means:
Community good will, cutomer satisfaction, competitive differentiation,
etc. - lots of reasons that are much harder to attach dollar figures to.
Imagine you are an excutive at LEGO and you get a proposal to release all of
your elements in a CAD format so the customers can do their own designs on a
computer. You can envision the line of questioning:
Project Manager: My proposal is to release all of our part models as
library parts in DXF format. It will allow our customers to design their
own models, something they have been asking to do for years. By releasing
in DXF we don't have to build a new CAD tool - which would be expensive -
but people would use their own (AutoCAD, ProEngineer, etc.).
Executive: Isn't that risky? Couldn't our competitors copy our parts much
easier?
Project Manager: I suppose. But many of our parts are already in a CAD
format on the Internet - there is a group of people who reverse engineer our
parts and publish them in this "L-Draw" format.
Executive: Really? How good are they?
Project Manager: They are really good although the more complex ones take
them some time to do and tend to have more errors.
Executive: Is there a big demand for this?
Project Manager: Growing - particulary with the adult market. There are
books available and more being written and no less than a half a dozen free
applications that allow people to create very detailed models and
instructions. It will also generate a lot of good will with a very loyal
part of our customer base. It also helps broaden the brand by having third
parties creating books and publishing models. We gain exposure without
having to spend the resources to write and publish books.
Executive: I am concerned about simply publishing our CAD files, is there a
middle ground?
Project Manager: Maybe. We might be able to define a neutral format or an
API that allows use of our data but limit the exposure of our sensitive
information. But there are a lot of clever people out there. Eventually
someone will reverse engineer it just like they did with MindStorms.
Executive: Maybe but it seems less risky, bring me a proposal based on that
concept. We also need to float this idea to some of these "L-Draw" people
and see what they think.
[ ... lots of snippage ... ]
These are my thoughts on this subject for now, I am really interested in
this thread. I make a living in the CAD industry (Electical Engineering)
and this whole topic isn't all that different than what I deal with on a
regular basis. In fact, It is surprising how similar this thread is.
For example - One of my customers is designing an ASIC (a custom chip) with
a really large semiconductor company (XYZ) and is concerned about the signal
integrity effects that ASIC will create when placed on a printed circuit
board. The customer would like to run a signal integrity analysis on the
design including the IO of the ASIC. They need a model of the ASIC IO and
only XYZ is really qualified to provide it.
However, if XYZ makes their IO models available on their web site for anyone
to download, their competitors can gain insight into their semiconductor
manufacturing process. So XYZ doesn't really want to give away IO models,
they would rather the customer create their own models (which they can do
but it is a slow, error prone process) from information published in XYZ's
databooks. But in some cases they have to provide models (customers really
can exert a lot of pressure if so inclined). So they provide models that
contain the minimum amount of information that the customer needs in order
to get their analysis done. It's a crappy way to get the information but
that is what happens.
Now XYZ is starting to provide encrypted models. Customer is happy because
they can do an analysis. XYZ is happy because they are not exposing trade
secrets. Some people still believe XYZ should make source avaible because
"we are a valued customer".
It is all about protecting intellectual property and satisfying the
customer - a hard line to balance on.
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
|
|
| |
In lugnet.cad, Mike Walsh writes:
> I have been watching this thread with interest. Personally I find the
> prospect that LEGO is going to potentially open up some of their
> intellectual property to the community pretty interesting and not something
> you see happen very often.
I agree and I think it'll represent a great step toward enhanced
collaboration with the community.
> How they do this remains to be seen and there has been an awful lot of
> speculation on what it all means. I am actually somewhat surprised with
> regard to the level of skepticism voiced on this topic. The prevailing
> thought seems to be that LEGO is trying to take over the area of the
> community that has been to date served by L-Draw.
I don't get that impression... I think LEGO will strive to work with the
LCAD/LDraw community to
establish new standards. I think the skepticism arises out of uncertainty
about the level of openness
of the file formats and out of concerns about LEGO patents and possible
cross-platform issues.
If the LXF format is as flexible, extensible, and wonderful as I think we
expect it to be, then it's
certainly within the realm of possibility that the LXF format could totally
replace the LDraw file
format within a year or two. Now I don't mean to suggest that tools like
MLCAD would be obsolete,
only that the LDR/MPD/DAT format may become obsolescent. Is that good or
bad? I don't know. I
know I'd be sad to see an open format be replaced with a proprietary one,
especially one
encumbered by patents.
*If* this happens, and we're all sharing LXF files in the future instead of
LDR/MPD/DAT files, it
*could* still be a totally beautiful thing. It seems likely, though, that
in order to discuss intimate
details of parts creation in LXF format, it will be necessary to convert the
LXF part file into ASCII text
through some sort of data structure dump. Some sort of LXF-dumping syntax
is likely to emerge
quickly and be standardized upon. (Perhaps LEGO will provide a tool for
this, perhaps not.) The
reverse will also be needed in order to update part files with changes.
Wouldn't XML be a logical
choice for the ASCII dumping syntax? And if so, why not create new parts
masters in XML instead of
LXF? A part master in XML could then be turned into .lxf, .dat, .pov, etc.
It seems patently obvious (no pun intended) to me that an XML-based part
masters would be a lot
more general and give more freedom than LXF-based masters. I don't know how
I'd manipulate LXF
files in Perl or Java, for example.
If you're a parts designer, would you rather design parts directly in LEGO's
proprietary LXF format or
instead in an open-standards XML-based format that could easily be
translated to LXF as a special
case?
> > > I can totally respect that. I would just ask that you give the benefits
> > > equal thought too. What do you get by buying in?
> >
> > Honestly, I don't see any benefits for the LCAD community in supporting the
> > LXF format, unless the LXF format is so many more light years ahead of the
> > LDraw format that the effort of supporting LXF would be miniscule compared
> > to the benefits.
>
> Not seeing any benefit is a pretty bold statement -
Ok, I think you missed the "unless" clause of my sentence above. :-)
> cetainly not one that should be made on the community's behalf based on
> the limited knowledge we have regarding what LEGO is really going to do.
I'm sorry if that was confusing. I didn't mean to make a statement on the
LCAD community's behalf.
What I mean is that *I* don't see anything that the LCAD community has to
gain by supporting the
LXF format, unless the LXF format is light years ahead of the LDraw format
(and it may well be).
> [...]
> Wouldn't it be nice if it was simply avaible from LEGO is a parts library?
> Presumably it wouldn't need to be verified - it comes directly from the
> source.
Absolutely, that would be awesome. That's been sometime wished for by many
for a long, long
time.
> [...]
> Suppose that LEGO releases a new LXF formatted parts library every month.
> Now suppose that new elements are included in the parts library in the same
> month that sets that contain them hit the street. There is zero ramp time
> for users of CAD tools (assuming they support the LXF format) to start using
> these new parts.
In order to benefit from the data contained within the parts library, is it
absolutely necessary for CAD
tools to support LXF natively?
Couldn't a tool simply convert the LXF parts into a neutral, open-standard
format and forget about
LXF?
> Again, maybe, maybe not. Raising the capabilities of the LDraw file format
> may be a fair amount of work too. Some of the features in LXF may not be
> implementable with the L-Draw format. What if the LXF format supports
> collision detection and/or connection points (the ability to define legal
> connections)? I have built models where parts were askew by one or two
> L-Draw units (LDU) were not obvious until I rendered it with POV. By that
> time it is pretty late in the instruction creation process for me - it would
> be nice to know that two parts were intruding on each others space.
>
> Imagine if the train track parts were smart enough to understand what a
> legal connection is. A replacement for Track Designer might not be as much
> work for someone to undertake. Right now no one can update or enhance Track
> Designer because no one knows where the source code is! So the choice is to
> either live with what we have or write a new one from scratch and
> re-engineering all of he connection smartness that Track Designer currently
> has. If the LXF library includes connection points, this may not be such a
> daunting task.
>
> If the converter is really good and easy to use, probably not much. If the
> converter is cumbersome and produces poorly converted parts, then support
> for LXF may provide the application developer quite a bit. Developers want
> access to the broadest library of high quality parts. If that library is
> the L-Draw based one, they will support that. If LXF looks like it will be
> a better solution and/or allow them to solve problems they currently can't,
> then they will add support for LXF.
Points well taken. But is that better than extracting the data from the LXF
parts libraries and
converting the parts to a new, slightly more general, vendor-neutral,
open-standard file format
that's owned by the open LCAD community?
--Todd
|
|
| |
In lugnet.cad, Todd Lehman wrote:
> If you're a parts designer, would you rather design parts directly in LEGO's
> proprietary LXF format or
> instead in an open-standards XML-based format that could easily be
> translated to LXF as a special
> case?
I don't think that's really a fair and answerable question. As a parts designer, I'd
rather work in the format that is (a) the least work for me and (b) gives me the
results I want. As a parts designer, I'm not terribly concerned about abstract issue
like openness.
Steve
|
|
|
