An alternative 3D player with a modular design, allowing for more flexibility.
What is the Composable Player?
The Composable player is an alternative to the Classic 3D player, allowing for more flexibility in the front-end implementation. It is based on the React Three Fiber framework, and requires a React-based front-end setup.
The Composable Player is in a very early stage of development.
Improvements will follow, and some of the features and workflows listed will change in the future.
Modular Architecture
The Composable player has a modular design, which flows from the React component-based architecture. This provides the following benefits:
- Integrate the player with different features and elements into the page with more freedom than the way the Classic 3D player is integrated.
- Create new effects and shaders using React Three Fiber functionality.
- Configuration information is handled entirely separately through the Composable Configurator.
Performance Implications
The Composable player loads the 3D assets using the glTF file format. This could lead to potentially very fast load times on both initial load as well as on configuration change loads once all assets are cached.
- On every request for an asset from the ThreeKit platform, the front-end will receive an updated glTF file representing the asset variant requested by the player. Conceptually, this is very similar to requesting a separate image for each variant of a product. In this case we request a 3D file instead of an image.
- The Composable Player avoids having to evaluate the configuration rules to determine what individual meshes and textures it needs to serve next. by serving the cached pre-generated glTF file for every variant. This results in a single request being made to the platform instead of potentially dozens or even hundreds of requests.
- The glTF files only need to be generated once on first request for every change, and then they get cached automatically.
Initial glTF File Request
The main caveat to the performance is that the initial load will take significantly longer when the glTF file has not yet been created and cached. Once this file is generated, the serving of the cached file will generally be very fast.
Feature Support
The Composable Player supports many of the same features supported by the Classic player. However, due to the differences in architecture, there are some important differences in how some of the features are supported, while others may not currently be supported at all in the composable player.
| Feature | Classic 3D Player | Composable SDK |
|---|---|---|
| Load asset data in single request | - | YES |
| Modular front-end composition | - | YES |
| Caching of assets | YES | SOME |
| Publishing | YES | - |
| Attributes | ALL | ALL |
| Logic | ALL | SOME |
| Personalization | YES | - |
| Parametric Configuration | YES | - |
| Modular Configuration | YES | SOME |
| Materials | ALL | (only Physical Material) |
| Material Operators | ALL | (only Map Override, Tiling Override, and Environment Override) |
| Stages | YES | - |
| Model Assets | YES | YES |
| Scene Assets | YES | YES |
| Proxy Assets | YES | YES |
| Mesh Operators | ALL | ALL |
| Cameras | ALL | SOME |
| Lights | ALL | ALL (except Shadow Plane) |
| Post Effects | ALL | SOME |
Exceptions
Caching
The Composable Player supports only a single cache scope on player embed. Cache keys generated by the Publish feature for individual catalog items are ignored by the composable player. By contrast, the Classic Player supports both.
Logic
The only rules supported are those that make changes to the attributes, and those that act as constructors on a configuration change. For example - loading assets through metadata queries, or changing a node location or appearance on configuration change.
Rules that change the appearance of meshes due to parametric configuration could potentially lead to an infinite number of variants. This would be problematic with the requirement of baking the result into a glTF file.
Custom code rules that perform actions in real-time are not supported. For example - rules that trigger animations. Some of this can be implemented directly on the front-end, but only if they affect nodes defined on the front-end through React Three Fiber, or the entire transform of an Asset Component.
Modular Configuration
The Composable Configurator supports nested configuration, and this allows the creation of some very simple modular configurators. However, Connectors and Layout Containers are not currently supported. An equivalent setup could be created in React, but it will require additional development time.
Cameras
The active player camera does get exported through the gltf file with the correct field of view, however the other properties do not get transferred. This includes properties like near clipping planes, orbit behavior or constraints. All of these properties need to be set up and controlled separately from the front-end implementation using react-three-fiber, threejs or custom libraries.
See the Camera Setup section for additional information on working with Cameras.
Post Effects
Only the following post effects are currently supported, although the effects will look a little different with the composable player than in the Classic Player:
- SAO - works the same as in the Classic Player.
- Bloom - supported, but is currently implemented with lower visual quality than the one in the Classic Player.
- Tonemapping and Exposure
- Anti-Aliasing - msaa and fxaa, similar to Platform settings. No high quality stop-and-refine AA
- Color Correction
- Player Background - Only the Transparency and Colors options are supported, but images may be added through HTML behind the player.