Sujith :) ->

1. Added documentation

Assets/LLM/source/Documentation.meta

@@ -0,0 +1,8 @@
+fileFormatVersion: 2
+guid: d5ef0fa5cc7cf4cfab54292275ddc3a6
+folderAsset: yes
+DefaultImporter:
+  externalObjects: {}
+  userData: 
+  assetBundleName: 
+  assetBundleVariant: 

Assets/LLM/source/Documentation/1_HighLevel_Data_Guide.md

@@ -0,0 +1,95 @@
+# LLM Guide: High-Level Project Data (`HighLevel.zip`)
+
+## 1. Purpose
+
+This data level provides a **high-level, bird's-eye view** of the entire Unity project. It is the smallest and fastest data source, designed for answering questions about the project's overall configuration, settings, and dependencies.
+
+**Use this data for questions like:**
+- "What is the product name and company name?"
+- "Which render pipeline is the project using (Built-in, URP, HDRP)?"
+- "What version is the application bundle?"
+- "List all custom tags and layers defined in the project."
+- "Which scenes are included in the build settings?"
+- "What packages and dependencies are included in the project?"
+
+## 2. File Structure
+
+The zip file will contain the following structure:
+
+```
+HighLevel/
+├── manifest.json
+└── packages.json
+```
+
+## 3. Key Files & Schema
+
+### `manifest.json`
+
+This file contains a comprehensive summary of the project's most important settings, aggregated from multiple files in the `ProjectSettings/` directory.
+
+**Schema Example:**
+```json
+{
+  "productName": "Terra-LLM",
+  "companyName": "DefaultCompany",
+  "bundleVersion": "0.1",
+  "activeColorSpace": 1, // 0: Gamma, 1: Linear
+  "renderPipeline": "URP", // Can be "Built-in", "URP", "HDRP", or "Scriptable"
+  "projectMode": "3D", // Can be "3D" or "2D"
+  "tags": [
+    "Untagged",
+    "Respawn",
+    "Finish",
+    "EditorOnly",
+    "MainCamera",
+    "Player",
+    "GameController"
+  ],
+  "layers": {
+    "0": "Default",
+    "1": "TransparentFX",
+    "2": "Ignore Raycast",
+    "4": "Water",
+    "5": "UI"
+  },
+  "buildScenes": [
+    {
+      "path": "Assets/Scenes/SampleScene.unity",
+      "enabled": true
+    }
+  ],
+  "physicsSettings": {
+    "gravity": { "x": 0, "y": -9.81, "z": 0 },
+    "autoSimulation": true
+  }
+}
+```
+
+### `packages.json`
+
+This file is a direct copy of the project's `Packages/manifest.json`. It lists all the Unity packages and other dependencies used in the project.
+
+**Schema Example:**
+```json
+{
+  "dependencies": {
+    "com.unity.ide.rider": "3.0.15",
+    "com.unity.ide.visualstudio": "2.0.16",
+    "com.unity.render-pipelines.universal": "12.1.7",
+    "com.unity.ugui": "1.0.0",
+    "com.unity.modules.physics": "1.0.0"
+  }
+}
+```
+
+## 4. Handling Shrunken / Tokenized Data
+
+The JSON files in this zip may have been processed by `json_reducer.py` to save space. You can identify this if the root object contains a `key_mapper` and a `data` key.
+
+**If the data is shrunken:**
+1.  The file content will look like this: `{"key_mapper":{"k0":"productName",...},"data":{"k0":"Terra-LLM",...}}`
+2.  You **MUST** use the `key_mapper` object to de-tokenize the keys in the `data` object before you can interpret the schema. The `key_mapper` is a dictionary where the keys are the short tokens (e.g., `k0`) and the values are the original, human-readable keys (e.g., `productName`).
+3.  Recursively replace every token in the `data` object with its original value from the `key_mapper`.
+
+Once de-tokenized, the data will conform to the schemas described above.

Assets/LLM/source/Documentation/1_HighLevel_Data_Guide.md.meta

@@ -0,0 +1,7 @@
+fileFormatVersion: 2
+guid: ca2f61613cc614f38be9b4b82a91aeba
+TextScriptImporter:
+  externalObjects: {}
+  userData: 
+  assetBundleName: 
+  assetBundleVariant: 

Assets/LLM/source/Documentation/2_MidLevel_Data_Guide.md

