Platform Concepts
The purpose of this section is to provide an overview of the concepts managed by the ByMe platform.
π Most of these concepts map directly to API objects, except for those followed by an asterisk*.
Core Platform Conceptsβ
Below is the list of the core platform concepts.
Applicationβ
An Application is a 3D Experience dedicated to a business process. For example, the Kitchen Planner, the Home Planner, the AR mobile app are applications. An Application is provided as a software component hosted by the ByMe Platform.
Each application has a unique ID which often has to be provided in web-services to target specific applications. Here is a list of the currently supported applications:
| Application ID | Application name |
|---|---|
| 1 | Home Retailers |
| 2 | Kitchen Retailers |
| 3 | Assembly Editors |
| 4 | Workplace 3D |
| 5 | Product Viewer |
| 6 | Kitchen Template Editor |
| 7 | Bathroom Retailers |
Note: some applications may not be available depending on your environment.
Projectβ
A Project is created and owned by a User.
When launching an Application, the User first designs or imports a floorplan and then, places configured Products (manually or through automated suggestions) on the floorplan.
The Project is the combination of the floorplan and these positioned, configured Products; it can be saved for future re-opening and further modification. It can be duplicated and reopened seconds or years after its creation.
Range*β
Does not map directly to API object
The Range is the digital representation of the Brand's catalog of products: the products, their 2D/3D representation, description, price, behavior, leveraging the concepts below. The Range products are linked to Legal Entities, Brands, and Catalogs.
The Range is made of product assets and information. These are pushed into the Platform by:
- Manual input by Range Managers using the ByMe platform tools;
- And/or automated pipeline retrieving data from enterprise information systems directly connected to the Platform through its API.
Legal Entityβ
A Legal Entity represents a company publishing its Range on the Platform. Legal Entities are managed by 3DVIA, including the delivery of dedicated API keys. The Range associated to a Legal Entity is managed by members of the Legal Entity. This Range is then exposed to end-users through the ByMe Applications.
Application Distributionβ
An Application Distribution is the way the Platform presents an Application to the Users in a way that is specific to the needs of a Legal Entity.
An Application Distribution is a configured instance of an Application:
- Configuring an Application Distribution is done by setting parameters that define language, branding, currencies, rules, parameters and assets needed by the Application;
- The Range selection of an Application Distribution is a set of Catalogs.
A Legal Entity can expose several Application Distributions of one or several Applications. An Application Distribution is delivered through an URL accessible by the User.
Userβ
The ByMe platform serves 2 categories of Users:
- The end-users who use the Applications: Customers, contractors, salespersons;
- The users who create the Range and run the platform for a Legal Entity: typically, Range Managers and Administrators.
User profiles are either resident in the platform, or externalized. If externalized, the ByMe platform only hosts an ID and the remainder of the profile information is typically stored in a CRM. Users create and own Projects. They can be linked to a Legal Entity for administration purposes.
Core Range Concepts - Mandatoryβ
Below is the list of range modelling fundamentals.
Productβ
A Product is a virtual representation of a real product (such as furniture, construction elements, coverings) presented in an Application as a sellable product or as a context element (e.g. a kitchen planner including window products and flowers).
See Product and Assembly Reference π
The Platform manages the following Product attributes:
- Brand
- Reference number
- Name
- A description in various languages
- 2D pictures,
- Representation (either a 3DModel, an Assembly, or a Material).
- Prices
- Availability dates
- Parameters
Some attributes are mandatory, depending on product usage scenarios in Applications. Products of a Legal Entity can be grouped in Catalogs. A same Product can belong to several Catalogs.
Making a Product visible requires that the product is linked to a Catalog itself linked to the targeted ApplicationDistribution, and that its availability date is current.
Products are used to define simple objects but also objects combining many components (see the Assembly documentation). Products configuration variability is managed through Parameters. Product have applicative behaviors, some of which have to be specified such as the insertion of an altitude or kinematics.
Material [Depreciated]β
A Material is a specific type of Product representing sellable coverings (wallpaper, floor tiling etc.), whose representation is a BM3Mat asset (and not a 3D Model).
Catalogβ
Products, Materials and Product Rules can be grouped in Product Catalogs; Templates in Template Catalogs; Applicative Rules in Applicative Rules Catalogs. Each item can belong to one or several Catalogs. An Application Distribution shows none, one or several Catalogs of each kind.
Brandβ
A Brand is representing a name known by the consumers. A Brand belongs to a Legal Entity. A Legal Entity can have several Brands. Each Product must have a Brand.
Free Tagβ
A freeform string linked to a Product. Several Free tags can be set on a Product. FreeTags can be used to classify Products for search and browse. Moreover, an Application can implement specific behaviors on Product set with a given free tag.
Closed Tagβ
Tags set on products, with platform-enforced list of possible values. The "Type" type Closed Tags are particularly interesting, implementing the strong typing system in the Platform. A Product has a single "Type" Closed Tag. Example values are "Double Sink", "Worktop", "Chair" etc.
Price*β
Does not map directly to API object
A Product can have several prices, in designated currencies, timeframes, and discount schemes.
3D Modelβ
Many Products have a 3D Model, stored in the platform in a specific BM3 binary asset. This 3D Model can be made scalable, enabling the same asset to represent various sizes of products.
For some Products, the 3D Model is considered a useless overhead, as this is the case for hinges, sink drains. For these, the 3D in not necessarily in the 3D scene, but a Product is still required in the Item List for ordering.
The appearance of a 3D Model is set by one or several textures represented by BM3Mat Assets, which can be either embedded in the 3DModel asset, of published separately and pointed to as a Publication Material.
Core Range Concepts - Optionalβ
Below is the list of additional range modelling concepts.
BM3Mat Assetsβ
BM3Mat Assets turn 3D Models into realistic lifelike objects, leveraging notions such as texture and lighting - or can be a simple flat RBG color. They can be shared between 3D Models. They can be Parameter values.
Generic Productβ
A Generic Product is a Product which is generally not displayed to customers but that is linked to currently orderable Products through mappings. The Generic Product carries a representation such as a scalable BM3, and is mapped to the currently orderable Products existing in different dimensions.
Benefit: Generic Products enable resource sharing across several products, easier Range management as well as simplification of the Product edit panel for the consumer. Example: An edit panel giving the choice between the "Madeleine grey"Β and "Opera white"Β fronts (Generic Products), instead of the longer list of actual orderable Products in each dimension.
Product Override*β
Does not map directly to API object
Overrides enable the reuse of existing Products with minor modifications of attribute values. When Product B is the override of Product A, the resulting Product created in the Application is Product A except for those attributes which are defined in B, whose values are retained in the resulting Product - including potentially the representation. Product A can have several overrides, and B cannot be overridden. A and B can be in different Catalogs and Application Distributions, but must share the same Legal Entity.
Benefit: Information factoring, resulting in less necessary updates on Range items for a given change, lower global Range footprint increasing solution agility, and reduction of possible copy errors potentially existing when information is duplicated.
Assemblyβ
Leveraging traditional CAD notions, an Assembly is the aggregation of several components which can be 3D Models and potentially other Assemblies, specifying relative positioning of said components. For instance a typical handle can be created only once as Product and be assembled to doors and drawer fronts of any dimensions used in any cabinets.
An Assembly is represented in the platform in the form of a BMA asset on a Product.
Benefit: Information factoring of leaves and subcomponents optimizes planner performance as well as Range management. Assembly is also a prerequisite to enable configurability scenarios - in order for the fronts of cabinets to be interchangeable, you need to first componentize the cabinet to separate the frame and the front in different Products and combine them in an Assembly.
Parameterβ
Parameters are variables defined on Products and 3D Models. These variables can be dimensions, numbers, strings, Booleans, Products and Materials. Setting the value of a Product Parameter is called an overload.
For those Products that can be configured by the User, the Edit panel shows drop-downs lists in which s/he selects desired dimensions, finishes and options in the form of Product lists - these drop-down lists refer to the Parameters of the Product.
Benefits: Parameters, together with scalable Geometries, Assemblies, Mappings and a system of formulas, enable the creation of compact Ranges implementing complex domain logic along with large scale product variation management. This notion will look very familiar to CAD designers.
Product Ruleβ
Implements the compatibility between Products.
Applicative Ruleβ
Played in an Application after each product modification, which triggers alerting or warning to Users. For example, it allows to verify relative placement of Products.
Templatesβ
Templates automatically propose to Users a typical arrangement of Products. The Application automatically fits those arrangements to the room size and shape defined by the User.
Those arrangements and their scalable behaviors are defined by Range Managers as Templates. They include Products from the Product Catalogs of their Legal Entity. Templates are published to Application Distributions through Template Catalogs.
Diagramsβ
The Range Modelling Fundamentalsβ
Product to Product Relationshipsβ
