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