@@ -0,0 +1,105 @@
+# LLM Guide: Mid-Level Project Data (`MidLevel.zip`)
+
+## 1. Purpose
+
+This data level provides a **structural and relational view** of the project's assets. It is designed for understanding the hierarchy of scenes and prefabs, and for locating assets within the project.
+
+**Use this data for questions like:**
+- "Draw the full visual hierarchy of `SampleScene.unity`."
+- "List all GameObjects in the `Player.prefab` file."
+- "What components are attached to the 'Main Camera' object?"
+- "Find all prefabs that contain a script with the GUID `a1b2c3d4...`."
+- "Where are all the material files located in the project?"
+
+## 2. File Structure
+
+The zip file will contain a replicated `Assets/` directory and a `GuidMappers/` directory.
+
+```
+MidLevel/
+├── Assets/
+│   ├── Scenes/
+│   │   └── SampleScene.json  // This was originally SampleScene.unity
+│   └── CustomGame/
+│       └── Prefabs/
+│           └── Player.json   // This was originally Player.prefab
+└── GuidMappers/
+    ├── materials.json
+    ├── prefabs.json
+    ├── scripts.json
+    ├── scenes.json
+    └── ... (other asset types)
+```
+
+## 3. Key Files & Schema
+
+### `GuidMappers/*.json`
+
+These files map the unique GUID of an asset to its project-relative file path. This is essential for cross-referencing. For example, when you find a script GUID in a scene file, you can look it up in `scripts.json` to find the script's path.
+
+**Schema Example (`scripts.json`):**
+```json
+{
+  "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6": "Assets/Scripts/PlayerController.cs",
+  "f1e2d3c4b5a69876543210fedcba9876": "Assets/Scripts/Gun.cs"
+}
+```
+
+### `Assets/**/*.json` (Scene/Prefab Hierarchy)
+
+Each `.unity` and `.prefab` file is converted into a single JSON file that describes its full visual hierarchy. The root of the JSON is a list of all top-level objects in that scene or prefab.
+
+**Schema Example (`SampleScene.json`):**
+```json
+[
+  {
+    "fileID": "14854",
+    "m_Name": "Main Camera",
+    "m_IsActive": 1,
+    "m_TagString": "MainCamera",
+    "m_Layer": 0,
+    "components": [
+      "Camera",
+      "AudioListener",
+      "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6" // Script GUIDs are used for MonoBehaviours
+    ],
+    "children": []
+  },
+  {
+    "fileID": "123456", // This is the fileID of the PrefabInstance
+    "source_prefab_guid": "abcdef1234567890abcdef1234567890",
+    "m_Name": "Explosion Effect",
+    "m_IsActive": 1,
+    "addedComponents": [], // Components added as an override in the scene
+    "children": [
+      {
+        "fileID": "789012",
+        "m_Name": "Smoke Trail",
+        "m_IsActive": 1,
+        "m_TagString": "Untagged",
+        "m_Layer": 0,
+        // This index preserves the object's order within the prefab's hierarchy
+        "deep_sibling_index": "0-1", 
+        "components": ["ParticleSystem"],
+        "children": []
+      }
+    ]
+  }
+]
+```
+- **`fileID`**: The unique ID of the GameObject or PrefabInstance within the file.
+- **`source_prefab_guid`**: Indicates that this node is an instance of a prefab.
+- **`components` / `addedComponents`**: A list of components attached. For scripts, this is the script's GUID.
+- **`children`**: A nested list of child objects, forming the tree structure.
+- **`deep_sibling_index`**: Only present for scene objects parented under a prefab instance. It defines the object's precise location in the hierarchy for correct ordering.
+
+## 4. Handling Shrunken / Tokenized Data
+
+The JSON files in this zip may have been processed by `json_reducer.py`. You can identify this if the root object contains a `key_mapper` and a `data` key.
+
+**If the data is shrunken:**
+1.  The file content will look like this: `{"key_mapper":{"k0":"fileID",...},"data":[{"k0":"14854",...}]}`
+2.  You **MUST** use the `key_mapper` object to de-tokenize the keys in the `data` object before you can interpret the schema.
+3.  The `json_reducer` also removes keys with empty values (e.g., an empty `children` array `[]` will be removed). If a key like `children` is missing from a de-tokenized object, you can assume its value was empty.
+
+Once de-tokenized, the data will conform to the schemas described above.

Assets/LLM/source/Documentation/2_MidLevel_Data_Guide.md.meta

