 | | | | | | |
| |
|
> > 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.
| | | | | | | | | | | | | | | |
| |
|
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:
> 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
| | | | | | | | | | | | | | | | | | |
| |
|
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.
| | | | | | | | | | | | | | | | |
I should point out that priority and override are features of GLIDE and are not
explicitly specified in the format.
| | | | | | |
