 | | | | | |
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.
| | | | | | | | | | | | | | |
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
| | | | | | | | | | | | | | | | | | |
| |
|
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 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
| | | | | | | | | | | | | | | | | | | | | | | | | | |
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 : (
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> > 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.
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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.
| | | | | | | | | | | | | | | | | | | |
| |
|
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, 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.
| | | | | | |