@@ -0,0 +1,7 @@
+fileFormatVersion: 2
+guid: 2c5050f620fef415892ea6b14eb2e658
+TextScriptImporter:
+  externalObjects: {}
+  userData: 
+  assetBundleName: 
+  assetBundleVariant: 

Assets/LLM/source/Documentation/3_LowLevel_Data_Guide.md

@@ -0,0 +1,89 @@
+# LLM Guide: Low-Level Project Data (`LowLevel.zip`)
+
+## 1. Purpose
+
+This data level provides the **most granular, detailed, and raw view** of the project's assets. It is designed for deep inspection of specific object properties, component values, and raw file contents.
+
+**Use this data ONLY when:**
+- The user asks for a specific property value that is not available in the Mid-Level data (e.g., "What are the exact position coordinates of the 'Player' object?").
+- You need to read the content of a C# script or a shader file.
+- You need to examine the raw, unmodified project settings files.
+
+## 2. File Structure
+
+The zip file contains a highly detailed breakdown of the project, where scenes and prefabs are exploded into their constituent GameObjects.
+
+```
+LowLevel/
+├── Assets/
+│   ├── Scenes/
+│   │   └── SampleScene.unity/  // A directory, not a file
+│   │       ├── 14854.json      // Represents the Main Camera GameObject
+│   │       ├── 99012.json      // Represents the Player Character GameObject
+│   │       └── root_objects.json // Lists the fileIDs of top-level objects
+│   ├── Scripts/
+│   │   └── PlayerController.cs // The actual C# script file
+│   └── Shaders/
+│       └── Lit.shader      // The actual shader file
+└── ProjectSettings/
+    ├── TagManager.json
+    └── ... (other raw project settings files as JSON)
+```
+
+## 3. Key Files & Schema
+
+### `Assets/.../{fileID}.json`
+
+This file represents a **single GameObject or Component** from a scene or prefab. The filename is the object's unique `fileID` within its original asset file. This is a raw dump of the object's data as seen in the YAML source.
+
+**Schema Example (`99012.json` for the Player Character):**
+```json
+{
+  "GameObject": {
+    "m_ObjectHideFlags": 0,
+    "m_CorrespondingSourceObject": { "fileID": 0 },
+    "m_PrefabInstance": { "fileID": 0 },
+    "m_PrefabAsset": { "fileID": 0 },
+    "m_Component": [
+      { "component": { "fileID": 990120 } }, // Link to its own Transform
+      { "component": { "fileID": 990121 } }, // Link to a BoxCollider
+      { "component": { "fileID": 990122 } }  // Link to a MonoBehaviour
+    ],
+    "m_Layer": 8,
+    "m_Name": "Player Character",
+    "m_TagString": "Player",
+    "m_IsActive": 1
+  }
+}
+```
+- The data is raw. To find the position, you would need to find the `Transform` component (e.g., `990120.json`) and look for the `m_LocalPosition` property within it.
+- To find which script is attached, you would need to find the `MonoBehaviour` component (e.g., `990122.json`) and look for the `m_Script` property, which contains the script's GUID.
+
+### `Assets/.../root_objects.json`
+
+This file contains a simple JSON list of the `fileID`s for all the root (top-level) GameObjects within that scene or prefab.
+
+**Schema Example:**
+```json
+[
+  14854,
+  99012,
+  123456
+]
+```
+
+### Other Files
+
+-   **`*.cs` and `*.shader` files:** These are direct, plain-text copies of the original source files.
+-   **`ProjectSettings/*.json`:** These are raw, one-to-one conversions of the corresponding `.asset` files from YAML to JSON.
+
+## 4. Handling Shrunken / Tokenized Data
+
+The JSON files in this zip may have been processed by `json_reducer.py`.
+
+**If the data is shrunken:**
+1.  The file content will look like this: `{"key_mapper":{"k0":"GameObject",...},"data":{"k0":{...}}}`
+2.  You **MUST** use the `key_mapper` to de-tokenize the keys in the `data` object before you can interpret the schema.
+3.  The `json_reducer` also removes keys with empty values. If a key is missing from a de-tokenized object, you can assume its value was empty.
+
+Once de-tokenized, the data will conform to the schemas described above.

Assets/LLM/source/Documentation/3_LowLevel_Data_Guide.md.meta

@@ -0,0 +1,7 @@
+fileFormatVersion: 2
+guid: 67e9dd12615614026b507cc61416ec0e
+TextScriptImporter:
+  externalObjects: {}
+  userData: 
+  assetBundleName: 
+  assetBundleVariant: 

