Part 1
Add additional columns to build_reports to capture new fields from the Summary object. When analyzing the output of an older version of Unity there should be no error and these columns can be left null.
** buildName (empty for AssetBundle builds)
** buildContentOptions (0 except for content directory builds)
** buildSessionGUID
** buildManifestHash (empty except for content directory builds)
** buildProfilePath
** buildProfileGuid
** dataPath
We continue to hide obsolete or obscure fields, e.g. platformGroupName, crc, multiProcessEnabled are intentionally ignored.
Part 2
Add 3 tables that are created on-demand, only if a ContentSummary object is identified. The on-demand behavior will be similar to PackedAssets, but there is always 0 or 1 ContentSummary objects, not more than 1.
Content summary is documented here: https://docs.unity3d.com/6000.6/Documentation/ScriptReference/Build.Reporting.ContentSummary.html
The tables will cover:
- the cross-build statistics (e.g. serializedFileSize, reusedSerializedFileSize...)
- the type statistics (type id, size, object count, resourceCount) based on the ContentSummary.m_typeStatsList
- the assetStatsList
It can also be useful to have a view that shows the type stats with a string for the type.
The schema should be consistent with other build report tables. Because there can be mutiple BuildReports analyzed in a single database there needs to be some way to join rows to the correct build report, e.g. build_report_id column referencing the BuildReport object that is in the same file as the ContentSummary.
Testing
Reference files built with Unity 6.6 are already available in the TestCommon location, e.g.
TestCommon/Data/LeadingEdgeBuilds/BuildReport-AssetBundles/LastBuild.buildreport
TestCommon/Data/LeadingEdgeBuilds/BuildReport-ContentDirectory/f64157fb08bb9f645971d39c1203bd03.buildreport
e.g. available data is visible using
UnityDataTool.exe dump --stdout --type BuildReport .\LastBuild.buildreport
Part 1
Add additional columns to build_reports to capture new fields from the Summary object. When analyzing the output of an older version of Unity there should be no error and these columns can be left null.
** buildName (empty for AssetBundle builds)
** buildContentOptions (0 except for content directory builds)
** buildSessionGUID
** buildManifestHash (empty except for content directory builds)
** buildProfilePath
** buildProfileGuid
** dataPath
We continue to hide obsolete or obscure fields, e.g. platformGroupName, crc, multiProcessEnabled are intentionally ignored.
Part 2
Add 3 tables that are created on-demand, only if a ContentSummary object is identified. The on-demand behavior will be similar to PackedAssets, but there is always 0 or 1 ContentSummary objects, not more than 1.
Content summary is documented here: https://docs.unity3d.com/6000.6/Documentation/ScriptReference/Build.Reporting.ContentSummary.html
The tables will cover:
It can also be useful to have a view that shows the type stats with a string for the type.
The schema should be consistent with other build report tables. Because there can be mutiple BuildReports analyzed in a single database there needs to be some way to join rows to the correct build report, e.g. build_report_id column referencing the BuildReport object that is in the same file as the ContentSummary.
Testing
Reference files built with Unity 6.6 are already available in the TestCommon location, e.g.
TestCommon/Data/LeadingEdgeBuilds/BuildReport-AssetBundles/LastBuild.buildreport
TestCommon/Data/LeadingEdgeBuilds/BuildReport-ContentDirectory/f64157fb08bb9f645971d39c1203bd03.buildreport
e.g. available data is visible using