|
|
| |
In lugnet.cad.dev.lcd, Thomas Dickerson wrote:
> Greetings everyone,
> I am a newbie to this mailing list, but I have been using LDraw-oriented
> software for close to a decade now.
>
> I am currently developing (and have been, in my spare time for several years) a
> sandbox-style building game called FreeBuild oriented around the construction of
> (and combat with) Lego vehicles, spaceships, mechs, etc. Most of my time in the
> last year and a half has been dominated by ensuring my game engine will have the
> technical infrastructure to handle this task, and I am now ready to begin
> implementing the building portion of this game, which I am basing around the
> LDraw parts library. I am working with a derivative of the LDLITE lexer/parser
> (with permission from Paul Gyugyi, the original author), and am in the process
> of modifying it to suit the needs of my application. Part of this process
> modifying it to support the Colour Definition Language Extension instead of the
> proprietary-to-LDLITE color metacommands currently present in the parser.
>
> The documentation for both version 1.0.0 of the core LDraw file format, and for
> the Colour Definition language extension mention several language features which
> they do not fully document. The Colour Definition language extension lists
> "DITHER" as a valid keyword tag to be used as part of a 0 !COLOUR line, but
> fails to document the arguments which can be supplied to it, and how they should
> be interpreted.
>
> The file format document itself mentions both "Direct Colors" and what appears
> to be a competing specification for blended/dithered colors, but does not
> specify how either of these would appear within a part or model.
>
> Any information that could be provided on these language features, or the
> prevalence of direct colors within models "in the wild" would be extremely
> helpful to my implementation and optimization for using LDraw files within my
> game engine.
>
> Many Thanks,
> Thomas Dickerson
Hello,
First of all, I think you are in the wrong news group. LCD is about connections
not colours. You probably better of in the main lugnet.cad.dev group
Second you are right about the DITHER keyword, personally i think it is a typo
and shouldn't be mentioned at all in the spec.
Dithering is the way old software worked using color code 256 upto 511 these are
leftovers from cga and vga times.
The !COLOUR meta doesn't need dither information cause it's a fullcolour (24bit
rgb, 8 bit alpha) spec. And imho it's upto the software interpreting the meta
how to display those colors, hence the 'hints' like metal, rubber etc.
Roland
|
|
| |
Greetings everyone,
I am a newbie to this mailing list, but I have been using LDraw-oriented
software for close to a decade now.
I am currently developing (and have been, in my spare time for several years) a
sandbox-style building game called FreeBuild oriented around the construction of
(and combat with) Lego vehicles, spaceships, mechs, etc. Most of my time in the
last year and a half has been dominated by ensuring my game engine will have the
technical infrastructure to handle this task, and I am now ready to begin
implementing the building portion of this game, which I am basing around the
LDraw parts library. I am working with a derivative of the LDLITE lexer/parser
(with permission from Paul Gyugyi, the original author), and am in the process
of modifying it to suit the needs of my application. Part of this process
modifying it to support the Colour Definition Language Extension instead of the
proprietary-to-LDLITE color metacommands currently present in the parser.
The documentation for both version 1.0.0 of the core LDraw file format, and for
the Colour Definition language extension mention several language features which
they do not fully document. The Colour Definition language extension lists
"DITHER" as a valid keyword tag to be used as part of a 0 !COLOUR line, but
fails to document the arguments which can be supplied to it, and how they should
be interpreted.
The file format document itself mentions both "Direct Colors" and what appears
to be a competing specification for blended/dithered colors, but does not
specify how either of these would appear within a part or model.
Any information that could be provided on these language features, or the
prevalence of direct colors within models "in the wild" would be extremely
helpful to my implementation and optimization for using LDraw files within my
game engine.
Many Thanks,
Thomas Dickerson
|
|
| |
Hi gang,
playing around with colors I was floored by the fact that we do not have a LDraw
color number or RGBs for quite a lot of LEGO colors. In addition our RGBs
sometimes differ a lot from the official colors:
http://www.peeron.com/inv/colors
http://www.peeron.com/cgi-bin/invcgis/colorguide.cgi
I remember the time when we were graving for those figures and now that we have
them I simply ignore them. Can anyone put some light on this? LSC?
Thx, w.
|
|
| |
Daniel Bennett schrieb:
> Hi
> I’m now working on GLIDE and clicking again. I have moved house and job which
> is why I have not done any work on GLIDE over the last 6 months or so. Version
> 0.74 is now available for download. http://www.mr-bucket.co.uk/GLIDE/index.html
> You can now set the background colour of an edit window. You can also add the
> current bricks colour to the pallet. There are a couple of bug fixes as well.
> Its worth looking at the key list in the help file.
Are there any improvements from that time?
It would be interesting.
cu
mikeheide
|
|
| |
I proxy this on behalf of Sergio Reano, who for some technical reasons is not
able to post to LUGNET. Please post here your comments but cc: also to Sergio
via mail.
Hi everybody,
my name is Sergio Reano and I'm a programmer and Lego fun from Italy.
In the last few years I have had little time to play with real bricks and
decided to mix passion and informatics to create a new Lego CAD software to
enjoy Lego at least while I was in front of the screen.
The program I came up with, called SR 3D Builder, is IMHO very innovative
compared to MLCad or Lego Digital Designer 'cos it is able to recognize
automatically connections between LDraw parts and, based on that, to manage
hinges, rotation axels, gears. Additional functionality is planed for the
future.
To allow connection detection, I have associated the most common connections
like studs, axles, pins with the subpart representing an existing connection. In
short: every time the program finds a STUD.dat subpart it adds a connection of
the STUD type with the same coordinates. The connections it manages are almost
the same you can find in http://www.ldraw.org/Article135.html, but minifigs and
most of the hinges are still not implemented.
Problem is; it's really hard to create a connection when there is no subpart I
can associate with. The only way I found was to patch every single .dat part by
hand, adding lines which describe this kind of connection (especially hinges).
The program plus the patched parts definitions can be freely downloaded from
http://staff.polito.it/sergio.reano (a link has also been added to the download
section at LDraw.org). Please have a look at it and let me know what you think
about.
As you might already guess there are a lot of parts to patch, and I'm feeling
kind of lost with the huge library out there. What I'm looking for are helping
hands to patch the parts (the software you'll need will be provided).
Furthermore, I would like to establish contact with someone of the LDraw
organization in order to work out a standard for the connections.
I have contacted Willy Tschager and he has proposed a standard based on meta
commands:
0 !NEW CONNECTION conn_type, xpos,ypos,zpos, xorient, yorient, zorient
where
- conn_type identify connection type (stud, hinge, ...)
- x,y,z pos identify connection position
- x,y,z orient identify connection orientation
which would be ok for me, even though I currently use a different code (you can
find the technical specification on my site).
I would be really happy hearing form you (especially form those willing to patch
;-) You can contact me at: Sergio[dot]reano(at)polito{dot}it
Thank you,
Sergio
|
|
| |
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.
|
|
| |
--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, 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
|
|
| |
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, 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...)
|
|
| |
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
|
|
| |
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.
|
|
| |
Hi
I’m now working on GLIDE and clicking again. I have moved house and job which
is why I have not done any work on GLIDE over the last 6 months or so. Version
0.74 is now available for download. http://www.mr-bucket.co.uk/GLIDE/index.html
You can now set the background colour of an edit window. You can also add the
current bricks colour to the pallet. There are a couple of bug fixes as well.
Its worth looking at the key list in the help file.
|
|
| |
I should point out that priority and override are features of GLIDE and are not
explicitly specified in the format.
|
|
| |
In lugnet.cad, Jason S. Mantor wrote:
> I guess I'm thinking about this differently. It's not that the
> individual studs on the brick don't allow other mating angles. (IE you
> can place a 1 x 6 technic plate with rounded ends on any single stud at
> some funcky angles) It's the combination of the contraints imposed by at
> least 3 studs in a non-linear arangement that results in the 90 degree
> "snaps" in that plane. Just like 2 studs limits one to 180 degree snaps.
> It's even worse than that. It's the number of studs that are actually
> being used, not count of stud primitive on the element, that determines
> how things behave. Try putting some 1x1 round plates (dots) in between
> some bricks and you'll see what I mean. With just 1 dot you can orient
> the 2xN bricks at any angle. We need to allow for things like that so
> any stud primitive, where ever it is used, should always allow aribrary
> angles...
I have tried to accommodate these sorts of behaviours in two ways:
Priority and override.
If two parts have different behaviours like a "dot" and a "Brick" the one that
is moved to form the connection is the one that takes priority. If you move a
dot connected to a plate with the dot as the primary selection (Pink highlights
in glide) then the connection angles are taken from the dot. Which is freely
rotating. Thus allowing lots of angles between the brick and plate.
Override is much simpler. The maximum and minimum rotations are ignored, as are
the locking angles. The click simply rotates freely about its axis. This is to
allow for more creative use of brick arrangements.
I believe clicking should be an aid to creating LDraw models with out being
restrictive.
so
> We need to allow for things like that so
> any stud primitive, where ever it is used, should always allow arbitrary
> angles...
Hopefully this should be possible.
The real test is going to be what people think of it once the first version of
GLIDE with clicking is released.
--Dan.
|
|
| |
In lugnet.cad, Tim Courtney wrote:
> A short news article with a
> cool introduction, the appropriate links, and maybe a screenshot or two would be
> great.
Not just yet please... I’d like to get clicking working first before GLIDE gets
announced to the world at large. Unfortunately experience tells me that my time
estimates on programming are always a bit optimistic. I "think" I will be able
to get it done within a month. I'll let you know.
--Dan.
|
|
| |
In lugnet.cad, Dan Boger wrote:
> On Tue, Jun 22, 2004 at 01:40:04PM +0000, Dan wrote:
> > To see the standard so far take a look at:
> >
> > http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
>
> Should the format perhaps be changed so that LCD info could be included
> inline in a valid DAT file? Perhaps make all the lines start with a "0
> LCD" before anything else? Then, when reading a DAT file, a program can
> recognize and parse LCD info, in addition to looking for the .lcd file.
>
> Does that make sense? Do you think it's worth the effort?
>
> I think connection data is really cool, and we should try to make it
> part of the standard library.
Long-term, making connection data a part of the library would be awesome.
Short-term, getting a working implementation should be the focus.
Dan (Bennett) - would you like some publicity for GLIDE and click authors on
LDraw.org? I can't spare the moments to write it up (just caught this thread on
the way to bed 2.5hrs late), but if you or someone else can, and pass the
article to Orion or myself, we'll certainly post it. A short news article with a
cool introduction, the appropriate links, and maybe a screenshot or two would be
great. That way your project can gain exposure from people who visit LDraw.org
for news and reference.
I'm excited the LCD proposal is being implemented! Great work, I can't wait to
try this out with the next GLIDE release.
Email me if you have any questions.
-Tim
|
|
| |
In lugnet.cad, Jason S. Mantor wrote:
> I guess I'm thinking about this differently. It's not that the
> individual studs on the brick don't allow other mating angles. (IE you
> can place a 1 x 6 technic plate with rounded ends on any single stud at
> some funcky angles) It's the combination of the contraints imposed by at
> least 3 studs in a non-linear arangement that results in the 90 degree
> "snaps" in that plane. Just like 2 studs limits one to 180 degree snaps.
> It's even worse than that. It's the number of studs that are actually
> being used, not count of stud primitive on the element, that determines
> how things behave. Try putting some 1x1 round plates (dots) in between
> some bricks and you'll see what I mean. With just 1 dot you can orient
> the 2xN bricks at any angle. We need to allow for things like that so
> any stud primitive, where ever it is used, should always allow aribrary
> angles...
Note also that a 1x4 brick can be attached to a 2x4 brick anywhere on about
70-80 degree angle if only attached by the end stud - its only the other studs
hitting the sides that restrict it.
ROSCO
|
|
| |
I guess I'm thinking about this differently. It's not that the
individual studs on the brick don't allow other mating angles. (IE you
can place a 1 x 6 technic plate with rounded ends on any single stud at
some funcky angles) It's the combination of the contraints imposed by at
least 3 studs in a non-linear arangement that results in the 90 degree
"snaps" in that plane. Just like 2 studs limits one to 180 degree snaps.
It's even worse than that. It's the number of studs that are actually
being used, not count of stud primitive on the element, that determines
how things behave. Try putting some 1x1 round plates (dots) in between
some bricks and you'll see what I mean. With just 1 dot you can orient
the 2xN bricks at any angle. We need to allow for things like that so
any stud primitive, where ever it is used, should always allow aribrary
angles...
Dan wrote:
> I do indeed think it would be undesirable. As we all know Stud.dat gets used
> every ware. There are a fair few instances were the clicking behaviours of two
> bricks would be different even though they are both referencing the same
> stud.dat file for geometry.
>
> For example parts 3822 and 3622. A door and a brick respectively. The studs on
> the brick snap every 90 degrees but on the door you often want it open to say
> 45degrees. So there are two different behaviours for stud.dat in this case. If
> you inherited clicking information from sub parts of the geometry of a brick,
> you would need to keep track of all the different ways that sub part can be
> used. This would make things much more complicated.
|
|
| |
In lugnet.cad, Jason S. Mantor wrote:
> it would be slick to have the LCD info in the dat file, but
> it might complicate issues being dicussed by the Ldraw committee : (
> It seems that pov style includes aren't allowd in official files either
> so maybe keeping it seperate for a while will be easier...
I really like the way the .dat format reuses geometry e.g. stud.dat. I think the
clicking format should be able to do the same thing. I imagine that would be
quite a bit more difficult to reuse if the clicking info was in the dat files.
> Actually, I was thinking of writing a quick vb app that parsed dat files
> and automatically genrates LCD info for parts that have stud and tube
> primitives. I bet that'd save a lot of time.
That’s a cracking idea. (In my part of the world cracking means good by the
way.) I imagine that it would still need some human input, as detecting ware
stud inlets are would be extremely difficult. But that program would certainly
make it a lot easier to start with. You wouldn't have to write all the clicks
from scratch just some of them.
--Dan.
|
|
| |
> > That's a great idea! Though, and I might be confused here, wouldn't it
> > be possible to just create a stud.lcd file, and as the stud.dat file in
> > included, the lcd info would automagically be there?
>
> I thought so too, but the format document (way at the bottom) implies
> that this might be undesirable. I'm not sure I understand why, though : (
I do indeed think it would be undesirable. As we all know Stud.dat gets used
every ware. There are a fair few instances were the clicking behaviours of two
bricks would be different even though they are both referencing the same
stud.dat file for geometry.
For example parts 3822 and 3622. A door and a brick respectively. The studs on
the brick snap every 90 degrees but on the door you often want it open to say
45degrees. So there are two different behaviours for stud.dat in this case. If
you inherited clicking information from sub parts of the geometry of a brick,
you would need to keep track of all the different ways that sub part can be
used. This would make things much more complicated.
The use of sub parts and primitives is a very elegant way of representing
geometry for Lego bricks. I think the same solution can be applied to clicks.
I propose that instead of inheriting from sub parts click authors can use a
library of sub clicks. The same way primitives like stud.dat are used for the
geometry of bricks.
To sum up. There would be a stud.lcf but it would not be referenced from
stud.dat.
The latest GLIDE download has a few .lcf files included with it. I recommend
taking a look at these. It shows a bit of file reuse for stud and stud inlet
pairs.
--Dan.
|
|
| |
Dan Boger wrote:
> There's a difference between supporting POV inline (which is not
> controlled in the community) and supporting LCD info (which could be
> integrated into the DAT format). I'd like to see programs support both
> options - both as an external .lcd file, and as inline lcd info in the
> .dat.
I agree, but in the short term, I think seperate files may be simpler.
> That's a great idea! Though, and I might be confused here, wouldn't it
> be possible to just create a stud.lcd file, and as the stud.dat file in
> included, the lcd info would automagically be there?
I thought so too, but the format document (way at the bottom) implies
that this might be undesirable. I'm not sure I understand why, though : (
|
|
| |
On Tue, Jun 22, 2004 at 04:17:29PM +0000, Xanthra47 wrote:
> The it would be slick to have the LCD info in the dat file, but it
> might complicate issues being dicussed by the Ldraw committee : ( It
> seems that pov style includes aren't allowd in official files either
> so maybe keeping it seperate for a while will be easier...
There's a difference between supporting POV inline (which is not
controlled in the community) and supporting LCD info (which could be
integrated into the DAT format). I'd like to see programs support both
options - both as an external .lcd file, and as inline lcd info in the
.dat.
> I'd be willing to take a stab at writing some "click" files : )
> Actually, I was thinking of writing a quick vb app that parsed dat
> files and automatically genrates LCD info for parts that have stud and
> tube primitives. I bet that'd save a lot of time.
That's a great idea! Though, and I might be confused here, wouldn't it
be possible to just create a stud.lcd file, and as the stud.dat file in
included, the lcd info would automagically be there?
--
Dan Boger
dan@peeron.com
|
|
| |
The it would be slick to have the LCD info in the dat file, but
it might complicate issues being dicussed by the Ldraw committee : (
It seems that pov style includes aren't allowd in official files either
so maybe keeping it seperate for a while will be easier...
I'd be willing to take a stab at writing some "click" files : )
Actually, I was thinking of writing a quick vb app that parsed dat files
and automatically genrates LCD info for parts that have stud and tube
primitives. I bet that'd save a lot of time.
LMKWYT
-JSM
Dan Boger wrote:
> On Tue, Jun 22, 2004 at 01:40:04PM +0000, Dan wrote:
>
> > To see the standard so far take a look at:
> >
> > http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
>
>
> Should the format perhaps be changed so that LCD info could be included
> inline in a valid DAT file? Perhaps make all the lines start with a "0
> LCD" before anything else? Then, when reading a DAT file, a program can
> recognize and parse LCD info, in addition to looking for the .lcd file.
>
> Does that make sense? Do you think it's worth the effort?
>
> I think connection data is really cool, and we should try to make it
> part of the standard library.
>
|
|
| |
On Tue, Jun 22, 2004 at 01:40:04PM +0000, Dan wrote:
> To see the standard so far take a look at:
>
> http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
Should the format perhaps be changed so that LCD info could be included
inline in a valid DAT file? Perhaps make all the lines start with a "0
LCD" before anything else? Then, when reading a DAT file, a program can
recognize and parse LCD info, in addition to looking for the .lcd file.
Does that make sense? Do you think it's worth the effort?
I think connection data is really cool, and we should try to make it
part of the standard library.
--
Dan Boger
dan@peeron.com
|
|
| |
Hi
Glide has been on hold now for about a month but its back in development. You
can look forward to clicking bricks in about two to three weeks.
Once I have the system implemented is there anyone out there who would be
prepared to start writing click files for parts?
It would be my own standard not officially accepted by anyone so the work may
never see the light of generally accepted day.
To see the standard so far take a look at:
http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
I don’t want any files yet I just want to know if there are people out there
prepared to do a few clicks.
--Dan.
|
|
| |
Ross Crawford wrote:
> To be truly correct, the restraints should also have tolerances, the one that I
> would find most useful is technic axle in it's hole - there's quite a
> significant clearance between them. Not sure the best way to handle such things.
>
> ROSCO
If this is a feature that is used deliberately and often enough
to motivate a software model for it, it would be possible to
encode a combination of hard constraints, demonstrating the
normal and preferred connection method, and additional means
for breaking those constraints within certain pre-defined
acceptable limits, to take advantage of the small tolerances.
If every connection would be allowed several simultaneous
degrees of freedom, we are in for some rather hairy problems
in structural mechanics, but it would be perfectly possible to
allow a user to deliberately break a single constraint within
reason, preferably also with real world knowledge that it is OK
to connect pieces like that and have them stay together.
However, I'm not sure that this is a feature that is used
often enough to motivate a software implementation of it.
Can you give some example of when and how you have used it
to your advantage in models?
|
|
| |
In lugnet.cad.dev.lcd, Daniel Bennett wrote:
> > Many creations I have seen and built make use of rotating
> > single-stud connections for articulated joints and odd
> > angle mounts, so allowing an inherently non-rotating stud
> > inlet is a flaw that should be avoided if possible.
>
> Hi
> I am currently working on my own version of LCD.
>
> http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
>
> I was thinking of adding some kind over-ride to the angle of movement for each
> connection. This clinches it, I will. The format itself could hold single-studs
> that lock at 90 degrees or similar as long as the editing programs can brake
> these rules at the users request. The locking of angles is still useful
> information to have even if its not always used.
>
> LCD should be an aid to building not a set of rules that confine creativity.
>
> For more info on GLIDE take a look at http://news.lugnet.com/cad/?n=11299
To be truly correct, the restraints should also have tolerances, the one that I
would find most useful is technic axle in it's hole - there's quite a
significant clearance between them. Not sure the best way to handle such things.
ROSCO
|
|
| |
> Many creations I have seen and built make use of rotating
> single-stud connections for articulated joints and odd
> angle mounts, so allowing an inherently non-rotating stud
> inlet is a flaw that should be avoided if possible.
Hi
I am currently working on my own version of LCD.
http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
I was thinking of adding some kind over-ride to the angle of movement for each
connection. This clinches it, I will. The format itself could hold single-studs
that lock at 90 degrees or similar as long as the editing programs can brake
these rules at the users request. The locking of angles is still useful
information to have even if its not always used.
LCD should be an aid to building not a set of rules that confine creativity.
For more info on GLIDE take a look at http://news.lugnet.com/cad/?n=11299
--Dan.
|
|
| |
Nothing much seems to be happening with the LCD spec,
but I read it through and have a comment, in case anyone
is listening. If not, at least this lands in the archives.
The "stud inlet" and the "turnable stud inlet" should not
be distinguished in their own merit. In fact, because every stud
inlet accepts any cylindrical stud, a stud-to-inlet connection
can always be rotated freely around the stud. The physical reason
for why some stud-to-inlet connections can be turned and some
can not is that most connections involve several studs connecting
to several stud inlets. Connections involving more than one stud
pose a constraint that removes one degree of freedom.
Collisions are secondary constraints that need to be handled
if we are striving for full realism.
Many creations I have seen and built make use of rotating
single-stud connections for articulated joints and odd
angle mounts, so allowing an inherently non-rotating stud
inlet is a flaw that should be avoided if possible.
|
|
| |
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?
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
|
|
| |
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.dev.lcd, Willy Tschager wrote:
| |
looks intriguing! the only thing I do not properly understand is the size
statement. this simplyfied statement makes sense for ordinary plates and
bricks of square or rectangular shape, but not wings, wedges, corners ...
|
Things that are unapplicable for a specific part (model, object etc.) should not
be used with it. For example, you can’t rotate an Axle--Axlehole connection
because it can slide only. Therefore, all statements, functions and properties
related to rotation are unapplicable for that movcon.
| |
have you bounced this proposal against the LSC? if they could come up with
just one or two ready-to-use .cdl files and - say - a plugin for LDDP where
we part-authors could test the definitions, I would immediately start to
set
up connections for the parts I authored. I also guess a copy of the
actual
PT could collect these parts.
I might totally wrong but I identified the
key-point in a prog which
actually uses the db. as long as we don’t kick
this thing round the room,
it’ll stay all theorical.
|
I’m afraid you are referring to abbreviations I do not know. (LSC, cdl, LDDP,
PT.) For the time being, I showed the proposal to Lugnet and people visiting my
home page only.
|
|
| |
In lugnet.cad.dev.lcd, Attila D. Láng wrote:
| |
In lugnet.cad.dev.lcd, Willy Tschager wrote:
| |
In lugnet.cad.dev.lcd, Damien Guichard wrote:
w.
ps. no it’s not a joke! yes, it’s a serious question.
|
Well, Willy, as you could read in my posting
The LCD guys strike again,
LCD and LMPL is available for download. Meanwhile, I’ve established my new
site at http://lattilad.org; you’ll found my Lego related works on the
personal home page.
Láng Attila D., http://lattilad.org
|
looks intriguing! the only thing I do not properly understand is the size
statement. this simplyfied statement makes sense for ordinary plates and
bricks
of square or rectangular shape, but not wings, wedges, corners ...
have you bounced this proposal against the LSC? if they could come up with
just one or two ready-to-use .cdl files and - say - a plugin for LDDP where
we
part-authors could test the definitions, I would immediately start to
set up
connections for the parts I authored. I also guess a copy of the
actual PT
could collect these parts.
I might totally wrong but I identified the key-point
in a prog which
actually uses the db. as long as we don’t kick this thing round
the room,
it’ll stay all theorical.
dear LSC, do you think this would be possible? not as a short term goal of
coarse. it would be great if we could start building up the database by the
end
of the year.
w.
www.holly-wood.it
|
|
| |
In lugnet.cad.dev.lcd, Willy Tschager wrote:
| |
In lugnet.cad.dev.lcd, Damien Guichard wrote:
w.
ps. no it’s not a joke! yes, it’s a serious question.
|
Well, Willy, as you could read in my posting
The LCD guys strike again,
LCD and LMPL is available for download. Meanwhile, I’ve established my new site
at http://lattilad.org; you’ll found my Lego related works on the personal
home page.
Láng Attila D., http://lattilad.org
|
|
| |
In lugnet.cad.dev.lcd, Damien Guichard wrote:
> Damien
w.
ps. no it's not a joke! yes, it's a serious question.
|
|
| |
> That's GREAT news!
> I have e-mailed Atilla about LMPL status but never got answer.
>
> Thanks Tim,
> Thanks Atilla,
>
> Damien
Hi Damien,
sorry for not being here for a long while. The fact is that, at the time when I
invented LCD and LMPL, I were using a slow dialup account with large phone
bills. I was unable to visit Lugnet often and I could answer private mail only.
Meanwhile, my address lad@rentahost.net became overwhelmed by spam and the mail
you have sent has been probably fallen as a victim of the spam filter. Two weeks
ago, I lost my account at rentahost.net, so there is no spam problem any more.
:)
Now I'm using several mail accounts at @freemail.hu, including lattilad,
langattila and langattiladavid, but I'm also behind the addresses lattilad0306
at hotpop.com and lattilad at axelero.com. I hope such an amount of addresses
will be enough... :)
Currently, I have no home page at all, but efforts have been made to purchase an
own domain with a hosting service. I'm in a great hope that in some days or
weeks I will be able to upload my page to the net again.
Now I'm using a cable modem connection, so finally I can use Lugnet normally and
answer messages appearing here, too. (However, I've subscribed
lugnet.cad.dev.lcd as a mailing list to keep an eye on what's going on.)
Stopping babbling about my situation, LMPL is ready as a version 1.00, finished
almost two years ago. It was published on my previous home page in the last one
year, but losing the page it disappeared from the net now. It will be up again
when I'll upload the page. But of course, I can send it to you if you wish. It
is a 38 kilobytes zip file.
By the way, only a single LCD guy had remained. KACS had disappeared from the
net while I was developing LMPL, and no answer from him since. His website seems
living, but he didn't answer mails, a snail mail, phones...
But I'm here, popping up.
|
|
| |
In lugnet.cad, Tim Courtney writes:
> Everyone -
> Not too long ago, Atilla La'ng emailed me some more documents he has written
> based on the original LDraw Connection Database (LCD) document:
>
> www.ldraw.org/reference/specs/lcd/
>
> You can find them at:
>
> http://lad.rentahost.net/lad/0e.htm
> Select "Sofware," and they are listed on the next page.
>
> I've also received another document, used for someone's masters' degree. I'm
> waiting to hear back from him whether or not I can post it (I don't see a
> problem, but I figure it's courteous to ask).
>
> Just thought I'd throw these up to inspire, enjoy. :-)
>
> -Tim
That's GREAT news!
I have e-mailed Atilla about LMPL status but never got answer.
Thanks Tim,
Thanks Atilla,
Damien
|
|
| |
In lugnet.cad.dev.lcd, Alexandre Soong writes:
> Hello, everybody!
>
> I am making a program that simulate a robot movement made with Lego (the
> robot draw is already made in Ldraw format) on a computer screen. And I
> pretend to use parts in .dat. I tried to learn it from ldglite but it is too
> complex and I cannot find a good tutorial. The program will be made in C++
> and OpenGL. If anyone can send me any information for this, I will be very
> thankful!
>
> Thanks and best regards,
>
> Alex
Hello Alex!
Ldraw files are made of text lines.
Typically, in model files (that contain parts), lines begin with numbers
lower than 2
0: comment
1: part (position and orientation)
Typically, in part files (that contain primitives), lines begin with numbers
from 2 to 5
2: line (2 points)
3: triangle (3 points)
4: quad (4 points)
Of course most parts also contain line(s) 1 as subpart(s) because of either
complexity or standardization.
Read http://www.ldraw.org/reference/specs/fileformat for more info about
line format.
Happy programming,
Damien
|
|
| |
Hello, everybody!
I am making a program that simulate a robot movement made with Lego (the
robot draw is already made in Ldraw format) on a computer screen. And I
pretend to use parts in .dat. I tried to learn it from ldglite but it is too
complex and I cannot find a good tutorial. The program will be made in C++
and OpenGL. If anyone can send me any information for this, I will be very
thankful!
Thanks and best regards,
Alex
|
|
| |
[XFUT lugnet.cad.dev]
In lugnet.cad.dev.lcd, Mark Kennedy wrote:
> What is the official stance on updating parts done by other people? I did some
> modifications to part 2485 on the tracker and have tried to send it to the
> orignal author, but am not sure wether he got it or not.
As long as you've tried to make contact, and not gotten a response, go
ahead and make your changes.
Steve
|
|
| |
What is the official stance on updating parts done by other people? I did some
modifications to part 2485 on the tracker and have tried to send it to the
orignal author, but am not sure wether he got it or not.
|
|
| |
Hello LCD "community",
As female connectors (mainly stud inlets) can effectively hide male
connectors (mainly studs), we should ensure that the LCD project do not
waste such an opportunity to further speed up LDraw display. I think this
possibility must be supported from the start to guarantee that advanced
displayers could easily detect and remove hidden male connectors (I mean studs).
Damien
|
|
| |
In lugnet.cad.dev.lcd, Damien Guichard writes:
> Is it deferred or still coming soon?
>
> Damien
KACS is working, as I know, but he has other tasks too. We must be
patient; he is often slow, but the result worths the time.
(Damien, would you be so kind to forward this mail to the group? It
needs a lot of work to respond on the website what I haven't the time
this minute for. TIA!)
La'ng Attila D., iro <lad@rentahost.net> <http://lad.rentahost.net>
|
|
| |
Is it deferred or still coming soon?
Damien
|
|
| |
Hi Kiss Attila Csongor,
Hi Láng Attila D,
Now I stop talking about LCD or LMPL, until publication.
Before publication I can not evaluate if my own approach has any "added value".
Termolo is a general purpose language with simplistic syntax.
Before of generality it can encompass any past, present and future needs.
Because of simplistic syntax it is easy to learn and ALM would be easy to
extend.
Also Termolo is somewhat like lego: you build complex programs from
simplistic statements.
Like lego, any future ALM statement would prefectly assemble initial ones.
Like lego, a termolo statement has no predefined usage (no type system) but
is usable if it fits (the practice rules).
At first, I imagined I have designed THE lego language.
No other language would match it for future lego usage.
But now I realize this is just "syntax preference".
Syntax preference is not added value.
I have made a conceptual mistake due to enthusiasm.
Or may be the above mentionned properties would only benefit in a future
beyond LMPL.
But I can not prove that now.
May be I had better to add new MOCs on my web page.
May be more useful to community.
Damien
http://brickcaster.multimania.com
|
|
| |
Hi Kiss Attila Csongor,
Hi Láng Attila D,
Now I stop talking about LCD or LMPL, until publication.
Before publication I can not evaluate if my own approach has any "added value".
Termolo is a general purpose language with simplistic syntax.
Before of generality it can encompass any past, present and future needs.
Because of simplistic syntax it is easy to learn and ALM would be easy to
extend.
Also Termolo is somewhat like lego: you build complex programs from
simplistic statements.
Like lego, any future ALM statement would prefectly assemble initial ones.
Like lego, a termolo statement has no predefined usage (no type system) but
is usable if it fits (the practice rules).
At first, I imagined I have designed THE lego language.
No other language would match it for future lego usage.
But now I realize this is just "syntax preference".
Syntax preference is not added value.
I have made a conceptual mistake due to enthusiasm.
Or may be the above mentionned properties would only benefit in a future
beyond LMPL.
But I can not prove that now.
May be I had better to add new MOCs on my web page.
May be more useful to community.
Damien
http://brickcaster.multimania.com
|
|
| |
DG> Do not forget to download Spiderbot.dat (in lugnet.cad.models)
It came automatically via e-mail. :)
DG> We embody two different well-known approaches.
Both of LCD and LMPL embody these two approaches.
DG> First : the Simulation approach.
DG> And the ultimate video game would be a game that is ray-traced in real time.
I hope we will reach some day that state...
(Now I have a scene. And when I start to render it, the Windows
generates about 700MB of swap file /I have 448MB RAM/... and it takes
a few minutes... and this is only one steady scene... :(
DG> (here I refer "" which sounds stupid to me: do you mean fun would be greater
DG> if lego bricks were mold at atomic precision? I don't think so.)
Why not? :) (If lego bricks in the above means LDraw parts on the
screen or printed)
DG> I do not say LCD+LMPL will fail. Because I know nothing about them.
DG> I still wait publishing.
:) I still work on it (formatting and illustrating).
You can know many and the most important things about LCD. We think it
to be the starting point, and that's why we need it first.
DG> However, I am sure about one thing: lego bricks are what you do with them.
DG> So I prefer to adhere the use-case approach.
DG> Because the existence precedes the essence.
Have you read the spirit of LCD project?
http://news.lugnet.com/cad/dev/?n=6823
DG> Consider the Spiderbot model.
DG> I guess the Spiderbot leg part "Plate 1 x 4 Offset" is not in LCD as a
DG> rotating connector.
Now we are at the beginning, so we have only a few precollected
connector _types_.
But I think "Plate 1 x 4 Offset" may as well have a rotating type connector
on it (and a sliding one at a time!). If not, this movement(s) can be
handled by LMPL level. :)
(The part is a part and a connector is a connector. A part is not
a connector, but a part can have connector(s!) on it.)
DG> In the real world the legs hardly articulate without model disassembly.
DG> But I must imagine they do. If they don't how my model would walk?
DG> So I decide they do. And I declare "" as a rotating connector. The reality
DG> is not what it is, it is just what I imagine (I realize while typing: that
DG> is lego slogan!!!).
Now your Spiderbot model will scuff if the Antenna not sliding up and
down. :) You must handle this type of movement too!
DG> Because I play lego. Because lego is a toy.
I say LEGO is not a toy. LEGO is THE toy! :)
DG> And, believe me, I am really tempted by abandon. Because this is too much work.
Yes, I agree with you. The LEGO itself is very-very complex. Now we
have "only" the geometry with LDraw and it's already fantastic. If we want
more (connections, movements, playability, etc.) we need to work on it
hard.
DG> I have to choose between ALM and a new, more robust, Termolo compiler.
DG> Currently I only have a very crude Termolo interpreter, written by myself.
DG> And I really need a compiler for advanced, computer intensive usage.
May I ask you to say me something about your Termolo
interpreter/compiler too? (I think it's going to be offtopic, so I ask
you to do it via private e-mail.)
Play well!
--
___ Bye: KACS, The BrickaMocka
/___\__
|o o| E-mail: kacs69@freemail.hu
_\_~_/_ kacs@makacs.hu
/|LEGO |\ lcd@makacs.hu
//|_____|\\
C |==|==| C Brick, Brick Hurray! :)
|__|__|
__I__I__I_________________< The Bat! 1.53d >_
|
|
| |
Hi Damien!
DG> Now you speak about layers.
DG> That is precisely what I called "multiple syntax levels".
DG> Software layers are known to be very bad for software engineering and design
DG> in general.
I don't think so.
What about object oriented programming? Is it bad or obsolete?
What about the different layers of protocols? Are these
works and are these flexible enough to expand?
What about standards? Some new standard based on a very new approach,
and some are based on a previous standard.
So a basic LDraw editor may not need to handle the LMPL level, but an
animation program does. And a simple textual editor (like Carsten's
very new and fantastic LDDesignPad, many thanks Carsten!) may not
need neither the LCD level and LMPL. And maybe there will be another
layer based on LCD what not needs LMPL.
This will help to keep structured the knowledge bases and functionality
levels.
(If I have bread, butter, jam and tomato slices I will not mix
together the butter and the jam. Maybe I want only bread, butter and
tomato, or only bread and butter...)
DG> Hence, LCD statements could be seamlessly integrated into part files.
We intend not to touch the part files (if it's possible) since the LCD
will be a complex database for connections, and the part files remain
to contain the pure geometry itself.
--
___ Bye: KACS, The BrickaMocka
/___\__
|o o| E-mail: kacs69@freemail.hu
_\_~_/_ kacs@makacs.hu
/|LEGO |\ lcd@makacs.hu
//|_____|\\
C |==|==| C Brick, Brick Hurray! :)
|__|__|
__I__I__I_________________< The Bat! 1.53d >_
|
|
| |
Hi Láng Attila D.
Hi Kiss Attila Csongor,
Do not forget to download Spiderbot.dat (in lugnet.cad.models)
The debate becomes VERY interesting.
We embody two different well-known approaches.
First : the Simulation approach.
Things are nothing but their properties.
Then complexity emerges from properties composition.
This is the suitable approach for a Ray-tracer.
And the ultimate video game would be a game that is ray-traced in real time.
(here I refer "" which sounds stupid to me: do you mean fun would be greater
if lego bricks were mold at atomic precision? I don't think so.)
Second : the Usage approach.
Things are only what you do/can-do with them.
Then complexity emerges from interaction of sensible usages.
This is the suitable approach for a GUI.
And the ultimate video game would be the game that dispenses most fun
according to you.
Let me tell you one thing: the Nature/Usage opposition is a recurring debate in
* physics (are atoms "real" or just solution to equilibrate chemical reactions)
* math (are numbers and functions "natural" or created by human need for
computing)
* software (do software components model reality or do they just mimic how
it works)
In science the debate is closed. Atoms and functions are known to be just
mind constructs that "work". Because to "work" is precisely the critter of
a scientific experience. In software field, very good OO languages that are
best for simulation (Simula, Eiffel) have disappeared. They all have been
replaced by user approach like Smalltalk, and use-cases approach like UML .
What succeeds is practice-driven. I do not say LCD+LMPL will fail. Because I
know nothing about them. I still wait publishing.
However, I am sure about one thing: lego bricks are what you do with them.
So I prefer to adhere the use-case approach.
Because the existence precedes the essence.
The LEGO group keep repeating the fun in lego comes from freedom and
imagination.
No cool play-value will emerge from limits and constraints inherent in bricks.
The properties of a model are not summation of individual part properties,
but imagination projected to its whole shape.
Consider the Spiderbot model.
I guess the Spiderbot leg part "Plate 1 x 4 Offset" is not in LCD as a
rotating connector.
In the real world the legs hardly articulate without model disassembly.
But I must imagine they do. If they don't how my model would walk?
So I decide they do. And I declare "" as a rotating connector. The reality
is not what it is, it is just what I imagine (I realize while typing: that
is lego slogan!!!). Because I play lego. Because lego is a toy.
The very bad news for me is : if I give up, who will defend the practical
approach?
And, believe me, I am really tempted by abandon. Because this is too much work.
I have to choose between ALM and a new, more robust, Termolo compiler.
Currently I only have a very crude Termolo interpreter, written by myself.
And I really need a compiler for advanced, computer intensive usage.
Damien
http://brickcaster.multimania.com
|
|
| |
In lugnet.cad.dev.lcd, Kiss Attila Csongor (KACS) writes:
> Hi all, hello Damien!
>
> DG> This thread is not very frequented now.
> DG> May be because the debate has to become much more technical.
>
> Yes, there is not so many traffic here nowadays. We knew this will be
> a long project because it's a big project with many steps. There is
> many questions to clarify, there is a huge amount of types of
> connections/connectors, etc...
> I promised we will keep the tips, the collected connections in tables
> and update the proposal. We will do it ASAP, but now I have a little
> bit technical problem but Jacob try to help me. (Many thanks to
> Jacob!)
>
> LAD> What are you meaning by multiple syntax levels, Damien?
> DG> I mean if LMPL is not sufficient, we are in danger to either add more and
> DG> more syntax extensions or to add a whole additionnal new language. Also LMPL
> DG> should be structured enough so that textual programming and GUI
> DG> manipulations are equivalent.
>
> I think it's not a danger, it's the normal flow of development. At
> first we defined the basic level (or layer) called LCD. This will
> solve the connections and nothing more. The next layer is the LMPL
> highly based on LCD. And maybe there will be additional layers too.
> And all of these will work via GUI interface, so it means there is no
> need to textual programming for the end user. (Similarly you not have
> to code anything if you want to use LDraw. Only when you want develope
> something new. Now you can develope only parts and nothing
> more. If we want to define connections and later movements we will
> need additional syntaxes and keywords to script them. Finally we can
> call it a language. Also, I think the LDraw file format is a language.
> Small, but language. :)
>
> LAD> Let me report that LMPL is almost ready. It is going to be published soon.
> DG> Good news. May be I will better know what I am talking about, when published.
>
> LAD wrote it, and now I do the formatting and illustrating according
> to the new LDraw.org site style. I try to do it ASAP, but it's more
> complex and longer than the LCD. :)
>
> > > > You should have only one specification language that encompasses all
> > > > present and future needs.
> > > Of course we should.
>
> And it must be flexible enough for future extensions. That's why we
> think in layers.
>
> DG> I mean a LMPL proposal. I am sorry I will not help to collect connectors and
> DG> measure distances and angles. I do not prefer promoting my own project
> DG> rather than to contribute. I actually prefer to review parts as I already do
> DG> in the Parts Tracker. The reason why I do not is because LMPL should precede
> DG> LCD. Because innovative usages are in LMPL. And because LCD notation must
> DG> assist LMPL, not the reverse. In my opinion, collection parts info should be
> DG> the very last stage. LMPL should be mainly driven by playing practice, not
> DG> by parts geometry.
>
> Hm, this is a very interesting question!
> In my humble opinion first we need to connect the parts somehow and
> after that we can move the connected parts (as in real life) and start
> to play with it. If we have no connections than we have nothing to
> play with. (Imagine a minifig starting to walk. Without connections
> the minifig will lose his/her head and all the other member. :)))
>
> DG> I am currently at stage 1 (nothing is done).
> DG> So my credibility is very low.
>
> I trust you, so I encourage you to work out your approach as a
> complete proposal!
>
> --
> ___ Bye: KACS, The BrickaMocka
> /___\__
> |o o| E-mail: kacs69@freemail.hu
> _\_~_/_ kacs@makacs.hu
> /|LEGO |\ lcd@makacs.hu
> //|_____|\\
> C |==|==| C Brick, Brick Hurray! :)
> |__|__|
> __I__I__I_________________< The Bat! 1.53d >_
Hello Láng Attila D.
Hello Kiss Attila Csongor,
Now you speak about layers.
That is precisely what I called "multiple syntax levels".
Software layers are known to be very bad for software engineering and design
in general.
On the contrary, ALM is a completely "flat" or "unified" approach.
I am currently at stage 3 as defined in my previous post.
My project is named ALM (Advanced LDraw Modelling).
I know nothing about LMPL, I am curious about what is prepared.
Here is more about ALM.
ALM is not only a scripting language for LDraw models.
ALM is both the models and their scripting.
ALM is based on my Termolo language, it extends it with LDraw capabilities.
I have designed Termolo during last months with lego applications in mind.
Termolo is the language I used in my post "I have read the LCD article".
To give a taste of Termolo, here is a function derivator (11 lines) :
Deriv(X) := R(1) // x'=1
Deriv(R(k)) := R(0) // k'=0
Deriv(Add(u,v)) := Add(Deriv(u),Deriv(v)) // (u+v)'=u'+v'
Deriv(Mul(R(k),u) := Mul(R(k),Deriv(u)) // (ku)'=ku'
Deriv(Mul(u,v)) := Add(Mul(Deriv(u),v),Mul(u,Deriv(v))) // (uv)'= u'v+uv'
Deriv(Power(u,b)) := Mul(R(b),Mul(Deriv(u),Power(u,b-1))) // (u^b)'=b u'u^(b-1)
Deriv(Sin(u)) := Mul(Deriv(u),Cos(u)) // (sin u)'=u'cos u
Deriv(Cos(u)) := Mul(R(-1),Mul(Deriv(u),Sin(u))) // (cos u)'=-u'sin u
Deriv(Tan(u)) := Mul(Deriv(u),Power(Cos(u),-2)) // (tan u)'=u'(cos u)^-2
Deriv(Log(u)) := Mul(Deriv(u),Power(u,-1)) // (log u)'=u'u^-1
Deriv(Exp(u)) := Mul(Deriv(u),Exp(u)) // (exp u)'=u'exp u
I will not further describe Termolo.
Now I describe ALM specifications.
As already said, I start where MLCad stops.
So a basic ALM module closely ressembles a DAT file saved by MLCad.
ALM-equipped software are supposed to load *.dat files and save *.alm files.
Thus the Spiderbot.dat file would be saved as a Spiderbot.alm file.
As an example I now describe Spiderbot.alm in details.
A *.alm file either contains a single ALM module or several ALM modules
embraced by :
Spiderbot := Modules.New(
// place Spiderbot module content here
)
As in a DAT file the module content starts with a Title and an Author :
Title := "Spiderbot: My first ALM specification"
Author :="damien.guichard@wanadoo.fr"
The module system use the pointed notation: outside Spiderbot module Title
is accessed by Spiderbot.Title
Then the primitive ALM construct is the LDraw Part, as following :
Part(no, col, x,y,z, ay,ax,az) // ax and az are optional (0 if absent)
So, Part(3001, Main, 0 0 0, 0) is a main-colored Brick 2 x 4 at origin.
Then the composite ALM construct is the MLCad Group.
The following Group is the spiderbot parts, excluding legs and minifig :
Body := Group(
Part(3020 Grey, 0 -40 0, 90)
Part(2342 Blue, 0 -48 -30, 0)
Part(4598 Grey, 0 -64 10, 0)
Part(4070 Grey, 10 -74 48, 180 -90 0)
Part(4070 Grey, -10 -74 48, 180 -90 0)
Part(4590 Grey, 0 -88 58, 180)
Part(4589 Black, -10 -110 58, 0)
Part(4589 Black, 10 -110 58, 0)
)
This Group can not be rotated. That means it has fixed position in its
super-group.
Now here is a spiderbot leg group, that can be rotated :
Leg1 := Group(
Rotation(10 0 30, AxisY(0 -90) )
Part(4590 Black, 40 -56 20, 0)
Part(3957 TransRed, 70 -16 30, 0)
Part(4740 TransRed, 70 -8 30, 0)
)
Rotation line indicates that the leg can freely rotate around (10,0,30) in
the Y direction, in (0,-90) range.
Of course, the (0,-90) range is the same as (-90,0) but not the same as (0,270).
There are similar declarations for Leg2, Leg3 and Leg4.
Groups may be manipulated via the following functions :
Move(dx dy dz, group) // vector is rectricted by group's Sliding statement
Rotate(ay ax az, group) // angle vector is restricted by group's Rotation
statement
Paint(col, group) // set the main color of a group
Color(group) // return the main color of a group
Freeze(group) // forbid Move and Rotate
Unfreeze(group) // reverse Freeze
Hide(group) // hide the group
Show(group) // show the group
Now, here is how a default spiderbot is defined :
NewDefault := Obj(
Rotation(0 0 0, AxisY AxisX AxisZ )
Body
Rotate(-25,Leg1)
Rotate(25,Leg2)
Rotate(65,Leg3)
Rotate(-65,Leg4)
Freeze( Minifigs.NewSpacePilot(Red, 0 -64 0) )
)
Obj is actually a group. Anything that contains part(s) or group(s) is
itself a group.
Outside the Spiderbot module a new spiderbot is allocated via
Spiderbot.NewDefault
Just like Minifigs.NewSpacePilot allocates a new sitting classic space minifig.
Here is the corresponding excerpt from the Minifigs module :
SpacePilot := Group(
Rotation(0 0 0, AxisY AxisX AxisZ )
// here are minifigs parts
)
// The allocator used in Spiderbot
NewSpacePilot(col, x y z) := Move( x y z, Paint(col,SpacePilot) )
// For more precise placement
NewSpacePilot(col, x y z, ay ax az) := Rotate( ay ax az, NewSpacePilot(col,
x y z) )
The default spiderbot is for building and basic articulation.
You can freely manipulate it within group movement limits.
Also all previous statements can be either created visually or textually.
Just like current MLCad usage, the work on visual side does not scratch the
work on textual side, nor the reverse.
Here is additionnal gadgetry :
// You can Show/Hide the pilot
SwitchPilot( Obj(..,Show(pilot)) ) := Obj(..,Hide(pilot))
SwitchPilot( Obj(..,Hide(pilot)) ) := Obj(..,Show(pilot))
// You can change pilot color
ColorPilot(col, Obj(..,pilot) ) := Obj(..,Paint(col, pilot))
Now the Spiderbot module happily clones the original MLCad file, with just
extra playability.
Well, I am almost finished with what makes sense to a builder user.
Which is stage 3 in my previous post.
Now I must address players concerns.
Which is stage 4 in my previous post.
And later, gamers concerns.
Which is stage 5 in my previous post.
Then stage 6 is LCD reconsidered and unified with ALM.
By unified I both mean using same notation and supporting construction of
ALM groups, instead of user definition. Then LDraw parts could be
reconsidered using such statements :
Line( col x1 y1 z1 x2 y2 z2 )
Triangle( col x1 y1 z1 x2 y2 z2 x3 y3 z3 )
Quad( col x1 y1 z1 x2 y2 z2 x3 y3 z3 x4 y4 z4 )
Hence, LCD statements could be seamlessly integrated into part files.
Actually ALM is a totalizing seamless approach, from quads to parts, from
LCD to ALM, from models to interactivity and network games. But, in case
there is unwilling to change at such a low level, ALM can work at top of
traditional LDraw parts and a foreign LCD definition. Anyway, if any change
has to be done, it should propagate from high level to low-level. It must be
sustained by a very wide approval. It must stop when resistance is
encountered. Anyway, only a very marginal part of ALM expression power is
lost if no change is done (creating or morphing LDraw parts by program is
not really a daily practice). By promoting unification, ALM actually
promotes compatibility without impairing evolution.
Damien
http://brickcaster.multimania.com
|
|
| |
Hi all, hello Damien!
DG> This thread is not very frequented now.
DG> May be because the debate has to become much more technical.
Yes, there is not so many traffic here nowadays. We knew this will be
a long project because it's a big project with many steps. There is
many questions to clarify, there is a huge amount of types of
connections/connectors, etc...
I promised we will keep the tips, the collected connections in tables
and update the proposal. We will do it ASAP, but now I have a little
bit technical problem but Jacob try to help me. (Many thanks to
Jacob!)
LAD> What are you meaning by multiple syntax levels, Damien?
DG> I mean if LMPL is not sufficient, we are in danger to either add more and
DG> more syntax extensions or to add a whole additionnal new language. Also LMPL
DG> should be structured enough so that textual programming and GUI
DG> manipulations are equivalent.
I think it's not a danger, it's the normal flow of development. At
first we defined the basic level (or layer) called LCD. This will
solve the connections and nothing more. The next layer is the LMPL
highly based on LCD. And maybe there will be additional layers too.
And all of these will work via GUI interface, so it means there is no
need to textual programming for the end user. (Similarly you not have
to code anything if you want to use LDraw. Only when you want develope
something new. Now you can develope only parts and nothing
more. If we want to define connections and later movements we will
need additional syntaxes and keywords to script them. Finally we can
call it a language. Also, I think the LDraw file format is a language.
Small, but language. :)
LAD> Let me report that LMPL is almost ready. It is going to be published soon.
DG> Good news. May be I will better know what I am talking about, when published.
LAD wrote it, and now I do the formatting and illustrating according
to the new LDraw.org site style. I try to do it ASAP, but it's more
complex and longer than the LCD. :)
> > > You should have only one specification language that encompasses all
> > > present and future needs.
> > Of course we should.
And it must be flexible enough for future extensions. That's why we
think in layers.
DG> I mean a LMPL proposal. I am sorry I will not help to collect connectors and
DG> measure distances and angles. I do not prefer promoting my own project
DG> rather than to contribute. I actually prefer to review parts as I already do
DG> in the Parts Tracker. The reason why I do not is because LMPL should precede
DG> LCD. Because innovative usages are in LMPL. And because LCD notation must
DG> assist LMPL, not the reverse. In my opinion, collection parts info should be
DG> the very last stage. LMPL should be mainly driven by playing practice, not
DG> by parts geometry.
Hm, this is a very interesting question!
In my humble opinion first we need to connect the parts somehow and
after that we can move the connected parts (as in real life) and start
to play with it. If we have no connections than we have nothing to
play with. (Imagine a minifig starting to walk. Without connections
the minifig will lose his/her head and all the other member. :)))
DG> I am currently at stage 1 (nothing is done).
DG> So my credibility is very low.
I trust you, so I encourage you to work out your approach as a
complete proposal!
--
___ Bye: KACS, The BrickaMocka
/___\__
|o o| E-mail: kacs69@freemail.hu
_\_~_/_ kacs@makacs.hu
/|LEGO |\ lcd@makacs.hu
//|_____|\\
C |==|==| C Brick, Brick Hurray! :)
|__|__|
__I__I__I_________________< The Bat! 1.53d >_
|
|
| |
Hello Láng Attila D. and
Hello Kiss Attila Csongor,
This thread is not very frequented now.
May be because the debate has to become much more technical.
> What are you meaning by multiple syntax levels, Damien?
I mean if LMPL is not sufficient, we are in danger to either add more and
more syntax extensions or to add a whole additionnal new language. Also LMPL
should be structured enough so that textual programming and GUI
manipulations are equivalent. Work on one side should not scratch work on
the other side.
> Let me report that LMPL is almost ready. It is going to be published soon.
Good news. May be I will better know what I am talking about, when published.
> > Then, without doubts, there will be additionnal syntax for, say, minifig
> > scripting, minifig dialog, model scripting, collision detection and user
> > control by joystick and mouse.
>
> LMPL contains these in theory.
That is more than what I expected.
> > You should have only one specification language that encompasses all
> > present and future needs.
>
> Of course we should.
I am more and more excited.
> In fact, I don't feel it an important question that which syntax should
> developers develop.
Let's be clear. I will have to prove I provide more than a syntaxical
variation. Actually I have to open a whole new world of possibilities not
covered by LMPL. If I can not achieve that I will give up and help your
proposal by concentrating on details. For example I prefer
xmin/xmax/ymin/ymax rather then x/y/width/height because limits are better
to express constraints. Also xmin/xmax/ymin/ymax is the way a regular quad
is modelled in current LDraw format.
> In fact, we didn't want to use a language to specify LCD. We simply planned
> to collect data and put them in a database. Do you think we need a
> programming language even to develop LCD itself, without LMPL?
No, we need not.
> > May be I will use it to develop a concurrent LCD proposal.
>
> If so, I'll be curious for it, but the main question is that if they
> (people around) going to collect data about connectors and connections
> or not. When we published the LCD proposal, lugnet.cad.dev was happy
> seeing it, what was very nice to see. But all wonders endure three days,
> and enthusiasm in the group has been fallen down. I didn't hear about
> a single person who would undertake the task to take LDraw or even Lego
> parts one by one, measure distances and angles, and write results down.
> Therefore, we may develop lots of concurrent proposals for our desk. :(
I mean a LMPL proposal. I am sorry I will not help to collect connectors and
measure distances and angles. I do not prefer promoting my own project
rather than to contribute. I actually prefer to review parts as I already do
in the Parts Tracker. The reason why I do not is because LMPL should precede
LCD. Because innovative usages are in LMPL. And because LCD notation must
assist LMPL, not the reverse. In my opinion, collection parts info should be
the very last stage. LMPL should be mainly driven by playing practice, not
by parts geometry.
> But on the other hand: if your proposal pushes the wheel and makes people
> working on the idea, I will be the happiest. I absolutely don't mind
> whose proposal will be realized, the ours or a different one, if the
> result meets my dreams about playing with virtual Lego. I ain't from the
> jealous kind. :)
I think my LMPL approach is really different than yours.
My proposal will not be a collective work.
It will be highly monolithic and rebarbative, all but seductive.
So I can't be suspected to attract attention (there is so little).
I hope more people will help you.
Also programmers are not in a hurry to realize your dreams about playing
with virtual Lego. So we have much time to perfect the idea so it will be
LDraw future without impeding it in any way.
Here is my development strategy :
1. By starting from where LDraw format stops I am sure to really extend
LDraw coverage of lego bricks usage. So I start from part-groups and
rotation-points facilities as provided by MLCad.
2. I reconsider these facilities with more structured and more unified notation.
3. Using this new model notation, I extend models capabilities to add more
play-value. At this point a model provides full sub-model articulation. A
Car model can have opened/closed doors at will.
4. I refine the notation so play-value is the basis for more
play-opportunities. Basically, interface provided by models should be
revised to allow more model collaboration. At this point a model provides
basic knownledge of its usage. A Car model may have a Pilot minifig and it
must go at fuel station for reload.
5. I refine the notation so play-opportunities is the basis for more
game-value. Basically, interface provided by models should be more
extensible to facilitate model scripting. At this point a model provides
autonomy and complex interaction with environment. A Car model may be
computer controlled and go at fuel station for fuel reload. And its Pilot
may prefer his bike if trafic is too dense.
6. Anywhere in step 5 or 4, I may encounter excluding features. May be I can
not provide all features incrementally. Or may be the notation is not
suitable for simulation. Anyway, when I stop to go forward, then I go
backward. That means I reconsider low-level part specifications in the new
unified language. And I try to improve their contribution to above
high-level facilities. The difficulty here is to keep the part
specifications unified, while having different priorities for more TECHNIC
parts and more LEGO SYSTEM parts. The priority for TECHNIC parts is
connection and mobility by mechanism. The priority for LEGO SYSTEM parts is
positioning and playability for end user.
I am currently at stage 1 (nothing is done).
So my credibility is very low.
> LAD
Damien
http://brickcaster.multimania.com
|
|
| |
> Whe should not develop multiple syntax levels.
What are you meaning by multiple syntax levels, Damien?
> Then there will LMPL so we specify submodel movements.
Let me report that LMPL is almost ready. It is going to be published soon.
> Then, without doubts, there will be additionnal syntax for, say, minifig
> scripting, minifig dialog, model scripting, collision detection and user
> control by joystick and mouse.
LMPL contains these in theory.
> You should have only one specification language that encompasses all
> present and future needs.
Of course we should.
> Here is a simple Prolog-style function that tests the Stud-Inlet connectivity :
>
> Connect( Stud(x1,x2,y1,y2,z1), Inlet(x3,x4,y3,y4,z3) ) :=
> if z1 # z3 then False
> else if x1 >= x4 then False
> else if x2 <= x3 then False
> else if y1 >= y4 then False
> else if y2 <= y3 then False
> else True
Well, this seems to be usable. In fact, I don't feel it an important
question that which syntax should developers develop, if once they do.
Actually, I've used a BASIC-like syntax for LMPL, being tired enough
with the multi-structurated, hierarchically hierarchical programming
languages of our days. LMPL contains as much of structurality as needed
to keep things working, and nothing more. (No GOTO inside. :)
> Actually, using such a structured language, we can formally specify LCD.
In fact, we didn't want to use a language to specify LCD. We simply planned
to collect data and put them in a database. Do you think we need a
programming language even to develop LCD itself, without LMPL? If yes, why?
> May be I will use it to develop a concurrent LCD proposal.
If so, I'll be curious for it, but the main question is that if they
(people around) going to collect data about connectors and connections
or not. When we published the LCD proposal, lugnet.cad.dev was happy
seeing it, what was very nice to see. But all wonders endure three days,
and enthusiasm in the group has been fallen down. I didn't hear about
a single person who would undertake the task to take LDraw or even Lego
parts one by one, measure distances and angles, and write results down.
Therefore, we may develop lots of concurrent proposals for our desk. :(
But on the other hand: if your proposal pushes the wheel and makes people
working on the idea, I will be the happiest. I absolutely don't mind
whose proposal will be realized, the ours or a different one, if the
result meets my dreams about playing with virtual Lego. I ain't from the
jealous kind. :)
LAD
|
|
| |
I have read the article about LCD.
The primary usage of an LCad library is to provide many quality virtual parts.
So the future of LDraw library is more and better parts.
The primary usage of an LCad tool is to select and position virtual parts.
So the future of LDraw tools is faster and easier part selection and
positioning.
What is the current state of LDraw organization?
The current state is fairly simple: LDraw library is already far beyond
LDraw tools.
The new Parts Tracker delivers more and more action-oriented parts at a
nearly monthly rate.
We now have the trap door, the motorcycle, many decorated parts, many
minifigs, minifig accessories and weapons. And much more is coming soon
(including horse, monorail, bike and bicycle).
So we have, or will soon have, needed parts for comics and animation, for
interactivity and games.
With all these play-oriented parts we do not want to restrict creativity to
building instructions only, as is still the case today. LDraw will surely
parrallel the LEGO group evolution: more build-oriented at first and then
more play-oriented.
I have read the article about LCD.
Here is my main objection :
Whe should not develop multiple syntax levels.
There is already LDraw so we specify parts. There will be LCD so we specify
connections. Then there will LMPL so we specify submodel movements. Then,
without doubts, there will be additionnal syntax for, say, minifig
scripting, minifig dialog, model scripting, collision detection and user
control by joystick and mouse.
You should have only one specification language that encompasses all present
and future needs.
Also the specification should be the same for the datas (as LCD) and the
treatments (as LMPL).
LCD should not be scattered arbitrary syntax, but structured data that is
manipulable by user.
Instead of (3001 Brick 2 x 4 example in LCD draft document) :
Stud at x = 0, y = 0, z = 1; Size x = 2, y = 4
Inlet at x = 0, y = 0, z = 0; Size x = 2, y = 4
We should write :
Stud(-1,1,-2,2,1) // I use LDraw origin and the shape
Stud(xmin,xmax,ymin,ymax,z)
Inlet(-1,1,-2,2,0) // I use LDraw origin and the shape
Inlet(xmin,xmax,ymin,ymax,z)
Then, this structured data is easily manipulated.
Here is a simple Prolog-style function that tests the Stud-Inlet connectivity :
Connect( Stud(x1,x2,y1,y2,z1), Inlet(x3,x4,y3,y4,z3) ) :=
if z1 # z3 then False
else if x1 >= x4 then False
else if x2 <= x3 then False
else if y1 >= y4 then False
else if y2 <= y3 then False
else True
Actually, using such a structured language, we can formally specify LCD.
Which greatly helps understanding LCD purpose and implementation.
For illustration, the Clutch function filters a List of Studs using a single
Inlet.
The result List is the list of Studs that connect the Inlet.
// if the List of Studs is empty then result is an empty List
Clutch( inlet, List ) := List
// else the List of Studs contains one "stud" plus ".."
Clutch( inlet, List(stud,..) ) :=
let rest = Clutch( inlet, List(..) ) in
if Connect(stud, inlet) then Cons( stud, rest )
else rest
Some comments:
* the List elision is .. and represents all (0 or more) non-designated elements
* Cons is the standard function to extend a List at left
Cons( stud, List(..) ) := List(stud,..)
* the "let - in" line is just a local definition
The language has no other construct.
And yet it has unlimited specification power.
May be I will use it to develop a concurrent LCD proposal.
Damien
http://brickcaster.multimania.com
|
|
| |
In lugnet.cad.dev.lcd, Kiss Attila Csongor (KACS) writes:
>
>
> I don't know. If we call it to friction I agree with you.
> But I think there must be a rotation properti for the grey
> pin, and no rotation allowed to the black one (still connector).
> I think it would be the easiest way to handle the pins as connectors.
> And over the LCD the LMPL (as the higher layer) will give an addition
> properties to it (similarly to the object oriented programming).
> How about this?
I agree. Although I called it friction, I didn't mean the true physical
property. It seems to me that the difference between grey pins and black
pins is structural in nature: they are different connectors from a builder's
point of view. I think this difference belongs to the LCD level, because I
think it is a difference in the way things connect.
I am not convinced by the need for more than a simple on/off property. I
don't think I have ever seen a design which uses the black pin's ability to
rotate after construction, and I can't imagine using it myself. Of course,
if you want to check that your design is strong enough, you must model this,
but this surely does belong to the LMPL level, along with the tensile
strength of connections.
Barney.
|
|
| |
Earlier on Mon, 28 Jan 2002 23:28:01 GMT on lugnet.cad.dev
Ross Crawford<rcrawford@csi.com> wrote:
--------------------------------------------------------------------------------
RC> I can see one limitation - the fact that technic axles are actually
RC> significantly smaller than the holes in the bricks (round holes, not axle
RC> holes), and allow a fair amount of movement (sideways in hole, and even
RC> angular) when "connected". The idea of "drag" doesn't really account for this.
RC> Maybe a "allowed movement" and "default position"? That's starting to get a lot
RC> more complicated though. Maybe that'll just have to be modelled by switching
RC> off "LCD mode".
Yes, but is this a useful property or not in real LEGO? I think it
just let the axle rotate free and nothing more. Or am I wrong?
And if we see it on MLCad, we can't move the axle so fine like this
"fair amount of movement" since the minimum grid size is 1.
LAD> However, the whole question belongs to the LMPL side of the project, not to
LAD> LCD. In a mere LCD system with no LMPL implementation, there is nothing to
LAD> do with friction, since we can't move connections. Moving them belongs to
LAD> the LMPL side.
I don't know. If we call it to friction I agree with you.
But I think there must be a rotation properti for the grey
pin, and no rotation allowed to the black one (still connector).
I think it would be the easiest way to handle the pins as connectors.
And over the LCD the LMPL (as the higher layer) will give an addition
properties to it (similarly to the object oriented programming).
How about this?
--
___ Bye: KACS, The BrickaMocka
/___\__
|o o| E-mail: kacs69@freemail.hu
_\_~_/_ kacs@makacs.hu
/|LEGO |\ lcd@makacs.hu
//|_____|\\
C |==|==| C Brick, Brick Hurray! :)
|__|__|
__I__I__I_________________< The Bat! 1.53d >_
|
|
| |
I haven't commented substantially on LCD, so maybe I should.
I am contemplating an algorithm that will find all of the possible
stud-insertion points on a part. The obvious way to do this is to recognize
the tube or enclosing box with their well-understood properties. The more
fundamental thing is to discover an opening where a stud makes at least 3
points of contact. Of course this is only for a stud and tube coupling.
(Each tube probably has 1, 2 or 5 possibilities.)
Second, how is this information to be used by a modeling program. (Either it
is loaded from the part file, or generated in memory from the algorithm.)
The obvious approach is that the program stores knowledge of point and
approach vector for each connection point, and checks for approximate
matches between a moving part and nearby candidates.
To find nearby candidates, BrickDraw3D for example maintains a list of all
parts sorted by height. A range query returns all parts intersecting a
bounding box . For instance, the bounding box of a moving part, usually
excluding the part's studs, or a bounding box + 1 cell width.) (range query
is as described in Franco Preparata, _Computational Geometry_, 1987.
These are my thoughts on how to proceed:
For each closest pair of plane surfaces that are parallel, each pair of
connection points within the planes are checked for nearness. Visual
feedback will be provided as they become close. If the part is let go it can
be moved to the exact point of connection, this is usually called
snap-to-grid (but the connection point may not be a grid cell.)
It is possible that some connection points should be denied access. For
example when trying to plug a 1x2 brick stud into a tube of a 2x2 brick.
This can be checked for, Here, the 1x2 brick has unsatisfied connection
points (studs) which intersect the bounding box of the other brick, a clear
violation.
I apologize in advance for not using the proposed terminology for every concept.
-Erik
|
|
| |
In lugnet.cad.dev.lcd, Barney Hilken writes:
> I was thinking of friction as a simple on/off property: connections with
> friction only move during construction, whereas connections without are free
> to move under gravity or inertia or other forces during animation of the
> final model. Is this too simplistic?
I think it probably is. The situations I'm thinking about are:
1. axles in technic bricks, which fit your "no friction" model;
2. the light grey low-friction pins, which could also fit the "no friction"
model (with regard rotation);
3. the black friction pins, which can rotate in the final model, but with
significantly more friction than 1 or 2 (ie can resist gravity up to a point).
There are probably other cases too, but I think there'd need to be at least 3
levels of friction (low, medium, high) to cover the friction pins (with low &
high corresponding to your off & on settings).
The next tricky thing to model is rubber bands, then comes chains...
ROSCO
|
|
| |
In lugnet.cad.dev.lcd, Barney Hilken writes:
> I was thinking of friction as a simple on/off property: connections with
> friction only move during construction, whereas connections without are free
> to move under gravity or inertia or other forces during animation of the
> final model. Is this too simplistic?
I think it probably is. The situations I'm thinking about are:
1. axles in technic bricks, which fit your "no friction" model;
2. the light grey low-friction pins, which could also fit the "no friction"
model (with regard rotation);
3. the black friction pins, which can rotate in the final model, but with
significantly more friction than 1 or 2 (ie can resist gravity up to a point).
There are probably other cases too, but I think there'd need to be at least 3
levels of friction (low, medium, high) to cover the friction pins (with low &
high corresponding to your off & on settings).
The next tricky thing to model is rubber bands, then comes chains...
ROSCO
|
|
| |
> I was thinking of friction as a simple on/off property: connections with
> friction only move during construction, whereas connections without are free
> to move under gravity or inertia or other forces during animation of the
> final model. Is this too simplistic?
Welcome in my brain, Barney: I was writing about gravity and inertia in this
very hour. The approach you describe may be usable, but as for myself, I'm
talking in the LMPL proposal about a tensile strength instead. I see some
difference. Tensile strength may allow or disallow parts to disconnect (in a
crash, for example), but friction can take influence on the working of a
connection. The higher the friction, the greater the force needed to make it
moving. Therefore, I didn't make a link between friction and gravity or inertia.
However, the whole question belongs to the LMPL side of the project, not to
LCD. In a mere LCD system with no LMPL implementation, there is nothing to
do with friction, since we can't move connections. Moving them belongs to
the LMPL side.
LAD
|
|
| |
I was thinking of friction as a simple on/off property: connections with
friction only move during construction, whereas connections without are free
to move under gravity or inertia or other forces during animation of the
final model. Is this too simplistic?
Barney.
|
|
| |
> Please make this distinction before building up a large database!
For the time being, Barney, the problem is that if we will have a
database at all. Lugnet.CAD.Dev was very enthusiastic when we presented
the idea. All wonders endure three days, this was the very example,
after the three days came silence. KACS and me are unable to make the
whole work ourselves. Without helpers, the idea will fail.
As for the friction, you are right, we have to include a property to
cover it. This means no problem, since the LCD proposal clearly states
that there may be properties not mentioned there but be discovered
later. Friction will be such a property.
By the way, how to measure friction?
News: working on the LMPL proposal is almost done. In some days, we can
present it to you.
LAD
|
|
| |
Perhaps I should say that my interest in this is that I am involved in the
project on the next-door website to develop an LDraw program for MacOS X,
and I think connections should be built in from the start.
I had a look at the LCD page on the LDraw website and was struck by the fact
that, although there is a discussion of parts which move, there is no
distinction drawn between parts which move freely, and parts which move when
pushed hard. This difference is extremely important to Technical lego. For
example, there are two sorts of pin connection: the black ones twist when
pushed, and the grey ones twist freely. Similarly, most gears slide along
rods when pushed, but worm gears slide along freely.
Please make this distinction before building up a large database!
Barney.
|
|
| |
Hey everyone!
It was a lot of fun casually chatting about the needs and the potential of the
LCD. Now its time to get down in the dirt and see it become a reality. KACS
and LAD have put a TON of energy and effort into this, and it seems to be a
promising project for LDraw users. We had this group created because we wanted
discussion to remain focused and on track. However, the other new group, the
Mac guys, are beating this group by far in number of posts ;-)
So, developers, please, add your input, and lets realize the plan for LCD!
(Just doing my duty and trying to get things on track here, even though I'm a
non-developer in the software sense of the word).
Tim Courtney - tim@ldraw.org
http://www.ldraw.org - Centralized LDraw Resources
|
|
| |
> Whatever happens, I love this idea! I've been wishing for something
> like this since starting LDraw.
OK, ladies, gentlemen and minifigs, so everybody is agreeing it is a
good idea, what is more, it is already a group of good ideas, including
LCD itself (by the way, LCD could stand for Lugnet.Cad.Dev, too! :)
and the LMPL language, and so on. Now the question is: what to do now?
As for the development, I will undertake it; I will create the
scripting language being mentioned -- you will be able to read it as a
proposal. I will develop everything necessary, and what I can't develop,
will be developed by KACS, for example, the databases for sure, he is
the database expert, not me. But the main part of it is the actual work
of collecting data. Connections, connectors, parts, connections,
connectors, parts. Not owning any real Lego and not having much
experience with the virtual one, I'm not the very man to do this work.
Let me call you to contribute. Let's collect connections. The way to
do so is simple. Take two Lego parts connectable with each other, and
connect them. Take notes about the connection: the coordinates of an
important point, specified according the coordinate system used in dat
files; the way of movement possible in connected state, including angles
and distances; and additional comments, problems, questions to be solved
etc. And give it a name like Stud Inlet or Towball. KACS took the job of
collecting them and keeping them in a database. And the group can decide
what to do with the arising problems.
Thank you in advance and have a good work!
LAD
|
|
| |
Two new CAD (Computer Aided Design) software development newsgroups have just
been created for the discussion of new CAD software projects.
CHARTER/PURPOSE
===============
-> lugnet.cad.dev.lcd (group):
LDraw Connection Database forum: in-depth technical discussions,
software and parts architecture, interoperability, tools, parts
planning & tracking, standards, etc.
-> lugnet.cad.dev.mac (group):
CAD developers forum, specifically focused on development for Apple
Macintosh operating systems (MacOS 9, MacOS X, etc.)
TO SUBSCRIBE
============
To read via NNTP (netnews), point your newsreader here:
news://lugnet.com/lugnet.cad.dev.lcd
or news://lugnet.com:1119/lugnet.cad.dev.lcd
or news://lugnet.com:8000/lugnet.cad.dev.lcd
or news://lugnet.com:8080/lugnet.cad.dev.lcd
news://lugnet.com/lugnet.cad.dev.mac
or news://lugnet.com:1119/lugnet.cad.dev.mac
or news://lugnet.com:8000/lugnet.cad.dev.mac
or news://lugnet.com:8080/lugnet.cad.dev.mac
To read via HTTP (web interface), point your web browser here:
http://news.lugnet.com/cad/dev/lcd/
http://news.lugnet.com/cad/dev/mac/
To subscribe for SMTP delivery (e-mail), point your web browser here:
http://news.lugnet.com/news/mail/sub/?lugnet.cad.dev.lcd
http://news.lugnet.com/news/mail/sub/?lugnet.cad.dev.mac
or here:
http://news.lugnet.com/news/mail/
To register for posting to any LUGNET group (if you haven't yet done so),
point your web browser here:
http://news.lugnet.com/news/post/setup/
--Todd
|
|
| |
TERMS OF USE FOR LUGNET.COM
OVERVIEW AND DEFINITIONS
lugnet.com ("LUGNET") is a privately owned Internet site designed
and run primarily for the benefit of those who enjoy building with,
discussing, collecting, buying & selling, trading, and exchanging
information about LEGO® brand toys.
As a user of this site, you are expected to read, understand, and
abide by the Terms of Use as set forth herein. If a portion is
unclear to you, you should ask a parent or guardian to explain, or
write to terms@lugnet.com for clarification.
ACKNOWLEDGMENT AND ACCEPTANCE OF TERMS OF USE
By using LUGNET, you agree to the following:
1. You understand that LUGNET is an unofficial fan-created Internet
site which is not prepared, sponsored, authorized, or endorsed by
the LEGO Group of companies and that the Official LEGO World Wide
Web Site is located at www.lego.com.
2. Although this site normally operates 24 hours per day, 7 days per
week, you understand that this site may experience failures or
other service outages without notice.
3. Although best efforts are made to ensure that information found
at this site is up-to-date and accurate, you understand that
inaccuracies or omissions are possible and that this site is not
necessarily suitable to every purpose.
4. LUGNET and its owners and/or operators do not control or censor
content in discussion groups. The LUGNET discussion group server
is provided as a "store and forward" mechanism "as is" without
filters, which means that you may encounter material which you
find offensive. IT IS YOUR SOLE AND INDIVIDUAL RESPONSIBILITY
TO MONITOR OR FILTER CONTENT TO A LEVEL APPROPRIATE TO YOURSELF
AND/OR YOUR FAMILY. If you are under 18 years of age, ask your
parent(s) or guardian(s) for permission and/or supervision before
using this service and make sure they have read and understood
this Terms of Use document.
5. You will not hold LUGNET or its creators, owners, operators,
or related entities responsible or liable ("indemnify and hold
harmless") for the inability to connect to or use this site,
or for any lost or corrupted data, or for any defamatory or
offensive material(s) which you may encounter on or originating
from this site, or for the conduct, opinions, or publications
of any user, or for any other problem whatsoever relating to the
use or existence of this site.
6. You will not use this site for any illegal activities and you
will not attempt to gain unauthorized access to this site or to
other sites or systems through this site.
7. By posting messages, uploading files, inputting data, or engaging
in any other form of communication through this service, you are
granting LUGNET and its owners a perpetual, irrevocable, royalty-
free, unrestricted, non-exclusive, worldwide license to:
i. Use, copy, publish, sublicense, adapt, transmit, archive,
restore, publicly perform, or display any such communication
in any medium, and to
ii. Sublicense to third parties the unrestricted right to
exercise any or all of the foregoing rights granted with
respect to the communication.
8. You understand that LUGNET owners or operators are regular LEGO
fans just like you, and that when they post to discussion groups,
their opinions and comments are their own and do not necessarily
reflect the opinions or policies of LUGNET.
9. You understand that LUGNET and its owners and/or operators have
no obligation to acknowledge, mediate, or otherwise settle any
disputes or differences of opinion which may arise between users.
Although we hope that everyone can play well together, we must
reserve the right to allow or to refuse access to this site to
anyone, for any reason, with or without prior warning or explanation.
Additional terms and conditions appear below.
DISCUSSION GROUP TERMS AND CONDITIONS
LUGNET includes discussion groups which allow feedback and
interaction between users. LUGNET and its owners and/or operators
do not control or censor messages, information, or files delivered
to discussion groups. It is a condition of your use of the
discussion groups that you do not:
1. (do not) Restrict or inhibit any other user from using the
discussion groups.
2. (do not) Falsely present yourself as a representative, employee, or
official of a LEGO company or of LUGNET through the accidental or
deliberate use of trademarks or servicemarks in your identity or
through misleading or confusing statements in your postings.
3. (do not) Post anonymously or post any message in which the 'From:'
header is not an e-mail address under your control. (Spamblocks
are OK, however, so long as it is possible for a reasonably
intelligent human to reconstruct your e-mail address using clearly
documented instructions, which you must include in each such message.)
4. (do not) Post using a pseudonym, alias, screen-name, handle,
alter-ego, meno, or any other type of name which is not your own
or which hides your true identity, unless your real name and identity
is clearly understood, accepted, and documented by the community as
the true identity behind such messages.
5. (do not) Post or transmit any unlawful, threatening, abusive,
libelous, defamatory, obscene, vulgar, pornographic, profane, or
indecent information of any kind, including without limitation any
transmissions constituting or encouraging conduct that would
constitute a criminal offense, give rise to civil liability, or
otherwise violate any local, state, national, or international law.
6. (do not) Post or transmit any information, software, or other material
which violates or infringes upon the rights of others, including
material which is an invasion of privacy or publicity rights or
which is protected by copyright, trademark, or other proprietary
right, or derivative works with respect thereto, without first
obtaining permission from the owner or right holder.
7. (do not) Post or transmit any information, software or other material
which contains a virus or other harmful component.
8. (do not) Post non-plain-text content such as HTML, multi-part MIME
messages, or so-called "binaries" including but not limited to:
images, sounds, multimedia files, computer programs, and blocks
of text created using binary-to-text conversion utilities such
as BinHex, uuencode, btoa, and PGP message encryptions (short
PGP signatures, however, are permitted by the server).
9. (do not) Post information or material for commercial purposes which
is not reasonably related to LEGO toys or which contains advertising
which is not reasonably related to LEGO toys.
10. (do not) Post or re-post a message excessively, especially unsolicited
advertisements, even if they are directly or indirectly related
to LEGO toys.
11. (do not) Post auction announcements, updates, or listings in
discussion groups which do not explicitly welcome their presence.
[If you are unsure whether auction spam is appropriate in a given
discussion group, check the group's descriptive charter. If the
discussion group's charter does not explicitly say that auction
postings are allowed in the group, then such posts are not welcome.
Currently, the only LUGNET discussion group which allows auction
spam is lugnet.market.auction, which was established specifically
for auctions.
12. (do not) Stray hopelessly off-topic without moving the discussion
to a more appropriate location. (There is a fair amount of leeway
here, since it is natural for discussions to drift, and moving
a discussion can sometimes be inconvenient or difficult. If in
doubt, appeal to common sense.)
13. (do not) Cross-post excessively, since many newsreader software
programs do not handle cross-posted articles elegantly or
transparently.
LUGNET, its owners, and its operators have no obligation to monitor
the discussion groups. However, LUGNET and its owners and/or
operators reserve the right at all times to disclose any information
as necessary to satisfy any law, regulation, or governmental request,
or to edit, refuse to post, or to remove any information or
materials, in whole or in part, that in the sole discretion of LUGNET
and its owners and/or operators are in violation of these terms and
conditions or of applicable law.
If you choose to use any mark owned by the LEGO Group as part of your
identity, you do so at your own risk. LUGNET can neither advise you
nor protect you if you infringe on the rights of the LEGO Group.
However, there are some common-sense guidelines which you must follow
as additional conditions of your use of the LUGNET discussion groups:
14. If you use a LEGO mark as part of your identity, and you are not
an employee or representative of the LEGO Group, you must include
an appropriate disclaimer in each post you make, noting (a) that
you are not associated in any way with the LEGO Group and that
your posts are unofficial and do not represent the views,
opinions, or policies of the LEGO Group, and (b) that the mark
or marks you are using are owned by the LEGO Group.
15. If you are an employee or representative of the LEGO Group, and
you wish to post as such, you must clearly indicate your title,
position, or relationship with or within the LEGO Group. Your
employer may also require you to include a disclaimer protecting
them from your personal opinions.
16. If you are an employee or representative of the LEGO Group, but
you wish to post on your own behalf as an independent LEGO
enthusiast and not as an employee or representative, you are not
required by LUGNET to disclose your affiliation. However, your
employer may have its own ideas about your participation; if in
doubt, consult your employer for appropriate posting guidelines.
The foregoing is not legal advice, and LUGNET and its owners cannot
guarantee that it is a bullet-proof formula for avoiding the dilution
or infringement of marks owned by the LEGO Group or for circumventing
rules which your employer may impose upon you. Questions on the
nature of trademarks or servicemarks should be directed to a
qualified legal professional. If in doubt, it is probably wisest
simply to avoid the use of LEGO trademarks as part of your personal
identity.
DISCLAIMERS OF WARRANTIES
LUGNET and/or its owners, creators, operators, and/or related
entities make no representations about the suitability of the
information contained in the documents and related graphics
published at this site for any purpose. All such documents and
related graphics are provided "as is" without warranty of any kind.
LUGNET and its owners and/or operators hereby disclaim all
warranties and conditions with regard to this information, including
all implied warranties and conditions of merchantability, fitness
for a particular purpose, title, and non-infringement.
The documents and related graphics published on this site may
include technical inaccuracies, typographical errors, or omissions.
LUGNET and its owners and/or operators may make improvements,
changes, and/or additions to the information and/or services
described herein at any time without notice or explanation.
Links to third-party Internet sites will let you leave this Internet
site. The linked sites are not under the control of LUGNET and
LUGNET and its owners and/or operators are not responsible for the
contents of any linked site or any link contained in a linked site,
or any changes or updates to such sites. LUGNET is providing these
links to you only as a conveninece, and the inclusion of any link
does not imply endorsement by LUGNET or its owners of the site.
LUGNET and its owners and/or operators do not warrant or make any
representations regarding the use or results of use of the materials
in third-party sites in terms of their correctness, accuracy,
existence, timeliness, reliability, or otherwise.
LIMITATION OF LIABILITY
In no event shall LUGNET or its owners, operators, and/or related
entities be liable for any special, direct, indirect, consequential,
or punitive damages, or any damages whatsoever resulting from loss of
use, data, or profits, whether in an action of contract, negligence,
or other tortious action, arising out of or in connection with (a)
the use or performance of LUGNET, (b) the software, documents,
information, or services obtained through or from LUGNET, (c) the
failure to provide or delay in providing any software, document,
information, or service, or (d) the links to and/or contents of
third-party Internet sites.
Additionally, you specifically acknowledge and agree that LUGNET and
its owners, operators and/or related entities are not liable for any
defamatory, offensive, or illegal conduct of any user. If you are
dissatisfied with any LUGNET material, or with any of the terms and
conditions herein, your sole and exclusive remedy is to discontinue
using LUGNET.
TERMINATION
This agreement is effective until terminated by LUGNET or its owners
and/or operators, at any time without notice. In the event of
termination, you are no longer authorized to access the discussion
groups and the restrictions imposed upon you with respect to material
downloaded from the discussion groups, the disclaimers, and
limitations of liabilities set forth in this agreement, shall
survive.
SEVERABILITY
This agreement shall be governed by and construed in accordance with
the laws of the State of Massachusetts (U.S.A.) without giving effect
to any principles or conflicts of law. If any provision of this
agreement shall be unlawful, void or for any reason unenforceable,
then that provision shall be deemed severable from this agreement
and shall not affect the validity and enforceability of any remaining
provisions.
COPYRIGHT NOTICE
Except where otherwise noted or where implicitly understood (such
as discussion group content created by users or images owned by the
LEGO Group), all material on this site site is Copyright © by
Todd S. Lehman and Suzanne D. Rich, 243 White St., Belmont, MA 02478,
U.S.A. All rights reserved.
TRADEMARK NOTICES
LEGO® is a registered trademark of the LEGO Group of companies.
LUGNET, the LUGNET logo, Fibblesnork, and AucZILLA are trademarks of
Todd S. Lehman and Suzanne D. Rich.
Other product and company names mentioned on this site are trademarks
of their respective owners.
OTHER
Any rights not expressly granted herein are reserved.
Contact terms@lugnet.com with questions or problems, as appropriate.
________________________
Last Updated: 7 Mar 2000
|
|
| |
Welcome to lugnet.cad.dev.lcd, a LUGNET discussion group.
CHARTER/PURPOSE:
lugnet.cad.dev (group and hierarchy):
CAD developers forum: in-depth technical discussions, software
architecture, interoperability, tools, parts planning & tracking,
standards, etc. (Formerly the L-CAD mailing list)
lugnet.cad (group and hierarchy):
Discussions of CAD software/models/animations, LDraw, LDLITE,
LeoCAD, MLCad, L3G0, L2P, L3P, BlockCAD, etc.
OTHER GROUPS:
For complete information about this discussion group server, including
a full listing of discussion groups and their purposes, point your web
browser here: http://www.lugnet.com/news/
--
news@lugnet.com
|
|
|