Assets/LLM/source/Documentation/4_Query_Strategy_Guide.md

@@ -0,0 +1,52 @@
+# LLM Query Strategy for Unity Project Data
+
+## 1. Core Principle: Top-Down Analysis
+
+The project data is split into three levels of detail (High, Mid, Low) to enable efficient querying. Always start with the highest, most abstract level of data and only "drill down" to a more detailed level when the query requires it. This prevents unnecessary processing of large, granular files.
+
+**The workflow is always: High -> Mid -> Low.** Never start with the Low-level data unless you have a very specific `fileID` you need to look up.
+
+## 2. The Triage Process: Which Zip to Use?
+
+When you receive a user query, use the following decision process to select the correct data source.
+
+### Step 1: Is it a Project-Wide Question?
+
+First, check if the question is about the project's global configuration, dependencies, or a general summary.
+
+- **Keywords:** "settings", "package", "version", "scenes in build", "tags", "layers", "render pipeline".
+- **Action:** Use **`HighLevel.zip`**.
+- **Example Queries:**
+    - "What is the name of the game?" -> Read `manifest.json`.
+    - "Which version of the Universal Render Pipeline is installed?" -> Read `packages.json`.
+    - "Is the 'PostProcessing' layer defined?" -> Read `manifest.json`.
+
+### Step 2: Is it about Structure, Hierarchy, or Asset Location?
+
+If the question is about the arrangement of objects within a scene/prefab, what components an object has, or where assets are, the Mid-level data is the correct source.
+
+- **Keywords:** "hierarchy", "list objects", "what components", "find all prefabs with", "children of", "location of".
+- **Action:** Use **`MidLevel.zip`**.
+- **Example Queries:**
+    - "Show me the hierarchy of `SampleScene.unity`." -> Read `Assets/Scenes/SampleScene.json` and format the nested structure.
+    - "What components are on the 'Player' GameObject?" -> Find the 'Player' object in the relevant scene/prefab JSON and list its `components`.
+    - "Find all objects with a 'Rigidbody' component." -> Scan all scene/prefab JSON files, check the `components` list for each object.
+    - "Where is the `PlayerController.cs` script?" -> Find the script's GUID in the `components` list of an object, then look up that GUID in `GuidMappers/scripts.json` to get the file path.
+
+### Step 3: Is it about a Specific, Raw Property Value?
+
+Only proceed to this step if the user asks for a specific detail that is not present in the Mid-level hierarchy view. You should ideally already have the `fileID` of the target object from a previous Mid-level query.
+
+- **Keywords:** "exact position", "specific value", "rotation", "scale", "property of", "what is the speed".
+- **Action:** Use **`LowLevel.zip`**.
+- **Example Queries:**
+    - "What are the exact local position coordinates of the 'Gun' object in the `Player` prefab?"
+        1.  **Mid-Level:** First, open `Assets/CustomGame/Prefabs/Player.json`. Find the "Gun" object in the hierarchy to get its `fileID` (e.g., `101112`).
+        2.  **Low-Level:** Now, navigate to the exploded directory: `Assets/CustomGame/Prefabs/Player.prefab/`. Find the `Transform` component associated with the "Gun" GameObject (you may need to open `101112.json` to find its component `fileID`s). Open the `Transform`'s JSON file (e.g., `1011120.json`) and read the value of the `m_LocalPosition` key.
+    - "What is the 'movementSpeed' value in the 'PlayerController' script on the Player object?"
+        1.  **Mid-Level:** Find the Player object in the scene, get the GUID for its controller script.
+        2.  **Low-Level:** Open the corresponding `.../{player_fileID}.json` file. Find the `MonoBehaviour` component that matches the script GUID. Look at its properties to find the `movementSpeed` value.
+
+## 4. De-Tokenization Reminder
+
+For all JSON files, **always check for tokenization first**. If the file contains a `key_mapper`, you must de-tokenize the `data` payload before attempting to process it according to the schemas and strategies outlined above.

Assets/LLM/source/Documentation/4_Query_Strategy_Guide.md.meta

@@ -0,0 +1,7 @@
+fileFormatVersion: 2
+guid: 07094386d22c4486089172deb75abb5f
+TextScriptImporter:
+  externalObjects: {}
+  userData: 
+  assetBundleName: 
+  assetBundleVariant: 

