Ciao Roland and Ben.
I 'm wonder if embedding connection information in .dat is the best strategy.
As I say in other message, there are at least three class of information related to connections:
- snapping/joint information (connection points, orientation, ...)
- geometric/structural (bounding boxes, collision volumes, degree of freedom, ...)
- physical and mechanical (weight, frictions, rigidity, center of mass, ...)
My model cover only first class and, with some assumptions, can help to define degree of freedom. Trying to extend it to cover mechanical and physical property is anything but trivial (... and far, far beyond my programming/math/physics skills
).
Some examples:
- a "click-hinge": it is relatively easy to define a connection that accepts only multiples of 22.5 degree (it is a prismatic connection), but to limit angle excursion (normally 180 degree, but without any other part interferes in rotation), define the weight that a hinge can support before slide down, requires lot more data and math.
- a gearbox, or a group of gears: my model can help on how to connect gears and align teeth, but to define how rotation, speed and torque is transferred require lot more information. And... what if you place three gears in triangle?
Adding all these information to a .dat can easily result in a file size explosion. Take a plain 2x4 brick: it has 19 connection points (8 studs, 11 underside stud receiver, counting three tube center), that requires (with my present connection model) 38 coordinates as x,y,z floats, 19 "type" definitions: if "type" can be represented as a single integer, we have a total of 114 floats and 19 integers.
If someone isn't interested in connectivity, including it in .dat lead to more complexity in parsing and greater library size.
If you include other mechanical and physical data, it could be worse, it could be rain!
Not counting a lot of work needed to maintain library as a whole. Keep data in different places can helps to distribute the work and effort needed. File format can be same of .dat. I chose XML for my personal preferences and the universality of use in Java classes and libraries, but I can do a converter to transform in any other choice format.
Mario
I 'm wonder if embedding connection information in .dat is the best strategy.
As I say in other message, there are at least three class of information related to connections:
- snapping/joint information (connection points, orientation, ...)
- geometric/structural (bounding boxes, collision volumes, degree of freedom, ...)
- physical and mechanical (weight, frictions, rigidity, center of mass, ...)
My model cover only first class and, with some assumptions, can help to define degree of freedom. Trying to extend it to cover mechanical and physical property is anything but trivial (... and far, far beyond my programming/math/physics skills
).Some examples:
- a "click-hinge": it is relatively easy to define a connection that accepts only multiples of 22.5 degree (it is a prismatic connection), but to limit angle excursion (normally 180 degree, but without any other part interferes in rotation), define the weight that a hinge can support before slide down, requires lot more data and math.
- a gearbox, or a group of gears: my model can help on how to connect gears and align teeth, but to define how rotation, speed and torque is transferred require lot more information. And... what if you place three gears in triangle?
Adding all these information to a .dat can easily result in a file size explosion. Take a plain 2x4 brick: it has 19 connection points (8 studs, 11 underside stud receiver, counting three tube center), that requires (with my present connection model) 38 coordinates as x,y,z floats, 19 "type" definitions: if "type" can be represented as a single integer, we have a total of 114 floats and 19 integers.
If someone isn't interested in connectivity, including it in .dat lead to more complexity in parsing and greater library size.
If you include other mechanical and physical data, it could be worse, it could be rain!
Not counting a lot of work needed to maintain library as a whole. Keep data in different places can helps to distribute the work and effort needed. File format can be same of .dat. I chose XML for my personal preferences and the universality of use in Java classes and libraries, but I can do a converter to transform in any other choice format.
Mario