3ds Max 2021, Maya 2023, and almost all modern DCCs, GameEngines support it!

More details:
https://bgolus.medium.com/generating-perfect-normal-maps-for-unity-f929e673fc57#c508

Current one is simply faced based index mesh.
Edge based data structure is preferred to process geometry algorithm.

References:
CGAL
GeometryCentral
MeshLib
OpenMesh

operator* but not only class method because it can only support vector.operator*(a), not a.operator*(vector).

Description

Currently we serialize all terrain mesh into a single binary file with ending cdbin. This contains the entire scene and it won't scale with increased number of sectorized terrain meshes. Instead, we should seek to create a terrain specific type that may store sectors in different files that gets loaded into the scene based on need.

Success Criteria

• Create a stand-alone class that would contain all terrain metadata. This should have the ability to load those meshes.
• This stand-alone class need to be reflected in SceneDatabase for AssetPipeline and RenderDataContext in the engine.
• The engine should contain logic to decide when to load these files and update the internal mesh data to send them for rendering.

For dcc files, models are not always in the (0, 0, 0) world position. So we need to adjust engine camera to frame all models' bbox which we want to view at the same time.

Another way is to import camera data so we can adjust runtime camera according to dcc scene's info. It is more convenient for us.

@Hinageshi01

What we have for now

MaterialImpl.h:

MaterialID m_id;

Each Mesh has a MaterialID, which can get a Material from SceneDatabase.

std::string m_name;

Name of Material.

TextureIDMap m_textureIDs;

Each Material has a std::map<MaterialTextureType, TextureID>, which can get TextureID by specified MaterialTextureType.
After that we can use TextureID to get a actural texture path from SceneDatabase.

What O3DE have

At the begining, we can refer to the BasePBR material type of O3DE.
BasePBR.materialtype

An explanation of the properties can be found here:
PBR Shading Model

Each PropertyGroup has several property and each property has several attribute including:

• id
• name
• description
• type
• default value
• a link to a variable in one of the shaders referenced by the .materialtype file.
• ...

The icon √ means that it's necessary for us to serialize this property.

BaseColor

BaseColorPropertyGroup.json

properties:

• color √
• factor √
• textureMap √
• useTexture √
• textureMapUv
• textureBlendMode

Metallic

MetallicPropertyGroup.json

properties:

• factor √
• textureMap √
• useTexture √
• textureMapUv

Roughness

RoughnessPropertyGroup.json

properties:

• textureMap √
• useTexture √
• textureMapUv
• lowerBound
• upperBound
• factor √

Specular

SpecularPropertyGroup.json

properties:

• factor
• textureMap
• useTexture
• textureMapUv
• enableMultiScatterCompensation

Normal

NormalPropertyGroup.json

properties:

• textureMap √
• useTexture √
• textureMapUv
• flipX
• flipY
• factor

Uv

UvPropertyGroup.json

properties:

• center
• tileU
• tileV
• offsetU
• offsetV
• rotateDegrees
• scale

Irradiance

IrradiancePropertyGroup.json

// Note: this property group is used in the DiffuseGlobalIllumination pass, it is not read by the shaders

We can ignore this PropertyGroup for now.

General Settings

GeneralCommonPropertyGroup.json

properties:

• doubleSided
• applySpecularAA
• enableShadows
• castShadows
• enableDirectionalLights √
• enablePunctualLights √
• enableAreaLights
• enableIBL √
• forwardPassIBLSpecular

How can we expand our Material Sysyem

#122

https://sketchfab.com/3d-models/restaurant-kitchen-set-part-1-129dd2f84879477ea261b422d21491f4

Can we analyze these instances in model files and convert to engine runtime?

1. MaterialProperty should have UVOffset and UVScale enum.
2. Modify GenericProducer::AddMaterial : not set tiling data to texture, set to material(multiple texture ...).
3. Update ProcessorImpl::DumpSceneDatabase to dump correct tiling data

GameEngineGems 2 - Chapter 1 Fast Computation of Tight-Fitting Oriented Bounding Boxes

• AABB
• OBB by DiTO-k : Ditetrahedron OBB algorithm
• OBB by PCA

Currently bgfx supports up to 8 color and texture coordinates per vertex. However, AssetPipeline only supports up to 4 and only 1 is encoded in the Mesh class.

