LCC2 Data Organization Format White Paper

(1) LCC2 Data Organization Format

Developed by XGRIDS, the Lixel CyberColor 2 (LCC2) is a specialized 3D Gaussian Splatting (3DGS) format designed for large-scale, high-complexity spatial data using Level-of-Detail (LoD). Designed to address the practical limitations of LCC in long-term iteration and scene editing, LCC2 retains the core advantages of efficient storage and high visual fidelity while enhancing flexibility, maintainability, and editability — making it more adaptable to the evolving needs of industries such as architecture, film, robotics, and large-scale digital twin construction.

Key Differences Between LCC2 and LCC1

1. Data Storage and Decoding Logic: The original LCC1 format adopts binary storage and supports transparent transmission mode for direct data block reading, which delivers high decoding efficiency but comes with drawbacks, including high maintenance complexity and difficulty in editing. In contrast, LCC2 decouples decoding logic from data storage — with data storage handled independently by a dedicated module — eliminating the strong binding between format versions and storage modes.
2. Level of Detail (LoD) Management: LCC1 integrates LoD partitioning with data storage, leading to tight coupling that increases iteration costs when adjusting LoD strategies. LCC2 separates data storage and LoD partitioning (a fully implemented design goal), allowing for more flexible LoD configuration and easier updates without modifying the core storage structure.

This document outlines the technical specifications and structure of the LCC format, offering insight into how it supports efficient data capture, processing, and integration within modern 3D workflows.

---

(2) Terms and Concepts

LCC2 is an N-ary tree, where Node serves as the fundamental unit. A Node is the basic unit in the data, which stores data within a region in the storage space. Its basic structure is as follows:

Node {
    id,             // Index name (follows specific naming rules)
    boundingBox,    // Bounding box
    data: {         // Data index module
        3dgs: {       // (Required)
            name,     // Sequence number of splatFiles in the root node
            start,    // Starting sequence number of the index in the GS corresponding to splatFiles.
            count     // Number of 3DGS points in the current node
        },
        mesh: {       // (Optional)
            name,     // Sequence number of meshFiles in the root node
            vertex,   // Number of vertices
            face      // Number of faces
        },
        bvh: {        // (Optional)
            name      // Sequence number of bvhFiles in the root node
        }
    },
    childNum,       // Number of child nodes (0 means no child nodes)
    child: {        // List of child nodes (example)
        0: Node     // Child node instance (naming rule: parent node name - serial number)
    }
}

• Index Name (id): The index name follows specific naming rules to facilitate quick positioning of the current node's parent and child nodes. For example, a node named "0-1-1-7" has a parent node named "0-1-1"; if child nodes exist, their names will be extended to "0-1-1-7-(serial number)".
• Data Index (data): The data index module records the data information associated with the current node and supports extended storage of other types of data. Currently, it includes the following predefined fields:
  • 3DGS Data Index: Records the storage information of 3DGS data, including file path (splatFiles, indicating the storage address on disk), point sequence number range (start, which can also be used as the address for binary storage), and number of points (count). To ensure data compression efficiency, adjacent Node data at the same level will be merged and stored as the same file.
  • Mesh Data Index: Records the storage information of Mesh data. The meaning of its fields is consistent with that of 3DGS (corresponding to splatFiles), and it additionally includes the number of vertices (vertex) and the number of faces (face). Mesh nodes are not stored with merged nodes. Not all nodes have mesh and bvh fields. The index in meshFiles can be obtained using "name" as the index, thereby identifying the corresponding PLY file (the same logic applies to BVH).

---

(3) Data Organization

