JBrickBuilder connection model

Re: JBrickBuilder connection model
Roland Melkert Wrote:It's needed with things like the axlehole primitive if you keep track of 'slide' limits. The primitive it self is open ended but it might be used in e.g. a motor drive axle which is not (e.g. 71427c01).

Right - there's a modeling-level version of this if a user puts two poles (or other "inner" slider) mechanisms end to end and they don't come with stops...do they form one -big- slider?

The least insane thing I can think of is:
- The sliders should be marked as -not- being "stopped" on the end.
- Apps that have full physics won't limit movement - if you move a part up, it slides off of one pole and onto another.
- Apps that don't have full physics could still do a "merge" phase where they take all known connections in a rigid body and consolidate. Two end-to-end sliders become one big slider.*

Such mechanisms would work with axle primitives that represent segments of an axle.

But I can see a pretty valid counter-argument that this is crazy and a single connector should be annotated on the length of the axle.


* I am seriously considering this for Bricksmith - the idea is that given a set of joints connecting two bodies, we can run a 'reduce' operation where degrees of freedom are in conflict. So for example, a series of colinear ball joints become a single hinge, or a pair of parallel hinge-sliders lose their hinge action.

My hope would be that a lot of the times the number of degrees of freedom of a set of joints drops to zero (e.g. it's a rigid model, e.g. made of things like clips and bars) and I can simply merge the rigid bodies, resulting in fewer "live" joints.
Re: JBrickBuilder connection model
No, I've started nothing yet, you can proceed if you feel like so Wink
Re: JBrickBuilder connection model
I fully agree with you that the library should be fixed.

The thread for collecting primitives abuse is there now:
« Next Oldest | Next Newest »

Forum Jump:

Users browsing this thread: 1 Guest(s)