Creating 3D objects
The performance requirements for image synthesis (aka rendering) of three-dimensional objects and scenes are very different for VR applications. While interactive, dynamic VR applications such as HEGIAS VR have to calculate images in real time (real-time rendering), static VR applications such as panotour or space glider can invest several hours, not infrequently even days, to calculate a photorealistic scene (realistic rendering).
In order for three-dimensional objects in dynamic VR applications to be visualised within milliseconds, they must be optimised for real-time rendering. The most important steps and requirements are described below. The maxim here is: As much as necessary, as little as possible.
For each object to be depicted in HEGIAS VR, it should always be checked first whether a high-resolution 3D model already exists for it. For example, Evermotion and Dimensiva offer many designer objects for architectural visualisations that can be used as source models.
HiRes: 55k polygons
LowRes: 2k polygons
The process of object modelling is usually always the same: The starting point is a high-resolution geometric model (HiRes model). Through normal mapping, the information relevant for the illumination of an object is transferred to a low-resolution 3D model (LowRes model).
For this purpose, so-called retopology tools are used, which decompose an object into as few flat, square surfaces (quads) as possible with the aim of reducing the number of object-describing polygons to a maximum. The result is a so-called mesh model. Automatic reduction tools do not produce usable meshes in most cases. Please make sure that the meshes of smaller objects do not contain more geometry than those of larger objects and use as many smoothing groups as possible to emphasise the shapes.
Then, neatly clamp a two-dimensional texture model (UV) onto the LowRes model. The so-called UV mapping practically foils the LowRes models. For the baking of the NormalMaps it is important that the UVs do not overlap or are mirrored, as this could lead to texture errors during baking. When creating the UVs, always work with different checkerboard and line textures and eliminate distortions as completely as possible.
If there are identical or mirrored details on an object, these should only be modelled once and placed in the correct positions after baking and texturing. Real-time models do not have to be built exactly. However, floating geometries are not allowed because the realtime zBuffer is limited and flickering could occur (z-fighting).
If possible, a mesh should only ever be foiled with one material. Very small objects, e.g. flower pots, cutlery, books, pictures, etc., should be logically grouped together and only covered with one texture and one material.
The pivot or centre point should always be moved to the correct position, otherwise problems may arise when placing or animating the object.
Materials and textures should be given the same name as the mesh, avoiding abbreviations or numbering.
At HEGIAS we work exclusively with Substance Painter. However, textures can also be created with other tools. It is important that the format of the PBR textures is correct. Especially NormalMaps and Metallic-Roughness Maps are not textures that can be edited by hand, but data stored in an image format!
Please do not use tools that promise to generate complete PBR textures from an image. This always looks wrong. With Substance Painter or xNormal you then beacon the HiRes to the LowRes model. To save time, you can check Substance Source and Substance Share to see if there are any textures that can be bought there. Otherwise, you can create procedural textures with SubstanceDesigner.
Bake in Substance Painter
If an object has different materials, you can assign different materials to the HiRes model and have them beaconed into an ID map. In the case of the treasure chest, two different materials were assigned to the HiRes model: Wood and Metal.
The wood was created and processed according to photo references of a real treasure chest. For the metal, a standard material was used. With the ID map, a material mask was quickly created for the wood and the iron fittings. Further mask effects were used to define and edit wear marks.
HEGIAS VR uses the WebVR API and the data is loaded as glTF files. It is mandatory that the textures comply with the glTF-PBR standard:
Albedo/Base colour map
Normal map
Emission map (rarely used)
ORM map, the format for the ORM map is as follows:
Red: Ambient Occlusion
Green: Roughness
Blue: Metallic
Important: Normal maps and ORM maps must not be compressed because they are data files, not image files. If they are compressed, there will be clearly visible shading artefacts. For the same reason, both maps should be saved in Linear Colorspace. Albedo and emission maps should be saved as JPEG(sRGB) and normal and ORM maps as PNG(linear).
More info: https://www.khronos.org/blog/art-pipeline-for-gltf
For the best result, the files should be saved as GLB files. These can be tested directly in HEGIAS VR. Also in the 3D-Object Viewer of Windows, you can check if the final object is visualised as intended.
Textures are embedded in GLB files. They should not be too large, as this means longer download times and higher memory consumption for the end user. A sense of proportion is required here - please compare the new object with existing objects.
Not all textures have to be the same size. In the case of the ORM map, it is sometimes possible to use a texture half the size without having to accept a loss of quality. However, this varies from object to object.
You should not use the following reserved keywords in file names:
Ceiling
Floor
Glass
Wall
Stair
Interior
These keywords can lead to unexpected results because the graphic engine interprets them and replaces the materials if necessary. Objects should always be created in real scale so that they look right in VR. Please also check this again and again in the headset. If an object appears too small even though it was created to scale, it may help to add a few small details to the object.
File names should always correspond to the CamelCase notation, e.g.: MyFirstObject.glb, MyFirstObject.fbx.
Do not use minus signs, spaces, dots, abbreviations and especially version numbers in the file name. Please use underscores only sporadically and only where it really makes sense, e.g. VitraPolderCompact_LeatherBlack.glb and VitraPolderCompact_LeatherBlue.glb.
All names and designations should be in English.
Edge Loops /Edge Flow
Whenever possible, try to work in quads and create clean edge loops. Clean loops can be easily selected, edited and deleted. This allows you to quickly modify LowRes meshes.
For details in HiRes geometry (and only there) you can use "flying" details. Instead of embedding details completely in the geometry, you simply let them float above the geometry. This makes almost no difference when beaconing the NormalMap. On the other hand, the model is easier to maintain and modify. Especially with negative shapes like dents, notches and other depressions, this is a big advantage.
The "baked" result
Smoothing groups can strongly influence the appearance of a LowPoly object. Therefore, care should always be taken to use them. Otherwise, a random value will be used when importing the object, which may lead to a worse display in the Graphic Engine. Smoothing groups also make a difference when beaconing. Therefore, smoothing groups should be created before beaconing and checked after beaconing to see if the desired result has been achieved.
Since vertex colours are not supported by HEGIAS, they should not be used. In most cases nowadays only information for programmers is coded in vertex colours to enable/control special effects.
Most applications reserve the second UV map of an object and overwrite it if necessary. For HEGIAS VR there is no reason to assign a second UV map to an object. In practice, it has been proven to assign more geometry and larger textures to an object, because cutting away, reducing and optimising is easier than the other way round.
You want to upload your own 3D object to your private library and use it in HEGIAS VR? Then take a look at the support article Uploading a new object into the library.
In order for three-dimensional objects in dynamic VR applications to be visualised within milliseconds, they must be optimised for real-time rendering. The most important steps and requirements are described below. The maxim here is: As much as necessary, as little as possible.
For each object to be depicted in HEGIAS VR, it should always be checked first whether a high-resolution 3D model already exists for it. For example, Evermotion and Dimensiva offer many designer objects for architectural visualisations that can be used as source models.
HiRes and LowRes models
HiRes: 55k polygons
LowRes: 2k polygons
The process of object modelling is usually always the same: The starting point is a high-resolution geometric model (HiRes model). Through normal mapping, the information relevant for the illumination of an object is transferred to a low-resolution 3D model (LowRes model).
For this purpose, so-called retopology tools are used, which decompose an object into as few flat, square surfaces (quads) as possible with the aim of reducing the number of object-describing polygons to a maximum. The result is a so-called mesh model. Automatic reduction tools do not produce usable meshes in most cases. Please make sure that the meshes of smaller objects do not contain more geometry than those of larger objects and use as many smoothing groups as possible to emphasise the shapes.
Then, neatly clamp a two-dimensional texture model (UV) onto the LowRes model. The so-called UV mapping practically foils the LowRes models. For the baking of the NormalMaps it is important that the UVs do not overlap or are mirrored, as this could lead to texture errors during baking. When creating the UVs, always work with different checkerboard and line textures and eliminate distortions as completely as possible.
If there are identical or mirrored details on an object, these should only be modelled once and placed in the correct positions after baking and texturing. Real-time models do not have to be built exactly. However, floating geometries are not allowed because the realtime zBuffer is limited and flickering could occur (z-fighting).
If possible, a mesh should only ever be foiled with one material. Very small objects, e.g. flower pots, cutlery, books, pictures, etc., should be logically grouped together and only covered with one texture and one material.
The pivot or centre point should always be moved to the correct position, otherwise problems may arise when placing or animating the object.
Materials and textures
Materials and textures should be given the same name as the mesh, avoiding abbreviations or numbering.
At HEGIAS we work exclusively with Substance Painter. However, textures can also be created with other tools. It is important that the format of the PBR textures is correct. Especially NormalMaps and Metallic-Roughness Maps are not textures that can be edited by hand, but data stored in an image format!
Please do not use tools that promise to generate complete PBR textures from an image. This always looks wrong. With Substance Painter or xNormal you then beacon the HiRes to the LowRes model. To save time, you can check Substance Source and Substance Share to see if there are any textures that can be bought there. Otherwise, you can create procedural textures with SubstanceDesigner.
Bake in Substance Painter
If an object has different materials, you can assign different materials to the HiRes model and have them beaconed into an ID map. In the case of the treasure chest, two different materials were assigned to the HiRes model: Wood and Metal.
The wood was created and processed according to photo references of a real treasure chest. For the metal, a standard material was used. With the ID map, a material mask was quickly created for the wood and the iron fittings. Further mask effects were used to define and edit wear marks.
HEGIAS VR uses the WebVR API and the data is loaded as glTF files. It is mandatory that the textures comply with the glTF-PBR standard:
Albedo/Base colour map
Normal map
Emission map (rarely used)
ORM map, the format for the ORM map is as follows:
Red: Ambient Occlusion
Green: Roughness
Blue: Metallic
Important: Normal maps and ORM maps must not be compressed because they are data files, not image files. If they are compressed, there will be clearly visible shading artefacts. For the same reason, both maps should be saved in Linear Colorspace. Albedo and emission maps should be saved as JPEG(sRGB) and normal and ORM maps as PNG(linear).
More info: https://www.khronos.org/blog/art-pipeline-for-gltf
Final object
For the best result, the files should be saved as GLB files. These can be tested directly in HEGIAS VR. Also in the 3D-Object Viewer of Windows, you can check if the final object is visualised as intended.
Textures are embedded in GLB files. They should not be too large, as this means longer download times and higher memory consumption for the end user. A sense of proportion is required here - please compare the new object with existing objects.
Not all textures have to be the same size. In the case of the ORM map, it is sometimes possible to use a texture half the size without having to accept a loss of quality. However, this varies from object to object.
You should not use the following reserved keywords in file names:
Ceiling
Floor
Glass
Wall
Stair
Interior
These keywords can lead to unexpected results because the graphic engine interprets them and replaces the materials if necessary. Objects should always be created in real scale so that they look right in VR. Please also check this again and again in the headset. If an object appears too small even though it was created to scale, it may help to add a few small details to the object.
Further details
File names should always correspond to the CamelCase notation, e.g.: MyFirstObject.glb, MyFirstObject.fbx.
Do not use minus signs, spaces, dots, abbreviations and especially version numbers in the file name. Please use underscores only sporadically and only where it really makes sense, e.g. VitraPolderCompact_LeatherBlack.glb and VitraPolderCompact_LeatherBlue.glb.
All names and designations should be in English.
Edge Loops
Edge Loops /Edge Flow
Whenever possible, try to work in quads and create clean edge loops. Clean loops can be easily selected, edited and deleted. This allows you to quickly modify LowRes meshes.
HiRes Details
For details in HiRes geometry (and only there) you can use "flying" details. Instead of embedding details completely in the geometry, you simply let them float above the geometry. This makes almost no difference when beaconing the NormalMap. On the other hand, the model is easier to maintain and modify. Especially with negative shapes like dents, notches and other depressions, this is a big advantage.
The "baked" result
Smoothing Groups
Smoothing groups can strongly influence the appearance of a LowPoly object. Therefore, care should always be taken to use them. Otherwise, a random value will be used when importing the object, which may lead to a worse display in the Graphic Engine. Smoothing groups also make a difference when beaconing. Therefore, smoothing groups should be created before beaconing and checked after beaconing to see if the desired result has been achieved.
Vertex Colors
Since vertex colours are not supported by HEGIAS, they should not be used. In most cases nowadays only information for programmers is coded in vertex colours to enable/control special effects.
UV Maps
Most applications reserve the second UV map of an object and overwrite it if necessary. For HEGIAS VR there is no reason to assign a second UV map to an object. In practice, it has been proven to assign more geometry and larger textures to an object, because cutting away, reducing and optimising is easier than the other way round.
You want to upload your own 3D object to your private library and use it in HEGIAS VR? Then take a look at the support article Uploading a new object into the library.
Updated on: 05/05/2023
Thank you!