 | | | | | | |
| |
|
dear LSC members,
LEGO Digital Designer http://www.lego.com/eng/create/digitaldesigner/ has only
one feature I really miss in the LDraw system: the snap-in behavior. guys,
I'd like to ask you - no I beg you down on my knees - to define a working
standard for a connection database. there is currently a proposal at ldraw.org:
http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=135&mode=thread&order=0&thold=0
but it is all theorical. to launch this thing we would just nead 2,3 working
examples (bricks, plates) of these .cdl files
http://www.ldraw.org/OLD/reference/specs/lcd/#Appendix%20B
with the proper coordinations and a prog (LDDP plug-in or stand-alone) where we
could test new definitions. a paralell PT could collect those .cdl files.
I can also think of a restriction for submitting new parts. authors would have
to submit a .cdl file first, before they are alowed to submit a .dat file. this
would boost the build-up of the library. could you make this happen?
w.
humble part-author with no programming
skills but seeking to submit his new
parts along with a proper .cdl file
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> dear LSC members,
>
> LEGO Digital Designer http://www.lego.com/eng/create/digitaldesigner/ has only
> one feature I really miss in the LDraw system: the snap-in behavior. guys,
> I'd like to ask you - no I beg you down on my knees - to define a working
> standard for a connection database. there is currently a proposal at ldraw.org:
>
> http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=135&mode=thread&order=0&thold=0
>
> but it is all theorical. to launch this thing we would just nead 2,3 working
> examples (bricks, plates) of these .cdl files
>
> http://www.ldraw.org/OLD/reference/specs/lcd/#Appendix%20B
>
> with the proper coordinations and a prog (LDDP plug-in or stand-alone) where we
> could test new definitions. a paralell PT could collect those .cdl files.
> I can also think of a restriction for submitting new parts. authors would have
> to submit a .cdl file first, before they are alowed to submit a .dat file. this
> would boost the build-up of the library. could you make this happen?
I like the idea of connections. I think it's really neat and would like to see
it realised. I support asking LSC to look into this further.
But I fear that requiring authors to submit a .cdl file might be increasing the
barriers to entry for new parts authors, which are already higher than we might
like, for valid reasons, so I'd be very careful about having that requirement in
place. At least initially. Perhaps someday down the road, maybe.
++Lar
| | | | | | | | | | | | | | | | | | | | |
I'm not sure where this standard definition is at these days, or whether it
could be used to automate what I'm doing by a clever MetaWiki robot coder, but I
(and others) started capturing some connection information in BrickWiki (
http://brickwiki.zapto.org/ )
You can see what we've created so far here:
http://brickwiki.zapto.org/index.php/Category:Connnection_Types and the articles
in that category...
Do people think this is valuable? Would people like to take a crack at adding
more types? Or rendering the needed images for the types there already? or
refining the ConnectionTypeBox?
Wikis are editable by anyone... if enough people capture what they know on
BrickWiki, this one will be really cool.
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On 7/17/05, Larry Pieniazek at@at dot.dot
<larmiltontrainworkscom@qs483.pair.com> wrote:
> I'm not sure where this standard definition is at these days, or whether it
> could be used to automate what I'm doing by a clever MetaWiki robot coder, but
> I
> (and others) started capturing some connection information in BrickWiki (
> http://brickwiki.zapto.org/ )
>
> You can see what we've created so far here:
>
> http://brickwiki.zapto.org/index.php/Category:Connnection_Types and the
> articles
> in that category...
>
> Do people think this is valuable? Would people like to take a crack at adding
> more types? Or rendering the needed images for the types there already? or
> refining the ConnectionTypeBox?
>
> Wikis are editable by anyone... if enough people capture what they know on
> BrickWiki, this one will be really cool.
While a connection database could be helpful, I just cant help
thinking that a relationship/constrain system like solidworks and
Pro/Engineer use could acheive a lot more.
It could certainly be a start, then simplified - so the CAD
applications (MLCad etc), then try (with confirmation) to make
assumptions that you want to place a peice on that one - with the
studs attached as so. It would be nice to tell it to center an axle in
a hole and so on.
This could get interesting though - as there are no real curves and no
parametric definitions, and therefore no center points defined - so
creating a "concentric" or "tangent" constraint could be difficult.
This may be contraversial (very) but an extension to the LDraw
standard could allow more advanced clients to work with parametric
definitions, and then render them into simple meshes for use in
others.
Just my two pence worth, I used to be a software engineer with a large
CAD corp - so I have a lot of ideas on this stuff.
Danny
--
http://orionrobots.co.uk - Build Robots
Online Castle Building RPG -
http://www.darkthrone.com/recruit.dt?uid=V30311I30328J30379X30379E30260X30277
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, danny staple <orionrobots@gmail.com> wrote:
>
> On 7/17/05, Larry Pieniazek at@at dot.dot
> <larmiltontrainworkscom@qs483.pair.com> wrote:
> > I'm not sure where this standard definition is at these days, or whether it
> > could be used to automate what I'm doing by a clever MetaWiki robot coder, but
> > I
> > (and others) started capturing some connection information in BrickWiki (
> > http://brickwiki.zapto.org/ )
> >
> > You can see what we've created so far here:
> >
> > http://brickwiki.zapto.org/index.php/Category:Connnection_Types and the
> > articles
> > in that category...
> >
> > Do people think this is valuable? Would people like to take a crack at adding
> > more types? Or rendering the needed images for the types there already? or
> > refining the ConnectionTypeBox?
Note that Rosco already did take a crack at a few, including generating some
images for them, and in doing so, found a problem in one I created, and caused
me to decide to add fields to the connectionTypeBox, which is goodness. Thanks!
> > Wikis are editable by anyone... if enough people capture what they know on
> > BrickWiki, this one will be really cool.
I saw a couple other people adding comments (corrections, expansions, links to
good external articles, etc) to the talk pages associated with the entries,
While that's awesome in its own right, I'd like to encourage people to be
bold... Edit that info right into the main article if you're sure it adds
value. (after peeking at the article to grok how the tagging and layout works)
Wikis can be edited by anyone. (Just please consider setting up an ID first so
we can tell who did it and so that communication back to you can happen)
> While a connection database could be helpful, I just cant help
> thinking that a relationship/constrain system like solidworks and
> Pro/Engineer use could acheive a lot more.
>
> It could certainly be a start, then simplified - so the CAD
> applications (MLCad etc), then try (with confirmation) to make
> assumptions that you want to place a peice on that one - with the
> studs attached as so. It would be nice to tell it to center an axle in
> a hole and so on.
>
> This could get interesting though - as there are no real curves and no
> parametric definitions, and therefore no center points defined - so
> creating a "concentric" or "tangent" constraint could be difficult.
> This may be contraversial (very) but an extension to the LDraw
> standard could allow more advanced clients to work with parametric
> definitions, and then render them into simple meshes for use in
> others.
>
> Just my two pence worth, I used to be a software engineer with a large
> CAD corp - so I have a lot of ideas on this stuff.
I agree with all that and certainly would love to see it come to pass.
However, my thinking on the stuff being put in BrickWiki though, is more
"encyclopedic", that is, it's an explanation of what's possible rather than a
constraint system. New builders often ask "how did you do that, how did you get
those things to connect that way" and perhaps these entries would be a resource
on how to do things. More techniques in the toolbox means better builders,
faster. And that means builders who enjoy themselves more, I think.
If LSC actually does get a lot of data, I'd be after getting someone to try to
write a bot to inhale it and create the connection box info.
(there could be a parallel of sorts in setting up information on how to do SNOT,
what sorts of things turn what angles, and information on how to do offsets,
what sorts of parts arrangements give you a 1/10 brick horizontal offset, or a
half plate vertical offset, etc...)
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> dear LSC members,
>
> LEGO Digital Designer http://www.lego.com/eng/create/digitaldesigner/ has only
> one feature I really miss in the LDraw system: the snap-in behavior. guys,
> I'd like to ask you - no I beg you down on my knees - to define a working
> standard for a connection database. there is currently a proposal at ldraw.org:
I would love to see a connection database for the LDraw system With that we
might be able to make a simulator. This could be handy for test driving ideas
as well as good for animations.
Kevin
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> dear LSC members,
>
> LEGO Digital Designer http://www.lego.com/eng/create/digitaldesigner/ has only
> one feature I really miss in the LDraw system: the snap-in behavior. guys,
> I'd like to ask you - no I beg you down on my knees - to define a working
> standard for a connection database. there is currently a proposal at ldraw.org:
>
> http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=135&mode=thread&order=0&thold=0
>
> but it is all theorical. to launch this thing we would just nead 2,3 working
> examples (bricks, plates) of these .cdl files
>
> http://www.ldraw.org/OLD/reference/specs/lcd/#Appendix%20B
>
> with the proper coordinations and a prog (LDDP plug-in or stand-alone) where we
> could test new definitions. a paralell PT could collect those .cdl files.
> I can also think of a restriction for submitting new parts. authors would have
> to submit a .cdl file first, before they are alowed to submit a .dat file. this
> would boost the build-up of the library. could you make this happen?
>
> w.
> humble part-author with no programming
> skills but seeking to submit his new
> parts along with a proper .cdl file
Hi Willy,
I think "working" needs a tool.
1. there is a tool
2. there is a developping database
There is no chicken-egg problem: the tool always precedes the database.
Would you model parts without MLCad, LeoCad or LDraw?
I doubt anybody would.
Then people would model POV parts because POV is a "working" tool.
A Wiki is always a great idea and helps to cumulate community knowledge.
But a "standard" always comes from a tool, never from a formal documentation.
Formal documentation comes only after a tool is established.
Sadly enough, building such a tool will take very long time because such tools
are generally built by a single person. As far as i know every LDraw compatible
tool is single-authored, while the LDraw database is multitude-authored. And i
bet it will remain so in the future. LCD-extended parts would considerably slow
down LDraw library progression (especially as no tool would exist to check the
specifications) and would help nothing. This additionnal workload would then be
wasted, because the first man who arrives with a working tool will actually
define the standard because only him knows what works and what is merely
christmas-wishes.
In my opinion, modelling and reviewing parts is currently the best way to
contribute. That's what you do and we all thank you for that. The day the savior
will come then you can do even better.
- damien
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Damien Guichard wrote:
> There is no chicken-egg problem: the tool always precedes the database.
> Would you model parts without MLCad, LeoCad or LDraw?
> I doubt anybody would.
> Then people would model POV parts because POV is a "working" tool.
nod, yes.
> Sadly enough, building such a tool will take very long time because such
> tools are generally built by a single person. As far as i know every LDraw
> compatible tool is single-authored, while the LDraw database is
> multitude-authored.
Add to this the fact that to get a working connection-enabled tool, you need
start with (or at least develop along the way) a working GUI-based editing tool.
That really narrows the field of potential tool-developers/standard-makers,
because any such PTD/SM either (a) has to write their own tool or (b) has to use
someone else's (open source) tool.
Steve
| | | | | | | | | | | | | | | | | | | | | |
| |
|
--SNIP--
> Add to this the fact that to get a working connection-enabled tool, you need
> start with (or at least develop along the way) a working GUI-based editing tool.
> That really narrows the field of potential tool-developers/standard-makers,
> because any such PTD/SM either (a) has to write their own tool or (b) has to use
> someone else's (open source) tool.
>
> Steve
I'm going to go a bit more general here so this is an answer to both parent and
grandparent and probably other relatives too.
--
Why does one person need to do the whole thing? We have a wealth of skills and
experience in the Lego CAD community as is evidenced by the number of people who
have written tools, and the number of people who have written parts etc.
This means, we could have some people write specs, some people code, some people
write connections etc. At a first iteration we could release connections lists
for the most basic pieces quickly but leave them to be approved later. Likewise
with code. The specs. of course would have to be thought out a little more
carefully, but if we make them adaptable (by using xml for example) this isn't
too much of a worry.
Personally I would be more than happy to contribute to a project designing a
fully open sourced editing tool with connections. While its nice to have a baby
to call your own, it does take a lot of time to finish writing one. It would be
so much easier just to finish a certain component of a larger project.
As such, I am going to announce myself as more than happy to work on any project
to develop an "open source, connections enabled, brick based, CAD editing tool".
I'll even post a mini-CV if desired so that if anyone else would like to
contribute they know what I can (probably) do.
I hope someone else is interested, either in tool, spec. or database design.
Yours (hopefully),
Tim
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Timothy Gould wrote:
> --SNIP--
>
> > Add to this the fact that to get a working connection-enabled tool, you need
> > start with (or at least develop along the way) a working GUI-based editing tool.
> > That really narrows the field of potential tool-developers/standard-makers,
> > because any such PTD/SM either (a) has to write their own tool or (b) has to use
> > someone else's (open source) tool.
> >
> > Steve
>
> I'm going to go a bit more general here so this is an answer to both parent and
> grandparent and probably other relatives too.
> --
>
> Why does one person need to do the whole thing? We have a wealth of skills and
> experience in the Lego CAD community as is evidenced by the number of people who
> have written tools, and the number of people who have written parts etc.
>
> This means, we could have some people write specs, some people code, some people
> write connections etc. At a first iteration we could release connections lists
> for the most basic pieces quickly but leave them to be approved later. Likewise
> with code. The specs. of course would have to be thought out a little more
> carefully, but if we make them adaptable (by using xml for example) this isn't
> too much of a worry.
>
> Personally I would be more than happy to contribute to a project designing a
> fully open sourced editing tool with connections. While its nice to have a baby
> to call your own, it does take a lot of time to finish writing one. It would be
> so much easier just to finish a certain component of a larger project.
>
> As such, I am going to announce myself as more than happy to work on any project
> to develop an "open source, connections enabled, brick based, CAD editing tool".
> I'll even post a mini-CV if desired so that if anyone else would like to
> contribute they know what I can (probably) do.
>
> I hope someone else is interested, either in tool, spec. or database design.
>
> Yours (hopefully),
>
> Tim
Hi Tim,
May be you should get a try at LeoCAM, a LeoCad derivative incorporating
LCD-like features:
http://news.lugnet.com/cad/?n=10110
Sincerely yours,
- damien
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Damien Guichard wrote:
| |
In lugnet.cad, Willy Tschager wrote:
|
SNIP-SNAP
| |
Sadly enough, building such a tool will take very long time because such tools
are generally built by a single person. As far as i know every LDraw
compatible tool is single-authored, while the LDraw database is
multitude-authored. And i bet it will remain so in the future.
|
hi damien,
I wrote that request more than a year ago! meanwhile I’ve made up my mind. I
agree that this would be very time consuming and I got convinced that we will
probably never see such a feature in any of the editor progs...
this is also why my priorities have shifted: now I’ll looking badly for a
code-god who is willing to put in shape a .ldr .dat .mpd browser ;-) you know,
kind of these ACDSee viewer with a folder tree on one side and tiny renderings
of the ldraw files on the other.
also a picaview type of thing, showing you a small rendering in the contextual
menu would do the job for the first:
any idea who has the right skills (and some spare time left ;-)?
w.
| | | | | | |
