Preparing a Mesh For CSR¶

In order to utilize the full capabilities of client-side rendering, as well as ensure naming compatibility between CSR and the product build, there are some important details to know.

Performance¶

One aspect that is not an issue when doing pre-rendered images is performance. Since only images are loaded, fully loading a page is as fast as the user's internet network. When addressing real-time constraints, we must optimize everything as much as possible in order to avoid stressing both the network and as computing resources.

Mesh Topology¶

One of the most straightforward optimization points is the mesh topology. From our own internal testing, a desktop PC can handle with good performance meshes up to 50k vertices, but this is really a worst case scenario. In this instance there is no lower bound to strive towards, it's quite simply a case of "the lower, the better". A mesh with around 15k vertices is great, but even lower than that is ideal.

For this purpose, there are some tricks you can do to reduce a mesh's poly count, without greatly impacting the visual aspect of the product:

• Create a lower-poly version, and bake the higher-res detail to a normal map: One interesting trick is to bake extra detail to a normal map. This would allow the artist to retain fine-grain in-surface details, without actually requiring geometry. Most 3D applications allow this workflow (Maya, Blender, ZBrush);
• Remove edge loops that don't contribute significantly to the overall shape: Sometimes more edge loops than necessary are created to round a shape, or even worse, are there to smooth out a mesh. Many programs allow the artist to specify areas to be "smooth shaded", which interpolates the normals of faces. This alone can be enough to remove a considerable number of vertices;
• Remove vertices in hidden areas, reduce them in less visible ones: For example, in the case of a shoe, the user can't view very well the interior of the shoe, so that can be a zone to reduce the poly count. In the case of a bag, if there's geometry that goes inside the bag, or is otherwise occluded by other parts, then those vertices should be removed;

For materials, all meshes require proper UV mapping.

Textures¶

For CSR, texture support relies on baked images to a specific mesh. There's currently no planned support for complex materials like .sbsar files. Different workflows exist for baking the maps to texture, so the CSR only concerns itself with properly displaying the textures.

To minimize network overhead, as well as storage space, it is encouraged, but not necessary, to reutilize the same maps for different meshes. As long as different meshes don't have overlapping UVs, it should be possible to re-use the same texture across different materials. The Editor intelligently parses the content of the textures, and if it detects a texture that's being added already has been loaded, it automatically assigns the previously loaded texture. This allows for less textures to be loaded in general, and less VRAM required on the user's computer.

Regarding image size, it's important to take into account that it's not only physical size that matters. A 4K JPEG takes as much space as a 4K PNG in VRAM, so it's important to minimize it as much as possible. One simple way of doing so is to use lower resolution versions of images that contain little to no information. For example, a roughness map that has only large white and black values, without much detail, does not need to be very large. In fact, it could be as low as 256x256 px, with negligible impact in visual fidelity.

Naming¶

The naming of the meshes themselves is very important, as this is what allows CSR to match the names in the build to their actual 3D representations.

There is also a good trick to prevent adding the same material a large number of times. Imagine a scenario in which there are 40 small meshes that are supposed to share the same material. It would be unfeasible to add an entry in the build for each mesh, with the same material. For this reason, both the editor and CSR automatically group internally all meshes that share the same name. In a specific example, if there were 40 bolts, if each bolt had the name bolt_001, bolt_002, bolt_XX, or even bolt_1, CSR will know that these meshes will share the material. No extra work is needed from the artist, so they can have complete creative freedom as to how they create the product's sub-meshes.

There's also another trick up the artist's sleeves, in the form of Mesh Groups. If there are meshes that are not in the main build, but are "grouped" with other meshes, the artist can create a Mesh Group inside the Editor to force a group. For example, in the case of a watch, the case part can include the glass, case, and interior meshes. In order to respond to a change in the case part, the artist can create a Mesh Group named case, and include the case, interior and glass sub-meshes. This way, CSR can respond to events appropriately, without forcing the artist to be extra careful while creating the mesh.

Exporting Settings¶

The mesh should be exported in glTF format, as this allows for best compatibility with CSR, and can include multiple animations seamlessly inside the file. The mesh should not include any material bundled with it, as it will be destroyed, but can still result in a larger filesize than necessary. The process of adding materials will be done later inside the CSR Editor.