 | | | | | | |
| |
|
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.
| | | | | | |
