Along with 3D assets and catalog items, Threekit also provides the ability to store data on the platform in the form of Data Tables. Data tables closely resemble spreadsheets that all users should be familiar with.
Through the use of Data Tables, Threekit admins can manage large amounts of data and configuration logic in a single easy-to-read format.
Example: Store 3D Configuration Data
Imagine a company sells various boxes which need to be visualized to customers. The geometry of the box is simple enough a single asset will be resized using configuration rules in the threekit player.
The boxes come in fixed sizes, so with each new box size, the configurator can be programmed following any one of these processes:
Using one asset and one catalog entry, updating the rules:
- Add the new size option to the Size field
- Create a new rule for the size option
- Add conditions and actions for each dimension for the size option
End result: 1 Asset, 1 Catalog Entry, Many Rules
Using one asset, multiple catalog entries, and two stagnant rules:
- Create a catalog item for each new size
- Add metadata and tags for all dimensions of the size
End result: 1 Asset, 1 Size Rule, Many Catalog Entries
Using one asset and one catalog entry with updating data tables:
- Update the data table for new values
- Add the new option to the Size field
End Results: 1 Asset, 1 Catalog Entry, 1 Size Rule, 1 Data Table
Each process above results in an identical end-user experience (see below). So why does it matter? The benefit gained from Data Tables in many cases is the administrative experience. All of the configuration information lives in a single place to edit – the data table – in a format expert and novice Threekit users are familiar with, a .csv file.
Here is what the final product looks like:
To set it up, here are the steps to follow:
1. Create a .csv file, match the data below:
2. Upload the Data Table by clicking “Import Table” in the Data Table section
3. Create an asset, select Model
4. Add a cube to the scenegraph.
6. Switch to the Logic Tab and Create 4 attributes
a. Size (String)
i. Add Each Size from the first column of the data table as an option for selection, be careful to match spelling and capitalization.
b. Box Length (Number)
c. Box Width (Number)
d. Box Height (Number)
7. Create one rule for querying attributes
a. No conditions
b. Match actions below
8. Create another rule for setting box dimensions based on queried values
a. No conditions
b. Match actions shown below
These rules allow the asset to automatically change size based on selection of the Size attribute by looking up the proper dimensions in the data table!
Following this setup: To add any new size, update the data table with a new size row, and update the size list in the string attribute to include your new size.
Try it yourself by adding a new size “Refrigerator” (Length: 1, Width: 0.75, Height: 2) to see how easy it is to maintain!
Example: SKU Resolution
For this example, we will describe the use case but will not go step-by-step into the setup.
Scenario: A company wants to attach Threekit to an ecommerce platform. Threekit will pass the final SKU being ordered to the ecommerce store. The SKU is a single value representing all user selections made during configuration. Each size and color combination of boxes is assigned a unique SKU.
Note: the color attribute is a string type in this example: “Red”, “Blue”, “Green”.
Below is the data table and rule setup required for looking up the SKU based on output from the size and color attributes.
Note when creating logic rules, the Data Table search parameters are always utilizing AND logic in their search. So, the above example searches for the first row in the SKU data table that matches [Size (column in table) = Size (attribute on asset)] AND [Color (column in table) = Color (attribute on asset)].