Subject:
|
Re: Re[2]: I have read the article about LCD
|
Newsgroups:
|
lugnet.cad.dev.lcd
|
Date:
|
Tue, 26 Feb 2002 19:27:30 GMT
|
Viewed:
|
3100 times
|
| |
|
|
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
|
|
Message has 1 Reply:
 | | Re[4]: I have read the article about LCD
|
| 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 (...) (23 years ago, 27-Feb-02, to lugnet.cad.dev.lcd)
|
Message is in Reply To:
| | Re[2]: I have read the article about LCD
|
| 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 (...) (23 years ago, 26-Feb-02, to lugnet.cad.dev.lcd)
|
6 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
