 | | | | | | |
| |
|
For whatever reason, I've never made the shift to MLCad or other platforms, and
I've been served very well James Jessiman's foundation programs. Lars Hassing's
L3Lab and Kevin Klague's LPub have been invaluable as well, but everything I do
that's Lego CAD-related (apocryphal or otherwise) starts in LEdit.
Anyone who knows me knows that my particular brand-loyalty makes me a bit of an
outsider in this community, and that's fair. However, speaking as an outsider,
I can say that one thing that has really soured me on LDraw in recent years is
the seemingly obsessive lawyer-ization of it, to the point that it's become less
of an exercise in Lego design and more a monument to hyper-legalism and
over-compartmentalized classification.
I don't have a specific example ready at hand, but I believe that a basic 2x4
brick might conceivably have 18 lines of actual code and 36 lines of why's and
wherefore's and provisos. However necessary this can be argued to be, I find it
distasteful, and a sharp diversion from what I have always perceived to be the
project's original value. This, coupled with a years-long drought of new LDraw
parts, has made it seem as though the primary goal was to create a system of
attribution which, by the way, could also be used to build virtual Lego models.
I think that I only interacted with James on one occasion (on RTL); others here
knew him much better and were in on the ground floor of LEdit long before I
showed up at the party in late 1997, so I don't presume to understand his vision
better than anyone else.
I'm also not flaming anybody, nor am I claiming special insight as to what would
work "better" than the current scheme. However, if we're asking why people have
drifted from the LDraw portion of the hobby, then it seems to me that part of
the answer must address the rigidity that's taken hold in the past few years,
and we must ask if it was worthwhile, even if we accept that it was necessary.
My $0.02.
Dave!
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Dave Schuler wrote:
> For whatever reason, I've never made the shift to MLCad or other platforms, and
> I've been served very well James Jessiman's foundation programs. Lars Hassing's
> L3Lab and Kevin Klague's LPub have been invaluable as well, but everything I do
> that's Lego CAD-related (apocryphal or otherwise) starts in LEdit.
LEdit's pretty much outdated these days. It doesn't support the LDConfig
colours, nor can it edit MPD:s and the LSC is not taking it too seriously when
making choices. (at least I'm not..)
> Anyone who knows me knows that my particular brand-loyalty makes me a bit of an
> outsider in this community, and that's fair. However, speaking as an outsider,
> I can say that one thing that has really soured me on LDraw in recent years is
> the seemingly obsessive lawyer-ization of it, to the point that it's become less
> of an exercise in Lego design and more a monument to hyper-legalism and
> over-compartmentalized classification.
>
> I don't have a specific example ready at hand, but I believe that a basic 2x4
> brick might conceivably have 18 lines of actual code and 36 lines of why's and
> wherefore's and provisos. However necessary this can be argued to be, I find it
> distasteful, and a sharp diversion from what I have always perceived to be the
> project's original value. This, coupled with a years-long drought of new LDraw
> parts, has made it seem as though the primary goal was to create a system of
> attribution which, by the way, could also be used to build virtual Lego models.
I agree here partially. I too think that some bits here are bit too formal...
but I tend to think that !HISTORY lines are pretty much useful to keep track on
what's happened and when.. but something that I can't possibly understand is
that if a part author completely remakes a part and gets it to the tracker, the
rewrite must be a !HISTORY line and the author cannot get the Author line!
Really de-motivating...
> I think that I only interacted with James on one occasion (on RTL); others here
> knew him much better and were in on the ground floor of LEdit long before I
> showed up at the party in late 1997, so I don't presume to understand his vision
> better than anyone else.
>
> I'm also not flaming anybody, nor am I claiming special insight as to what would
> work "better" than the current scheme. However, if we're asking why people have
> drifted from the LDraw portion of the hobby, then it seems to me that part of
> the answer must address the rigidity that's taken hold in the past few years,
> and we must ask if it was worthwhile, even if we accept that it was necessary.
>
> My $0.02.
>
> Dave!
-Santeri
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Santeri Piippo wrote:
> In lugnet.cad, Dave Schuler wrote:
> > For whatever reason, I've never made the shift to MLCad or other platforms, and
> > I've been served very well James Jessiman's foundation programs. Lars Hassing's
> > L3Lab and Kevin Klague's LPub have been invaluable as well, but everything I do
> > that's Lego CAD-related (apocryphal or otherwise) starts in LEdit.
> LEdit's pretty much outdated these days. It doesn't support the LDConfig
> colours, nor can it edit MPD:s and the LSC is not taking it too seriously when
> making choices. (at least I'm not..)
That's 100% fair, and I wouldn't expect them to base any policy decisions on a
platform that hasn't changed in 13+ years. The number of people who still use
it as their primary interface can probably be counted on one hand.
The main reason that I stick with it is that I'm comfortable using it, and I can
do in it pretty much everything I need to do, LDraw-wise. I've tried MLCad, but
it just hasn't captured me.
> I agree here partially. I too think that some bits here are bit too formal...
> but I tend to think that !HISTORY lines are pretty much useful to keep track on
> what's happened and when..
I don't know. At the user end of it, I don't see how this information is of any
value at all 99% of the time, except maybe as trivia. And even when it *is*
useful, it has the potential to become bogged down.
I recall a time not so long ago when people campaigned passionately for the most
parsimonious part-designs, on the basis that it makes the processing faster.
Since that time, the basic, default format for even the most basic bricks in the
inventory has expanded hugely, in some cases with little or no visible
improvement to part-utility.
Dave!
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
--snip--
> I don't know. At the user end of it, I don't see how this information is of any
> value at all 99% of the time, except maybe as trivia. And even when it *is*
> useful, it has the potential to become bogged down.
>
> I recall a time not so long ago when people campaigned passionately for the most
> parsimonious part-designs, on the basis that it makes the processing faster.
> Since that time, the basic, default format for even the most basic bricks in the
> inventory has expanded hugely, in some cases with little or no visible
> improvement to part-utility.
>
> Dave!
Please excuse ne while I become really blunt ;)
That information isn't there for the end users. It's there for the people
volunteering their time to make the parts. As Philo said it's very easy to add
automatically with DATHeader and thus next to no effort for the parts editors
but it is a good source of credit for those that have donated their time.
Likewise the legal issues may seem superfluous but with the new license the
parts library is finally legally able to be used and distributed in a more
verstile way. That's a good thing.
The trick for the parts library is finding a balance between parts that are
perfect for the user (including being consistent) and parts that are easy to
develop. _Possibly_ there is too much focus on the former but it's got little to
do with the mostly non-issues you raise.
Tim
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Timothy Gould wrote:
> That information isn't there for the end users. It's there for the people
> volunteering their time to make the parts. As Philo said it's very easy to add
> automatically with DATHeader and thus next to no effort for the parts editors
> but it is a good source of credit for those that have donated their time.
>
> Likewise the legal issues may seem superfluous but with the new license the
> parts library is finally legally able to be used and distributed in a more
> verstile way. That's a good thing.
>
> The trick for the parts library is finding a balance between parts that are
> perfect for the user (including being consistent) and parts that are easy to
> develop. _Possibly_ there is too much focus on the former but it's got little to
> do with the mostly non-issues you raise.
Non-issues to you, perhaps. To an outsider, they are symptomatic of a big
exercise in narcissism.
Decades ago, when I was without a tv but hoping to see the "Spock" episode of
ST:TNG, a friend and I went to Penn State's Star Trek club. They had a meeting
starting one hour before the episode was to air, and we opted to attend the
meeting so that we wouldn't just seem like parasites showing up simply to mooch
their tv.
Well, that one-hour meeting was spent arguing about whether or not the
Enterprise-D on the group's letterhead should be facing to the left or to the
right. After two minutes it was comically preposterous. After forty-five
minutes it was unbearable.
I'm sure that the reasons for the letterhead argument were many and subtle and
well-justified. But to someone watching from the outside, it made the group a
geeky caricature, even to the geek who didn't have his own tv!
I'm not diminishing the efforts of the parts authors, nor am I writing this out
of thin air; I've personally authored well over 1,000 parts that will never be
included in the LDraw library. That is, I *know* how difficult the authoring
process can be.
I've spoken with at least three other people who find the hyper-legalistic
process equally off-putting, and I'm confident that we're not the only four who
think so. Part of the question in the OP was about why people have drifted
away, and I've given an answer.
You may dismiss it as a non-issue if you wish.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Dave Schuler wrote:
> In lugnet.cad, Timothy Gould wrote:
>
> > That information isn't there for the end users. It's there for the people
> > volunteering their time to make the parts. As Philo said it's very easy to add
> > automatically with DATHeader and thus next to no effort for the parts editors
> > but it is a good source of credit for those that have donated their time.
> >
> > Likewise the legal issues may seem superfluous but with the new license the
> > parts library is finally legally able to be used and distributed in a more
> > verstile way. That's a good thing.
> >
> > The trick for the parts library is finding a balance between parts that are
> > perfect for the user (including being consistent) and parts that are easy to
> > develop. _Possibly_ there is too much focus on the former but it's got little to
> > do with the mostly non-issues you raise.
>
> Non-issues to you, perhaps. To an outsider, they are symptomatic of a big
> exercise in narcissism.
Possibly so but I'm of the opinion that those that make and share the parts are
entitled to some narcissism. And I speak having done minimal part authoring in
quite some time (due to laziness) so it's not self-interest at work.
--snip--
Your analogy isn't really a fair one IMO as the ST club is not actually creating
anything for others to use. I see your point but I'm not sure it entirely
applies here.
> I'm not diminishing the efforts of the parts authors, nor am I writing this out
> of thin air; I've personally authored well over 1,000 parts that will never be
> included in the LDraw library. That is, I *know* how difficult the authoring
> process can be.
But how much of that difficulty stems from making the part and how much comes
from filling in a few lines in the header? I've authored a bunch of parts myself
(both easy and hard) and I've simply never had trouble (well OK I have but Chris
has fixed them on the Part Tracker).
> I've spoken with at least three other people who find the hyper-legalistic
> process equally off-putting, and I'm confident that we're not the only four who
> think so. Part of the question in the OP was about why people have drifted
> away, and I've given an answer.
>
> You may dismiss it as a non-issue if you wish.
I shall continue to do so I'm afraid until I understand why it's an issue. As I
said above I just don't understand why a few lines in a header make such a big
difference. And I'm honestly not being obtuse here either. I'm ready to change
my opinion if I understand and agree with what you're saying. I feel I must be
missing something.
Tim
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Timothy Gould wrote:
> In lugnet.cad, Dave Schuler wrote:
> > You may dismiss it as a non-issue if you wish.
>
> I shall continue to do so I'm afraid until I understand why it's an issue. As I
> said above I just don't understand why a few lines in a header make such a big
> difference. And I'm honestly not being obtuse here either. I'm ready to change
> my opinion if I understand and agree with what you're saying. I feel I must be
> missing something.
>
> Tim
It is an issue IMO. Probably a small one compared to other ones, but it's the
sum of real or subjective obstacles that makes me worried about recruiting new
LDraw authors.
What I believe is the biggest issue is nobody's fault: All the easy, "basic"
parts are already made, and the new parts LEGO makes are very hard to LDraw. One
of my first parts, maybe the very first one, was 31.dat, Classic Window 3x2. I
looked at the 2x2 I believe, manipulted it a little here and a little there and
noticed the changes it made. That was a challange in the just right level for me
as a newbie.
When my first LDraw parts were officialized, I think it was by JJ himself(?), it
was probably too fast and too easy. There were obvious flaws that was either
overlooked with or missed. But we only had original LDraw to review them in, and
they looked ok there, so...
Today it is the opposite way. Parts are held hostage in the Tracker for years
and I have been both annoyed and discouraged from the reasons that my and other
authors' parts are being held.
On top of everything, the growing part headers have a highly psychlogical
impact. No matter if there is a DatHeader utility to support me as an author. If
I as an "LDraw veteran" get the feeling that this is impossible, I can never
write a header that complies to all those rules - how much more would a newbie
be discouraged? No matter what the crew who has added the rules, one by one and
after discussions, think: it really is repellant. I can imagine a newbie wanting
to become a part author. He or she will not get to business at once with the
line types that makes something happen in the renderer, but will likely try to
understand the meaning of the header lines first.
One thing that strikes me is that all header lines are cheerfully ignored by the
LCad programs except the BFC Certify line. They are in a sense "useless" for the
output image. I mean that the picture would look exactly the same without all
the header lines. I'm *not* saying that we should ban all header lines to make
newbies feel better to join the part author's guild. It's just a thought worth
having in mind. Maybe worth mentioning early in a part authoring tutorial. A
part or model file would work just as well if the first line was a type 1 ~ 5.
It's not a really big issue. But it is an issue, on top of others.
/Tore
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Tore Eriksson wrote:
***snip***
I'd like to mention at this point that Tore Eriksson is personally responsible
for my first forays into apocryphal parts-authoring. I found his small handful
of Tyco-based half-height elements, and I thought "I can do that." I knew
nothing of the code, but I started by tweaking the placement of the stud.dat
primitives in a 2x4 half-height brick, and that was that.
After those humble beginnings, I was hooked. So you can blame Tore for the 1200
or so non-canonical parts that have followed.
Thanks, Tore!
Dave!
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Tore Eriksson wrote:
>
> What I believe is the biggest issue is nobody's fault: All the easy,
> "basic" parts are already made, and the new parts LEGO makes are very
> hard to LDraw.
I think you are completely right here! I have done some starts in part
authoring, but given up on 'the real thing' as there are no easy parts left
to do. Of course this makes it much harder for a budding part author.
The quality which is required is also a hurdle - who really cares aboth the
thickness of an invisible inner wall? Who really cares if two surfaces
overlap a bit, if it *looks* OK?
In my BlockCAD program I go the other way - only the outside of my parts
matter, I try to simplify them as much as possible, to make it easier/faster
for my program to draw them. This way my users can actually work with models
contaning tens of thousands of parts (and the models created are still
compatible to LDRAW, if needed).
--
Anders Isaksson
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Timothy Gould wrote:
> And I'm honestly not being obtuse here either. I'm ready to change
> my opinion if I understand and agree with what you're saying. I feel I must be
> missing something.
Well, I singled out the header-code not as the problem in itself but as
symptomatic of a shift that's taken place over a period of years. I don't know
how else to say it without sounding petty, and I'm absolutely not singling out
any one person in my criticism.
The Star Trek club demonstrated a farcical obsession with the *process* rather
than with the *purpose.* I admit that I'm not 100% clear what their exact
purpose was (I presume it had something to do with sharing Trek fan-news and the
like), but I'm sure that it wasn't simply to display a letterhead. Yet that's
what occupied the entirety of their quite heated meeting.
The reason I use this as an analogy is because it strikes me as rather similar
to something that LDraw went through not long ago, resulting in a years-long
drought of new part libraries. Whatever the reason, the end result was that
eager users had no access to new parts for a *very* extended period; the purpose
was bogged down by the process.
It didn't help that the only glimmers of life throughout this long delay were
occasional posts about the LSC and who was getting voted into what position.
Again, this isn't to diminish the work of these contributors; it's a comment on
where the priority seemed to be during this time. And when that time passed, I
found my interest in the "official" product all but quenched.
Additionally, the inclusion of official entries straight from LEGO has
compromised the organic, fan-based purity of LDraw. Why would anyone bother
spending weeks authoring a new Bionicle element when the good people @ LEGO can
crank one out on demand from their existing files?
Here IMO is the crux of Tore's question from his OP:
> Where have LDrawers moved? Away from LCad I'm afraid?
I've attempted to give a partial answer to this, based on my own personal
experience and discussions with other people who've formerly been much more
involved in the sharing of MOCs via LDraw, if not in the actual process of part
authoring.
I accept that you don't see my reasons as significant or central, and you're
welcome to reach different conclusions, of course. I can only tell you what I
know.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Dave Schuler wrote:
--snip--
> I accept that you don't see my reasons as significant or central, and you're
> welcome to reach different conclusions, of course. I can only tell you what I
> know.
I think I see a bit better what you were getting at (and what Tore is getting at
too which is the same issue I think). I kind of do agree with you both that
making new parts is too hard due in part to an overzealous set of requirements.
It's almost as though part authors are expected to match the famous 1 in a 1000
tolerance if genuine LEGO parts. The header is just a symptom of it.
I've actually argued quietly in the past that the requirements are too high. I
believe that so long as a part looks right in its visible surfaces and uses the
important primitives that affect rendering (for studs and curves etc.) and has
its centre in the right place it should be good for release. I feel that the
library _has_ gone beyond that 'sweet spot' and into the realm of overaccuracy.
Ultimately I'd love to see parts put into too categories: good for release
(where the orientation and origin is locked) and locked in perfect (where the
part should never be touched again). That way the parts updates could happen
more frequently while the part design perfectionism in the library could
continue without affecting the end users.
Tim
| | | | | | | | | | | | | | | | | | | | | | | |
> I agree here partially. I too think that some bits here are bit too formal...
> but I tend to think that !HISTORY lines are pretty much useful to keep track on
> what's happened and when.. but something that I can't possibly understand is
> that if a part author completely remakes a part and gets it to the tracker, the
> rewrite must be a !HISTORY line and the author cannot get the Author line!
> Really de-motivating...
Is it really...??? Anyway, the average LDraw user will never see the Author line
or the History ones!
I definitely don't subscribe to the all legalese line we see today (in LDraw or
in real life!). To me, it's just something that must be done. Fortunately there
are tools to manage this (Datheader). So it is and remains a hobby (and an
addictive one!)
Philo
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Philippe Hurbain wrote:
> > I agree here partially. I too think that some bits here are bit too formal...
> > but I tend to think that !HISTORY lines are pretty much useful to keep track on
> > what's happened and when.. but something that I can't possibly understand is
> > that if a part author completely remakes a part and gets it to the tracker, the
> > rewrite must be a !HISTORY line and the author cannot get the Author line!
> > Really de-motivating...
>
> Is it really...???
I more meant that it de-motivates me from remaking parts if I don't get the
proper credit for them! I'm a human being - I want credit for what I do. But
maybe "de-motivating" is the bad word for it. Maybe "annoying" is better there.
But I just can't see the point in it. If you make a part from scratch - be that
a new one or something that has been on the parts tracker before - it hasn't had
former history. So why can't the history then be wiped out? Even more, we
already wipe the history when remaking Non-CA parts.
> Anyway, the average LDraw user will never see the Author line or the History ones!
>
> I definitely don't subscribe to the all legalese line we see today (in LDraw or
> in real life!).
Ditto. I hate legal stuff. The world would be a better place without it.
> To me, it's just something that must be done. Fortunately there
> are tools to manage this (Datheader). So it is and remains a hobby (and an
> addictive one!)
Indeed. But the problem for me is that most parts I have around are either
Bionicle parts which are difficult to author or generic Technic parts that have
already been modeled. So the hobby is challenging for me.
>
> Philo
-Santeri
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Santeri Piippo wrote:
> In lugnet.cad, Philippe Hurbain wrote:
> > > I agree here partially. I too think that some bits here are bit too formal...
> > > but I tend to think that !HISTORY lines are pretty much useful to keep track on
> > > what's happened and when.. but something that I can't possibly understand is
> > > that if a part author completely remakes a part and gets it to the tracker, the
> > > rewrite must be a !HISTORY line and the author cannot get the Author line!
> > > Really de-motivating...
> >
> > Is it really...???
> I more meant that it de-motivates me from remaking parts if I don't get the
> proper credit for them! I'm a human being - I want credit for what I do. But
> maybe "de-motivating" is the bad word for it. Maybe "annoying" is better there.
>
> But I just can't see the point in it. If you make a part from scratch - be that
> a new one or something that has been on the parts tracker before - it hasn't had
> former history. So why can't the history then be wiped out? Even more, we
> already wipe the history when remaking Non-CA parts.
For the Non-CA parts it should be clear that for legal reasons there has to be
another author mentioned. That's why it is handled there in this way.
For normal parts it is much more difficult.
From what point on it is made from the scratch? - Only the author knows.-
Please imagine that a part where you have spend hours on and you are proud to be
mentioned at the author (because it has been really difficult to make) is
overwritten with the content of a file from another author and you are no more
mentioned! That I feel would be annoying or better "de-motivation" as you will
never know how long will your name be mentioned.
cu
mikeheide
> > Anyway, the average LDraw user will never see the Author line or the History ones!
> >
> > I definitely don't subscribe to the all legalese line we see today (in LDraw or
> > in real life!).
> Ditto. I hate legal stuff. The world would be a better place without it.
>
> > To me, it's just something that must be done. Fortunately there
> > are tools to manage this (Datheader). So it is and remains a hobby (and an
> > addictive one!)
> Indeed. But the problem for me is that most parts I have around are either
> Bionicle parts which are difficult to author or generic Technic parts that have
> already been modeled. So the hobby is challenging for me.
> >
> > Philo
>
> -Santeri
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Dave Schuler wrote:
> For whatever reason, I've never made the shift to MLCad or other platforms, and
> I've been served very well James Jessiman's foundation programs. Lars Hassing's
> L3Lab and Kevin Klague's LPub have been invaluable as well, but everything I do
> that's Lego CAD-related (apocryphal or otherwise) starts in LEdit.
>
> Anyone who knows me knows that my particular brand-loyalty makes me a bit of an
> outsider in this community, and that's fair. However, speaking as an outsider,
> I can say that one thing that has really soured me on LDraw in recent years is
> the seemingly obsessive lawyer-ization of it, to the point that it's become less
> of an exercise in Lego design and more a monument to hyper-legalism and
> over-compartmentalized classification.
Hi Dave,
Thanks for your thoughtful input. I might be one of the causes of the
bureaucracy you are referring to (in follow on posts). When I started to write
LDraw tools back in late 1999, I turned to lugnet's LDraw forum to ask for
guidance. I wanted to extend LDraw to support the markup concepts that we know
today as LPub and LSynth.
When I asked for recommendations on how to extend it, the only answer I got
was "Just make sure it doesn't break LEdit" from Steve Bliss. While succinct
and sufficient, it was lacking in any sort of guidance. I deduced that my
extensions should be in the form of meta commands. As I got more connected with
the community, I lobbied for some form of standards committee. My goal was not
to make there be lots more rules (I'm not a huge fan of lots of rules), but to
provide a good place to ask such questions. I think we're better off with the
LSC, even though this makes us a more formal group.
I also assisted in the formulation of the LDraw Steering Committee.
I can see how these formalizations can be a turn off for a grass roots effort
like LDraw, but I guess I see them as a sign of success of James' work. Maybe
if James were still around we would not have needed these things. I don't know,
maybe we didn't need them at all.
I do think that before LDD, LDraw was the only choice, so we did get more
newbies to LDraw. The LDraw tools are still superior to LDD in many ways. I
guess I don't know if I see that we have less people using LDraw than we have in
the past, but I may be wrong.
In the past decade, I think we've made significant progress on the "back end
tools" such as the fantastically realistic renderings made with POV-Ray, the
fast renderers such as LDGLite and LDView, upon which we have LPub to make
building instructions.
I know you're not into MLCad, and it is indeed so 1990's. I wish the front
end tools (model entry) were more modern, and some recent developments might be
heading in the right direction (Bricksmith, SR 3D Builder). Like you, I use the
tools I already know, so I've not tried them. I'd like an entry tool like LDD
(which I've hardly used).
I think that LDraw is no longer in its infancy, and maybe that is what you
miss.
I feel that LDraw is still vibrant and growing. In many ways, we're well
ahead of the tools LEGO uses internally, or at least that was true two years ago
when I gave a presentation on LPub at Brickworld.
Kevin
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Kevin L. Clague wrote:
> In lugnet.cad, Dave Schuler wrote:
> > For whatever reason, I've never made the shift to MLCad or other platforms, and
> > I've been served very well James Jessiman's foundation programs. Lars Hassing's
> > L3Lab and Kevin Klague's LPub have been invaluable as well, but everything I do
> > that's Lego CAD-related (apocryphal or otherwise) starts in LEdit.
>
> I know you're not into MLCad, and it is indeed so 1990's. I wish the front
> end tools (model entry) were more modern, and some recent developments might be
> heading in the right direction (Bricksmith, SR 3D Builder). Like you, I use the
> tools I already know, so I've not tried them. I'd like an entry tool like LDD
> (which I've hardly used).
There is also LeoCAD, which has some great features MLCad doesn't have. It
sufferes from not being able to use the official parts library (directly), but
it's database is regularly updated.
And as a bonus it's available for Linux too. I'm surprised someone hasn't tried
to build it for Mac, give Bricksmith a little friendly competition ;)
ROSCO
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Ross Crawford wrote:
>
> There is also LeoCAD, which has some great features MLCad doesn't have. It
> sufferes from not being able to use the official parts library (directly), but
> it's database is regularly updated.
>
> And as a bonus it's available for Linux too. I'm surprised someone hasn't tried
> to build it for Mac, give Bricksmith a little friendly competition ;)
LeoCAD directly imports LDRAW parts. There's no need to wait for an update of
its database. It is as simple as downloading from the parts tracker, and then
importing into LeoCAD itself.
Some folks don't like to manage parts at that level, but it's quite doable.
-- joshuaD
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Joshua Delahunty wrote:
> In lugnet.cad, Ross Crawford wrote:
> >
> > There is also LeoCAD, which has some great features MLCad doesn't have. It
> > sufferes from not being able to use the official parts library (directly), but
> > it's database is regularly updated.
> >
> > And as a bonus it's available for Linux too. I'm surprised someone hasn't tried
> > to build it for Mac, give Bricksmith a little friendly competition ;)
>
> LeoCAD directly imports LDRAW parts. There's no need to wait for an update of
> its database. It is as simple as downloading from the parts tracker, and then
> importing into LeoCAD itself.
Yes that is correct, but importing the files is not using them directly, as most
other LDraw programs do. And for folks that have multiple parts folders, that
can make a big difference.
ROSCO
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> In lugnet.cad, Joshua Delahunty wrote:
> > LeoCAD directly imports LDRAW parts. There's no need to wait for an update of
> > its database. It is as simple as downloading from the parts tracker, and then
> > importing into LeoCAD itself.
In lugnet.cad, Ross Crawford wrote:
> Yes that is correct, but importing the files is not using them directly, as most
> other LDraw programs do. And for folks that have multiple parts folders, that
> can make a big difference.
I wanted to make sure people weren't turned away from LeoCAD because they might
think they'd be dependent on third parties to provide a parts library, that's
just not true, so people SHOULD check it out. It's certainly my LCAD tool of
choice (Philo's too, and he's arguably our most prolific parts author at this
point).
This brings up another point that hasn't entirely been part of the discussion:
the concept of self-helped individuals versus end users. A lot of people early
on (by necessity) were quite willing to climb the mountain to get LDRAW set up.
They don't mind a little tinkering and manual labor to get things into place,
and to tweak and tinker along the way to keep things updated.
The project has since moved into a new phase where there are plenty of end users
of the products. They don't like or want (and shouldn't need) to worry about
the nuts and bolts, they just want to use cool software.
When you get to that point, you "lock in" a certain set of requirements, and
those requirements dictate rigor and attention, in order to provide consistency
and clarity.
Long gone are the days that an author can "play" with a part, changing the
origin or default posing on a whim. There are a host of issues that go along
with that. So a lot of the growth of "committees" and voting and the cost of
entry are due to those factors as well. The library has a host of annoying
errors (such as pairs of parts that have the wrong part numbers, but have to
stay that way for backward compatibility) that are really locked in, because of
that issue. In a way, the project is a bit of a victim of its own success.
It's because of all those issues that part authors and reviewers are much more
careful to "get it right" the first time, so we don't get stuck with designs or
situations that are lacking.
The whole "rewrite every header by hand" job that Chris had to do certainly
didn't help the situation, of course. It really HAD to happen, though.
-- joshuaD
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Joshua Delahunty wrote:
> This brings up another point that hasn't entirely been part of the discussion:
> the concept of self-helped individuals versus end users. A lot of people early
> on (by necessity) were quite willing to climb the mountain to get LDRAW set up.
> They don't mind a little tinkering and manual labor to get things into place,
> and to tweak and tinker along the way to keep things updated.
>
> The project has since moved into a new phase where there are plenty of end users
> of the products. They don't like or want (and shouldn't need) to worry about
> the nuts and bolts, they just want to use cool software.
>
> When you get to that point, you "lock in" a certain set of requirements, and
> those requirements dictate rigor and attention, in order to provide consistency
> and clarity.
>
> Long gone are the days that an author can "play" with a part, changing the
> origin or default posing on a whim. There are a host of issues that go along
> with that. So a lot of the growth of "committees" and voting and the cost of
> entry are due to those factors as well. The library has a host of annoying
> errors (such as pairs of parts that have the wrong part numbers, but have to
> stay that way for backward compatibility) that are really locked in, because of
> that issue. In a way, the project is a bit of a victim of its own success.
>
> It's because of all those issues that part authors and reviewers are much more
> careful to "get it right" the first time, so we don't get stuck with designs or
> situations that are lacking.
>
> The whole "rewrite every header by hand" job that Chris had to do certainly
> didn't help the situation, of course. It really HAD to happen, though.
>
> -- joshuaD
That's a really good explanation of why the 'rules and regulations' have grown
alongside the part library and software.
Tim
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Joshua Delahunty wrote:
> The library has a host of annoying
> errors (such as pairs of parts that have the wrong part numbers, but have to
> stay that way for backward compatibility) that are really locked in, because of
> that issue. In a way, the project is a bit of a victim of its own success.
How widespread a problem is that, though? I know that some parts do indeed have
two numbers, but this would seem a glitch that should have been resolved eight
or more years ago, no? I mean, when you can turn a brick over and say "Yep,
it's a 3001," I don't see how it can continue to be an issue.
Granted, the embossed number may not always be clear, and for all I know LEGO
may change the numbers from time to time (or not--I have no idea). But even so
this would seem like a minor annoyance rather than an issue to dictate policy.
For that matter, why is backwards-compatibility such a big deal? In this thread
it's been stated that LEdit doesn't support LDConfig colors, so why should a
"wrong" part number be maintained, rather than replacing it with a simple
~~MOVED TO statement or deleting it from the library altogether?
Dave!
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> In lugnet.cad, Joshua Delahunty wrote:
>
> > The library has a host of annoying
> > errors (such as pairs of parts that have the wrong part numbers, but have to
> > stay that way for backward compatibility) that are really locked in, because of
> > that issue. In a way, the project is a bit of a victim of its own success.
First, let me make it clear that I am not a supporter of this policy (the fact
that I have to write "policy" makes me feel a tad ill, to be honest). I was
reporting, not defending.
You quoted the most relevant portion of what I wrote. "The project is [...] a
victim of its own success." If we could start NOW with a new official release,
I'd be much happier, personally.
In lugnet.cad, Dave Schuler wrote:
> How widespread a problem is that, though? I know that some parts do indeed have
> two numbers, but this would seem a glitch that should have been resolved eight
> or more years ago, no? I mean, when you can turn a brick over and say "Yep,
> it's a 3001," I don't see how it can continue to be an issue.
>
> Granted, the embossed number may not always be clear, and for all I know LEGO
> may change the numbers from time to time (or not--I have no idea). But even so
> this would seem like a minor annoyance rather than an issue to dictate policy.
I think the example I have in mind is a little bit different from what you're
talking about.
Start here:
http://www.peeron.com/inv/parts/2790
then go here:
http://www.peeron.com/inv/parts/2791
The first I linked? That's LEGO Design 2791. The second? LEGO design 2790.
2792 is correct: http://www.peeron.com/inv/parts/2792
I'm PRETTY sure this is an issue that dates back to James' time. I won't go
into specifics, but obviously the right numbers were provided, but they were
miscommunicated somewhere along the way, and the first two had their numbers
reversed. [to be honest, James was pretty willing to guess at certain logical
numberings, and many turned out to be "off" in retrospect. Still, we all did
the best we could with the information at hand...]
> For that matter, why is backwards-compatibility such a big deal? In this thread
> it's been stated that LEdit doesn't support LDConfig colors, so why should a
> "wrong" part number be maintained, rather than replacing it with a simple
> ~~MOVED TO statement or deleting it from the library altogether?
By the time I spotted it and reported it (last year or so? Maybe 2 years
back?), there were LOTS and LOTS of people who had used these parts. So they
were now "locked" in to LDRAW with those numbers.
As a fix, we now have shortcuts 2790a and 2791a, which have the right numbering,
and are ~moved to files that (literally) cross reference the originals.
Not the way I would have run it personally, but then I wouldn't have a very good
answer for the (rather sprawling) user-base who would now be pretty unhappy
about their now "broken" files (I'm speaking generally, not necessarily about
these two parts specifically -- see my postscript below).
-- joshuaD
P.S. These two parts (not available from TLG for years now) are admittedly not
at the nexus of the LEGO parts database; they were simply the first concrete
example of this that jumped to mind; though I did just catch a day ago two
TECHNIC panels that had been reverse-numbered on the parts tracker. Thanks to
the policy, these were caught before release; despite having several "yes" votes
because they are otherwise stellar parts. It was chance, though, I just happened
to need images for those parts at this particular spot in time. :-/
| | | | | | | | | | | | | | | | | | |
Kevin L. Clague wrote:
>
> I'd like an entry tool like LDD (which I've hardly used).
Actually, there has been an 'entry tool' around since 1998 - BlockCAD
(www.blockcad.net). While it's using part definitions of its own, and has a
lot of limitations (studs up only, fixed rotation of parts, no Technic) you
can
save models in the LDRAW format. BC has also had the availability of
one-click-rendering in POVRay almost since its beginning.
Thanks to its ease of use (parts snap on to each other), BC have been, and
is still, used in schools (and pre-schools) all around the world, as a first
introduction to CAD, for 3D visualization, maths, plain entertainment and so
on.
The natural step after BC is MLCad - you can open all your old BC models and
continnue in the more advanced tools.
--
Anders Isaksson
| | | | | | |
