Mario Pascucci Wrote:Actually, I use an hybrid method:
- a Technic pinhole has two connection point (one per side) of type "PEGHOLE". This connector is directly coupled with a connector type "PIN" (there is a function called "opposite()" that gives the coupled connection type), but in program logic it accepts "STUD" and "AXLE" type connection if no direct coupling is available.
- Other connection with special handling are: AXLE (can connect with AXLEHOLE and PEGHOLE); STUD (can connect to R_STUD, a tube, or PEGHOLE); BAR (can connect with CLIP or AXLEHOLE). Of course, vice-versa is provided: PEGHOLE in STUD, AXLEHOLE in BAR and PEGHOLE in AXLE.
I understand. One of my design goals for Bricksmith is to avoid having any knowledge of the -actual- connection types in the actual implementation; I only want to code their 'classes' (e.g. rail, vector, point). That way we won't need code mods and a new app to extend the connectivity data.
Quote:Constraints rules are partially leaved to the user: not having collision volumes it is really hard to detect wrong connections.
I think LDD uses more and more sophisticated model. But I must take account of Java speed limits, and accept less complex models and methods.
Right - from what I can tell, LDD has bounding boxes, connections, constraints, and some kind of solver that can try to figure out the affect on an entire model of 'pulling' on one of the hinges. The solver appears to simultaneously be very sophisticated and sometimes a bit stupid:
- If the model is complex, pulling on it can result in unusual motions, not what you'd expect from the physical model. I can't fault them; they probably don't have enough "physics" data to model the real model without a much more detailed set of annotations.
- Sometimes the solver gets stumped. The Ultra Agents HQ truck's hinges are a series of ball joints with friction; because the ball joints are all along the same axis, their three degrees of rotational freedom degenerate into a single hinge. The solver can't figure that out and decides the hinges are "stuck".
For what it's worth, even without bounding boxes, there are some useful modeling operations you can do only with constraints and connectivity, e.g. rotate a series of locked-together parts around a common hinge. One of my motivations for adding connectivity to Bricksmith is that it's really hard in Bricksmith to model shapes that work at angles off of a 90 degree grid.
So for example, if a radar dish is tilted 37 degrees by a 1x2 hinge, I want to be able to build the part "upright" and then simply pick the hinge and tip the whole thing over; with connectivity and constraints Bricksmith can figure out who rotates (all of the 0-DOF connections above the hinge form a rigid body) and how to rotate (around the hinge axis). Right now i have to make the selection by hand and enter the rotation numerically...very slow.
This 'constraints for editing' can be done even without bounding boxes and collision; in such a system i'm on my honor to not over-rotate the hinge past its natural limit. But I'm happy to do that and have the app take over the tedious data of selecting complete rigid bodies and finding out what they rotate around.
Quote:I'm thinking on two optimization: spatial sorting (connection point ordered by X, Y and Z) and remove used (coupled) connection, but no code yet.
For spatial sorting, I suggest my favorite pet spatial index: the R-Tree. :-)
http://en.wikipedia.org/wiki/R-tree
I use it in Bricksmith to index the vertices of a part before smoothing; this lets me find common edges very rapidly. It works in 3-d, it's good for point hit tests, nearest-entity-within-X queries, and (most importantly) finding all entities within a range.
cheers
Ben