Skip to content
Search the Knowledge Base
< All Topics

Load Class

Default Xcelgo Logo Box as it is viewed in Experior.
Load type "Default" representing an xcelgo logo box (1m, 1m, 1m)
Loads in Experior means models that represent items to be transported by material handling equipment such as conveyors, lifts or cranes. The Load Models Overview article presents a gallery view of the implemented Load types in Experior, showcasing items such as pallets, packages, cans, suitcases, bags and more.
 
The Load class takes care of definitions for both the Physics Engine and Discrete Events Engine, where there are important differences to take note of. In Physics mode, a Load is considered a dynamic object (Kinematic = false). This implies that the Load’s position and orientation is determined by the underlying NVIDIA PhysX engine, which experior’s physics engine is built on. The PhysX engine applies forces/torques on the Load to achieve positioning/rotation/orientations.
 
In Discrete Events Mode, the physics engine is not used (Kinematic = true). Here it is instead important to note that, unless a given Load is made undeletable, the Load will always be on a Route or an Action Point. When a Load is no longer on either of these, it is deleted from the environment by the underlying engine. In Discrete Events mode, Loads are not saved when an Experior Model is saved either, which they are in physics mode.
 
Built in Load types in Experior are implemented by a Load type class that inherits from Dynamic, which defines the physics actor implemented by a given Load type. Some of the physics related concepts implemented in Dynamic are also defined in the Load class, hence why their documentation will overlap.

Concepts Implemented in the Load Class

A comprehensively detailed view of available methods and properties implemented can be found in the API Load Class documentation.

Generally Shared Implementation

Concepts that apply to all Loads, regardless of engine Experior is running in.
  • Load Identification – Such as “Barcode” strings.
  • Transformations
    • Positioning (x = Length, y = Height, z = Width)
    • Orientation
    • Rotation (Yaw, Pitch, Roll)
  • Load Coloring
    • For selected/unselected state and highlighting when an action point is reached for instance.
  • Selectable – Whether the Load is selectable by mouseclicks.
  • Deletable
  • Disposal Handling
  • Visibility
  • Grouping
    • Defines whether a given Load is part of a group of Loads.
    • Note: In Discrete Events mode, grouping/ungrouping Loads happen instantaneously, whereas the Physics engine requires finishing its current cycle of applying forces to Loads before grouping/ungrouping can occur.
  • Attachment
    • Whether the Load is attached to another RigidPart and therefore follows that RigidPart’s movement.
  • Report
    • Boolean to decide if the Load should be counted in the Statistics counter/window in Experior.
  • Parenting
    • Takes care of correctly setting parent/child hierarchies when multiple Loads are part of a grouping or attached to other RigidParts.
  • User Data
    • Users can add customized data to a Load, which for instance could represent data from a WMS such as PurchaseOrder, Customer Source, Destination, DueDate..etc. and attach it to the Load.
  • Mouse/Keyboard
    • Interaction methods open for extension
    • Keyboard: KeyUp() and KeyDown() methods.
    • Mouse: DoubleClick() method.
  • Kinematic
    • A Kinematic = true actor will act as if it has infinite mass, which means it can push regular non-kinematic dynamic actors away, but cannot be pushed back itself. Secondly, if movement is intended for the Part, the programmer must define the actor’s movement each time step, which can be useful if it is desirable that the object should follow a specific pre-defined path. 
      • (Physics) Kinematic = false.
      • (Discrete Events) Kinematic = true. 
Physics Related Implementation
  • Friction coefficient – sets friction force of a Load, defining how easily it “glides” across a surface.
  • Rigid – Matters in defining how the actor behaves when collisions occur. Also defines how precise the collision should be (as in how closely collision detection point matches point on the mesh) – this is also a question of performance, where rigid body shape complexity increases performance cost.
    • Rigid body shape – has the following options:
      • None
      • Box (Default)
      • Rounded
      • Dice
      • Sphere
      • Convex
  • Linear/Angular Dampening
  • Linear/Angular Velocity
  • Center of Mass Position
    • When the physics engine applies a force to a Load to make it move, the force is applied into its center of mass. By default, a Load’s density is equally distributed over the whole volume of the Load and hence the center of mass of the Load is also its geometrical center. By providing the CenterOfMassOffsetLocalPosition, it is possible to move this center of mass and potentially place the center of mass lower than the geometrical center to, decrease the collapsing of a Load.
    • Note: The value provided to this property is an absolute value. The CenterOfMassOffsetLocalPosition property provided in the property window of a feeder is a normalised value, where 0:0:0 is center of the Load and 0:1:0 would be at the top-center position. 
  • Collision Detection (true/false)
    • Default: true
  • Density – used in calculating Load’s weight, which in Experior is Density * Volume.
  • AddForce()/AddTorque()
  • Sleep/Wake – Physics concept of enable/disable. Setting a Load as “Sleeping”, means it will no longer responds to physical forces applied to it, until it is enabled/woken up again.
Discrete Events Related Implementation
Loads move through an Experior model differently in Discrete Events mode compared to Physics, as described in the articles regarding differences between discrete events and physics and Action Points. The Load class contains implementations for handling moving Loads to another Action Point or Route, defining what should happen in the event of a Load reaching an Action Point, advancing simulated time and returning information regarding the events that occur for the Loads such as total distance traveled.
 
Examples of concepts implemented:
  • Stopping/Releasing Loads on Action Points, meaning stopping and moving Loads when its a given Load’s time to step forward in time.
  • Moving Loads directly to a specified Action Point
  • Switching Loads to another Route or Action point with a variety of overloaded methods that handle different parameters, such as distance from start of the route, rotation and more.
  • Distance (or “space”) a given load occupies on a route
  • Getting the next event time, used by the Discrete Events engine to correctly determine the order in which to process the incoming events.