Assets/LLM/source/SceneParsing.md

@@ -1,427 +0,0 @@
-
-Use case 1:
-Link between gameobjects in scene
-
---- !u!1 &330585543
-GameObject:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-serializedVersion: 6
-m_Component:
-- component: {fileID: 330585546} -> Usually the first one is transform
-- component: {fileID: 330585545} -> Any component that is not transform
-- component: {fileID: 330585544} -> Any component that is not transform
-- component: {fileID: 330585547} -> Any component that is not transform
-m_Layer: 0
-m_Name: Main Camera
-m_TagString: MainCamera
-m_Icon: {fileID: 0}
-m_NavMeshLayer: 0
-m_StaticEditorFlags: 0
-m_IsActive: 1
-
-Transform data:
-
---- !u!4 &330585546
-Transform:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-m_GameObject: {fileID: 330585543}
-m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}
-m_LocalPosition: {x: 0, y: 1, z: -10}
-m_LocalScale: {x: 1, y: 1, z: 1}
-m_ConstrainProportionsScale: 0
-m_Children:
-- {fileID: 1429936258} -> This refers to the first child's transform
-m_Father: {fileID: 0}
-m_RootOrder: 0
-m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
-
---- !u!4 &1429936258
-Transform:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-m_GameObject: {fileID: 1429936256} -> This refers to the transform's gameobject data reference
-m_LocalRotation: {x: -0, y: -0, z: -0, w: 1}
-m_LocalPosition: {x: 0.2898221, y: -23.73114, z: -48.733814}
-m_LocalScale: {x: 1, y: 1, z: 1}
-m_ConstrainProportionsScale: 0
-m_Children: []
-m_Father: {fileID: 330585546}
-m_RootOrder: 0
-m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
-
---- !u!1 &1429936256
-GameObject:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-serializedVersion: 6
-m_Component:
-- component: {fileID: 1429936258} 
-- component: {fileID: 1429936257}
-- component: {fileID: 1429936259}
-m_Layer: 0
-m_Name: MEEE
-m_TagString: Untagged
-m_Icon: {fileID: 0}
-m_NavMeshLayer: 0
-m_StaticEditorFlags: 0
-m_IsActive: 1
-
-Now, we have a link between the gameobject and the transform and their children. So for game object the children link are found using the transform data.
-So the way to traverse is: GameObject -> Transform -> Children -> <For Each Child> -> Transform -> GameObject, now we append the gameobject1 child info with the gameobject2. This is the way to traverse the hierarchy to find the parent-child relationship between scene objects.
-
-
-Use case 2:
-
-Prefab in root, with no children & no overrides:
-
---- !u!1001 &1482527665
-PrefabInstance:
-m_ObjectHideFlags: 0
-serializedVersion: 2
-m_Modification:
-    m_TransformParent: {fileID: 0}
-    m_Modifications:
-    m_RemovedComponents: []
-m_SourcePrefab: {fileID: 100100000, guid: 61c90d4029cba460eaac555f5cfa2f97, type: 3}
-
-
-There are no additional artifacts that unity generates, so in this use case, since the 'm_TransformParent' is 0, the prefab is in the root of the scene, with no custom scene objects as children + no overrides.
-
-
-Use case 3:
-
-Prefab in root with overrides:
-
---- !u!1001 &1482527665
-PrefabInstance:
-m_ObjectHideFlags: 0
-serializedVersion: 2
-m_Modification:
-m_SourcePrefab: {fileID: 100100000, guid: 61c90d4029cba460eaac555f5cfa2f97, type: 3}
---- !u!1 &1482527666 stripped
-GameObject:
-m_CorrespondingSourceObject: {fileID: 5118133154516674719, guid: 61c90d4029cba460eaac555f5cfa2f97,
-type: 3}
-m_PrefabInstance: {fileID: 1482527665}
-m_PrefabAsset: {fileID: 0}
---- !u!65 &1482527667
-BoxCollider:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-m_GameObject: {fileID: 1482527666}
-m_Material: {fileID: 0}
-m_IsTrigger: 0
-m_Enabled: 1
-serializedVersion: 2
-m_Size: {x: 1, y: 1, z: 1}
-m_Center: {x: 0, y: 0, z: 0}
-
-Here in this use case, prefab has a override of a box collider, in that case unity would generate a ghost gameobject with prefab instance reference, where the box collider would have reference of gameobject.
-The way to note this is to identify if the gameobject data is stripped, then ideally just assume that the gameobject is a ghost created for prefab. It wouldn't have components list of identify the components that are attached on this prefab.
-So, we iterate through components which have m_GameObject and identify gameobject, and then implicitly see if the gameobject is stripped, then we identify its prefab instance.
-
-Use case 4:
-
-Prefab with a scene object as child:
-
---- !u!1001 &1482527665
-PrefabInstance:
-m_ObjectHideFlags: 0
-serializedVersion: 2
-m_Modification:
-m_TransformParent: {fileID: 0}
-m_RemovedComponents: []
-m_SourcePrefab: {fileID: 100100000, guid: 61c90d4029cba460eaac555f5cfa2f97, type: 3}
---- !u!4 &1482527666 stripped
-Transform:
-m_CorrespondingSourceObject: {fileID: 7908724477659422290, guid: 61c90d4029cba460eaac555f5cfa2f97,
-type: 3}
-m_PrefabInstance: {fileID: 1482527665}
-m_PrefabAsset: {fileID: 0}
---- !u!1 &309364077
-GameObject:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-serializedVersion: 6
-m_Component:
-- component: {fileID: 309364078}
-- component: {fileID: 309364081}
-- component: {fileID: 309364080}
-- component: {fileID: 309364079}
-  m_Layer: 0
-  m_Name: Cube
-  m_TagString: Untagged
-  m_Icon: {fileID: 0}
-  m_NavMeshLayer: 0
-  m_StaticEditorFlags: 0
-  m_IsActive: 1
---- !u!4 &309364078
-Transform:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-m_GameObject: {fileID: 309364077}
-m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}
-m_LocalPosition: {x: 0, y: 0, z: 0}
-m_LocalScale: {x: 1, y: 1, z: 1}
-m_ConstrainProportionsScale: 1
-m_Children: []
-m_Father: {fileID: 1482527666}
-m_RootOrder: 0
-m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
-
-Here, the prefab has a child which is a scene object called cube. Here note, a ghost transform is generated against the prefab. The way the link works is the Cube (GameObject) -> Cube (Transform) ->  Check m_Father property -> Find related transform -> See if the transform property is stripped -> If stripped, then it is a ghost.
-Since we identified it is a ghost, we find the transform's 'm_PrefabInstance' and identify what is the prefab instance that this transform is related to. Now due to this, we can identify that this is a prefab with a scene object (Cube) as child.
-
-Use case 5:
-
-Prefab with a prefab as child:
-
---- !u!1001 &1482527665
-PrefabInstance:
-m_ObjectHideFlags: 0
-serializedVersion: 2
-m_Modification:
-m_TransformParent: {fileID: 0}
-m_RemovedComponents: []
-m_SourcePrefab: {fileID: 100100000, guid: 61c90d4029cba460eaac555f5cfa2f97, type: 3}
---- !u!4 &1482527666 stripped
-Transform:
-m_CorrespondingSourceObject: {fileID: 7908724477659422290, guid: 61c90d4029cba460eaac555f5cfa2f97, type: 3}
-m_PrefabInstance: {fileID: 1482527665}
-m_PrefabAsset: {fileID: 0}
---- !u!1001 &617805067
-PrefabInstance:
-m_ObjectHideFlags: 0
-serializedVersion: 2
-m_Modification:
-m_TransformParent: {fileID: 1482527666}
-m_RemovedComponents: []
-m_SourcePrefab: {fileID: 100100000, guid: 7cf72a57738ed4c1e993c0388fa836d4, type: 3}
-
-Here one prefab instance has reference of another prefab instance. Here, the way we identify the relationship is by finding the 'm_TransformParent' property. If it is not 0, then it means the prefab has a parent.
-If we check the parent, which is linked to a stripped transform, we know that the transform is related to a prefab. We can then find the prefab instance. This is the way to traverse the prefab hierarchy.
-
-
-Use case 6:
-
-Prefab with scene object as parent:
-
---- !u!1001 &1482527665
-PrefabInstance:
-m_ObjectHideFlags: 0
-serializedVersion: 2
-m_Modification:
-m_TransformParent: {fileID: 491276561}
-m_Modifications:
-m_RemovedComponents: []
-m_SourcePrefab: {fileID: 100100000, guid: 61c90d4029cba460eaac555f5cfa2f97, type: 3}
---- !u!4 &1482527666 stripped
-Transform:
-m_CorrespondingSourceObject: {fileID: 7908724477659422290, guid: 61c90d4029cba460eaac555f5cfa2f97,
-type: 3}
-m_PrefabInstance: {fileID: 1482527665}
-m_PrefabAsset: {fileID: 0}
---- !u!1 &491276560
-GameObject:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-serializedVersion: 6
-m_Component:
-- component: {fileID: 491276561}
-  m_Layer: 0
-  m_Name: Sala
-  m_TagString: Untagged
-  m_Icon: {fileID: 0}
-  m_NavMeshLayer: 0
-  m_StaticEditorFlags: 0
-  m_IsActive: 1
-  --- !u!4 &491276561
-  Transform:
-  m_ObjectHideFlags: 0
-  m_CorrespondingSourceObject: {fileID: 0}
-  m_PrefabInstance: {fileID: 0}
-  m_PrefabAsset: {fileID: 0}
-  m_GameObject: {fileID: 491276560}
-  m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}
-  m_LocalPosition: {x: 0, y: 0, z: 0}
-  m_LocalScale: {x: 1, y: 1, z: 1}
-  m_ConstrainProportionsScale: 1
-  m_Children:
-- {fileID: 1482527666}
-  m_Father: {fileID: 0}
-  m_RootOrder: 3
-  m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
-
-Here while parsing through gameobject, if we identify, the trasform has a child, and that child's transform is stripped, that means, the transform is related to a prefab. We can then find the prefab instance. This is the way to traverse the prefab hierarchy. 
-
-
-Use case 7:
-
-Prefab with the scene object as child for one of the prefab's children:
-
---- !u!1 &5604345
-GameObject:
-m_ObjectHideFlags: 0
-m_CorrespondingSourceObject: {fileID: 0}
-m_PrefabInstance: {fileID: 0}
-m_PrefabAsset: {fileID: 0}
-serializedVersion: 6
-m_Component:
-- component: {fileID: 5604346}
-  m_Layer: 0
-  m_Name: PEACE
-  m_TagString: Untagged
-  m_Icon: {fileID: 0}
-  m_NavMeshLayer: 0
-  m_StaticEditorFlags: 0
-  m_IsActive: 1
-  --- !u!4 &5604346
-  Transform:
-  m_ObjectHideFlags: 0
-  m_CorrespondingSourceObject: {fileID: 0}
-  m_PrefabInstance: {fileID: 0}
-  m_PrefabAsset: {fileID: 0}
-  m_GameObject: {fileID: 5604345}
-  m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}
-  m_LocalPosition: {x: 0, y: 0, z: 0}
-  m_LocalScale: {x: 1, y: 1, z: 1}
-  m_ConstrainProportionsScale: 1
-  m_Children: []
-  m_Father: {fileID: 920412709}
-  m_RootOrder: 0
-  m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
-  --- !u!1001 &920412706
-  PrefabInstance:
-  m_ObjectHideFlags: 0
-  serializedVersion: 2
-  m_Modification:
-  m_TransformParent: {fileID: 0}
-  m_Modifications:
-  m_RemovedComponents: []
-  m_SourcePrefab: {fileID: 100100000, guid: 874028b39d9764ee997aa13686619919, type: 3}
-  --- !u!4 &920412709 stripped
-  Transform:
-  m_CorrespondingSourceObject: {fileID: 8145956705230478064, guid: 874028b39d9764ee997aa13686619919,
-  type: 3}
-  m_PrefabInstance: {fileID: 920412706}
-  m_PrefabAsset: {fileID: 0}
-
-To identify the parent child relationship, where the father of a scene object is prefab and that object can be 'n'th child of the prefab, we use the following steps:
-
-Step 1: Find "PEACE" and its Parent in SampleScene.unity
-
-First, we locate the "PEACE" GameObject in the scene file to find its direct parent.
-
-1. We search for m_Name: PEACE. This leads us to the GameObject with ID &5604345.
-2. This GameObject has one component, a Transform with fileID: 5604346.
-3. We examine the Transform component with ID &5604346:
-
---- !u!4 &5604346
- Transform:
-   # ...
-   m_GameObject: {fileID: 5604345}
-   m_Father: {fileID: 920412709}
-   m_RootOrder: 0
-     - Parent ID: The m_Father is 920412709.
-     - Sibling Index: The m_RootOrder is 0.
-
-This gives us the last number in our sequence: (?-?-0).
-
-Step 2: Identify the Parent (920412709) in SampleScene.unity
-
-Now, we look for the object with ID 920412709 in the scene file.
-
---- !u!4 &920412709 stripped
-Transform:
-m_CorrespondingSourceObject: {fileID: 8145956705230478064, guid: 874028b39d9764ee997aa13686619919, type: 3}
-m_PrefabInstance: {fileID: 920412706}
-m_PrefabAsset: {fileID: 0}
-
-- The stripped keyword tells us this Transform is part of a prefab instance. Its properties are not defined here.
-- To find its real properties (like its parent and name), we must look inside the source prefab.
-- The m_CorrespondingSourceObject gives us the fileID of the original Transform inside the prefab file: 8145956705230478064.
-
-Step 3: Find the Corresponding Transform in Parent.prefab
-
-We now switch to the Parent.prefab file and search for the Transform with ID &8145956705230478064.
-
-1. Locating &8145956705230478064:
-
---- !u!4 &8145956705230478064
-Transform:
-  # ...
-  m_GameObject: {fileID: 1790231484505338027}
-  m_Father: {fileID: 1455291841571425918}
-  m_RootOrder: 0
-
-2. We can now identify this object and its parent:
-  - Its m_GameObject is 1790231484505338027. Looking up this GameObject reveals its name: m_Name: SpawnPoint. So, 920412709 in the scene is the "SpawnPoint" Transform.
-  - Parent ID: The m_Father is 1455291841571425918.
-  - Sibling Index: The m_RootOrder is 0.
-
-This gives us the second number in our sequence: (?-0-0).
-
-Step 4: Find the Next Parent (1455291841571425918) in Parent.prefab
-
-We continue up the hierarchy within the prefab file, looking for the Transform with ID &1455291841571425918.
-
-1. Locating &1455291841571425918:
-
---- !u!4 &1455291841571425918
-Transform:
-  # ...
-  m_GameObject: {fileID: 8435291834557686729}
-  m_Father: {fileID: 6729460392160249717}
-  m_RootOrder: 0
-
-2. We identify this object and its parent:
-  - Its m_GameObject is 8435291834557686729. Looking up this GameObject reveals its name: m_Name: Launcher.
-  - Parent ID: The m_Father is 6729460392160249717.
-  - Sibling Index: The m_RootOrder is 0.
-
-This gives us the first number in our sequence: (0-0-0).
-
-Final Verification: The Prefab Root
-
-To be certain, we can check the final parent, Transform &6729460392160249717.
-
---- !u!4 &6729460392160249717
-Transform:
-# ...
-m_GameObject: {fileID: 5669290172027642543}
-m_Father: {fileID: 0}
-m_RootOrder: 0
-
-Its m_Father is {fileID: 0}, which signifies that it is the root Transform of the prefab, as it has no parent. Its GameObject (5669290172027642543) is named "Parent".
-
-By parsing the files and following the m_Father and m_RootOrder references, we have programmatically confirmed that the deep sibling index of the "PEACE" GameObject is indeed (0-0-0).
-
-
-Conclusion:
-
-So essentially, it is beneficial to resolve the parent-child relationship between normal game objects in the scene using m_Parent logic.
-Whenever, we deal with a prefab instance, we create a relationship of child-parent between the prefab instance and it's found normal scene object parent. The transforms can be stripped out of the prefab instances in the final output, since the relationship is already resolved.
-In instances where a scene object has a prefab as a parent, we add the deep sibling index json property, which exactly tells where does the scene object exist in the prefab hierarchy within scene.
-So irrespective of which sibling index's child the scene object is, we add it always to the root of the prefab data object and add children with the deep sibling index data.
-Finally, one more pass of run through in the left over data, to see if any gameobject is missed out, then they are marked as orphans and exported.
-Now, since this is done, we append the components name to the component section of every gameobject that has been identified and created a virtual tree out of.
-Ultimately, we parse through our collated data, and find the m_RootObjects in the root objects found and sort the objects in root based on them.
-Note: When extracting information from prefab's modification, check if it has value of 'm_IsActive' in 'm_Modifications' inside m_Modification object of PrefabInstance, we need only this value and 'm_RemovedComponents' property to be exported from the prefab instance.

Assets/LLM/source/SceneParsing.md.meta

@@ -1,3 +0,0 @@
-fileFormatVersion: 2
-guid: 20db35d0017e4224914d3cec1b9ee7db
-timeCreated: 1754370002