To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cadOpen lugnet.cad in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / 11842
11841  |  11843
Subject: 
Re: on Collision, stop Movement
Newsgroups: 
lugnet.cad
Date: 
Sun, 22 Aug 2004 19:35:20 GMT
Viewed: 
1295 times
  
Purple Dave wrote:

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.

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 connections from parts. This should be
faster and more accurate than assigning the connectable positions by
hand like LCD. Special cases may be added in a file. The only problem is
to think up a smart algoritm to do it :).
I don't think there is a need for very accurate collision detection. A
stick-to-grid interface may do the trick where a grid is made of
positions that are connectable. That way you can add parts to possible
spots in a model. A model should know know which positions are
connectable. Perhaps this can be programmed like the DOM for XML.

Martijn Zwaal



Message has 1 Reply:
  Re: on Collision, stop Movement
 
(...) That assumes that you have primitives made for both the male and female connector, which I very much doubt is always the case. Studs are pretty much always going to be one of two types (solid or hollow, though many of the BIONICLE masks use (...) (20 years ago, 22-Aug-04, to lugnet.cad)

Message is in Reply To:
  Re: on Collision, stop Movement
 
(...) 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 (...) (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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR