| |
Lots of good comments, this is very exciting stuff, ne?
In lugnet.cad, Todd Lehman writes:
> In lugnet.cad, Jake McKee writes:
> > However, as
> > many developers will tell you, it's good to try and manage the growth of a
> > format to some extent, so we would like to maintain the official list of
> > what the format includes.
>
> So -- no, it won't be an open format? It'll be a closed, proprietary,
> undocumented format?
Those aren't the only two alternatives. It could well be closed (changes
controlled by LEGO only, rather than by a standards committee) but still
well documented rather than "undocumented".
++Lar
|
|
| |
In lugnet.cad, Larry Pieniazek writes:
> In lugnet.cad, Todd Lehman writes:
> > In lugnet.cad, Jake McKee writes:
> > > However, as
> > > many developers will tell you, it's good to try and manage the growth of a
> > > format to some extent, so we would like to maintain the official list of
> > > what the format includes.
> >
> > So -- no, it won't be an open format? It'll be a closed, proprietary,
> > undocumented format?
>
> Those aren't the only two alternatives. It could well be closed (changes
> controlled by LEGO only, rather than by a standards committee) but still
> well documented rather than "undocumented".
Ya, that would be a lot like Adobe's approach to PostScript. It's a closed
language in that Adobe has decreed that they are the official purveyors of
enhancements to the language, but it's an open language in that it's extremely
well documented.
I suspect that LXF will be a completely undocumented, proprietary, closed,
binary file format and that it will be up to us to reverse engineer the file
format in order to create useful cross-platform tools to manipulate LXF files.
On the other hand, reverse engineering the file format may engender ill will,
the fear of which works towards TLC's advantage, passively discouraging people
from attempting it. It'll be interesting to watch this unfold. I made my
best case for a well-documented text-based format long ago...I was thanked
for my input and I think that's as far as the suggestions got. :-)
I would *love* to be proven wrong, however, because I don't think it's
healthy for the community to be locked into and dependent on a proprietary
SDK and proprietary conversion tools to interface with LXF files --
especially software that isn't cross-platform. I also think that TLC won't
achieve its goal of having LXF be the new de-facto standard for interchange
of models online unless TLC either releases -all- the parts or works with the
community to allow the community to develop unofficial versions of the parts.
--Todd
|
|
| |
In lugnet.cad, Todd Lehman writes:
> I suspect that LXF will be a completely undocumented, proprietary, closed,
> binary file format and that it will be up to us to reverse engineer the file
> format in order to create useful cross-platform tools to manipulate LXF files.
> I would *love* to be proven wrong, however, because I don't think it's
> healthy for the community to be locked into and dependent on a proprietary
> SDK and proprietary conversion tools to interface with LXF files --
> especially software that isn't cross-platform.
I also hope you're proven wrong, but the presence of an NDA would
seem to indicate otherwise. Either way, I'm willing to work on cross
platform tools if the Digital Designer software is more popular with
my kids than Creator was.
> I also think that TLC won't
> achieve its goal of having LXF be the new de-facto standard for interchange
> of models online unless TLC either releases -all- the parts or works with the
> community to allow the community to develop unofficial versions of the parts.
I don't know about that. They could still leverage their patent
portfolio http://news.lugnet.com/cad/?n=8622 to achieve that goal.
Yikes! I'm gonna have to stop reading Todd's posts. They're bringing
out my paranoid side. I think I'll just cross my fingers, cover my
eyes and ears, and hope for the best in June.
Don
|
|
| |
In lugnet.cad, Don Heyse writes:
> [...] They could still leverage their patent
> portfolio http://news.lugnet.com/cad/?n=8622 to achieve that goal.
Oh! That's interesting! The upside of thisof course is that at least some
of the LXF format -is- documented. That's good. Hmm, I wonder which
countries LEGO has obtained this patent in, or if it's even enforceable in
the U.S.? Does anyone at a law firm or in law school have access to all 89
claims? Granted patents are public information, so someone could post a
copy of the claims here and we could pick them apart for fun.
> Yikes! I'm gonna have to stop reading Todd's posts. They're bringing
> out my paranoid side. I think I'll just cross my fingers, cover my
> eyes and ears, and hope for the best in June.
Sorry, I'm not trying to make anyone else paranoid or offend Jake or anyone
else at LEGO, I just think it's in our best interests for us all to ask
tough questions and state our deepest concerns honestly, publicly, and
candidly, before becoming overly enthusiastic. Don't get me wrong, I think
LEGO is headed in a great direction with this.
The question I think we all must ask ourselves is, what do we each give up
in order to get what LEGO is asking us to buy into with our individual and
collective time and brainpower?
--Todd
|
|
| |
In lugnet.cad, Todd Lehman writes:
> Sorry, I'm not trying to make anyone else paranoid or offend Jake or anyone
> else at LEGO, I just think it's in our best interests for us all to ask
> tough questions and state our deepest concerns honestly, publicly, and
> candidly, before becoming overly enthusiastic. Don't get me wrong, I think
> LEGO is headed in a great direction with this.
Not at all offended. I knew there would be some questions and concerns.
There have been a number of things raised that I will work on getting solid
answers for, since I'm not well versed in the details of this project.
Before much of this spirals out of control, let me get some answers and then
we can talk.
> The question I think we all must ask ourselves is, what do we each give up
> in order to get what LEGO is asking us to buy into with our individual and
> collective time and brainpower?
I can totally respect that. I would just ask that you give the benefits
equal thought too. What do you get by buying in?
I swear that we are not the "big bad company", and we aren't out to take
advantage of anyone. We are a group of people working on a very long term
project for many many months, and are doing our absolute best to share as
much with you as possible. We have no interest or intention of releasing a
standard file format that doesn't allow the community to add their own
parts. As mentioned in the announcement, for the forseeable future, the
LDraw format and LXF will probably live side by side.
We haven't developed (and aren't trying to) any kind of "secret society", or
playing favorites. This project is monumentally large in that we are
releasing data on how LEGO elements (our very reason for being as a company)
are described. As you can imagine, there is much legal groundwork to lay,
and is still being laid. Rather than involve the community when this is
finished, we decided to invite the LDraw software developers (under NDA) to
have some discussions with us about the concepts we are working on. Simply
put, we have to protect our business.
By the way, the thing that we "want" from the community on this
collaboration is not to have you write software for us, we are already
working on that (Digital Designer). Rather we felt it was important to share
as much as possible with you in order to help drive community. Imagine if
the original Mindstorms software had focused on kids, but we had also
released the details of the RCX to the AFOLs at launch. It wouldn't have
made much difference to the kids market, since a 10-12 year old wouldn't
have developed NQC, for instance. But man, it would have made it easier to
develop that language.
More information tomorrow!
Jake
---
Jake McKee
Community Development Manager - N. America
LEGO Direct
|
|
| |
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.
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?
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?
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.)
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 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.
> [...] We have no interest or intention of releasing a
> standard file format that doesn't allow the community to add their own
> parts.
Yay!
So why didn't you just say that in the first place? :-)
BTW, does this mean that people can add their own unofficial versions of
official LEGO parts, or will people only be allowed to add unofficial
non-LEGO parts? (I realize that probably sounds like a dumb question, but I
just want to clear up any possible ambiguity on what "their own parts" could
mean.)
Can people add MEGA-BLOKS(R) parts or do they have to stick with LEGO(R)
parts? What if someone creates and releases a library of MEGA-BLOKS parts
in LXF format?
> As mentioned in the announcement, for the forseeable future, the
> LDraw format and LXF will probably live side by side.
When you say "in the forseeable future," do you mean that LXF may replace
the LDraw format someday as the format of choice among cadders? Would LEGO
like to see LXF replace LDraw someday? Or would LEGO like to see LXF and
LDraw co-exist indefinitely?
> [...]
> By the way, the thing that we "want" from the community on this
> collaboration is not to have you write software for us, we are already
> working on that (Digital Designer). Rather we felt it was important to share
> as much as possible with you in order to help drive community.
What if the community embraces the _concepts_ regarding how to describe
parts, but ultimately rejects the LXF _file format_? (I don't mean that as
a hypothetical question -- I think it's a real possibility, albeit small.)
> Imagine if
> the original Mindstorms software had focused on kids, but we had also
> released the details of the RCX to the AFOLs at launch. It wouldn't have
> made much difference to the kids market, since a 10-12 year old wouldn't
> have developed NQC, for instance. But man, it would have made it easier to
> develop that language.
Hmm, well, I think people wanted to program the RCX directly because the
software that LEGO released with it was designed for kids, while the RCX
hardware itself was powerful enough for adults. It's entirely clear to me
why people would want to program a sophisticated piece of hardware like the
RCX, but it's not entirely clear to me why people would want to make tools
which read and write LXF files when the only LEGO product that supports LXF
files is designed for kids. I guess it's kind of a chicken and the egg
problem, huh?
> More information tomorrow!
Ok, thanks for shedding light on questions tonight! Looking forward to more
of your answers tomorrow!
--Todd
|
|
| |
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
|
|
|
