2. VRay Asset Preparation
Overview
The ThreeKit platform supports Vray assets through the use of vrscene file exports, and the VFB file export (vccglb from Vray4 only at this time).
When the user triggers a Vray render inside Maya or 3dsmax, the Vray plugin generates a vrscene output file that contains all the necessary data for Vray to process the render, excluding the texture data. This means that the camera, render settings, mesh data, materials (with links to the texture assets), and lights are all stored inside the vrscene file.
All of these elements can be set up for configuration on ThreeKit, with the most notable exception at this time being the render settings.
The following list shows the typical configuration changes in a given project:
Swapping models
Swapping materials
Swapping textures
Changing number-based nodes and properties in the shader graph (eg: multipliers)
Light properties and light linking
Naming Convention & Hierarchy
With this list in mind, we have to prepare these assets for ease of configuration, especially at scale. This means that naming conventions are very important. A naming convention that is easily understandable, and being used consistently is critical to the success of the project. This applies to all the elements listed above (models, materials, textures, configurable nodes in the shader graph, and lights).
Automating configuration of these elements at scale is entirely dependent on a consistent naming convention. This is of particular importance for the models and textures, which may need to be loaded automatically using metadata queries. This means that we could automatically connect textures with materials based on the file naming convention used on the texture (eg. MaterialFamilyName_FabricName_diffuse.png). Click here for more information about metadata queries.
Clear identification of material names vs model names is also very useful, as the ThreeKit platform has certain dropdown lists where it does not differentiate between model, texture, scene, and material assets. This means that naming a material with the same name as a model is not recommended. Instead, we prefer to use something like ModelName_MAT for material names.
For model hierarchy organization, the ThreeKit platform does support group nodes (NULLs) and dummy/locator objects. These are very useful for organization purposes. However, too much nesting in the hierarchy can also cause issues with the ThreeKit UI, so it is recommended to keep it at a minimum.
Exposing Nodes For Configuration
For configuration of individual shader nodes, this is possible through the use of the TK_ prefix on shader node names. This is currently supported only on texture file nodes and VrayUser nodes (specifically the VrayUserColor, VrayUserInteger, and VrayUserScalar nodes). Naming one of these nodes with the TK_ prefix will expose that node for configuration on the ThreeKit platform during the vrscene import process. In the following example, the TK_BaseMap and TK_BaseTint will be exposed for configuration on ThreeKit inside the material asset:
When connecting these nodes with TK_xxx names to a shader network, please ensure that they are actually being saved in the vrscene file as well. In some cases, Vray does not actually end up saving these nodes in the vrscene file. Instead, it just transfers their values directly to the property in the parent node where they are connected. In Maya, this happens especially when the connection is made to a property that does not have the explicit “checker” icon beside it.
To check whether these nodes were properly saved in the vrscene, the user can open the vrscene using a text editor, and perform a simple search there for the name. Be aware, however, that some vrscene files can be very large, and they may crash the typical text editors that do not support opening large files.
Warning!
Unfortunately, 3dsmax does not save the custom names of these vrayUser Nodes in the 3dsmax file. Upon reopening the file, 3dsmax will rename these nodes to generic names.
Configurable Vray Features
The ThreeKit platform offers support for a number of Vray features directly in the ThreeKit UI, which allows their properties to be configurable directly on the platform. These features are the following:
Vray Displacement/Subdivision settings
Vray Material Wrapper settings (including additional similar settings from geometry meshes that affect primary visibility and Reflect/Refract visibility)
Vray Rounded Corners
Applying these features on the ThreeKit platform to mesh nodes inside an imported vrscene would typically override these existing features in the vrscene file.
The ThreeKit UI does not currently support connecting shader node networks into the properties of these additional features added through the platform, such as the file node in the Vray Displacement operator. If that functionality is needed, it should be baked through the vrscene file, and the models imported with the vrscene file. In that case, the user would not need to add the Vray Displacement operator on the platform on top of it.
Template Materials
A good practice with configuration at scale is to think in terms of creating templates, rather than unique assets with exceptions. This applies in particular to materials.
A Vray fabric material can be set up simply as a collection of texture nodes connected to a standard Vray material, instead of unique Vray materials for each individual fabric. This one template material can then be reused as a template on ThreeKit, connected to multiple fabric catalog items, with the individual file nodes configurable based on the fabric that requires them.
This kind of automation can be achieved in several different ways on ThreeKit, but what they all have in common is the reliance on a consistent naming convention that allows the textures to be matched with their corresponding material.
Here is an example of what a simple template fabric material could look like:
Another important advantage of keeping the Vray materials as flat and simple as possible is that often the project requires the product to exist both as a 3D and 2D configurator. This means that the artist would need to be able to reuse the same textures with both the Vray material as well as with the Webgl PBR version. Since the Webgl material is currently a flat structure, without the ability to have a node network, it would be easier to match the look of the material if the Vray version is also kept simple.
This essentially requires a workflow that bakes all necessary color corrections directly into the textures, rather than relying on shader nodes.
Conclusion
As a simple rule of thumb, it would be best to keep the setups as simple and straight-forward as possible. It will make the configuration setup on ThreeKit (and in general) a lot simpler, and easier to understand.
Last updated
Was this helpful?
