Features
Last updated
Was this helpful?
Last updated
Was this helpful?
The Features page provides details of the current subscription, as well as a preview of available ThreeKit Platform features.
Making any changes to this page requires the press of the Save Settings button at the bottom of the page. Please note that the changes will take some time to take effect, as the change needs to be propagated through the system. The delay may be anywhere between 5-15min under typical system load.
Provides the start date of the Threekit platform subscription.
If this feature is enabled, an Organization has the ability to create photorealistic renders of their products. Toggles are available for both WebGL and V-Ray Rendering.
Threekit is delivered with a default environment for all asset types. At times, this default view does not present the asset in the manner in which it will be displayed or illuminated either within the deployed instance of the configurator (3D Player) or rendered images (2D player). Therefore, the artist may collaborate with the team responsible for realistic presentation of the models and materials by making use of a default stage specifically customized for the desired viewing experience. Once created, the default stages (which reference Scene Assets) for viewing assets of a specific type can be set via these dropdowns.
Advanced
Advanced is a level of configuration requiring use of all attributes types and rules. This level of configuration is necessary to fully leverage Smart Assets and Part References.
Simple
Simple configurations contain only multi-choice attributes and do not require Rules.
None
No ability to configure the Product.
Not a functional feature at this time. This option does not currently do anything.
Enabling this feature will reveal a toggle on all Catalog Items, allowing the freedom to publish any Catalog Item on Threehub.
Limits for Users and number of Assets.
Org-wide settings are available for distribution of the player.
Use this setting to grant Threekit's support team access to your Organization without the need for formal invitations. Access is revoked automatically based on the End Date:
The features listed here are only available in a beta state to select clients who choose to opt in, with the full understanding that there may be stability issues associated with these features.
This feature allows for branches to be created and managed within the org. This option needs to be enabled from here in order to make branching functional. It is currently disabled by default. Visit the Branching Docs to read more about this feature.
This feature enables the tracking of data and events within the org, for the purpose of generating analytics data. It is enabled by default for all orgs. Visit the Advanced Buyer Analytics Docs for more information.
This feature enables the use of a backend API that can generate composite images from existing layered renders. The main advantage of this API is that it allows the trigger and generation of these composites faster than through the native Virtual Photographer feature. This option is disabled by default.
This feature is designed to optimize the initial load of a configurator when it is embedded on the front-end. It has no effect on the loading of the player on the ThreeKit platform.
The feature will reduce the initial number of requests made by the player to the platform by bundling up some of the resources into a single request.
Requests to meshes or configuration options that are populated by external scripts will not be optimized through this feature.
The optimization will have the most significant impact on projects with hundreds of choices and lots of overlapping tags for those choices. Most other projects may not see a noticeable improvement.
We would strongly recommend that you make use of the Publishing feature on catalog items, in order to take advantage of the caching of this bundle across CDNs.
The static publish bundle will get cached when used in conjunction with either the Publishing feature on catalog items, or when the player is embedded with the cache parameter.
Embedding the player with the cache parameter will always load the version of the static publish bundle generated for that particular cache scope. This means that if changes are made to the catalog item, a new static publish bundle will not be served to the front end in this scenario.
This does not apply if you're making use of the cache keys from the Publishing feature instead of the cache parameter.
The Static Publish feature is completely unrelated to the Item Publish feature. Aside from the associated caching mentioned above, the two features are unrelated. This means that Publishing an item will have no impact on the generation of the static publish bundle for that item. The static publish bundle will always be generated automatically after every change to the item, independently of the Publish state of that item.
Switching ON the Static Publish feature will not take effect instantly. The Static Publish file for an item will need to be generated the first time that item is requested by the player. This will create a job, and so it might take 30s or more before this takes effect. Once the static publish manifest file is generated, then it gets cached, until the item is republished.
Static Publishing will only speed up the initial player load. It has no effect on the load that happens during configuration changes
Custom scripts from actions inside the rules system for an item/asset will not get executed during the initial load when static publish is enabled. If you wish to do something like populating attribute options with a custom script, and have static publish take that into consideration for optimization, then you will need to put the script on a stage instead.
