Connectivity Part 50: Travel Limits

Re: Connectivity Part 50: Travel Limits
Roland Melkert Wrote:Yes but that information is at the combined level of those two sub parts, it's basically specific joint info.

How would you go define limits in the two loose parts? Like I wrote "those local limits are usually non existent as they would be completely depended on (very detailed) bounding box information."

Or do you want to include joint info by setting up a table instead of adding info at the .dat level?

The short answer is, I don't know yet. :-( Here's the total set of ideas, none of which strike me as clear winners:

1. Punt and don't have connection limits. Programs can add collision data to determine limits. This is simple to implement but makes connectivity less useful and makes it a lot harder to limit joint motion (since you have to have collision data and a collision engine just to know that the 1x4 hinge has a stopping point).

2. Giant global table with a pair of parts, some specification of the connections involved, and the limits. This is flexible, but for parts with a lot of connections, specifying -which- connections- are involved might get messy. Consider the simple case of a door frame with a door snapped into it - the door's travel limits are quite different depending on which side of the frame it is snapped into. :-( Having to have a way to "globally address" which connector we are talking about adds complexity to connection specs.

3. Define a range limit on one connector from a connector pair. This works only in the case where the connection's limits are universal - e.g. it's easy for the 1x4 hinge brick (there's only one thing you can connect with that hinge in the real world and its limits are consistent) but works quite badly for, say, a locking hinge (where having the hinge on a tile or plate makes a big difference in range of motion).

4. Defining a range limit on the part level. This has all of the weaknesses of proposal 2 -and- proposal 3! :-(

Quick aside: for -rotational limits- I'm stuck with the above limits. For -translational- limits, I think there's a pretty easy trick: define the translation limit based on the length of the translation connector. This is sort of like (3) except less likely to get us in trouble.

I suppose you could argue that (3) should only be used for rotation when the rotation limit is _part of_ the hinge itself and not the result of some -other- part of the brick crashing into something else.

Similarly, if two parts can translate over a given distance (based on the actual joint) but some other area of a large, complex part has a collision, it would be up to AABB to capture that.

I think when it comes to (3), I am not sure how much value capturing hinge rotation limits is when we only capture the case where the hinge is -guaranteed- to be fear is that the answer is "not much value here".

(I think capturing the 'grid snapping' of hinges is easier and probably pretty useful.)

« Next Oldest | Next Newest »

Messages In This Thread
Re: Connectivity Part 50: Travel Limits - by Ben Supnik - 2015-02-08, 21:47

Forum Jump:

Users browsing this thread: 1 Guest(s)