LDraw.org Discussion Forums

Full Version: LDraw - Part "Behaviour" Descriptions and Conditions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Looking around the forum at other posts and threads discussing improvements to the LDraw file standards etc made me start thinking about individual part behaviours.

Some of these have been discussed and even implemented already but I wonder if they could be grouped and streamlined somehow?

Each part clearly has its "Physical" characteristics. (sorry if i use the incorrect modelling vocabulary)

1. Physical Part - including 
     1a. - Complete Frame
     1b. - Primitives
     1c. - Texture
     1d. - Color
     1e. - Pattern

After hitting some modelling limitations across various platforms, I'm imagining a file standard that could natively describe the various "behaviour" characteristics of each part. Some behaviours are already handled through different methods whilst others seem to be undefined yet.

2. Part Behaviours - including
     2a. - Connectivity (Snapping)
     2b. - Hinge Points (Hinge points, rotation angles, etc)
     2c. - Length (Parts clearly fixed in length, though would allow application to string lengths, pipe lengths, and rubber band type applications. Could this be applied to ideas of elasticity by using open limits for strings etc but defined limits for compression and elasticity?)
     2d. - Flexibility (already being progressively applied to various parts across platforms.)
     2e. - Gravity (to describe how a part behaves with gravity, ie chains and loose string)
     2f. - Elasticity (not sure if this is the best word but the intent to describe a parts ability to stretch (+) or hold tension (-). Intended for use with technic rubber bands etc)
     2g. - Compression (used to  describe the parts ability to compress, imagined for springs in shock absorbers in this instance, could be merged with Elasticity as a negative value.)

Just thoughts.
Cheers
Adam
I would second that. For starters, I could use command lines for:
- Snapping Anchors, e.g the bottom coordinates of a stud, this would help in positioning other elements
- Pivot Axis, this would make automatic calculation of movements possible

Maybe it is time for LDraw 2.0 specifications. Could even be marked in the file headers as a meta command.
(2019-11-06, 20:28)AdamM Wrote: [ -> ]2. Part Behaviours - including
     2a. - Connectivity (Snapping)
     2b. - Hinge Points (Hinge points, rotation angles, etc)
     2c. - Length (Parts clearly fixed in length, though would allow application to string lengths, pipe lengths, and rubber band type applications. Could this be applied to ideas of elasticity by using open limits for strings etc but defined limits for compression and elasticity?)
     2d. - Flexibility (already being progressively applied to various parts across platforms.)
     2e. - Gravity (to describe how a part behaves with gravity, ie chains and loose string)
     2f. - Elasticity (not sure if this is the best word but the intent to describe a parts ability to stretch (+) or hold tension (-). Intended for use with technic rubber bands etc)
     2g. - Compression (used to  describe the parts ability to compress, imagined for springs in shock absorbers in this instance, could be merged with Elasticity as a negative value.)
I can conceive another broad category, which is Friction. This would have two aspects, each having at least three possible values:
  • Rotational friction – whether and how freely a part can rotate with respect to another part
  1. Fixed: the part does not rotate with respect to another part
  2. Firm: the part holds its position when at rest, but can be rotated with the application of a small force (such as a Technic pin with friction ridges, or a 1x1 brick attached to a single stud)
  3. Free: the part can rotate freely within a bearing (such as a wheel or Technic axle, or a pin without friction ridges)
  • Static friction, or clutch – whether and how firmly a part is held to another by mechanical forces
  1. Fixed: the part is held fast to another part, or if it is detached, it amounts to disassembly of the model (this describes the typical connections made with studs or other methods such as hinge assemblies, etc.)
  2. Firm: the part is held to another part, but can be separated as part of the model's functionality (for example, a detachable roof held in place by a stud at each corner, or the partial clutch of the studs on a hinge plate assembly)
  3. Free: the part is not held fast to another part (a vehicle placed on a road baseplate, or a minifig seated on a tile bench, for example)
There are a few ways this concept might be expanded. For instance, the "fixed" category could be split to include parts which are physically detachable but always attached when part of a model (i.e., regular bricks), and those which are never intended to be disassembled (like the individual components of a boat hull or a motor housing). Or, for rotational friction, the "firm" category could distinguish between parts which can physically rotate but are not intended to in the finished model (like an antenna or flagpole attached to a single stud) and those that are designed to be posable (like minifig parts).

There could also be a third aspect of friction, namely lateral friction, again with three possible values: fixed (studded parts), firm (gears and bushings on an axle) and free (tiled parts sliding between each other). This concept is already part of the snapping protocol for certain types of part.


Aside from the idea of friction, a couple of other thoughts…

Gravity could (or perhaps would, necessarily) also be a global characteristic of the model, and could be used, for example, to determine the resting position of loose parts—say a bunch of tools or bricks dumped into the back of a truck—that currently depend on complex, multi-axis rotations to realistically depict. This would have to be combined with the general concept of simple mass—meaning, simply, that two pieces of plastic, when pushed up against each other, cannot physically be moved any farther. (Although I think some applications have such a concept for collision detection, I'm a bit surprised that this fundamental property is largely absent from the modeling environment.)

Also, more generally, is there any real discussion of implementing a next-level LDraw standard, or are we just tossing around ideas here? I do think having an understanding of part behaviors built into the system would be useful, and a necessity for as-yet wishful ideas like true kinetics that might one day exist. (Imagine being able to build an engine or steering system and LDraw being natively able to animate all its moving parts!)