Subject:
|
Re: on Collision, stop Movement
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Mon, 16 Aug 2004 14:00:51 GMT
|
Viewed:
|
1153 times
|
| |
|
|
In lugnet.cad, Travis Cobbs wrote:
> Having said that, I totally agree that a comprehensive LCD would be an
> enormous undertaking. That said, a much less comprehensive LCD would still
> be extremely useful. After all, a vast majority of LEGO modeling uses the
> standard connection mechanisms. Additionally, LCD updates could be done in
> a similar way to the current part updates, which would allow a large number
> of people to contribute, improving the database as time went on.
I hope so. Many of the parts that most need this system to be implemented are
probably going to be the most difficuult to implement and the least likely to be
included in an initial release. Basic stud connections would benefit from
clickability, but MLcad, at least (haven't tried any other interface) is
tailored to make standard brick connections very simple. TECHNIC parts, on the
other hand, require a lot more futzing, but are doable. Ball joints...well,
let's just say that I'm never really sure when I've correctly located a given
piece or not. Minifigs look like they'll be the biggest improvement in any
initial release (I'm not fond of adding minifigs to vehicles on the basis that
every time I add one that's not posed quite right, there's no easy way to adjust
the pose without creating a new minifig from scratch).
> It sounds to me like you're still talking about creating a database based on
> knowledge of the elements. After all, how do you define "center geometry"
> for a stud going into a round hole (say in the bottom of a 2x4 brick) unless
> you know that both the stud and the hole are round and have specific radii.
> The actual triangles in the LDraw model certainly won't tell you that. So I
> stand by my contention that doing collision detection purely on the geometry
> in the files isn't going to work.
I was thinking along the lines of providing a tolerance range, and allowing a
part to exceed the dimensions by +X as long as they also exceed in the other
direction by -X, which should work fine for attaching a 1x1 brick to another 1x1
brick at any rotational angle (though I guess it would fall apart the instant
you tried to connect it to a corner of a larger brick, where it bumps two
adjacent walls and a non-matching tube in the other corner). That is, in my
mind, effectively the same as telling the system to calculate the mathematical
center of a stud and a stud-recepticle on the fly, and then match them up. From
the second link you posted, it looks like they're trying to avoid assigning any
LCD data to the stud primitive itself, and instead go strictly based on
pre-determined part geometry, which is not at all the same thing. I suspect
that method will be harder to set up, but should require less computational
resources in the long run.
|
|
Message has 1 Reply:
 | | Re: on Collision, stop Movement
|
| (...) I am a programmer with an interest in implementing something like clickablibity. I think te best way to do it is to assign connecection rules to primitives or combinations of primitives. That way you may be able to derive most possible (...) (20 years ago, 22-Aug-04, to lugnet.cad)
|
Message is in Reply To:
| | Re: on Collision, stop Movement
|
| (...) I personally have pretty much kept out of the LCD discussions, and to be honest, I'm pretty sure that all the work that has been done so far on the spec hasn't been done by programmers interested in actually implementing the functionality. (...) (20 years ago, 16-Aug-04, to lugnet.cad)
|
23 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
|
|
|
|