The complete LCC2 data consists of the following files: XXX.lcc2, data/3dgs/*, data/mesh/*

File Name	Description	Optional
XXX.lcc2	Metadata description file, providing an overall description of the scenario data	Required
data/3dgs	Contains all 3dgs files, file extensions like .ply, .spz, .sog	Required
data/mesh	Contains all mesh files	Optional

The following field descriptions correspond to version 0.0.3

(a) XXX.lcc2 Description

JSON Field	Data Type	Description
version	string	Version number
name	string	Name
description	string	Descriptive information
epsg	number/int	Spatial reference coordinate system code
guid	string	Unique identifier
source	string	Data source
dataType	string	Data type
offset	array[number]	Contains 3 floating-point elements, reserved field
shift	array[number]	Contains 3 floating-point elements, reserved field
scale	array[number]	Contains 3 floating-point elements, reserved field
fileType	string	"quality" indicates with spherical harmonics; "portable" indicates without spherical harmonics
totalSplats	number/int	Total number of Gaussians
lodSplats	array[number]	Contains N integer elements, number of Gaussians for each LOD level
totalLevels	number/int	Number of LOD levels
virtualLoD	object	Optional: Record information related to virtual LoD. null means invalid.
splatType	string	Storage formats for 3DGS, such as .spz .ply or .sog
env	object	Optional: Record information related to environment maps. null means invalid.
splatExtraAttributes	object	Optional: Record additional attributes of 3DGS, such as instance, semantic, thermal. null means invalid.
root	object	LoD tree root node
renderingHints	object	Record rendering-related settings

• virtualLoD

Records the number of virtual LOD levels, simplification method, downsampling factor, and the splat count threshold that triggers the virtual LOD mechanism.

"virtualLoD": {
    "levels": 1,
    "method": "simple",
    "downsizeFactor": 2,
    "maxSplats": 500000
}

• renderingHints

Specifies core rendering parameters for 3DGS (default), including the splatting algorithm, anti-aliasing variant, depth sorting strategy, and camera projection model.

"renderingHints": {
    "renderMethod": "splatting",
    "renderMethodVariant": "ewa",
    "sortingMethod": "depth",
    "cameraModel": "pinhole"
}

• env

Describes environmental splat data, including the environment type, total number of environmental splats, and 3D bounding box that defines the spatial range of the environment.

"env": {
    "type": "splats",
    "splatsCount": 4208,
    "boundingBox": {
        "min": [
            -954.31591796875,
            -855.6387329101563,
            -810.5621337890625
        ],
        "max": [
            795.0885009765625,
            905.033447265625,
            635.71533203125
        ]
    }
}

• Core Common Fields (All Nodes Include)

JSON Field	Data Type	Description
id	string	Unique identifier of the node, named by tree hierarchy
boundingBox	object	Axis-Aligned Bounding Box (AABB) of the node
boundingBox.min	array[number]	Minimum coordinates of the AABB (3 floating-point elements: [x, y, z])
boundingBox.max	array[number]	Maximum coordinates of the AABB (3 floating-point elements: [x, y, z])
childNum	number/int	Number of child nodes, 0 indicates a leaf node

• Root Node Exclusive Fields (Only for Root Node)

JSON Field	Data Type	Description
data	object	Root node exclusive business data, contains only env substructure. If null, indicates no environment file configured
data.env.name	number/int	Environment data, the number indicates the index corresponding to the entry in files (optional)
splatFiles	array[string]	List of file paths for 3D Gaussian Splatting (3dgs) related data files
meshFiles	array[string]	List of file paths for mesh model (PLY format) files (optional)
bvhFiles	array[string]	List of file paths for BVH structure (btree format) files (optional)

• Node Exclusive Fields (Included when child_num > 0)

JSON Field	Data Type	Description
child	object	Collection of child nodes. Keys are child node serial numbers (0/1/2...), values are core node structures (recursively nested)

• Leaf Node Exclusive Fields (Included when child_num = 0)

JSON Field	Data Type	Description
data	object	Contains 3dgs/mesh/bvh substructures (present on demand)

• Detailed Subfields of Leaf Node data

Parent Key	Subkey	Data Type	Description
data	3dgs	object	3DGS point cloud data information (required)
3dgs	name	number/int	3DGS data file identification number
3dgs	start	number/int	Starting index of the data
3dgs	count	number/int	Number of data entries
data	mesh	object	Mesh model data information (optional)
mesh	name	number/int	Mesh file identification number
mesh	vertex	number/int	Number of mesh vertices
mesh	face	number/int	Number of mesh faces
data	bvh	object	Bounding Volume Hierarchy (BVH) data information (optional)
bvh	name	number/int	BVH file identification number

For the detailed binary format specification of .btree files, see BTree File Format Specification.

(b) Coordinate System

Right-handed, keep the same with LCC.

---

(4) Versioning & Compatibility

• Readers must check version. This document describes version 0.0.3.
• Additional optional properties may appear in future versions; readers should ignore unrecognized fields.

---

(5) License and Restrictions

(a) Subject to your full compliance with this White Paper, we/XGRIDS (meaning XGRIDS LIMITED and its Affiliates, where "Affiliate" refers to any entity that directly or indirectly controls, is controlled by, or is under common control with a Party, and which maintains a direct or indirect interest relationship therewith) hereby grant you a non-exclusive, non-transferable, and royalty-free limited license to use, reproduce, modify, distribute (including provision to third parties, but excluding assignment), and create derivative data organization formats or other works based on the LCC2 Data Organization Format (hereinafter the "Data Organization Format"), provided that you satisfy all of the following conditions:

(i) You shall display a clear and prominent attribution stating "Data Organization Format originated from XGRIDS" within your application, website, or other visible interface of the product developed using the Data Organization Format.

(ii) You shall include a conspicuous notice in all modified data organization formats or derivative content stating that you have made modifications to the original Data Organization Format.

(iii) You shall provide an accessible electronic link or a copy of this White Paper to all third parties receiving the Data Organization Format or any derivative thereof.

(iv) Any redistribution to third parties must include a notice stating that the individual or organization uses and distributes the Data Organization Format under authorization from XGRIDS pursuant to this White Paper, and that XGRIDS or its Affiliates own and retain all intellectual property and other rights in the Data Organization Format.

(v) Without the prior written consent of XGRIDS, you shall not use the Data Organization Format for training or fine-tuning any artificial intelligence model that competes, directly or indirectly, with XGRIDS' products or services. You shall inform all third parties to whom you distribute the Data Organization Format of this restriction in writing and shall incorporate this clause into any applicable agreement (including but not limited to license agreements or terms of use) governing the use and/or distribution of the Data Organization Format.

(vi) You shall comply with this White Paper and all applicable laws and regulations.

(b) Subject to your compliance with this White Paper, any modification, extension, reprocessing, or derivative data organization format or content created based on the Data Organization Format shall be made publicly available under terms no less open than those of this White Paper License, and you shall indicate the source and licensing information of the Data Organization Format.

(c) Failure to perform or a breach of the foregoing open-source obligations shall automatically terminate all rights granted to you under this White Paper as of the date of such failure or breach.

(d) Subject to your compliance with this White Paper, you may use, reproduce, or distribute the Data Organization Format and its derivative forms in accordance with this White Paper; provided, however, that such use, reproduction, or distribution shall not be deemed a waiver, assignment, or limitation of any existing rights of XGRIDS.

(e) This White Paper does not grant any trademark license. Licensees shall not use any name or logo owned by or associated with XGRIDS or its Affiliates, except to the extent reasonably and customarily necessary for the description and distribution of the Data Organization Format.

(f) You shall not use the Data Organization Format or its derivatives in any of the following ways:

(i) In violation of any applicable international, national/federal, local, or other applicable laws or regulations;

(ii) To develop, train, test, or support any model or system that directly or indirectly causes harm, discrimination, misinformation, or any unlawful purpose;

(iii) To develop, train, test, or support any model, system, or application intended to exploit, harm, or potentially harm minors;

(iv) To support high-risk automated decision-making systems (including but not limited to those involving personal safety, health, employment, credit, justice, or education), or for any unlicensed professional use;

(v) In a manner that violates generally accepted social ethics or public order;

(vi) To implement, support, or promote violence, extremism, or terrorism;

(vii) For any discriminatory purpose based on race, gender, religion, nationality, disability, age, or any other legally protected characteristic;

(viii) For any military or weapons development purpose;

(ix) To identify, de-anonymize, or recover any personal data, confidential information, or sensitive content that may be present in the Data Organization Format;

(x) In any manner that damages or may damage the rights or interests of XGRIDS.

(g) If you initiate or participate in any lawsuit, arbitration, or other legal proceeding against XGRIDS or any party, alleging that XGRIDS has infringed upon your rights or interests, all rights granted to you under this White Paper shall automatically terminate as of the date such legal action is initiated.

---

(6) Miscellaneous

(a) XGRIDS shall have no obligation to provide any support, maintenance, updates, training, or to develop any subsequent versions of the Data Organization Format, nor shall XGRIDS be obligated to grant any further licenses related thereto. Unless and only to the extent required by applicable law, the Data Organization Format and any outputs or related results are provided on an "AS IS" basis, without any express or implied warranties, including but not limited to warranties of title, merchantability, non-infringement, fitness for a particular purpose, or those arising from a course of dealing, usage, or trade practice. You are solely responsible for determining the appropriateness of using, reproducing, modifying, performing, displaying, or distributing the Data Organization Format or any output derived therefrom, and you assume all risks associated with your and any third party's use, distribution, or exercise of rights and licenses under this White Paper.

(b) Any implementation, tool, model, or service developed, released, or distributed by any third party based on or derived from the Data Organization Format or its structure shall be deemed the independent action of such third party. Such actions shall not represent the views of XGRIDS, nor shall they constitute an official version, authorization, or endorsement by XGRIDS. XGRIDS makes no representations or warranties, and assumes no liability, regarding the performance, compatibility, legality, or fitness for any purpose of any such third-party implementations.

(c) In the event that any third party makes a claim, initiates litigation, arbitration, or other legal proceedings against XGRIDS arising out of or in connection with your or your authorized third party's use, modification, redistribution, or derivative application of the Data Organization Format, you shall provide necessary assistance (or cause your authorized third parties to assist) in the defense of such proceedings and shall hold XGRIDS harmless from and against any and all liabilities, losses, damages, or expenses arising therefrom.

(d) To the maximum extent permitted by applicable law and regulation, and regardless of the theory of liability (including contract, tort, negligence, product liability, or otherwise), XGRIDS shall not be liable for any damages arising out of or in connection with this White Paper or the Data Organization Format, including without limitation any direct, indirect, special, incidental, punitive, or consequential damages, or any loss of profits, revenues, data, or goodwill.

(e) This White Paper, and any dispute arising out of or in connection with it, shall be governed by and construed in accordance with the laws of the People's Republic of China (Mainland), without regard to its conflict of laws principles. Any dispute arising out of or relating to this White Paper shall be submitted to the Shenzhen Court of International Arbitration (SCIA) for arbitration in Shenzhen, China, in the Chinese language. The arbitral award shall be final and binding upon the parties.

(f) XGRIDS reserves the right to update, revise, or interpret this White Paper at any time. Any updated version shall take effect upon its publication on the official XGRIDS website or other official channels, or upon written notice (including by email or other accessible means) provided to you by XGRIDS.

---

If you need any assistance or would like to share your feedback, please let us know through our Community.