Currently we generate elevation at every single vertex unit even when there isn't a vertex being rendered; While this is high resolution and may be useful to run interesting algorithms, it is not optimized for rendering. This issue is opened to optimize the generation such that it is 1:1 even when inter-vertex length is > 1.

Currently, class Mesh/Material/Texture contains a source file path to describe where the source asset was from.

We should adjust and save more info:

• class Asset
  • used Prodcuer class names
  • UTC timestamp when the asset was imported
  • filepath but only file base name is OK, no need to save absolute path
  • what is the display label name in editor
  • md5 hash(unique number for a file)

These data needs to serialize and deserialize only for Editor.
So CatDogConsumer should read class Asset data if it is used in editor, but doesn't read it if it is used in engine.
Generated .catdog.bin should also keep smaller size without class Asset if it is used in the final stage to generate game release package. If not, it can just save all data for editor and engine.

Reference:

• UnrealEngine - struct FAssetImportInfo and class UAssetImportData

• Dependency for SDK can be splited
• Easier for Editor to use. No need to depends on static libs.

Currently, we need to implement serialization and deserialization codes inside CatDogProducer and CatDogConsumer. And, we need to keep them in order.

So we can split the implementations back to data struct. For example, void Mesh::ImportBinary(const std::fstream&) and void Mesh::ExportBinary(std::fstream&). When designing the data struct, we can implement it if necessary.

To do it more generally, we can design an interface class ISerializeable. It has virtual void ImportBinary(const std::fstream&) = 0 and virtual void ExportBinary(std::fstream&) = 0. All classes which need to do things about serialization should inherit from this interface.

Or try to use CRTP trick in template programing.

So every data struct inherited from ISerializeable is TDerived. For example, they are mesh/material/texture/... in current codebase. We can combine Array<TDerived>+ TDerived::ImportBinary + TDerived::ExportBinary as an item. Every item will be in a list in order. So we can save effort on keeping an eye on Producer and Consumer if their orders are same.

• BlendShape
  • MorphTarget
• Skin
• Joint
• Skeleton
• BindPose
• VertexWeight
• ...

Reflection is better. But not required at first as we know C++ reflection is not in the std.

Also, it is not OK to parse lights from gltf. Need to have a look.

For linux build or other platforms, they may not have concepts about external project. So a cross-platform project may need to create a new build tool such as Unreal, or just keep the usage simple.

We already had some math shape classes. Then we need to a generator class to input a math shape to output a mesh which has vertex format, position/normal/uv, index buffer so that game engine can use these data to draw it directly.

Need some math functions to calculate simple vector arithmetic.

• Learn about Terragen features
• Import by GenericProducer
• Consume it in the editor

Description

Currently terrain meshes can be generated in sectors but they all of the same LOD. This issue covers the effort to generate different LOD or resolution of meshes such that they can be swapped out during rendering time.

Success Criteria

• Each terrain mesh have their LODs generated.
• Each terrain mesh must be compatible with their lower and upper LOD mesh (ie no gaps).

Description

Currently terrain generation supports only one tiled texture. A simple way to support up to 4 texture is to use the color attribute of vertices with each channel indicating the blending of 4 different textures. Note this doesn't have to be the vertex attribute but can also be an output texture that's sampled at rendering time.

Success Criteria

• Support 4 textures for terrain to be rendered.

Define an enum can generate const char* GetXXXName(EnumType e) method automatically.

The first version I implemented is:

// Generate names for enum automatically.
#define DEFINE_ENUM_WITH_NAMES(EnumName, ...) \
	enum class EnumName { __VA_ARGS__, Count }; \
	constexpr std::array<const char*, static_cast<int>(EnumName::Count)> EnumName##Names = { #__VA_ARGS__ }; \
	constexpr const char* Get##EnumName##Name(EnumName enumValue) { return EnumName##Names[static_cast<int>(enumValue)]; }

But #__VA_ARGS__ will convert all enums to a single string. For example, Enum class Foo { A, B, C }; will get "A, B, C". So I need to split by comma in compile time or have a better preprocessor than macro.

After some searchs, I can use BOOST_PP_SEQ_FOR_EACH_I in boost. Or use static reflection lib about enum process such as https://github.com/Neargye/magic_enum.

Also, it is not OK to parse lights from gltf. Need to have a look.

Previous import keep unique vertex for same position. But if it has smoothing groups or multiple uvs, it will be wrong.