MeshCoder: LLM-Powered Structured Mesh Code Generation from Point Clouds
Authors: BingQuan Dai
Luo Li
Qihong Tang
Jie Wang
Xinyu Lian
Hao Xu
Minghan Qin
Xudong XU
Bo Dai
Haoqian Wang
Zhaoyang Lyu
Jiangmiao Pang
Venue: NeurIPS 2025 poster ()
Keywords: 3D reconstruction
point cloud
LLM
Primary area: deep_learning
TL;DR: We trained MeshLLM, an Object-to-Code inference framework that generates Blender Python scripts to reconstruct 3D meshes from point clouds in a structured and editable manner.

Abstract: Reconstructing 3D objects into editable programs is pivotal for applications like reverse engineering and shape editing. However, existing methods often rely on limited domain-specific languages (DSLs) and small-scale datasets, restricting their ability to model complex geometries and structures. To address these challenges, we introduce MeshLLM, a novel framework that reconstructs complex 3D objects from point clouds into editable Blender Python scripts. We develop a comprehensive set of expressive Blender Python APIs capable of synthesizing intricate geometries. Leveraging these APIs, we construct a large-scale paired object-code dataset, where the code for each object is decomposed into distinct semantic parts. Subsequently, we train a multimodal large language model (LLM) that translates 3D point cloud into executable Blender Python scripts. Our approach not only achieves superior performance in shape-to-code reconstruction tasks but also facilitates intuitive geometric and topological editing through convenient code modifications. Furthermore, our code-based representation enhances the reasoning capabilities of LLMs in 3D shape understanding tasks. Together, these contributions establish MeshLLM as a powerful and flexible solution for programmatic 3D shape reconstruction and understanding.

MeshCoder: LLM-PPoered Structured Mesh Code Generation from Point Clouds
Bingquan Dai+ Li L.3 Qihong T Jie Wang! 1.5 Xinyu Lian', Hao Xu Minghan Qin?, Xudong Xu', Bo Dai Haoqian Wang??, Zhaoyang Lyu Jiangmiao Pang'
'Sannghai Artificial Intelligence Laboratory "Tsinghua University Harbin Institute of Technology
The University of Hong Kong AA Thrust, HKUST(GZZ)
Beijing Institute of Technology
(a)
Chrir
(b)
Figure 1: (a) MeshCoder predict codes and reconstruct 41 categories of objects. (b) MeshCoder takes in point clouds and produce part-segmented meshes by executing the predicted code in Blender. For the dishwasher, apply transparency to the foremost part to showcase the internal structure.
Abstract
Reconstructing 3D objects into editable programs is pivotal for applications like reverse engineering and shape editing. However, existing methods often rely on limited comain-speciffe languages (DSLs) and small-scale datasets, restricting their ability to model complex geometries and structures. To address these chal- lenges, we introduce MeshCoder, a novel framework that reconstructs complex
"Equal contribution.
"Corresponding authors.
Project leader: Zhaoyang Lyu
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

3D objects from point clouds into editable Blender Python scripts. We develop a comprehensive set of expressive Blender Python APIs capable of synthesizing intricate geometries. Leveraging these APIs, we construct large-scale paired object-code dataset, where the code for each object is decomposed into distinct semantic parts. Subsequently, we train a multimodal large language model (LLM) that translates 3D point cloud into executable Blender Python scripts. Our ap- proach not only achieves superior performance in shape-to-code reconstruction tasks but also facilitates intuitive geometric and topological editing through conve- nient code modifications. Furthermore, our code- oode-based representation enhances the reasoning capabilities of LLMs in 3D shape understanding tasks. Together, these contributions establish MeshCoder as a powerful and flexible solution for programmatic 3D shape reconstruction and understanding. Project homepage: httpss//daabbinguuan
crapauaannnntttttt github. io/MeshCoder
Introduction
Inferring shape programs from 3D observations is of great importance for reverse engineering, shape editing. and 3D structure understanding. Prior work [ has explored this problem by defining Domain-Specific Languages (DSLs) to model geometric and structural properties of objects and training neural networks to map 3D observations to shape programs. However, existing methods struggle to generalize to objects with complex geometry and structure. Two key limitations underlie this gap. First, existing DSLs are constrained to modeling simple primitives (e.g., cubes, spheres, cylinders) and cannot represent real-world objects with intricate parts. Second, training shape-to to-coee inference models demands large-scall scale paired datasets of 3D objects and their corresponding code, while such datasets are scarce. Prior work often relies on datasets with limited categories, geometric complexity and part count.
To address these challenges, we introduce MeshCoder, a novel framework for generating Blender Python scripts that reconstruct complex 3D objects into their constituent parts. First, we design set of expressive Blender Python APIs that are capable of synthesizing intricate geometries beyond simple primitives. For instance, our APIS can create complex shapes by translating 2D section curve along specified trajectory, bridging section curves of different shapes, adding bevels or applying Boolean operations on basic shapes, repeating basic shape in one dimension or two dimensions. With these concise yet powerful Blender Python APIs, we can model highly complex shapes, addressing the limitations of prior DSLs.
Second, we present a novel pipeline to construct a large-scale paired object-code dataset. We begin by synthesizing diverse object parts using our APIs with parametrically sampled parameters, yielding a part-level dataset. A part-to-code inference model is then trained on this dataset to predict code for individual parts. Next, we employ this model to construct a holistic object-code dataset. We use Infinigen-Indoor [4] to generate a dataset of objects, and each object is decomposed into its constituent parts. We use the part-to-code inference model to predict code for each part of an object, and then carefully design rules to concatenate code of all parts to obtain code of the object. This process yields a dataset of approximately million objects spanning 41 categories, with objects up to more than 100 parts. Finally, we train multimodal large language model (LLM) on this dataset to infer code from 3D objects. We use point clouds as 3D shape representations due to their ease of acquisition, and use triplane-based tokenizer to transform the input point cloud to a set of fixed-lengre -enghh tokens. These tokens are fed into the LLM to generate Blender Python scripts that replicate input geometries in distinct semantic parts.
We evaluate our approach against existing shape-to-code methods, with experimental results and quantitative metrics demonstrating that our framework significantly outperforms prior work. Fur- thermore, by representing shapes as executable code, our method facilitates intuitive geometric and topological editing through simple code modifications. This capability enables precise alterations to object geometry and mesh topology, enhancing flexibility in downstream applications. Additionally, we conduct experiments on shape structural and geometric understanding tasks, revealing that our code-based representation improves the reasoning capabilities of large language models (LLMMs) when interpreting 3D shapes. In summary, our contributions are outlined as follows:
2

---

We have developed comprehensive set of Blender Python APIs, facilitating the modeling of intricate geometries. This enhanced API suite empowers the procedural generation of complex 3D structures, effectively addressing the limitations of traditional domain-specific languages (DSL.s) in representing detailed and varied shapes.
We propose pipeline to construct large-scale paired object-code dataset. Using the dataset we constructed, we can train an shape-to-code inference model.
We trained MeshCoder, an Object-to-Code inference framework that generates Blender Python scripts to reconstruct 3D meshes from point clouds in a structured and editable manner. Our model encodes 3D shapes into part-level code, simplifying mesh editing and enhancing LLMS' understanding of 3D objects.
Shape Shape Tokenizer
Large Large Language Model
Clode talem
Clout
bpy bib import
a... (code ignored)
create create_curve curve(nane= 11", control points-[[-one -8.05, -8.22], - [-8.9, -8.05, -8.22]], handle handle_type-(8, 9, 1, 0])
ooject nane:
a part_1: leg
8, 9, 6, 9, 6, B,
create_pr creato_prinstivennee ittoppprinttiioonammooo__.
prinitive cylinder',, location=[ (-0.199, -0.25, 8.21], scale=(9.83, 0.83, 8,25], rotation=(0.31. 8.23, -0.61, 8.7]) a...
fill gilddgnnnnnaee seat 12", #Hickness=8.8790 bevel seat_1l', width:8,84 segnents=1) t... part_ 14: back decoration create prinitiveennnee- back decoration 14', primitive type- cube', location-[--..3 0.45, 0.25], scale-[8.15, 8.05, 8.03], rotation- 6.0, -1.0, 8.06])
# part_5: leg create creste_primitiveete www.nddiieeeeneeeeeeeeeeeeeee lee decoration_s" prinitive_tvee typpe cylinder', location=[-8.16, -2,22, -8.0], scale=(9.03, 0.63, 8.21], rotation=(0.24, 8.87, -8.02, -8.97]) A...
bevel (nameean' decoration_id"; width=0.21, sognents=2)
# part 11: seat
Figure 2: Overview of MeshCoder. The input point cloud first encoded into shape tokens via shape tokenizer. These tokens are then fed into large language model (LLM), which autoregressively generates executable code representing part-based based 3D structures. The decoded code specifies object's name, part identities and names, enabling interpretable and modular reconstruction.
Related Work
Shape programs. Shape programs provide a structured and interpretable framework for representing 3D geometry by utilizing domain-specifit languages to describe the generative processes of shapes. Early work such ShapeAssembly (5) introduced explicit shape programs that capture the hier- archical and part-based organization of objects. Subsequent methods, including ShapeCoder [6], PLAD [2]. and ShapeLib 71, progressively improved program abstraction, learning efficiency, and scalability with large language models. Other approaches, such as those proposed by Liang B and Tian al. [1, incorporate differentiable rendering or neuro-symbolic reasoning to enhance program inference and execution. While these methods exhibit strong generalization capabilities in composing simple geometric elements like boxes and cylinders, they often struggle to model complex part geometries or generate artist-grade quad meshes, which restricts their application in high-fidelity asset creation. addition, a range of methods in CAD program generation [8] 9 [0] [T 12 [3] have explored synthesizing code representations for individual CAD parts. However, these approaches
are limited to isolated component generation and lack the capability to model complete multi-part objects with coherent structural relationships.
Part-based Representation. Part-based representations have proven highly valuable in 3D shape analysis and synthesis. Some approaches [14]
15
16
17
18
19
20
21
22
23 take generative
approach, assembling objects by combining predefined or learned parts into complete 3D structures.
Other methods 24 25 26
27
28
29
30
31
32
33
34
35) focus segmenting 3D objects

---

into individual parts, enabling more modular and flexible manipulation of shapes. For instance, SAMPart3D (24] introduces a scalable zero-shot 3D part segmentation framework that segments any 3D object into semantic parts at multiple granularities without requiring predefined part label sets as text prompts. PIrtSLIIP 28 explores low-shot part segmentation of 3D point clouds by leveraging pretrained image-language model, GLIP, transferring rich knowledge from 2D to 3D through GLIP-based part detection on point cloud rendering and a novel 2D-to-3D label lifting algorithm. SATR [26] performs zero-shot 3D shape segmentation via text descriptions by using zero-shot 2D object detector, inferring 3D segmentation from multi-view 2D bounding box predictions by exploiting the topological properties of the underlying surface. Despite these advancements in part segmentation and reconstruction, these methods do not translate segmented parts into executable code representations, limiting their integration into code-driven design workflows.
3 Methodology
As shown in Figure we aim to train an object-to-code inference model that takes in point cloud of an object, and then predict the Blender python scripts of each part of the object. When executing the python scripts in Blender, we can obtain the same object in separated parts. To train such an object-to-code inference model, we need a dataset of paired objects and the corresponding codes. To obtain such dataset, we first train a part-to-code inference model that predicts code for single part on our synthetic dataset of paired parts and the corresponding codes. Then, given a dataset of objects separated in different parts, we use the trained part-to-code inference model to predict code for every part of an object. Finally, we concatenate the codes of every part of the object and obtain the code of the object. Now, we have dataset of paired objects and the corresponding codes, and are ready to train the object-to-code inference model.
We explain the key steps described above in details in the following sections. First, we explain how to synthesize a dataset of paired parts and the corresponding codes in Section 3.1] Then, we describe the training procedure of the part-to-code inference model in Section 3.2 Next, we use the
part-to-code inference model to obtain the code an entire object in Section 3.3 Finally, we train the object-to-code inference model in Section 3.4
3.1 Part Dataset
We aim to generate a dataset of paired part shapes and codes. To do so, we implement probabilistic programs to generate Blender Python scripts, and obtain the corresponding shape by executing the code in Blender. We carefully design these probabilistic programs and ensure that the shapes generated are within the range [-1, 1 There are several types of shapes that we generate, as We explain them in the following paragraphs.
illustrated in Figure 3
Primitive. Primitives are set of fundamental geometric shapes, consistent with those defined in Blender. Specifically, we consider five basic shapes: cube, cylinder, UV sphere, cone, and torus. Each primitive is parameterized by three attributes: location on (location R'3), rotation (rotation E H)), and scale (scalc R²3, where H denotes the space of unit quaternions. The location specifies the shape's 's position in 3D space, rotation defines its orientation via quaternions, and scale determines the shape's 's size along its local axes. Examples of Primitives can be found in the first row of Figure 3
Translation. Translation is defined as the geometry obtained by sweeping a 2D cross-sectional shape along 3D trajectory curve, which equivalent to Sweep in CAD. As illustrated in the second row of Figure 3 during this translation process, the tangent direction of the 3D trajectory remains perpendicular to the 2D shape, and the size of the section shape can change along the 3D trajectory. For more detailed explanation, please refer to A. To implement this, we first define a 2D shape using a set of control points (i.e., spatial coordinates), and then specify a 3D trajectory curve in a similar manner. Specifically, our experiments consider five types of cross-sectional shapes: rectangles, circles, circular arcs, polygons, and Bézier curves. For the trajectories, we define six forms: straight lines, polylines, circles, circular ares, rectangles, and Bézier curves. Notably, this method also allows a 2D shape to rotate around an axis to form solid of revolution, making suitable for modeling objects such as bottles and plates.

---

Primitive
locatiom: (0.31, -4.0, 0.27], scaler(0.30, 0.30, 9.09), rutatim 0.04, 0.31, -b.27))
type
create, (irve clrved, control 0.25, 0.6l, 9:24, 8.db, 0.81, (1025,, 0.85, e.al, (bith, 8.32, 0.811. handle typont,, 9, 8,
cloadermee centere proffle
Translation
control contol soints [-- 9.8,, w.ed], (6,0,, eun, 8.0), [0.s,, 1811, serll, podnts radlusef., i, 1.8, 2.0), sinlll 3, 3, triceeceesssee capl and")
create curve fouree 11, 'curve 'curve 3r, feurve, " control [1--te at, 0.01, 0.30l 10.90, 0,40, - +2.07]11 patats, rasturnll 4, ciosedeTrus) 'curve 3", "carce 4', "curve 5"1, nuber cutsmi, suottrmssse.d., interpolation sustAce" fill capse both")
Bridge Loop
www.iriveieeeeeeeeeeee. tool", peieitive
lecatione
s.a), scall-fa is, 8.55, 1.0), retatiorejo 0.5, 0.5, 5.53) create prattateeeee bool2" pessitive typee locaiinnfs s.d, 6.d), scaloff b.4), retacione( solionn.perationn bool
Boolean
create pwwpttiieetseeeeeooo...... cabe', prinitive 'ome' lecationi 0.07, -8. 2.38), 2000s 0.0050, 1.2005), rotationiD.et,, -0.49 0.35, -0,70), applyeTrus)
Army
constant offast/ 9,012, 0.032, 0.22])
Figure 3: Visualization of basic geometric shape types and their corresponding code. For each shape category, the code shown corresponds to the first example.
Bridge loop. Although the Translation method is capable of generating certain complex objects, remains constrained in several ways. For instance, the Translation operation, the 2D cross- sectional shape is always orthogonal to the tangent direction of the trajectory. Moreover, the section shape is allowed to change only in scale, without any deformation in geometry. address this limitation, introduce alternative method for constructing geometries, namely the Bridge Loop. This geometry is constructed by first generating a sequence of 2D shapes and then connecting their corresponding vertices to form continuous 3D geometry, which is equivalent to Loft in CAD. Some cases can be seen the third row of Figure 3 The Bridge Loop approach enables the creation of more complex geometries compared to those achievable via Translation alone. For more detailed explanation, please refer to A.
Boolean geometries refer to geometries formed by applying Boolean operations-namell union, intersection, and difference-to two or more the fundamental shape categories defined in Section 3.1 The union operation enables the construction of complex composite geometries, while the difference operation is used to generate geometries with holes or indentations. We can see some examples and their corresponding codes in the fourth row of Figure 3
Boolean.
Array. When particular type of primitive geometry appears repeatedly in regular pattern, do not invoke the construction function for each primitive individually. as this would result in lengthy code. Instead, we employ an Array method construct the entire structure collectively. Specifically, we define two types of Arrays: ID Arrays, where geometry is repeatedly instantiated along curve, and 2D Arrays, where repetition occurs across a plane. Cases of this type can seen the last row of Figure 3
It is important note that when designing our functions, the function parameters include two types: array-based parameters and individual parameters. During dataset construction, we select the parameter format based on the most suitable fit for the object: individual parameters are used for simpler parts, while array-based parameters are adopted when a part contains multiple similar shapes. For instance, the translation example in Figure 3 uses individual parameters, whereas the bridge loop example employs array-bat based parameters.
After designing the five fundamental types of template functions described above, we perform probabilistic random sampling over these functions and their parameters to generate a series of function code snippets. For each sampled code snippet y, execute obtain the corresponding mesh M. In this way, we construct dataset of paired code y and mesh M.
5

---

3.2 Part-to-code Inference Model
After constructing the dataset of paired code y and mesh M, we sample a point cloud R Vx3 from each mesh M, where N is the number of points in the point cloud. We train part-to-code inference model h that takes in a point cloud and predict the corresponding code y. The inference model consists of two modules: The shape tokenizer model and fintuned L.M. The tokenizer model takes in the point cloud x and outputs a set of fixed length tokens 2 E RL*D where is the number of shape tokens and D is the dimension of each token. We set D) to the same dimension as the word embeddings in the LLM. Thereafter, the LLM takes in the shape tokens & and then predict y, the code of the point cloud æ. We train the shape tokenizer model and finetune the LLM at the same time using the cross-entropy loss for the prediction of the next token the shape code y. We use Llama-3.2-1 as the base LLM and finetune it using LoRA.
Leanshll
Transformer blocks
Self Altemiin
Cross Ausention
MLP
Figure 4: Architecture of the shape tokenizer. We first project the point cloud into the triplane and obtain triplane features. The triplane features patchified and reshaped into ID sequence, and fed into transformer blocks to obtain triplane tokens. Finally, we use set of learnable tokens to aggregate information from triplane tokens via cross-attention.
The shape tokenizer model. We explain the detailed structure of the shape tokenizer model. As shown in Figure 4] the shape tokenizer model transforms point cloud RRNxx set of fixed length tokens E RLXDD We first project the point cloud æ to a triplane and obtain triplane feature R xD, where H, W the height and width of the planes, and Dj is the dimension of the triplane feature. The coordinates of each point is fed to shared MLP and feature of dimension D2 obtained. We project each point's feature the three perpendicular planes according to the point's position. Features projected to the same pixel are aggregated by max-pooling, Pixels that do not correspond to any point are filled with zeros. After obtaining the triplane feature u. we patchify and reshape it into 1D sequence & E (B(3-///-//f)x/ the sequence
where is the patch size. We then feed set of transformer blocks and outputs v' ff3-H//fw/f))x
Next, to compress the number tokens fed into the LLM, we use a learnable set of tokens w E LLxD2 to aggregate information from o' using cross attention:
CrossAttm (TrattttnrTossoomrr(r... w), ,'))',
where Transformer denotes a transformer block, CrossAttn (2attn((244) K, V) denotes cross attention block, and Q, K, V are query, key, value, respectively. By feeding w a of these cross attention blocks, we obtain tokens w' E R Lx Da that contain information about the point cloud æ. Finally, we use an MLP to transform the dimension of w' from D2 to D and obtain shape tokens z e IR LxD where D is the dimension of the word embeddings in the LLM. Now, the shape tokens can be readily fed to the LLM and predict the code corresponding to the point cloud æ.
3.3 Assemble Parts to Objects
After training the part-to-code inference model h. we can use it to obtain the code of an object. Given dataset of objects, in which each object O separated into its constituent parts O {q.
1, ..... M). where q: is the i-th part of object O, and M is the number of parts of the object O. We also assume that each part qi has its semantic label. We can use the part-to-com inference model h to obtain the code of each part. Specifically, we first normalize each part to the cube 1, according to its minimum bounding box and obtain the shape l. Then we use the part-to-code inference model h to obtain its code y h(g.). We then implement algorithms to transform the relevant numerical parameters in the code y to the original location, scale, and pose of q' and obtain the code y, of the original shape q. Finally, concatenate the codes of all parts of

---

the object, add semantic information to the code for each part, and obtain the code of the object y = (3:li 1, 1. 2....... .. When concatenating the code, we each part based on its spatial position. Specifically, we assign index to each part following a spatial order from bottom to top, left to right, and front to back. An overview of this pipeline is illustrated in Figure During code inference, the part point cloud is first transformed into canonical space using rotation matrix R. translation matrix T, and scaling factor 8, resulting qf The trained part-to-code inference model h generates the code y of q/- y is then transformed back to the original pose and scale using the inverse of R, T. and 8, and we obtain the code y: of qi-
Canonical Space
A
91
42
qM
R,T
h
R 1-1111
Code Inference
Part-to-code Inference
Vi
qi
y/2
Y2
YM
#t object_name name
# part_1, name
create centttoprintttvvenaeeee "cy prinitive sypee typetyyyleette "yllndder', location=[-B.4 yi -0.0, -0.01, scale=[0.11, 8.11, 1.01, rotation=[0.6, -0.69, -8.72, 8.0])
Y1
1f part_2, _2, name
Yt create, ceatte.prriiiie(aaeeee 'eg 1', prinitive types' "pe=secylnder', locations[-0.22 0.25, -8.21], scale-[o.03, 0.e3, 0.25], rotation-(8.71, -8.66, -0.e8, -8.22])
y22
# part_M, name_N
Figure 5: Pipeline of object-level code dataset construction using the part-to-code inference model. For each part point cloud qi the code inference module independently predicts its corresponding code yi- All part codes y; are then concatenated to form the complete object code. We also add meaningful semantic information to the object code following the template shown in the figure. The complete code of the example chair is shown in Figure 2
3.4 Object-to-code Inference Model
After obtaining the code y of each object O in the dataset, inference model. Our object-to-code inference model has the same structure as the part-to-code inference model described in Section 3.2 We initialize the weights of the object-to-code inference model as the weights of the trained part-to-code inference model, and use the same training method inference model. It is worth noting semantic information in
them train object-to-code
in Section 3.2 to train the object-to-cont the ground-truth code of objects enables the object-to-code inference model to learn the semantic structure of objects, and facilitate 3D shape understanding.
4 Experiment
4.1 Datasets
4.1.1
Synthetic Part Dataset
To facilitate the training our part-to-inference model, first constructed synthetic part dataset. Specifically, we utilized functions from our basic shape code library, randomly sampling their parameters based on manually defined distributions generate paired data of synthetic parts and corresponding code. This process yielded 1.5 million point cloud-cod pairs for primitive shapes, million for Translation- parts, 1.5 million for Bridge Loop structures, 1.5 million for Boolean operations, and 2.4 million for Array-based constructions. In total, our constructed part dataset comprises around 10 million point cloud-code pairs. We partitioned the dataset into 70% for training, 15% for validation, and 15% for testing.

---

4.1.2 Object Dataset
We trained our model on the Infinigen Indoor []] dataset. Infinigen Indoor is procedural framework for generating synthetic 3D indoor objects, where each generated instance is automatically composed by its corresponding parts. We have made extensive modifications to the original Infinigen codebase to enable it to produce both individual components and their complete assemblies. Using this framework, constructed synthetic dataset comprising 41 common object categories, generating million object-code pairs in total. We partitioned the dataset into training, validation, and test sets, following the same split strategy the Synthetic Part Dataset. For more details, please refer to the
4.2 Implementation Details
We conduct training and evaluation on the Infinigen Indoor datasets 36). For the part-to-code reconstruction model, adopt the AdamW optimizer and train it for 20 epochs NVIDIA A 100 GPUs with a batch size of 512, and a learning rate of 10- We evaluate the model at every epoch and select the checkpoint with the lowest L2 Chamfer Distance (CD) loss. Then we initialize the weights of the object-to-code reconstruction model with the weights of the trained part-to-code reconstruction model, and train the model on Infinigen Indoor dataset for 10 epochs, with a batch size of 256, and learning rate of 10-4. The checkpoint with the lowest CD loss is selected. For additional training details and the parameter settings of the models, please refer to A.3 and A.2
4.3 Reconstruction Performance
For reconstruction performance, compare our method with two representative shape-to-code baselines, Shape2Prog [ and PLAD (2). Figure@Billustrates visualization comparisons results. We adopt IoU and L2 CD outputs into 32 grids and compute the IoU between the predicted and ground truth voxel grids. In parallel, sample point clouds from both the predicted outputs and the ground truth, and calculate the Chamfer Distance between the two point clouds. Regarding the number of points and normalization, please refer the appendix A.4 In Table T present reconstruction metrics for some specific object categories as well as the overall performance across the entire dataset. It can be observed that our method consistently outperforms the baselines in both IoU and CI) metrics. Complete results for all categories in each dataset are provided in A.4] We conducted a series of ablation studies evaluate the impact of various components within our model. For comprehensive details on these experiments, please refer to A.4
evaluation metrics. Specifically, voxelize the model's is predicted
Table Quantitative comparison of reconstruction performance between MeshCoder and baselines.
CD(x10 3)
IoU (%)
Method
Lamp
Chuir
Sofa
TableDining
Toilet
All
Lamp
Chuir
Sofa
TableDining
Toilet
All
Shape2Prog
25,44
1.30
2.14
1.03
7.51
6.01
16.96
49.68
65.29
71.26
51.14
45.03
PLAD
1.4
2.26
1.52
5.52
2.30
1.87
69.58
40.93
81.33
58.43
62.61
67.62
MeshCoder
0.004
0.060
0.027
0.024
0.022
0,063
86.23
81.87
93.81
88.14
89.10
86.75
4.4 Shape Editing
MeshCoder facilitates the transformation of 3D shapes into high-level, human-readable code repre- sentations, significantly enhancing the interpretability and editability of complex geometries. This capability enables intuitive and precise modifications through code-based interventions. Our shape editing encompasses two primary categories: geometric editing and topological editing. As illustrated geometric editing can be performed by adjusting function calls or modifying specific parameters within the generated code. For instance, can adjust the parameters of the code to convert a square tabletop into larger circular one. Additionally, topological editing, which is illustrated in Figure such as adjusting mesh resolution, can be achieved by modifying designated parameters within the code, allowing for control over the mesh's 's complexity and surface detail. This code-centric approach streamlines the process of modifying 3D models, making it more accessible and efficient for applications requiring iterative design and customization. Additionally, it empowers users to adjust the model resolution according to their desired balance between storage requirements and mesh quality. For additional results and details, please refer to A.5 in the appendix.
in Figure 7

---

GT
Phape2Prog
PLAD
MeshCoder
Figure 6: Qualitative comparison of reconstruction performance between MeshCoder and baselines. MeshCoder can accurately reconstruct objects with intricate parts and complex structures.
create create_curve(-) curve(..)
create create_curved curve(..)
create create_prinitie prinitive (prinitive type= feylinder" scaale sccale -[8.4, 8.4, 0.03]-)
bridge adge loops
bridge edge loops(..) create prinitiveelocctiion 0.0, +1.5], boolean operation(operations IFFERENCE",
create prinitive (prinitive_ type= teube"l, scale=(00 26, 8.28, 0.03)..)
prinitsie(cocationn-PP 0.0, 0.0], -) boolean, weweeeannprratiionno ( IFFERENCE',..
Figure 7: Parameter modification the code conveniently to alter the geometric shape. Left: Change tabletop from square to circular. Right: Make the bathtub shallower.
4.5 Shape Undertanding
MeshCoder is capable of predicting object codes with rich semantie information. These codes effectively capture structural and geometric de- tails, making them valuable for shape under- standing. By inputting the predicted codes into GPT, we can assist it in comprehending object structures. We conduct experiments on shape understanding, with an example illustrated in Figure 9 Additional results and details are given in A.6
MesliCader
soject office chaie
sprered
crazra, cade sgiceed
cenere: wisl tor
Quotas Hay may vinca cac daar!
GPT-
the appendix.
Figure 9: The pipeline of conducting experi- ments shape understanding.
Limitations
Although our method achieves significant advancements in category diversity, geometric complexity. and reconstruction accuracy compared existing approaches, it primarily targets human-made objects. The applicability of code-based representations to organic forms, such as animals and humans, remains underdeveloped. reserve this as a direction for future research.
Conclusion
In this work, we present MeshCoder, comprehensive framework that translates 3D point cloud data into editable Blender Python scripts, enabling detailed reconstruction and intuitive editing of complex 3D objects. By developing robust set of Blender Python APIs, we facilitate the modeling of intricate geometries. Leveraging these APIs, we constructed a large-scale dataset pairing 3D objects with their corresponding code representations, decomposed into semantic parts. Subsequently,

---

bezter, rotation fresolations,,
bezter, rotation tresclutiones,
rotation (reselutiion24,
tresslutions
(resoliitionad
(resoliction)
Apm)
Figure 8: Mesh resolution adjustment by modifying the resolution parameters in the code. The figure depicts results with progressively increasing resolution from left right.
trained multimodal large language model (LLM) capable of generating executable Blender scripts from point cloud inputs. Our approach not only achieves superior performance in shape-to-code reconstruction tasks but also enhances the reasoning capabilities of LLMs in 3D shape understanding. By representing shapes as structured code, MeshCoder offers a flexible and powerful solution for programmatic 3D shape reconstruction and editing, paving the way for advanced applications in reverse engineering, design, and analysis.
7 Acknowledgement
This work is funded by the Shenzhen Science and Technology Project (Grants 000020011100001000 and KJZZD2024093303320000 the National Key R&D Pro- gram of China (Grant 2022ZD0160201, Shanghai Artificial Intelligence Laboratory, and in part by the HKU Startup Fund.
References
[1] Yonglong Tian, Andrew Luo, Xingyuan Sun, Kevin Ellis, William T. Freeman, Joshua B. Tenenbaum, and Jiajun Wu. Learning infer and execute 3d shape programs. International Conference on Learning Representations, 2019.
[2] Kenny Jones, Homer Walke, and Daniel Ritchie. Plad: Learning to infer shape programs with pseudo-labels and approximate distributions. In Proceedings of the IEEE/CVF Conference Computer Vision and Pattern Recognition, pages 9871-9880, 2022.
[3] Yichao Liang. Learning to infer 3d shape programs with differentiable renderer. arXiv preprint arXiv:2206. 12675, 2022.
[4] Alexander Raistrick, Lingjie Mei, Karhan Kayan, David Yan, Yiming Zuo, Beining Han, Hongyu Wen, Meenal Parakh, Stamatis Alexandropoulos, Lahav Lipson, Zeyu Ma, and Jia Deng. Infinigen indoors: Photorealistic indoor scenes using procedural generation. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), pages 21783-21794, June 2024.
[5] Kenny Jones, Theresa Barton, Xianghao Xu, Kai Wang, Ellen Jiang, Paul Guerrero, Niloy J Mitra, and Daniel Ritchie. Shapeassembly: Learning to generate programs for 3d shape structure synthesis. ACM Transactions on Graphics (TOG), 39(6):1-20 2020.
[6] R Kenny Jones, Paul Guerrero, Niloy J Mitra, and Daniel Ritchie. Shapecoder: Discovering abstractions for visual programs from unstructured primitives. ACM Transactions on Graphics (TOG), 42(4):1-17, 2023.
[7] R Kenny Jones, Paul Guerrero, Niloy J Mitra, and Daniel Ritchie. Shapelib: designing library of procedural 3d shape abstractions with large language models. arXiv preprint arXiv:2502.08884 2025.
[8] Pradeep Kumar Jayaraman, J. Lambourne, Nishkrit Desai, Karl Willis, Aditya Sanghi, and Nigel Morris. Solidgen: An autoregressive model for direct b-rep synthe- sis. ArXiv, abs/2203. 2022. URL. htttts://aaapp htatts/:/app..mmmticcccccolooo somaattteeehhllarr...o////oooop
semanticscholar. org/Corpus
247761924
10

---

[9] Mohammad Sadil Khan, Elona Dupont, Sk Aziz Ali. Kseniya Cherenkova, Anis Kacem, and Djamila Aouada. Cad-signet: Cad language inference from point clouds using layer-wise sketch instance guided attention. In Proceedings of the IEEF/CVE Conference on Computer Vision and Pattern Recognition (CVPR), pages 4713 4722, June 2024.
[10] Rundi Wu, Chang Xíao, and Changxi Zheng. Deepcad: deep generative network for computer- aided design models. In 202/ IEEE/CVE International Conference on Computer Vision (ICCV), pages 6752-6762, 2021. doi: 10.1 109/CCCV49922 2021 200100670...... 000600
[11] Jingwei Xu, Zibo Zhao, Chenyu Wang, Wen Liu, Yi Ma, and Shenghua Gao. Cad-milm: Unifying multimodalliy--ooniiiiio
cad generation with milm, 2024.
[12] Xiang Xu, Pradeep Kumar Jayaraman, Joseph G Lambourne, Karl DD Willis, and Yasutaka Furukawa. Hierarchical neural coding for controllable cad model generation. In International Conference on Machine Learning, pages 38443-38461, 2023.
[13] Jianyu Wu, Yizhou Wang, Xiangyu Yue, Xinzhu Ma, Jingyang Guo, Dongzhan Zhou, Wanli Ouyang, and Shixiang Tang. Cmt: cascade mar with topology predictor for multimodal conditional cad generation, 2025.
[14] Juil Koo. Seungwoo Yoo, Minh Hieu Nguyen, and Minhyuk Sung. Salad: Part-level latent diffu- sion for 3d shape generation and manipulation. In Proceedings of the IEEE/CVF International Conference on Computer Vision, pages 14441-14451 2023.
[15] Anran Liu, Cheng Lin, Yuan Liu, Xiaoxiao Long, Zhiyang Dou, Hao-Xiang Guo, Ping Luo, and Wenping Wang. Part123: part-aware 3d reconstruction from single-view image. In ACM SIGGRAPH 2024 Conference Papers, pages 1-12, 2024.
[16] Minghao Chen, Roman Shapovalov, Iro Laina, Tom Monnier, Jianyuan Wang, David Novotny, and Andrea Vedaldi. Partgen: Part-level 3d generation and reconstruction with multi-view diffusion models. arXiv preprint 2..iv:2412218600 2024.
[17] Yuhang Huang, SHilong Zou, Xinwang Liu, and Kai Xu. Part-aware shape generation with latent 3d diffusion of neural voxel fields. arXiv preprint WrXiv24055000998 2024.
[18] Lin Gao. Jie Yang, Tong Wu, Yu-Jie Yuan, Hongbo Fu, Yu-Kun Lai, and Hao Zhang, Sdm-net: Deep generative network for structured deformable mesh. ACM Transactions on Graphics (TOG), 38(6):1-55 2019.
[19] Zhijie Wu, Xiang Wang, Di Lin, Dani Lischinski, Daniel Cohen-Or, and Hui Huang, Sagnet: Structure-aware generative network for 3d-shape modeling. ACM Transactions on Graphics (TOG), 38(4):1-14, 2019.
[20] Kaichun Mo, Paul Guerrero, Li Yi, Hao Su, Peter Wonka, Niloy Mitra, and Leonidas J Guibas. Structurenet: Hicrarchical graph networks for 3d shape generation. arXiv preprint arXiv:: /908. 00575, 2019.
[21] Rundi Wu, Yixin Zhuang, Kai Xu, Hao Zhang, and Baoquan Chen. Pq-net: A generative part seq2seq network for 3d shapes. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, pages 829-838. 2020.
[22] George Kiyohiro Nakayama, Mikaela Angelina Uy. Jiahui Huang, Shi-Min Hu, Ke Li, and Leonidas Guibas. Difffacto: Controllable part-based 3d point cloud generation with cross diffusion. In Proceedings of the IEEF/CVF International Conference on Computer Vision, pages 14257-14267, 2023.
[23] Dmitry Petrov, Matheus Gadelha, Radomír Měch, and Evangelos Kalogerakis. Anise: Assembly- based neural implicit surface reconstruction. IEEE Transactions Visualization and Computer Graphics, 2023.
[24] Yunhan Yang, Yukun Huang, Yuan-Chen Guo, Liangjun Lu, Xiaoyang Wu, Edmund Y Lam, Yan-Pei Cao, and Xihui Liu. Sampart3d: Segment any part in 3d objects. arXiv preprint 241002241, 2024.
11

---

[25] Hengshuang Zhao, Li Jiang, Jiaya Jia, Philip HS Torr, and Vladlen Koltun. Point transformer. In Proceedings of the IEEE/CVF international conference on computer vision, pages 16259-16268, 2021.
[26] Ahmed Abdelreheem, Ivan Skorokhodov, Maks Ovsjanikov, and Peter Wonka. Satr: Zero-shot semantic segmentation of 3d shapes. In Proceedings of the IEEE/CVF International Conference on Computer Vision, pages 15166-15179, 2023.
[27] Zongji Wang and Feng Lu. Voxsegnet: Volumetric enns for semantic part segmentation of 3d shapes. IEEE transactions on visualization and computer graphics, ((()):291--293)) 2019.
[28] Minghua Liu, Yinhao Zhu, Hong Cai, Shizhong Han, Zhan Ling, Fatih Porikli, and Hao Su. Partslip: Low-shot part segmentation for 3d point clouds via pretrained image-language models. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, pages 21736-21746,, 2023.
[29] Yuchen Zhou, Jiayuan Gu, Xuanlin Li, Minghua Liu, Yunhao Fang, and Hao Su. Partslip++: Enhancing low-shot 3d part segmentation via multi-view instance segmentation and maximum likelihood estimation. arXiv preprint arXiv:2312.03011 2023.
[30] Yuheng Xue, Nenglun Chen, Jun Liu, and Wenyun Sun. Zerops: High-quality cross-modal knowledge transfer for zero-shot 3d part segmentation. arXiv preprint arXiv:2311. 142262,..222 2023.
[31] Ardian Umam, Cheng- Kun Yang. Min-Hung Chen, Jen-Hui Chuang, and Yen- Yu Lin. Partdistill:
3d shape part segmentation by vision-language model distillation. In Proceedings of the IEEF/VV Conference on Computer Vision and Pattern Recognition, pages 3470-3479, 2024.
[32] George Tang, William Zhao, Logan Ford, David Benhaim, and Paul Zhang. Segment any mesh: Zero-shot mesh part segmentation via lifting segment anything 2 to 3d. arXiv preprint arXiv:2408. 13679, 2024.
[33] Anh Thai, Weiyao Wang, Hao Tang, Stefan Stojanov, James M Rehg, and Matt Feiszli. 3x 2: 3d object part segmentation by 2d semantic correspondences. In European Conference on Computer Vision, pages 149-166. Springer, 2024.
[34] Ziming Zhong, Yanyu Xu, Jing Li, Jiale Xu, Zhengxin Li, Chaohui Yu, and Shenghua Gao. Meshsegmenter: Zero-shot mesh semantic segmentation via texture synthesis. In European Conference on Computer Vision, pages 189-199.900 Springer, 2024.
[35] Xiangyang Zhu, Renrui Zhang, Bowei He, Ziyu Guo, Ziyao Zeng, Zipeng Qin, Shanghang Zhang, and Peng Gao. Pointelip v2: Prompting clip and gpt for powerful 3d world learning. In Proceedings of the IEEE/CVF international conference on computer vision, pages 2639-2650. 2023.
[36] Kaichun Mo, Shilin Zhu, Angel X. Chang, Li Yi, Subarna Tripathi, Leonidas J. Guibas, and Hao Su. PartNet: A large-scale benchmark for fne-grained and hierarchical part-level 3D object understanding. In The IEEE Conference on Computer Vision and Pattern Recognition (CVPR), June 2019.
[37] Tencent Hunyuan3D Team. Hunyuan3d 2.0: Scaling diffusion models for high resolution textured 3d assets generation, 2025.
[38] Jianfeng Xiang, Zelong Lv, Sicheng Xu, Yu Deng, Ruicheng Wang, Bowen Zhang, Dong Chen, Xin Tong, and Jiaolong Yang. Structured 3d latents for scalable and versatile 3d generation. arXiv preprint arXiv:2412.01506, 2024.
[39] Matt Deitke, Dustin Schwenk, Jordi Salvador, Luca Weihs, Oscar Michel, Eli VanderBilt, Lud- wig Schmidt, Kiana Ehsani, Aniruddha Kembhavi, and Ali Farhadi. Objaverse: A universe of annotated 3d objects. 2023 IEEE/CVF Conference Computer Vision and Pattern Recognition (CVPR), pages 13142-13153, 2022. URL https:/t semanticscholar. org/CorpusIDD 254685588
12

---

[40] Rafael Rafailov, Archit Sharma, Eric Mitchell, Stefano Ermon, Christopher D. Manning, and Chelsea Finn. Direct preference optimization: Your language model is secretly reward model. ArXiv, abs/2305.18200 2023. URI. httpss//apl semant semanticscholar
258959321
[41] Qihao Zhu Runxin Xu Junxiao Song Mingchuan Zhang Y.K. Li Y. Wu Daya Guo Zhihong Shao, Peiyi Wang. Deepseekmath: Pushing the limits of mathematical reasoning in open language models, 2024. URL httphhtts://ett
btttpps:/arxtie /ttpvv/aaxvvvv/.. Borg/abs/200 2402. 03300
[42] Ruowen Zhao, Junliang Ye, Zhengyi Wang, Guangce Liu, Yiwen Chen, Yikai Wang, and Jun Zhu. Deepmesh: Auto-regressive artist-mesh creation with reinforcement learning. arXiv preprint arXiv:2503. 15265, 2025.
13

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: Yes, they can reflect the paper's contributions and scope.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results
be expected to generalize other settings.
is fine to include aspirational goals as motivation as long is clear that these goals are not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification:
We do discuss the limitations of the work.
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those not discussed in the paper.
The authors are encouraged to create separate "Limitations" section in their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification. asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution low images are taken in low lighting. Or speech-to-text system might be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach address problems of privacy and faimess.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren't 't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
3. Theory assumptions and proofs
Question:
For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [Yes]
14

---

Justification:
We have discussed them in our paper.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated referenced in the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but they appear in the supplemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that affects the main claims and/or conclusions of the paper (regardless whether the code and data are provided or not)?
Answer: [Yes]
Justification:
We have elaborated on work in detail in our paper.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g.. in the case of large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) If the contribution is primarily a new algorithm, the paper should make clear how to reproduce that algorithm. (b) the contribution is primarily a new model architecture, the paper should describe the architccture clearly and fully.
(c) If the contribution is new model (e.g., a large language model), then there should either way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome to describe the particular way they provide for reprodueibility. the case of closed-source models, may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers have some path to reproducing or verifying the results.
5. Open access to data and code
Question: Does the paper provide open access to the data and code, with sufficient instruc- tions to faithfully reproduce the main experimental results, as described in supplemental material?
15

---

Answer: [Yes]
Yes, we will provide open access to the data and code.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurlPS code and data submission guidelines (https://nips.cm
woooooooocccy for more details.
While we encourage the release of code and data, we understand that this might not be possible, so "No" an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https
/ ccpppp.ccppulli//guuii wwwtii/gguie///eeeeceoocc CoodeSubeiiieeee ssi wswonnolli onnolicy)))) for more details.
The authors should provide instructions on data access and preparation, including how access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification:
We specify all the training and test details in the paper.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, or as supplemental material.
7. Experiment statistical significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Answer: [Yes]
Justification: Yes, we mentioned some limitations and indicators.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi- dence intervals, statistical significance tests, at least for the experiments that support main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
should be clear whether the error bar is the standard deviation the standard error of the mean.
16

---

It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of enrors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out range (e.g. negative error rates).
If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?
Question:
Answer: [Yes]
Justification: Yes, mentioned that in our paper.
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g.. preliminary or failed experiments that didn't make into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics sattps://neur// http://............ttttcccsueaa.
Answer: [Yes]
Justification:
We obey the NeurIPS Code of Ethics.
Guidelines:
The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special cireumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g., if there is a special consid- eration due to laws or regulations their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification:
We mentioned the real-world impact of the work.
Guidelines:
The answer NA means that there is no societal impact of the work performed.
If the authors answer NA or No. they should explain why their work has no societal impact or why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that improvement in the quality of generative models could be used to
17

---

generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
there are negative socictal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [Yes]
Justification:
We declare that what we using is a public dataset.
Guidelines:
The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards challenging, and many papers do require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Are the creators original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Question:
Answer: [Yes]
Justification:
We have done that.
Guidelines:
The answer NA means that the paper does not use existing assets.
The authors should cite the original paper that produced the code package dataset.
The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (c.g., website), the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, wwppppswpptseeee whworee.wthhhe....c. com/ datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if has changed) should be provided.
this information is not available online, the authors are encouraged to reach out to the asset's is creators.
13. New assets
Question: Are new assets introduced in the paper well documented and the documentation provided alongside the assets?
18

---

Answer: [Yes]
Justification: We will make our data public.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details the dataset/codd/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset used.
At submission time, remember to anonymize your assets (if applicable). You can either create anonymized URL or include an anonymized zip file.
14. Crowdsourcing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well details about compensation (if any)?
Answer: [No]
Justification:
We did not conduct such experiments.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included the main paper.
According to the NeurIPS Code of Ethics, workers involved in data collection, curation, other labor should be paid at least the minimum wage in the country of the data collector.
Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [No]
Justification:
We did it open data, there potential dangers.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Depending on the country in which research is conducted, IRB approval (or equivalent)
may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Question: Does the paper describe the usage of LLMs if it is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigorousness, originality of the research, declaration is not required.
Answer: [Yes]
19

---

Justification:
LLM is part of our model, and we 've fine-tuned it.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, or non-standard components.
Please refer to our LLM policy http:s/s//eerrpppocccc//o/rrrees for what should or should not be described.
20

---

A Appendix of MeshCoder: LLM-Powered Structured Mesh Code
Generation from Point Clouds
A.1 Datasets
A.1.1 The principles of Translation and Bridge Loop
Translation
Bridge Loop
Figure 10: A schematic illustration of the principles of Translation and Bridge Loop. In the Translation module. the wireframe of the resulting mesh is shown as a cross cross-sectional circle is translated along yellow trajectory. the Bridge Loop module, the wireframe of the mesh constructed by connecting the vertices of two 2D shapes.
As illustrated in the figure T0 in the Translation operation, a cross-sectional shape (a circle in this example) and 3D trajectory curve must first be defined. The Translation process generates mesh by sweeping the 2D shape along the 3D trajectory. During this sweep, the cross- cross-section remains perpendicular to the tangent direction of the trajectory at all times, and only uniform scaling (either enlargement or reduction) of the cross-section permitted.
In contrast, the Bridge Loop operation begins with two predefined 2D shapes. By connecting the corresponding vertices of these two shapes, mesh can constructed. This method places no constraints on the types of 2D shapes used meaning the two shapes can differ, such as circle and a irregular closed shape this example. Moreover, it imposes no restrictions on the relative orientations of the shapes. As a result, Bridge Loop overcomes the limitations of Translation, which requires the cross-section to align with the trajectory's tangent direction. This enables Bridge Loop to generate more complex geometries that Translation cannot produce.
A.1.2 Part datasets
create_cureee coante__cureeeameeeeie 'seat__' control_points-et handle_type=(0.0, 0.0, 1.0, 1.0, 0.0, 0.0, 0.0, ...))
Fill Grid
(ameeedad===seeaa __",, thickness=0. 04771) bevel(name= seaat_9 9', width=0. segments=1)
create_spoon(( 'spoo' , thickness=sss0.01 , (9. .., w..46l.y_anchors-e 0. 2.01),2__nchors::00.66 |ot
"
Spoon
create_
1
kts=3.0,x_anchorsse y y_anchors=[-1), 2 2_anchors=[-.,, location=[-.,,, rotation=[-], scale=[-]])
Fork
Figure 11: The Fill Grid type, Spoon type and Fork type in basic shape code library
For certain shapes that are difficult to represent using the method we defined Section 3.1 we introduce three additional categories: the Fill Grid type, Spoon type and Fork type. As illustrated in the Figure TT. For the Fill Grid type, we first construct closed 3D shape (as opposed to 2D cross- cross-scctional shape used in Translation), fill it to form surface, and then extrude it along its
21

---

normal direction to generate the final mesh. For the Spoon and Fork type, we draw inspiration from the implementation in Infinigen Indoor and design dedicated procedural functions tailored for their generation.
We present
functions from codebase: the complete implementation for creating primitives (Figure (22) and the complete implementation for creating curves (Figure 23 The full codebase can be found in the supplementary materials.
More examples of parts and their corresponding complete code implementations are provided in Figures 12
and 16
Iiport 1788 tayale s1oor
64 ML. retettae
Figure 12: Examples of Primitive and complete code. And the code corresponds to the first two objects shown the figure.
Frzl with dipart radlans,
ail Joe's raclas,
ACote a013)
Nores XlD
centrol wetrereet 9.11, 18.43, 9.4, E.l 1..7, 8.3. bymnlh
Diett caree, cenoet wore i.l, e.dl, Beis, wol, Bu 6.6, Boss, 5.3 11,9 8.1 wette will, aiteelll (M) bondi howdlh io hochoweee weme
Figure 13: Examples of Translation and complete code. And the code corresponds to the first two objects shown in the figure.
Aigrrt
Expert Eay
Seport
coumru sirte rook's, prodttio 'o0traen,, louatia [-0.0, -6.0],
Jocecioe sode
en secto pedaitiinn,ppe Vutataes Jesstan[--..9, 6.0, -6,4) Sh 14). werttieele..
crente cuttin Ssoce (r20120n pue cas Aeantionna 2i, 8.41, s.ad, mosets. suado Bood Boutd
Figure 14: Examples of Boolean and complete code. And the code corresponds to the first two objects shown in the figure.
Taking the Primitive type as an example, we describe how use functions from the basic shape code library to generate synthetic part dataset. We begin by randomly selecting the type of primitive generate (c.g., cube, cylinder, etc.). Next, for each axis, we independently uniform sample a value x from the range [- and then set the corresponding scale as 10". To determine the orientation of the shape, we uniformly sample direction from unit sphere and roll angle from uniform distribution. Once the orientation is fixed, we scale the shape uniformly along all three axes based on the size of bounding box. Specifically, we ensure that the longest edge of bounding box lies within the range [1, 2]. Finally, we assign the shape a random position within the 3D space such that the entire shape remains within the [-1, bounds. For other shape types beyond Primi tive, we follow similar approach by randomly assigning values to the relevant parameters.
22

---

Free tore relery byy
virts Whatt vitcle
sorl, of 6.n Gal. 16.0 M. Kal ftot 16 koull: inoi
s.mn). anatie moae TErtAE
Figure 15: Examples of Bridge Loop and complete code. And the code corresponds to the first two objects shown in the figure.
Froe Aath palfer,
ley Japart
proettistteeee tooe Scoetiorate
9.30,, 8.09e],
NJ) seaiegh 5.300,, 8.8101) reteiiimpp.l 18.00
Matklawe 11,, 28,, artattii
Jocntle- (6.ta, 20), rosle rann).
Jehaam loder' Nilloye room, coar, coutiily sancual Lattherdd
wre. Jotheaa Ca8 fir nowe (240 Joa coared, contert offine"" 2000 144) (171)
Figure 16: Examples of Array and complete code. And the code corresponds to the first two objects
shown in the figure.
A.1.3 Object datasets
For assembling part codes into complete program, provide full example containing the complete code, as shown in Figure 17 Regarding the ordering strategy used when assembling parts into complete object, adopt consistent spatial heuristic to determine part sequence. Specifically, parts are arranged from bottom to top, left to right, and front to back. To implement this, we divide the 3D space into a 32 32 32 grid and assign each part characteristic grid cell that serves as the basis for sorting. The characteristic grid cell of a part is defined as follows: among all grid cells that the part occupies, we first select the one with the smallest z-coordinate. If multiple candidates share the same z-value, we choose the one with the smallest z-coordinate. If a tie still exists, we select the one with the smallest g-coordinate. Parts are then sorted based on the lexicographic order of these characteristic grid cells, which determines their final sequence within the object.
It is important sponding code lies in the ability of our part-to-code inference model to accurately infer all of its individual parts. We consider part be successfully inferred if the Chamfer Distance (CD) between the predicted point cloud and the ground truth is below x 10-3 Therefore, when constructing the object-code pairs dataset, we only include objects for which all constituent parts meet this criterion. Objects with any part failing to meet this standard are discarded. As a result, the number of success- fully constructed object-code pairs is smaller than the total number of objects in the original Infinigen dataset. In fact, the original Infinigen dataset we use contains 1.57 million object instances, from which we successfully construct 1 million shape-code pairs. For training and evaluation, we split the full Infinigen dataset into 70% for training, 15% for testing, and 15% for validation. Accordingly. MESHCODER is trained only on the subset the shape-code pairs that fall within the training portion of the Infinigen dataset. In contrast, the baseline models are trained the full set of objects in the training split of the original Infinigen dataset. Importantly, all evaluation results for our method and the baselines reported the same test set, i..., the testing split of the complete Infinigen dataset.
that for each object, the prerequisite for successfully constructing its corre-
23

---

q5
42
44
Part-to-code Inference
Y1. Y2. Va. V4.
bey mudions Lepart
Y1
mnnticcnncin cheee pretic exapet 1.8), hasdle tepeall
okjectt sleple
enetti peloeeessoooetteo heaaaeee addeas, calissa ay
poollie "rrapee" conrol (eeuts
Y2 cantriiasttte
n.me), (eecth, si-th, Weli, saleec So0, 100), randn Do b,
transform
woeeioollooggteeeeee hesagess's sidaans, radiasse as
and concat
6.00], (ot,4,, (apeetee
create carmettoe trambaatien areelin heagen
1.4,, hendle byeeic buccnesse f0ll
part,
creats polgpttteeeee "heagge siteani, rediaset a0)
proriia, teehrrap cowral.ttrteette.
6.00]) (6-40, sail,, puttsyelllee L.), randa, Opend tnickmweend. rill
y4 centrol
creats powpgottaeeeee....oooooo hhssge sidert, d0)
part.
6.001, (6-40, sialy prriii smeeheeggnn cnte entrrsete mntchneteno.i, rsta_aepe borth))
perti:: weteeso
-8.h, case D.
rotatian 8:41)
cnengrtettiionn tabdette ardettiin tooe " lecettoneg o, 9.46, MateelL,r, 0.49, retattonajo
Figure 17: A complete code example of converting part codes into full object program.
[125, 12 cms atlenionn blocks dia--1024 sumber of hosis-16
12
cim- 765 nimber of brndg=12
1222
Launabic
Saguemoz
Transformer blocks
Self Attencion
2088
Figure 18: Detailed configuration of the shape tokenizer.
A.2 Model architecture
We explain the detailed structure of the shape tokenizer. As illustrated the Figure 18 project the input point cloud of shape R=* onto three orthogonal planes to obtain tri-plane features with shape 23x256x256x33 With patch size set to 16 16, these tri-plane features are encoded into tokens and fed into Transformer blocks, where the resulting representation is mapped to v and used as the key and value (K, V) inputs. Meanwhile, a set of learnable tokens with shape IR 128x 1024 are used as queries in self and cross attention module. After passing through 12 layers of self and cross attention, we obtain output tokens of shape 1228x1024 which are then projected the final representation of shape gg 128x2048 via MLP.
first

---

A.3 More training details
For the part-to-code reconstruction model, we adopt the Adam optimizer and train it for 20 epochs on 64 NVIDIA A100 GPUs for about a week with batch size of 512, and learning rate of 10- We evaluate the model at every epoch and select the checkpoint with the lowest L2 Chamfer Distance (CD) loss. Then we initialize the weights of the object-to-code reconstruction model with the weights of the trained part-to-code reconstruction model, and train the model on Infinigen Indoor dataset for 10 epochs, with batch size of 256, and a learning rate of 10-4. It is trained on 64 NVIDIA A GPUs for about 2 days. The checkpoint with the lowest CD loss is selected.
To further enhance the robustness and generalization ability of the object-to-code inference model, we apply data augmentation techniques. Specifically, we perform random rotation and scaling on the objects. Additionally, during training, we randomly sample the number of points in each point cloud within the range of 4096 to 16384, and add Gaussian noise to further perturb the input. MeshCoder is trained and evaluated on unified dataset that aggregates all object categories.
A.4 Complete experiment result of Shape Reconstruction
For MeshCoder, during inference, each object is represented by a point cloud containing 16,384 points. Given the input point cloud, the object-to-code inference model is able to predict the corresponding Blender Python script code. The resulting code then executed to generate corresonningg mesh. We uniformly sample 100,000 points from the generated mesh and compute the Chamfer Distance (CD) to the input point cloud using the L.2 norm.
Given two point sets P and Q, each of size 100,000, the Lg Chamfer Distance is defined as:
CD(P.Q) 1 PP
1
Σ
min | BEQ
v112 +
1 Q
Σ DEQ
min lyyly x ZEP
To evaluate IoU, we voxelize both the ground-truth mesh and the predicted mesh into grids of resolution 323, and compute the voxel-based Intersection-over-Uniie (loU) as:
pprea n Vgll
IoU
preed U Vgll
where Vpned and Vg. denote the sets of occupied voxels in the predicted and ground-trute voxel grids, respectively.
For baseline methods, which take voxel grids as input and output voxel grids, we first voxelize the ground-truth mesh into 323 grid and feed it into the baseline models. The predicted voxel grid is then compared to the input voxelized ground truth to compute IoU. Additionally, we extract a mesh from the predicted voxel grid using the Marching Cubes algorithm and uniformly sample 100,000 points from the resulting mesh surface. These sampled points, along with the ground-truth point cloud, are then both uniformly scaled fit within the [- 1]3 volume. Finally, the Chamfer Distance is computed between the two normalized point clouds using the L2 norm.
It's noticed that for each object category, we independently train the baseline models, according to their official code, resulting in category-specifie checkpoints. These models are then evaluated on the corresponding test sets for each category.
The guantitative comparison of reconstruction metrics between MeshCoder and baseline methods across all object categories is summarized in Table 2 and Table Some additional examples of object reconstruction results and their complete code can be referred to Figure
26
In addition to evaluating our object-to-con co-de inference model, we also perform quantitative assess- ment of our part-to-code inference model. Specifically. for each category described in Section B.1 we construct test set consisting of 10,000 samples. We evaluate the model's performance using the CD and voxel IoU metrics on these test sets. The results, shown in Table demonstrate strong performance across all categories, with low CD values and high IoU scores, indicating that our part-to-code inference model highly effective in generating accurate code representations for individual parts.
25

---

Table 2: Comparison of reconstruction metrics across all categories. Chamfer Distance (CD) and IoU
shown in percentage (%)
Category
L2
CD(x10
Voxel IoU (%)
MeshCoder
PLAD
Shape2prog
MeshCoder
PLAD
Shape2prog
ArmChair
0.04
2.31
4.44
94.33
78.79
62.74
BarChair
0.03
2.23
2.55
88.73
74.96
58.23
Bathtub
0.09
1.22
2.45
78.70
74.50
42.94
BeverageFridge
0.22
1.12
12.63
88.03
82.13
39.13
Bottle
0.01
1.08
6.34
88.65
65.58
40.24
Bowl
0.02
1,43
6.29
89.93
60.02
25.60
CeilingClassicL.amg
1.98
3.94
96.13
76.01
59.07
LeilingLight
0.03
3,46
1.32
65.83
40.61
44.97
CellShelf
0.01
1.93
9,40
94.67
59.02
22.30
Chair
0.06
2.26
1.30
81.87
40.93
49.68
Chopsticks
0.03
1.38
21.06
82.24
55.68
11.25
Cup
0.06
1.40
7.35
85.96
62.03
29.47
DeskLamp
0.02
1.76
8.77
80.28
64.31
25.35
Dishwasher
0.13
1,44
3.01
88.37
84.44
46.69
FloorLamp
0.00
2.13
22.97
85.96
66.89
17.16
Fork
0.14
0.34
8.40
58.86
89.28
11.03
Hardware
0.01
0.62
8.45
89.87
83.96
23.56
Jar
0.03
0.76
1.39
79.12
69.67
41.51
Lamp
0.00
1.40
25.44
86.23
69.58
16.96
LargeShelf
0.02
0.82
5.15
88.08
60.70
16.81
Lid
0.05
1.83
2.39
73.22
63.47
50.11
LiteDoor
0.03
5.75
94.75
36.91
18.71
LouverDoor
0.07
1,40
16.17
89.46
37.43
20.94
Microwave
0.07
1.44
11.04
91.72
55.65
49.38
OfficeChair
0.03
1.44
2.63
78.41
55.65
46.91
PanelDoor
0.04
1.31
6.50
94.60
37.18
20.94
Plate
0.04
0.96
1.07
72.70
70.72
60.05
SidetableDesk
0.01
0.67
4.50
93.23
91.75
35.75
SiopleBookcase
0.03
1.78
2.89
92.14
65.14
33.79
SimpleDesk
0.01
2.12
25.39
88.68
93.80
45.79
Sofa
0.03
1.52
2.14
93.81
81.33
65.29
Spoon
0.67
0.37
4.09
74.00
87.04
18.92
TableCocktail
0.02
2.59
5.93
88.47
60.49
25.19
TableDining
0.02
5.52
1.03
88.14
58.43
71.26
Toilet
0.02
2.30
7,51
89.10
62.61
51.14
TriangleShelf
0.01
2.30
12.61
88.75
62.61
30.59
TV
0.04
1.53
3.41
87.80
72.69
34.14
SVat
0.01
0.78
13.50
91.26
73.78
22.57
Vase
0.30
0.73
19.10
72.26
89.95
60.94
Window
0.14
0.59
3.73
87.36
84.21
64.64
Wineglass
0.06
0.98
6.83
88.36
73.96
28.56
All (Avg.)
0.06
1.87
6.00
86.75
67.62
45.03
A.4.1
Ablation Study
We conduct four ablation studies to evaluate the impact of key design choices in our framework.
Triplane Resolution and the Number of Learnable Tokens. The first ablation investigates the effect of varying the resolution of the triplane representation and the number of learnale tokens. As shown T we observe that increasing both the triplane resolution and the number of learnable tokens consistently improves the performance of the object-to-code inference model. This suggests that a finer-grained spatial encoding and a richer set of token representations enable the model to better capture the underlying 3D structure of objects.
26

---

Table 3: Comparison of standard deviation of reconstruction metrics across all categories.
Category
loU PLAD
MeshCoder
PLAD
Shape2prog
MeshCoder
Shape2prog
ArmChair
1.51 x 10
9.35 10
1.51
10-2
4.62 x 10
6.48 x 10-2
5.28 x 10
BarChair
1.82 10
1.18
10-2
9.90
10-3
8,19 10-2
1.00 10
8.30 x 10-2
Bathtub
1.02
6.70
1.31 10
1.91
10
8.57 10
BeverageFridge
4.84 10
2.81 10-3
3.44 10
1.13 10
6.23
10-2
6.64 10
Bottle
7.56 10-6
6,80 10
6.00
10
1.13 10
7.05
10
6,90 10
Bowl
4.83 x 10"
5.13 10
8.78
10
8.11
10
6.24
10 2
2.35 x 10
CeillngClasicLamp
7.33 x 10-7
7.66 x 10
9.86
10-1
3.39 10-5
2.96 10-3
3.82 X 10
LightngLightt
1.79 x 10
3.90 x 10
4.4
10
3.10 10
5.08 x 10
6,93 X 10
CellShelf
3.37 x 10"5
1.94 10
6.95 10-2
9.65 X 10
1.34 x 10
9.45 X 10
Lamp
2.20 x 10-6
9.05 X 10
2.74 10
1.56 X 10
6.87 X 10
1,18 X 10-1
Chuir
1.09 x 10
1.04 X 10
4.52 X 10
1.05 X 10
9.17 X 10
6.72 X 10
Chopsticks
3.64 x 10-3
1.31 10
1.85 10
1.87 10
1.00 X 10
1.01 X 10-1
Cup
1.59 10-3
5.79 10
3.60 10
9.84 10
6.80 X 10
6.98 x 10-2
DeskLamp
8.60 10
4.55 10
1.30 10
7.21 10
6.01 X 10
Dishwasher
9.66 10
2.69 10
2.39 10
L.27 10
4.74 10
8.82 X 10
FloorLamp
1.23 x 10-4
2.09 10
2.54 10
1.68 10
4.92 10
1.12 10-1
Fork
8.81 10-3
2.14 10
8.57 10
2,14 10
1.25
10
6,55 10
Hardware
2.20 x 10
3.07 10
4.48 X 10
1,21 10
1.02 10
1.34 10
Jar
1.40 x 10
2.44 X 10
6.11 X 10-3
1.41 10-1
6.31 10
8,98 X 10-2
LargeShelf'
1.79 x 10
4.65 10
5.12 10
1,53 10
8.67 10
7.09 X 10
Lid
8.89 x 10
1.09 x 10
1.95 X 10
1.55 x 10
1.22 x 10
1.23 x 10
LiteDoor
5.79 x 10
4.39 x 10
2.88 X 10
1.44 x 10
6.32 x 10-2
9.69 X 10
LouverDoor
4.67 x 10
4.84 10
9.23 X 10
1.63 x 10
6.82 X 10
1.53 10
Microwave
3.92 x 10
2.43 10
3.15 10
7.26 10
1.34 x 10
1.65 10
OfficeChair
1.72 x 10
7,35 x 10
2.95 X 10-2
8,97 10
1.06 x 10
1.0 X 10
PanelDoor
4.79 10
3.74 10
1,50 10
7.17 x 10
1.09 X 10
Plate
1.73 10
x
5.78 10-3
1.70 10
1.29 10
1.74 10
SidetableDesk
5.11 10-5
3.52 10-3
5.37
10
9.64 10
5.83
10
1,23 X 10
SimpleBookcase
3.66 x 10
6.54 10
7.01
10
1.08 10
9.62 10
6.06 X 10
SimpleDesk
4.29 x 10-5
9.90 10
1.72 10
1.68 10-1
6.43 10
8.00 X 10-2
Sofa
1.35 x 10
5.78 x 10
6.99 10
6.61 10
7.32 X 10
6,37 X 10
Spoon
5.64 x 10
1.63 x 10
4.59 X 10
2.26 x 10
8.26 x 10
9.81 X 10-2
TableCocktail
2.03 x 10
2.85 X 10
3.10 X 10-2
1.09 x 10
2.11 X 10-1
8,68 X 10-2
TableDining
3.31 x 10
7.18 x 10
6.16 X 10
1.55 10
1.64 X 10
9.41 X 10
Toilet
1.09 x 10
8.44 10
1.99 X 10
4,22 10
5.24 X 10
5.41 x 10
TriangleShelf
3.60 x 10
9.30 x 10
9.47 x 10-2
1.03 10
6.63 x 10-2
1.08 x 10
TV
6.25 10
1.74 10
1.02 10-2
1,66 10
2.84
10
6.68 x 10
TVStand
1.45
5.63 10
1.31 10
9.48
10
5.92 10
Vasc
9.97 10-3
3.44 x 10
1.05 10
2,68 10
2.48
10
4,00 10
Window
9.57 10-3
3.51 X 10
6.61
10
181 10
1.14
10
1.88 10
Wineglass
1.40 x 10
3.12 10
3.86 10
1.04 10
5.39
10 2
6.99 x 10
All (Std.)
2.92 10-3
2.49 10
7.23 10
1.25 10
1.94
10
1.92 10
Initialization from Part-to-Code Checkpoint. The second ablation study evaluates whether initializing the object-to-code model with the pre-trained checkpoint of the part-to-code inference model yields performance improvements. Table 6 demonstrates that such initialization leads to noticeably better results. This improvement may be attributed the part-to-code model's ability to learn robust 3D geometric representations and syntactic grammar structures from the diverse part-level dataset. These learned features likely provide transferable knowledge that facilitates generalization during the object-level inference process, thereby improving the effectiveness of the model.
Using Learnable Tokens as Queries. The third ablation study explores the role of learnable tokens when used as queries for the LLM. In our default setup, learnable tokens are used as input queries to the LLM, whereas in the alternative setup, the MLP and directly fed into the LLM. As reported in Table 7 the learnable-token. aeven-as-quus as-query strategy achieves superior performance. We hypothesize that this advantage arises for two reasons: (1) the learnable tokens are capable of aggregating global information across the entire input, unlike the direct feature approach where each patch predominantly captures localized information, and (2) the learnable tokens can adaptively organize the input representation in a layout that more aligned with the LLM's internal understanding and processing patterns.
features are passed through an
27

---

Table Quantitative evaluation of the part-to-code inference model across different part categories. CD is reported in 10 10-2, and IoU is reported in percentage.
Category
CD (x 10
IoU (%)
Primitive
0.18
94.81
Boolean
0.03
96.13
Arra
0.70
78.90
Bridge Loop
0.14
89.16
Translation
0.17
83.45
Table 5: Ablation study on triplane resolution and the number of learnable tokens in MeshCoder.
report L2 Chamfer Distance (x 10- and IoU (%).
Triplane Resolution
Token Number
L2 CD (x10-4)
IoU (%)
256
128
6.32
86.75
256
64
7.72
85.11
256
32
7.05
85.02
128
128
6.55
86.62
64
128
6.51
86.05
32
128
6.88
84.56
Ablate triplane. To investigate the effectiveness of different point cloud encoding methods, conducted an ablation study focusing on the triplane encoding strategy. Specifically, we compared it with the point cloud encoding approach from Hunyuan3I [37]] each input point is treated as independent token, and its information is directly transferred to learnable tokens via cross-attention, bypassing the triplane intermediate representation. The experimental results presented in the table, which demonstrate that the tri-plane encoding method achieves superior performance on the target task.
A.5 Complete experiment result of Shape Editing
We additionally present two examples of shape editing along with their complete code implementa- tions. In Figure 27| modify the thickness of the chair legs and armrests by adjusting the scale parameter. In Figure 28 we change the mesh resolution of a plate by modifying the resolution parameter.
A.6 Complete experiment result of Shape Understanding
When presented with a 3D point cloud of an object as input, MeshCoder can infer the corresponding code for the object. Upon execution of this code in Blender, the geometry of the object can be obtained. Notably, the comments within the code encompass a variety of semantically rich cues, such the object's identity and the specifics of each component. The primary aim of this experiment is to highlight that our model can assist existing large language models, like GPT-4, in understanding the structure of 3D objects. We provide the inferred code to GPT-4 with the implementation details and functional descriptions of the functions used in the reconstruction code. Then, we input the object's reconstruction code itself and then inquire about the geometry or structure of the object, showed in Figure 19 Figure 20 and Figure 2T GPT 4 is able to generate relevant responses based on the code. More importantly, we found that this code-based representation has unique advantages over visual inputs like multi-view images. For instance, code enables the LLM to understand complex internal structures and provide precise dimensional measurements, which from images alone. Our further experiments demonstrate that code and multi-view images are complementary: providing both the LLM leads higher accuracy than using either input in isolation. This demonstrates that our model possesses capabilities in understanding the geometry and structure of 3D objects and can aid large scale models such as GPT in addressing such questions. However, our model does have limitations. Currently, the code inferred by our model solely contains geometric information of the object and does not include the color or texture information that images provide. As result, it is unable to answer questions pertaining to color.
very difficult ascertain
28

---

Table Ablation study on whether initialize object-to-code model from the part-to-code check- point.
Initialization Strategy
L2 CD (x10-4)
IoU (%)
From Scratch
8.62
85. 16
From Part-to-Code Checkpoint
6.32
86.75
Table 7: Ablation study on whether to use learnable tokens queries in the transformer.
Query Type
L2 CD (x10-*)
IoU (%)
MLP Projection Only Learnable Tokens (Ours)
9.88
84. 12
6.32
86.75
A.7 More comparative experiments
To demonstrate our model's ability to generalize beyond the Infinigen dataset, we have conducted reconstruction experiments using non-Infinigen data. Specifically, leveraged Trellis (38], cur- rently popular generative model that takes single images as input and outputs corresponding meshes, create experimental data. We collected images of three categories (chairs, shelves, and bottles) from online sources, with 10 images collected for each category. These images were input into Trellis generate meshes, from which sampled point clouds to serve input for MeshCoder. To further demonstrate that our model does not merely memorize the training data, we selected examples from training dataset that have the smallest CD loss with the point clouds generated by Trellis. All metric results are presented in Table
This experiment shows that our model maintains satisfactory performance non- non-Infinigen data, demonstrating its generalization capability. Additionally, we argue that the model does not merely memorize Infinigen-speciff structures. If it did, the metries of our model's predictions to outperform those of the dataset matches, which represent the closest possible examples from the training set. However, found that the reconstruction results suboptimal when attempting to reconstruct objects from categories not present in the training dataset. To further strengthen generalization in future work, we plan expand Objaverse 39), and incorporate reinforcement learning techniques (DPO14) 40) GRPO 41) into our training pipeline, like DeepMesh to boost the model's ability to handle broader data distributions.
unlikely
extensive and diverse datasets such as
Moreover, to investigate how varying point cloud densities affect reconstruction quality, we designed experiments with three different point cloud quantities. where the number of input points for trained MeshCoder was set to 4096, 8192, and 16384 respectively to observe its reconstruction metrics across four representative categories: bottles, cell shelves, chairs, and sofas. The metric results are shown in Table [0] Notably, we observe a clear trend: as the number of input points increases, the reconstruction quality consistently improves.
29

---

Table 8: Ablation study on triplane
Encoding approach Strategy
L2 CD (x10-4) +)
IoU (%)
Treat point-cloud as token
8.96
85.17
Triplane
6.32
86.75
Table 9: Metrics of different methods on non- non-Infinigen data.
Method
Chairs
Shelves
Bottles
CD Loss (L)
IoU (1)
CD Loss (4)
IoU (1)
CD Loss (4)
IoU (?)
PLAD
0,09
0.13
0.12
0.16
0.21
0.22
Shape2Prog
0.03
0,46
0.06
0.06
0.25
0.40
Dataset Matches
0.25
0.11
0.08
0.17
0.08
0.41
MeshCoder
0.005
0.52
0.011
0.61
0.0015
0.78
Note: "Dataset Matches" represent examples from the training set with minimal CD loss to Trellis-generated point clouds.
Table 10: Reconstruction metrics under different point cloud quantities
Number of Points
CD Loss (4)
IoU (1)
4096
0.000404
0.8707
8192
0.000396
0.8718
16384
0.000325
0.8907
Inperi
pari, 16: rmeate peintetont-..))
Wast Barttsoo
Iran esth supart rodtare,
The clecttetaco do comeund Enginnin
aeleve_all()
sroate sostteuaccin tave canee haand Locations a. 46, 0.3 (o.), rotat jond -ils, Ha.7h,
pact. body
parti upiic de aboeddac pctie accluing qudiooaeiiocc
...
past Mi wtw.niidde iound wein peinilien, loser 0.s1,
(olladir by cylade: F. Sorobd 11")
24 body cre crnvoeaaranttinn (ire.....
Locatton
scate 1he3 Rull, 6.
0.213)
di compo nouf eatees
irtenge dereacco spoodde hands, magpring Earrest repooteeds
create creata_gr3vit 3ww...
coeate prinntie hand io Locatson 13.teeen13--. 3-46, 0.20, a.24y,
paet mandrilaterst rack create, potposooettoggl.....
rotacsin (310, -dis, -b.3,,
etectt coneniing piammmbe
aodriletanl circlef. create perrareeee .....) ifc...
16, Looats ocin.tief....
Dunsc dase dakiraia "auai: 7.
pndiutes easy woddan
rack crezce ari
(tow: home mndrobe ioda ioder des disus Thi compe on www.rracccccceeeeiii...go maitts as pan offiiieeee boco Dhees the sijectus welken vieu disher medi for byyeg
crease apsattiooe...)
Figure 19: Experiments on how GPT-4o can understand shape through given dishwasher code.
30

---

Inpert boy from 1a,,11 arpoct
Maa'ss Goilayy
cecate coree Coamce curre, 15's
slo), [-0-2, 0.035, 0,31, [-0.36s,
Toe pattic par, JT sed pust JF you cvuned wikg Co tyo
This eeee: beiles en leakod
4 jejectt coses office chiir
B.43l. handle syeents,
1J. closed-Thut) Jevel....
Donn das bevewbodh!
create www.itiiiiaaaeeeeeeee (omeel
cylinder',
bese 3" ...)
lecettate...
part_36s chair base
part anal jeur (' Block vhune is usttll wkk
2t printtivn(..e)
pattte- 8.,, si0),
There ore eitert. Answer Yos
B,222, 0.0), (-0 dhi, a.8,
Boooce Prrchmmlatteee lops
ceeate (e
1J, closediTrue) create (ora(.))
bevelf...)
snacdan componuet tar conuact part
Lie las ackatt laikl
ceeate (ratttrritttin((...))
part_ Tes
candin iepicall cresesiin
a part, as wheet cap sssate sectanglee.... are Hy.pnttntta....)
eser lew. 17 whet Loar, andl serv an dave nalorine tan Russ remnher This connnt
1art_18: )
part,es whst aste create pr..
part__n; seat
create www.scrrsnnneeei.... "Crrete___1
"Cipcla_ 1.10
a 7
"civele.2.19". "ciecle.3.
create are by Hoolnts(....)
"Circle "circle
a Es wheel scle
beidge edge (x
seq,
create (..
add, ciw.lialllee.ooooo
cefore indir
a part, 321 whesl create rectanglel Hy..Hoootisss....)
origie..... potatipen...)
part.33: aheet treate rec.oattttap.... Mys.inooint.....)
hendle
add cwmee
Curve
part, cceate www.sritttiitt....
potatioew....
axis- RO5 (')
a p3: chale base Sevelç....
part.3k1
create carvelasse carve centrol reinte-l((.. 8,425, (o,ess, tull, (aobi, 8.6, selll. sandle it, 3. clscndarne)) bevelt ... create cu
6.6].
Figure 20: Experiments on how GPT-4o can understand shape through given office chair code.
31

---

fron ests laaort radiand, p1 bay
Caate 9.22, 6.005], 0,51)
Wiatt olyen
obect doachel cefiele rlick Mode
al)))
emppee shiking designe "clfl temuaaciag eutipi laveall dhocsse carder shoige
part_5: attach
sbject cett
side
godget
create petetti letatiorelo E-0, -2.40),
types -2.453, clocationn
scalexioin du dille 0.001l.
What lele Slaet
rotation-12.5.
setatista(e 71, -6.7 21,
creats create pre.arrttteeeeeee banee actach
The seee be slen' anerapett calcaet uaa cempntuerts compe two side by sobwvigg
create pww.ertttti cultiee hame botton tecastarigo -0.40 -0,91
petestive, types cabe".
caleei outi, 0.001l,
bosbel boared (jet, 231 sution heard part topir bucional Vockeal
kearth and pat,
und
1otations 0.5, 0.5,
retetione(D:,, -8., 0.5])
dacie the diel'ves calyy cublle sallinime will farrenne Albeck pulgrhi part secutty the koach tigeter viclle evedl ansorane
a 2 wertice division board
create prapataiee nance top prinitive location: 13.0, -0.31,
prinitiis "vertieal toard.3', printtive, caoe". ieratiateln-3 8.8, 8.81, scalenfs retetiar-(Dod, 10.71, Bifly
b.22, bl00..
rotations 9.5, 0.5))
bettoally veil ailly
Factiaata)
create www.stiree hame- side tecatlaneto 4, 8.8, 3.40,
colibee los fectoradyy of pervilig appaceed
retetiandD-4,, -6.71, -6.71 9.01)
stone Croaed verted and bertrran derssro boads
witls tadendal odl. Altic sabiliyy: The stuch sanolvel ainelly alsellly of will cluef cnnertel Compuct Breige: the of cvepuct
part.i horizentat division
create www.grintttitaaaaeeaeoo borrtenn arinttiv, wypee "ubs""
eqjets, poteraalyy coffi deplers, proveal wengg
oepeices soppoad
fecturally duat's laully
ssilngg meal officillyy sttuctiaa gleass
Figure 21: Experiments on how GPT-4o can understand shape through given cell shelf code.
32

---

Craate orarstive obzect
artndtive(rree,
recation
-.diddidaatonnee sondivinlononllon, vee_einlie,, fareeuse setrapeeegge htwp:reeeppleeeeeeeeeeeeeo (iilt, resaluttonnleng)
if trdektinn.ttpeeeeee not uwe_airaman_
nec-tint) /eveeeaee,, Tength)
copeorts, ring count-sut,, rec
6isel
veggents, rima contteenllatinn())) resolacion()]
primttion bsy.contact. (prpddiwwwwroatttwwe.oooo wttp://w........oooooeeoooooooo.
prteee nare rare
alee:
petattrchry aps P"pennitivee "j (twlsattwwwttoeo__a...
prinitive.
ordedeive type ["cylinden", "'oon"1 11:
sige_Jength l-Hore:
1oo_eenn (2"92/ w/ve Jengggg
verticeperen_
res, 2t__2xont(2//11 /n/nrt/////araaee /average adge Jangth)
verticee, (i resolutionts]
prtactrilay nesh, ("giindtivee (printtiie (oppsitti___oy___aeeo___ "two://eeeooerieeeeeeeeeeee
eeviee context object
priniti www.ttteeeeeeiiiiee antratioeeramesrrree (1 (2221)
alea:
toseppt (1oms (0)
wrinition bgy.contert. object
priniesce rare rane
www.eeiiiinnn.e... facee
evaregs_eege, Length intore:
res, Srs_ieint2""////ei http///eerreeeepp_irrrre
Desntee Stpp///raragg... wagee Jergth)
2irecclatiinn(), recalution(S]
getarteing iase aech, Peeinitiiee (eetatetiieggggeoo (yte)_ateeeeee htrp://eeee///eeee//rrrrr sinne http://s__eeeeeeeenrtttoot tegientcunes__)
prinitive bay, coytecn object prinitive.
petactr(asy.cos
*"prindtive, (prinntiii type)
priuteson : bay contectt obdect
pristtive name rose
prdnstive_ttp if rot use_sii-sun_fece IT average edge. Jength Inlore: resstrt:2//arenat edge length)
resolution=[res,
clas:
vetattr//ss..aa.coe *"prindtive, (prinition sype)_ade""
prtutttio caee
wriettiioowsnniiiieee slase
(1X)) (21))
petattriosy.com meah, t'rrinitive (wwp://ntriiitttttoooo__...oe_ee
prisiitie
34 ondedtive typese goid")
prisitive meshh prinitivw.rass
Miltive.occution locution
16 aculs:
prindtivw.sew.e scale
rotation:
prinirive rotation exder Fongle angle rotacios]
alle recation moliew quatemntoon
prinitive rotatior_nod modd QUATERNSON"
prinitive retaationnquterriii rotation
incationnnnddee
rotation rotation
aott 191]]
boy coy..corcant.viee www.:..yyaoree.e update()
scale world (ir
acala satris torch epect)
scale patls_aat acaa stt ( sraie..oojj).enttereeeiee seie__oo_
natrin,
scale, wwtrwtttrr...te.. int (ittee
scala Anw. 3141.0 scale, acate_ sim
acace_ratris www.torch..ereeeee.o.. www.srnn...aarrettt...ooo wtt.aareetttttppeeerrroo /iattaajassaaa catasaaajssseeaattraaaa matrix
dsy.dara.dde
sonld
onfeers[ssee)) astels porligut
apply:
anject crarafore www.fe/reeeoyyyeattooooooo rotesionntrie, acalenTrue)
petndetive
Figure 22: Implementation of the function for creating primitives
33

---

tranciational trajecter
creats.cinatrress praftte,naee-lere, wttp:eessstttaatiiiiioooi potnttr papatts (ea Lendin hendia__tpeeeeeeeeeeee claeee wlc.eeeeaaaa Lal,,, centere www.etetotteeeeeee........
Whee origisiimtt met)
Iddestancetom,, sort:
ontrrs poánts reververtastion, aninost,tntissd contrel can bardle,tyss, countt)
(contrel,
nat necoortrol_aiist e Lentcortrll_aiing poortss nun_hendle_ss
curvadata dieenscora "30"
beilarhy helnn. besier points. centrol, poorts bactarapäine syilic cloaed
for rongefeum contro, redmms):
sezder poirt Jeft tpp.dditthadiiappptttt
type tspe Dop_ddic((ennieatrree (
coetrel wirtss pet()
aezlee polit
sesser point handia S.p topa, www.dicttandie.treetttoo
sester point. radius points raziuels) If Jencpolitts racius]ise alse 1.8
ung_driimue face:
use recolittion
for perpedeneaaaarrpiiiiii bezter potirts)
pl becserspliin becker (isttrrs
total Length
Serghh
cMuresolition sote:. wtt....ngghheeerrggg.... Jangeh
ioseluttion fmn
use recolation nacstation
carracata. u usR, css_ressi.ttion
Currece date dwjocts. reniinis, curveruta)
corvadate,
"0SOECT"
carscluto sptires isccewtt Poloc
bevd, sidthlellee:
beveleane-roee virthsbert) wdeth, curvacata boy-dats dedectefram)) curvecets rode 1033227
carvelots, Jegect bey wwwerrefrrrrttttaa...a.
curvedate tap.
alse:
rap.
uss aww_ninimem,.e face:
fon La (areelanneaetteniti better, potens)
besterdaiore bester_ patntals).cc
(ute), Jenghh (yt v3] langh
see unk_reciiition total Janger/ www.agg Lagges
resolutioe:
uns www.romnaation don reselution
survedata, rasolution presclutttt
wbtesttt/sttttteeee active innecc/na
sas ape ordect ands, sue(cedd "0BJECT1)
tay atsectsjmmme) relect_sst(True)
deta to mawoeelayyy data dojectt (orossssrrllleeeeer (kganlinketnee)
#331, cass in D'start" ")
#2dp nomeado:
www.eruuuaaaooo.o. Cramo, (ww.e,isiieetrru
recatcatata_ waw.aoooeaaaaaaeeeeeeeeee (1s.eesassseeeaaata
solidify Coame,, biickress)
return curvede
contact, collection
sen obpects (irk(curvatt)
data addectsi selact, set(lrau)
boy- ops obdect www.gggettttteeee SEONEE cEnter>""E0S8"")
"center"/cntee)
proftle, ranarriire::
profile (poffiierre))
Lantpodnns radise] Hisisttannaaatee radiaste), flast) Ininstancefaiirts radlasfe), Int)))
wlif Zer/polnta
aesrts_raatis [11) Seninans)
tancle (1))
(rame)
Asdratanceeccoeee, 5002]:
clesen [stened] flan(rem))
certer [esster(iaan((ss))))
for ranas(ian((ams))
conter-cente(E3), biicness-hisned,, opl.ll caps, filgrrumeiss-/llp nemals, memi,,, heolltiieeossaaiion polnrs dww.raarreey.dwsrro/oo... polore))
spoints,
Figure 23: Implementation of the function for creating curves
34

---

wot sam won vose w-th nebx oweets 1. Micoee nis seeticrr
Leas, seril,
Mindayy www.neeeeeteeaaoo walt yon wilh tentgreetl Metooeet All
Sonttire and mantrng
Figure 24: An example of sofa. The input is a point cloud of a sofa, and the figure shows the code inferred by the ooject-to-code inference model, as well as the resulting mesh generated by executing the inferred code.
Jnport bey from biy
rectara,
(x2eta_x13()
seject rame:
crease_ co
a.d), Bisl, (-e
(o.0, 100 451, (-8 -8 41]. (+0
nie nice), tels milh [t sal bold, De will, HD on, oa. 1els, aes, 1o bur,,
s.es], co-se, -0 8-45), De Di.s s.1s]. Decasy
0.41l, Lob
0.43, 15, 40 2515 Lob, -bi5, +8.35) 1-0 57 10.55 0-01, 1 eussl susll (10.22, -2.35,
0.303, poautt, 15, d.00 19000 lous, 0005 1-0 sous, 0.27l, 1-0 whss Doads, aeaa mll fea3s, 30, warl, (e.ad, ah a.271. (662,, a.1). Deiad, -aarth fEea
0.01,
(e.35, -0.25, 5.11], (1.23, 6.31], [h.25, -3.25, 1.9), [6 21, -8:1123,, hedlin, loeeds, closse-Trua)
"curve 2.1 "crre. romber sieent, arterpsiationn SURENC"" f1ll unwii.griiiiiee grinilivs(rmme beiMee 3 prandlore Lypew oobels becetionn iy, 8.0, 0.0), mostumtion 9.55, e.stl, rotetionneee n.e. 9.73, todden www.sreeeeeeeeeeeeeeeeeooo 3" ronale tr operatione sevrereace" uotiee_ mostr
pert.a: crein plus
creat pew.p_petetttvveraa. 'dratr slan."', printttue "ryltadent, lacettos (ot.0), 26, a.i1), scale (6.00, a.60 R.w.... 0.0))
rotatione(0.77,
Figure 25: An example of bathtub. The input is point cloud of a bathtub, and the figure shows the code inferred by the object-to-code inference model, as well as the resulting mesh generated by executing the inferred code.
35

---

undeenttti may sold, Des any sndf thaits
2011 shall Paile,
boder commiti
Sombeeffl undeet renntrrt Lid)
Intpptane anp
Figure 26: An example of toilet. The input is a point cloud of toilet, and the figure shows the code inferred by the object-to-code inference model, as well as the resulting mesh generated by executing the inferred code.
36

---

Cremt lng.l, edettiia Ooen bortanndnn -im e.07) sedle THHSSwO A.d, -6.0, -6,41)
crwm Heg.". prietton Iourterd 104, (4A)) sndedillt mesting St 16 melk, A-112
NTT Sorttan desi eoon Giltio que sale, sootaar (subh Huat, st.n), soiu 1e-4,, t.o. a.m), meseoinn +o,8))
Cramm prRettin sater decrraton eitatiia now Joonttendy oot, rostee e.0 resttinn -tu exddl
sut pua, A-S pray, aun, sal, o5 eu KA6, ka1s, po A.a.
1-00
wand tull wel)
prtectio lecedlodde
Enemi www.errrttteeeeeee (eedaaA net Leveliil ceterr HEGAA'
alt 26 1.1 11 1445, s.o 2.0 Aill internetennd
centrel levegick 1.11)
siry, th (606,
lovel samen decumatin 130) scitbed repertantt)
priettson
Tewttennsh 44, sattggiit wuttenng -6.9, -0.4g)
pwwsttonn Soee Lesttarn- (i, 4un, -U.4), wite restoreeee Hudy Hirtt, A.4))
priitoo Ouer bosttar-e rent)) sote (635 Ein vnnden -0y silty s.i0)
Inentand anl, mitel mm))
priettin Immrlangl oi et, sndtecs suep, reuttengee in, diut, 6. (.a]]
aut (eiis, s.n, e-c1, (uut, 6.0 1i08, sutt, s-db, (iim, x.n, 6.21), 19-31, 6.m.
-oedl peinss aush, killl iile will connttretteete
7.0) SerCA tower A. entereiiee inc. fill Filee wer
boch
1008 N0DI))
Figure 27: By modifying the scale parameters of the leg and arm parts, we adjust their thickness. The highlighted sections indicate the changes made.
37

---

japort by free bty
redians,
objjct name: plate
Craverraaeee curvett', FescSutierea,
controi_addrteeee10.. 6.91,
0.02, 20.90,
0.0]3, type -0.44), thiotressnb 602)
typee 8, is 3, 9, 0,
Secatiorw(o.e, -0.09, 9.6), rotationnee
Saport 10% froe bls Snpere
obdect name: plate
create, curve(ranee curvert', Psselactiran, contsi_esircee[j.., m.t], (Hirry M.r, 0.41, (H.00, 0.36 n.9), (609, 6.423, handse Sypen ia
Incetiorw(o.0,
-Mi (6. thiskeessen 8902
Laport
from with Lepart radiorr, pl
object name: plate pper Lt plate
conmist_pptree 1[8-8
0.03,
0,0]3, handie_type Sypae Iesier_rvttat intaatin glebett reselocionts prefflle.veeee/oooooo commeii,, Incetionwjoo 0, -8.85, 8.8], rntationnne 54, 10.95 19.45,
0])
Figure 28: By modifying the resolution on parameter, we change its resolution. The highlighted sections indicate the changes made.
38


Reviews:
[{"review_id": "ra899OK5cM", "reviewer": "Reviewer_WTgQ", "summary": "This paper proposes an algorithm for reconstructing procedural 3D models (as Blender Python API scripts) from point cloud input. The primary contributions are an expressive Blender Python API library (embedded DSL) capable of some non-trivial CAD operations (primitive creation, beveling, patterning, swept and lofted shapes), a technique for generating large data sets of semantically commented and part segmented programs/models, and a large dataset of such models. The dataset is generated by first randomly synthesizing part-level programs and training a model to reconstruct parts in the embedded DSL from point clouds. The final dataset is constructed by sampling from Infinigen Indoors and using the part-level model to generate DSL code for each part of the sampled models, rejection filtering for reconstruction quality.", "questions": "- Was the train/test split done over sampled models or over inifinigen parametric models?\n- why were \"translation\" and \"bridge loop\" used as names when these operations are traditionally called \"sweep\" and \"loft\"? Is there a difference between these and their normal CAD versions?\n- Are the part dataset probabilistic programs hand-crafted or somehow sampled from the grammar?\n- In Figure 3, the example code seems to show a syntax where the primitive creation operations can be passed arrays of names and parameter lists rather than single names and parameter lists; is this done in-practice in the data set, and if so why is this preferred over separating into multiple lines?", "limitations": "Limited number of object categories supported.", "rating": 5, "confidence": 5, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 4, "clarity": 4, "significance": 4, "originality": 4, "strengths_and_weaknesses": "Strengths:\n- Dataset generation method is generalizable to larger procedural modeling contexts\n- Reconstruction in most categories appears robust and high quality\n- Output is semantically labeled procedural models, good for editability and understanding\n\nWeaknesses:\n- Since the test set is construction from the same base set of parametric models (Infigen Indoors) as the training set, it is possible that the model is primarily memorizing the structure of the infinigen procedural models rather than a generalizable pattern. It would be good to see reconstruction experiments performed on non-infinigen inputs.", "was_revised": true, "final_justification": "I maintain my evaluation that this paper should be accepted.\n\nThe authors addressed my primary concern about generalizability to a sufficient degree. In my response to their rebuttal I suggested a second experiment that could further quantify the generalizability, but I do not think it is critical for the paper to be published.\n\nThe 3 changes I would like to see to the manuscript before it is published are:\n\n1. A note in the text that \"translation\" and \"bridge loop\" are equivalent to the more common names \"sweep\" and \"loft\"\n2. An improved description of the parts dataset construction protocol, specifically the collaboration between GPT and human experts. This could be done as an appendix added for reproducibility; the main text only needs the same level-of-detail as they gave in their response \"Q3\" in the rebuttal.\n3. The parameter-array calling convention and its use in the dataset should be described for reproducibility.", "rebuttal": "**Thank you very much for your detailed and insightful review!** We greatly appreciate your recognition of the strengths of our work, including the generalizability of the dataset generation method, the robustness of reconstruction, and the value of semantically labeled procedural models for editability. Your valuable suggestions and questions also help us further improve the clarity and rigor of our research. Below we address the weaknesses and questions systematically.\n\n**Response to Weaknesses**  \n\nWe fully agree with your concern that verifying performance on non-Infinigen inputs is critical for assessing generalization capabilities. To demonstrate our model’s ability to generalize beyond the Infinigen dataset, we have conducted reconstruction experiments using non-Infinigen data. Specifically, we leveraged Trellis[1], a currently popular generative model that takes single images as input and outputs corresponding meshes, to create our experimental data. We collected images of three categories (chairs, shelves, and bottles) from online sources, with 10 images collected for each category. These images were input into Trellis to generate meshes, from which we sampled point clouds to serve as input for MeshLLM. To further demonstrate that our model does not merely memorize the training data, we selected examples from our training dataset that have the smallest CD loss with the point clouds generated by Trellis. All metric results are presented in the table below.  \n\n| Method         | Chairs         |              | Shelves        |              | Bottles        |              |  \n|----------------|----------------|--------------|----------------|--------------|----------------|--------------|  \n|                | CD Loss (↓)    | IoU (↑)      | CD Loss (↓)    | IoU (↑)      | CD Loss (↓)    | IoU (↑)      |  \n| PLAD           | 0.09          | 0.13         | 0.12          | 0.16         | 0.21          | 0.22         |  \n| Shape2Prog     | 0.03          | 0.46         | 0.06          | 0.06         | 0.25          | 0.40         |  \n| Dataset Matches | 0.25          | 0.11         | 0.08          | 0.17         | 0.08          | 0.41         |  \n| **MeshLLM**    | **0.005**      | **0.52**     | **0.011**      | **0.61**     | **0.0015**      | **0.78**     |  \n\n*Table X: Metrics of different methods on non-Infinigen data.*  \n*Note: \"Dataset Matches\" represent examples from the training set with minimal CD loss to Trellis-generated point clouds.*   \n\nThis experiment shows that our model maintains satisfactory performance on non-Infinigen data, demonstrating its generalization capability. Additionally, we argue that the model does not merely memorize Infinigen-specific structures. If it did, the metrics of our model’s predictions are unlikely to outperform those of the dataset matches, which represent the closest possible examples from the training set. However, we found that the reconstruction results are suboptimal when attempting to reconstruct objects from categories not present in the training dataset. To further strengthen generalization in future work, we plan to expand to more extensive and diverse datasets such as objaverse[5], and incorporate reinforcement learning techniques (DPO[2], GRPO[3]) into our training pipeline, like DeepMesh[4], to boost the model’s ability to handle broader data distributions.  \n\n\n**Response to Q1**  \nWe generated our dataset using the Infinigen Indoor method. In this approach, each object category is associated with only one procedural generation model. Parameters governing the object shape are sampled and subsequently fed into the model to generate objects. After generating all objects through this process, the entire dataset is split into training and test sets.\n\n\n**Response to Q2**  \nWe sincerely appreciate you raising this question. Our naming of the data generation methods was referenced from operational conventions in Blender. In fact, \"translation\" and \"bridge loop\" are fundamentally identical in principle to the \"sweep\" and \"loft\" operations in traditional CAD systems. To achieve terminological consistency with standard CAD practices, we will revise these method names to \"sweep\" and \"loft\" in the revised manuscript, and we are grateful for your insight that prompted this important clarification.  \n\n\n**Response to Q3**  \nThe probabilistic programs for the part dataset are developed through a structured collaboration between AI and human expertise. We provided GPT with detailed specifications for each function, including its purpose, input/output parameters, functional scope, and generatable shape types, to generate initial program drafts. Domain experts then reviewed these drafts to assess their quality and ensure coverage of diverse shape variations. For cases where the AI-generated programs were insufficient, human experts manually refined or authored the necessary code to achieve comprehensive coverage. This iterative workflow combines the efficiency of AI-driven generation with human expertise to ensure reliability and diversity in the dataset.\n\n\n**Response to Q4**  \nYes, we have indeed implemented this array-based parameter passing functionality. The code shown in Figure 3 is **extracted directly from our dataset**, with only some parts omitted for brevity. We specifically designed this feature to enable the passing of a list parameter to generate multiple shapes simultaneously. The main purposes of this design are to reduce code length, improve code representation efficiency, and be more resource-friendly for LLM—ultimately reducing training costs and inference time.   \n\n\n**References**  \n[1] Xiang, J., Lv, Z., Xu, S., Deng, Y., Wang, R., Zhang, B., Chen, D., Tong, X., & Yang, J. (2024). Structured 3D Latents for Scalable and Versatile 3D Generation. arXiv preprint arXiv:2412.01506.  \n[2] Rafailov, E., Tang, L., Ziegler, D. M., & Leike, J. (2023). Direct Preference Optimization: Your Language Model is Secretly a Reward Model. arXiv preprint arXiv:2305.18290.  \n[3] DeepSeek. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. arXiv preprint arXiv:2402.03300.  \n[4] Zhao, Ruowen, et al. \"Deepmesh: Auto-regressive artist-mesh creation with reinforcement learning.\" arXiv preprint arXiv:2503.15265 (2025).  \n[5] Deitke, Matt, et al. \"Objaverse: A universe of annotated 3d objects.\" Proceedings of the IEEE/CVF conference on computer vision and pattern recognition. 2023."}, {"review_id": "ii1hARh27G", "reviewer": "Reviewer_4dat", "summary": "MeshLLM aims to train an object-to-code inference model. To accomplish this, MeshLLM first trains a part-to-code inference model that predicts code for a single part. Then, the difficulty is increased by training a model that predicts code for every part of an object. Finally, the codes for every part of the object are concatenated together to represent all parts of the object. To enable model training, MeshLLM constructs a synthesized dataset of paired parts and their corresponding codes. MeshLLM achieves shape-to-code reconstruction tasks by developing a comprehensive set of expressive Blender Python APIs capable of synthesizing intricate geometries.", "questions": "For different objects, the number of points sampled by MeshLLM is fixed. For complex objects, such as those with many parts, will the tokenizer model's capability decrease? Thanks to the use of the triplane projection method, the model can project different numbers of sampled point clouds into a fixed length. Sampling different numbers of points may improve the model's capability, which could be a direction for future work.", "limitations": "Yes.", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 2, "significance": 3, "originality": 3, "strengths_and_weaknesses": "**Strengths:**\n1. The paper defines a series of shapes and corresponding algorithmic rules, enabling the expression of complex shapes in a highly efficient manner. For example, the \"array\" representation allows for the concise construction of structures where certain geometric shapes are repeated in specific patterns, using array methods to build the entire structure at once.\n2. MeshLLM uses a triplane model to represent sparse point cloud structures as compact feature vectors, enabling an efficient tokenizer.\n3. MeshLLM achieves improved reconstruction performance compared to previous methods in terms of Chamfer Distance loss and IoU. In addition to quantitative evaluation, qualitative evaluation also shows improved geometric quality.\n\n**Weaknesses:**\n1. Regarding shape understanding, since GPT is a closed-source model, it cannot be fine-tuned to understand the series of shapes and algorithmic rules defined during creation. Does directly inputting these codes and their function names help with 3D understanding, without providing the specific algorithmic rules, as shown in Fig. 19? Furthermore, MeshLLM claims to enhance LLMs’ understanding of 3D objects. It would be better to provide comparisons, such as giving GPT multi-view images of objects or other methods, and comparing their 3D understanding capabilities with those when given the codes in MeshLLM.\n2. Minor weaknesses in visualization: Since MeshLLM is related to 3D objects, showing multi-view results of 3D objects or supplementary videos could better demonstrate the quality of the generated results.", "was_revised": true, "final_justification": "Thanks to the authors' replies! My concerns have been addressed, and I will keep the positive score.", "rebuttal": "**Thank you sincerely for your thorough review and valuable feedback!** We greatly appreciate your recognition of MeshLLM’s strengths, including efficient shape expression, effective triplane-based tokenization, improved reconstruction performance, and your positive assessments of quality, significance, and originality. Your insights on weaknesses and questions are particularly helpful for enhancing our work’s clarity and rigor, and we address them systematically below:  \n\n\n**Response to Weaknesses 1**  \nIn our shape understanding tasks, we first input the implementation details and functional descriptions of functions—specifically those used in the object's reconstruction code—to GPT, followed by the object's reconstruction code and specific questions. We apologize for not explaining clearly that Figure 19 currently only shows the reconstruction code and question segments; we will provide a more complete and clear demonstration of the full input process (including function implementations and descriptions) in the revised manuscript to better illustrate how we support GPT’s understanding of shape rules.\n\nIn our further experiment, we ask GPT to answer questions given code, multiview (6 views from front, back, left, right, top, and bottom), and we found that the advantage of using code as input lies in: 1) Understanding the inner structure is very hard when providing images only. For instance, given multiview images GPT can see how many racks inside but it's hard to see how many bars between one rack, whereas given code GPT can easily obtain the number. 2) Providing a measure of the dimensions. For example, we asked GPT to answer the width of the table given absolute height width. In this case GPT was able to answer the correct width given code while it failed to measure the width if only the images provided. But giving multiview images has its own strength, such as identifying color and texture of the object while the code doesn't have any informations about the material. Additionally, we found that those questions that could not be answered by only providing multiview images could be correctly answered by providing both multiview images and code, and the accuracy in providing both images and code is higher than only providing either images or code, which showed that multiview images and code are complementary to each other in shape understanding tasks. We will provide more examples and results in the revised version to further demonstrate the code representation could enhance LLM's understanding of 3D assets.\n\n\n**Response to Weaknesses 2**  \nWe kindly thank the reviewer for raising this point, which is very crucial for solidifying the performance of MeshLLM. We will release more rendered images and videos surrounding the 3D assets generated by MeshLLM. We are sorry for not providing more visualization results here, as uploading images or videos is not permitted during the rebuttal phase. We will include these materials in the revised manuscript to provide a more comprehensive demonstration of geometric quality.  \n\n\n**Response to Question**  \nThank you for your insightful question and suggestions. We need to clarify that, as stated in line 798 of our appendix, during the training phase, we do not use a fixed number of points. Instead, we randomly sample 4096 to 16385 points and add Gaussian noise for training. This approach, which we will emphasize more prominently in the revised manuscript’s main text, enhances the model's robustness and its ability to handle point clouds with different numbers of points, which aligns with the suggestions you put forward. Through our observations, when we use 16384 points for inference, a configuration consistent with the point count used for all reported metrics in our paper, we can reconstruct complex objects comprising nearly twenty components (see Figure 20 in the Appendix). Additionally, to investigate how varying point cloud densities affect reconstruction quality, we conducted the following supplementary experiments.\n\nSpecifically, we designed experiments with three different point cloud quantities, where the number of input points for our trained MeshLLM was set to 4096, 8192, and 16384 respectively to observe its reconstruction metrics across four representative categories: bottles, cell shelves, chairs, and sofas. The metric results are shown in the table below. **Notably, we observe a clear trend: as the number of input points increases, the reconstruction quality consistently improves.**  \n\n| Number of Points | CD Loss ($\\downarrow$) | IoU ($\\uparrow$) |  \n|------------------|------------------------|------------------|  \n| 4096             | 0.000404               | 0.8707           |  \n| 8192             | 0.000396               | 0.8718           |  \n| 16384            | $\\mathbf{0.000325}$     | $\\mathbf{0.8907}$ | \n\n*Table Y: Reconstruction metrics under different number of points.*  \n\nWe are grateful for your constructive feedback and will incorporate these improvements and clarifications into the revised manuscript."}, {"review_id": "2alv5YvUzg", "reviewer": "Reviewer_w67m", "summary": "The paper introduces a new dataset consisting of 1 million objects spanning 40 classes. Each object is composed of multiple parts with codes represented as a parameterized function implemented using the Blender API. The whole object is represented as a concatenation of the individual part codes.\n\nThe authors use a two stage regime to train a model that predicts object codes from an input point cloud. In the first stage a LLM model is trained to predict part codes from the corresponding point clouds. For each object in the dataset its part codes are predicted through this model and concatenated to form the object codes. The model is then initialized from the first stage weights and fine-tuned on the full object codes and point clouds.", "questions": "1. I wonder how the model would perform if using point clouds from generative models as input such as Point-E [1]? This would demonstrate the model's generalization capabilities and extend it to generative applications using image or text.\n\n2. Additional details regarding the generated object's mesh quality can be useful. Comparing additional metrics such as face count against human made meshes or other recent 3D generation methods can help determine the model's usefulness in applications like simulations.\n\n3. For articulated objects in the dataset, I’m curious how the parts are defined and distributed and whether parts are semantically meaningful for articulation applications.\n\n4. I am curious about the scalability of such approaches to more object categories in the future. For example, how many more functions would need to be required in order to represent a dataset like Objaverse [2]? And whether it is actually feasible for such an approach given the effort needed to design these functions.\n\nI am willing to increase my score if these points are addressed in the rebuttal.\n\n[1] Nichol, Alex, et al. \"Point-e: A system for generating 3d point clouds from complex prompts.\" arXiv preprint arXiv:2212.08751 (2022).\n\n[2] Deitke, Matt, et al. \"Objaverse: A universe of annotated 3d objects.\" Proceedings of the IEEE/CVF conference on computer vision and pattern recognition. 2023.", "limitations": "yes", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 4, "clarity": 4, "significance": 3, "originality": 3, "strengths_and_weaknesses": "## Strengths\n\nThe paper writing is clear and well organized, covering most details regarding code representation and model training. The dataset provided is also reasonably large with a somewhat limited number of classes. However, it is significant considering the smaller number of available datasets available for program based object generation. The reconstruction results are convincing, with the LLM producing better shapes compared to prior program based methods. The method also has potential for applications in simulations where the part representation can yield cleaner meshes compared to other 3D representations like SDF.\n\n## Weaknesses\n\nWhile the paper has demonstrated impressive reconstruction results. It is lacking concrete examples that can better show how it can be applied in real world applications.  However, I believe this can be addressed with minor revision. I listed more specific questions regarding this below.", "was_revised": true, "final_justification": "The authors have addressed my concerns during the rebuttal. I have read other reviewers' questions and author responses, and found the authors adequately addressed those concerns as well. Most reviewers are also positive of the paper and I think it will have a strong impact in the program based 3D generation direction. As such I will raise my rating of the paper to 5 accept.", "rebuttal": "**Thank you sincerely for your thorough review and valuable feedback!** We greatly appreciate your recognition of our work’s strengths, including the clear organization of the paper, the significance of the dataset for program-based object generation, and the convincing reconstruction results. Your insightful questions provide important guidance for enhancing the completeness of our research, and we address them systematically below.  \n\n\n**Response to Q1**  \nUsing point clouds generated by generative models as input to MeshLLM for mesh reconstruction is indeed one of the key application directions of our method.\n\nWe are truly grateful for the reviewer’s incredibly insightful suggestion to explore Point-E for point cloud generation—your attention to refining our experimental design has greatly enriched the rigor of our work. Following this valuable input, we conducted extensive experiments with Point-E. Unfortunately, we found that the point clouds generated by Point-E are of relatively poor quality. Therefore, we turned to Trellis[5], a widely acclaimed and robust method for single-image mesh generation. Specifically, we collected 10 samples for each of the three categories (chairs, shelves, and bottles) from online platforms, processed all 30 collected images using Trellis, sampled point clouds from the high-fidelity meshes it generated, and then fed these point clouds into MeshLLM for reconstruction.  \n\nTo further demonstrate that our model does not merely memorize training data, we identified examples from our training dataset with the smallest CD loss relative to the generated point clouds. All metric results are presented in the table below:  \n\n| Method         | Chairs         |              | Shelves        |              | Bottles        |              |  \n|----------------|----------------|--------------|----------------|--------------|----------------|--------------|  \n|                | CD Loss (↓)    | IoU (↑)      | CD Loss (↓)    | IoU (↑)      | CD Loss (↓)    | IoU (↑)      |  \n| PLAD           | 0.09          | 0.13         | 0.12          | 0.16         | 0.21          | 0.22         |  \n| Shape2Prog     | 0.03          | 0.46         | 0.06          | 0.06         | 0.25          | 0.40         |  \n| Dataset Matches | 0.25          | 0.11         | 0.08          | 0.17         | 0.08          | 0.41         |  \n| **MeshLLM**    | **0.005**      | **0.52**     | **0.011**      | **0.61**     | **0.0015**      | **0.78**     |    \n   \n\nWe can observe that MeshLLM still achieves superior reconstruction results even when using point clouds generated by generative models. These results demonstrate that our model can serve as a critical component in converting real-world images into 3D digital assets, bridging the gap between visual inputs and structured 3D representations for practical applications. However, not all examples can be reconstructed well. We found that the reconstruction results are suboptimal when attempting to reconstruct objects from categories not present in the training dataset. To further strengthen generalization in future work, we plan to (1) expand our training data to cover a more diverse set of object categories and topologies, such as  Objaverse [4], and (2) explore advanced alignment techniques, such as Direct Preference Optimization (DPO)[1], which is adopted by Deepmesh [2], to fine-tune the LLM's ability to handle noisier and more varied inputs. We will add a discussion of these preliminary findings and future plans to the paper.  \n\n\n**Response to Q2**  \nThank you for raising this important point. The suitability of our meshes for applications like simulation is one of our method's key advantages.\n\nA core feature of our programmatic representation is that mesh resolution is an explicit and editable parameter in the generated code. As we demonstrate in our shape editing examples (Section 4.4), users can easily modify the resolution parameter to generate meshes ranging from low-polygon to high-fidelity, depending on the application's needs. We show this explicitly in Figure 8 and Figure 28, where the density of the mesh is adjusted with a simple code change.\n\nAs for mesh quality, unlike methods that rely on Marching Cubes over SDFs to produce dense, irregular triangular meshes, our approach generates structured geometry, often with clean quad-based topology. This structured quad topology is particularly well-suited for UV unwrapping, artistic editing, and so on as it simplifies these processes and reduces artifacts.\n\nTo demonstrate our model's ability to create efficient digital assets, we compared the face counts of meshes generated by different methods across specific object categories. Specifically, we analyzed human-authored meshes from the ShapeNet dataset, meshes generated by one of the widely used 3D generation methods (e.g., Trellis[5]), and those produced by MeshLLM in default resolution. We selected four representative categories—chairs, sofas, bathtubs, and shelves—with 10 examples included for each category, and the quantitative results are presented in the table below. As shown in the table, the face counts of meshes generated by our method are close to those of human-authored assets, significantly lower than those generated by Trellis, and even lower than human-authored meshes in some categories. \n\n| Method               | Chair Face Count | Sofa Face Count | Bathtub Face Count | Shelf Face Count |  \n|----------------------|------------------|-----------------|--------------------|------------------|  \n| ShapeNet             | **1038**         | **1537**        | 14,527             | 239        |  \n| Trellis              | 12,186           | 10,040          | 15,433             | 47,301            |  \n| MeshLLM              | 5800             | 3115            | **3,625**          | **67**            |  \n\n\n**Response to Q3**  \nThis is a crucial aspect and feasible future work of our framework. The part definitions in our dataset are semantically meaningful and directly suitable for articulation. Our methodology leverages the Infinigen Indoor dataset, where objects are procedurally generated with a semantically correct, hierarchical part structure. Our pipeline is designed to preserve this meaningful decomposition mostly. For instance, in our appendix, we show that an office chair is correctly inferred with distinct parts like 'wheel', 'wheel_axle', and 'chair_base' (Figure 20). This part-based semantic information is explicitly encoded in the comments of our generated code, making it immediately interpretable and usable for downstream applications that require object articulation. Actually, Infinite Mobility [3] follows the same segmentation as Infinigen, and are capable of producing articulated objects with semantically meaningful part label.\n\n**Response to Q4**  \nWe believe MeshLLM has the potential to generalize to more diverse datasets such as Objaverse. To represent objects in Objaverse as codes, we need to 1) decompose objects into constituent parts and 2) represent every part as code using our Blender APIs. \n1)  Recently part-aware 3D generation works, such as PartCrafter [6] and From One to More [7], demonstrate that we can filter and process objects in Objaverse and obtain a wide range of objects decomposed into constituent parts, providing the necessary training data.\n2) We posit that most parts can be represented by our Blender APIs. For some simple parts, we can use Primitive and Translation tools to represent them. For complex compound parts that can not be constructed by Primitive and Translation tools, we can decompose them into simpler sub-parts which could be constructed using Primitive and Translation tools, and join them using Boolean operations to form the complex compound part. For complex monolithic parts that are difficult to decompose into simpler parts, we can use Bridge Loop tool to contruct them. Specifically, we can cut the part along an appropriate polyline or Bezier curve at multiple points and obtain multiple cross-sectional contours. We can fit every contour using a planar Bezier curve. Finally, the part can be obtained by connecting these ordered section Bezier curves using the Bridge Loop tool.\n\nIn addition, for a part with fine-grained details (e.g., animal feathers or scales) , we can first represent its coarse shape as code using our Blender APIs, and then train a neural network to predict offset of every vertex in the coarse mesh. In this way, we can restore details on the surface by deforming the coarse mesh. This is consistent with workflows used by most artists: They often start by creating a coarse base mesh from geometric primitives and then moving to sculpting tools (like ZBrush) to deform the base mesh and recover intricate surface features. \n\n[1] Rafailov, Rafael, et al. \"Direct preference optimization: Your language model is secretly a reward model.\" Advances in neural information processing systems 36 (2023): 53728-53741.  \n[2] Zhao, Ruowen, et al. \"Deepmesh: Auto-regressive artist-mesh creation with reinforcement learning.\" arXiv preprint arXiv:2503.15265 (2025).  \n[3] Lian X, Yu Z, Liang R, et al. Infinite Mobility: Scalable High-Fidelity Synthesis of Articulated Objects via Procedural Generation. arXiv preprint arXiv:2503.13424, 2025.  \n[4] Deitke, Matt, et al. \"Objaverse: A universe of annotated 3d objects.\" Proceedings of the IEEE/CVF conference on computer vision and pattern recognition. 2023.  \n[5] Xiang, J., Lv, Z., Xu, S., Deng, Y., Wang, R., Zhang, B., Chen, D., Tong, X., & Yang, J. (2024). Structured 3D Latents for Scalable and Versatile 3D Generation. arXiv preprint arXiv:2412.01506.\n[6] Lin Y, Lin C, Pan P, et al. PartCrafter: Structured 3D Mesh Generation via Compositional Latent Diffusion Transformers. arXiv preprint arXiv:2506.05573, 2025.\n[7] Dong S, Ding L, Chen X, et al. From One to More: Contextual Part Latents for 3D Generation. arXiv preprint arXiv:2507.08772, 2025."}, {"review_id": "30ssPBVehf", "reviewer": "Reviewer_46UV", "summary": "This paper introduces MeshLLM, a novel framework that leverages large language models (LLMs) to reconstruct 3D objects from point clouds into editable Blender Python scripts. The authors have designed a comprehensive set of APIs to model intricate geometries beyond simple primitives, enabling the synthesis of complex 3D structures. Then, a model trained to generate executable Blender scripts from point clouds, facilitating part-level reconstruction and intuitive editing through code modifications. MeshLLM outperforms existing shape-to-code methods in reconstruction tasks. The framework is evaluated properly, showcasing its ability to handle complex geometries and enable precise geometric and topological edits.", "questions": "(1) The paper acknowledges that MeshLLM is primarily designed for human-made objects and struggles with organic shapes (e.g., animals, humans). Given that many real-world applications (e.g., medical imaging, character modeling) require handling organic forms, how do the authors justify the framework’s broader applicability?\n(2) In the mentioned pipeline, if there are certain errors in the code predicted by the mesh after the object is split into parts in Section 3.3, then this would be considered an erroneous sample when constructing the dataset. It seems that such errors cannot be corrected in subsequent training. How do the authors address this issue? Additionally, under the current settings, are there potential failure cases? Furthermore, do common LLM hallucination issues, such as repeatedly generating similar code, also exist here? The authors are kindly requested to elaborate on these points.\n\nFrom the current submission format, it appears that the authors have placed greater emphasis on dataset construction, resulting in relatively limited theoretical innovation. Additionally, the ablation studies on various aspects of the model are somewhat insufficient. Therefore, I tentatively recommend rejection. However, if the authors can address the aforementioned issues, I am open to raising the score. Thanks.", "limitations": "Yes.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 2, "originality": 3, "strengths_and_weaknesses": "MeshLLM represents a notable advancement in 3D shape reconstruction and editing, offering a scalable and flexible solution for generating editable code from point clouds. Its strengths lie in its innovative use of LLMs, expressive APIs, and large-scale dataset construction. However, limitations such as restricted generalization to organic shapes and lack of open access to data/code may impact its broader applicability. A short summary is listed as follows:\n\n** Strength\n(1) It bridges the gap between 3D point clouds and editable code representations, offering a flexible solution for reverse engineering and shape editing.\n(2) The Blender Python APIs support advanced geometric operations (e.g., Boolean operations, sweeping trajectories), enabling the modeling of intricate real-world objects.\n(3) Quantitative results demonstrate significant improvements over baseline methods in reconstruction accuracy (e.g., higher IoU, lower Chamfer Distance).\n(4) The code-based representation allows for intuitive geometric and topological modifications, enhancing usability in downstream applications.\n\n** Weakness\n(1) The framework primarily targets human-made objects and may not generalize well to organic shapes (e.g., animals, humans), as noted in the limitations. Besides, it is tightly coupled with Blender, which may restrict its applicability to other 3D modeling software or environments.\n(2) While the paper mentions ablation studies, more detailed analysis of the impact of individual components (e.g., tokenizer design, LLM architecture) would strengthen the statement.", "was_revised": true, "final_justification": "Thanks for the rebuttal. The rebuttal did address my concerns, particularly regarding novelty and the ablation studies. I will raise my score to 'borderline accept'. Please make sure to include the necessary discussions in the revision.", "rebuttal": "**Thank you sincerely for your detailed review and valuable insights!** We greatly appreciate your recognition of MeshLLM’s strengths, including its innovation in bridging 3D point clouds and editable code, expressive Blender APIs, improved reconstruction accuracy, and enhanced usability through code-based editing. Your thoughtful feedback on limitations and questions is crucial for us to strengthen the completeness of our work. We address your concerns systematically below.\n\n**Response to the lack of open access to data/code**  \nWe fully acknowledge the importance of open access for reproducibility and community advancement. We are pleased to share that our function collection has already been open-sourced and can be found in the supplementary materials, specifically in the file `bpy_lib.py`. Additionally, upon acceptance of our paper, we commit to releasing the entire dataset, all source codes, and the model's training checkpoints to ensure full reproducibility and community access.\n\n**Response to the ability to generalize to organisms**  \nWhile MeshLLM primarily targets human made objects, we would like to kindly clarify that we have not acknowledged that MeshLLM struggles with organic objects when discussing its limitations. We stated that the applicability of MeshLLM to organic objects is underdeveloped and we leave this as a future work. In fact, we believe MeshLLM has the potential to generalize to organic objects. To achieve this, we need to 1) collect a dataset of organic objects decomposed into constituent parts and 2) represent every part as code using our Blender APIs. \n1)  Recently part-aware 3D generation works, such as PartCrafter[1] and FromOnetoMore[2], demonstrate that we can filter and process objects in Objaverse and obtain a wide range of objects decomposed into parts, which contains organic objects. In addition, Infinigen contains many procedural programs that can generate organic objects in semantically meaningful parts and can be used as training data. It is worth noting that Infinigen already demonstrates that it is feasible to generate organic objects such as animals using Blender codes.\n2) We posit that most parts can be represented by our Blender APIs. For some simple parts, we can use Primitive and Translation tools to represent them. For complex compound parts that can't be constructed by Primitive and Translation tools, we can decompose them into simpler sub-parts which could be constructed using Primitive and Translation tools, and join them using Boolean operations to form complex parts. For complex monolithic parts that are difficult to decompose into simpler parts, we can almost always use Bridge Loop tool to contruct them. Specifically, we can cut the part along an appropriate polyline or Bezier curve at multiple points and obtain multiple cross-sectional contours. We can fit every contour using a Bezier curve. Finally, the part can be obtained by connecting these ordered section Bezier curves using the Bridge Loop tool.\nIn addition, for a part with fine-grained details (e.g., animal feathers or scales) , we can first represent its coarse shape as code using our Blender APIs, and then train a neural network to predict offset of every vertex in the coarse mesh. In this way, we can restore details on the surface by deforming the coarse mesh. This is consistent with workflows used by most artists: They often start by creating a coarse base mesh from geometric primitives and then moving to sculpting tools (like ZBrush) to deform the base mesh and recover intricate features. \n\n**Response to the coupling with Blender**  \nWe appreciate the reviewer's point about the coupling with Blender. We chose Blender initially for its open-source nature, robust Python API, and suitability for programmatic 3D asset generation. Our core contribution—the code-based constructive methodology—is not Blender-dependent; it adapts readily to other scriptable 3D tools (e.g., CAD software) with shared core functionalities like sweep operations. While our current constructive code is Blender-specific, these functions can be re-implemented in other code-capable 3D software. By retaining consistent functions, the inferred code works directly in these environments. Thus, only our current functions are Blender-coupled—our trained model and constructive logic are adaptable to other tools. Notably, our framework supports interoperability by exporting to standard formats, enabling seamless use across 3D pipelines.\n\n**Response to ablation studies**  \nThank you for suggesting a more detailed ablation studies. We have already conducted several ablation studies. We would like to respectfully point reviewer to Appendix A.4.1, where we provide three detailed ablation studies on key design choices. These experiments already investigate:  \n\n1. The impact of the shape tokenizer's triplane resolution and the number of learnable tokens (Table 5).  \n2. The critical importance of our two-stage training strategy (initializing the object model from the part model checkpoint), which significantly improves performance (Table 6).  \n3. A key aspect of the tokenizer architecture, confirming that our use of learnable tokens as queries to aggregate global information is superior to a simpler direct projection of local features (Table 7).  \n\nAs suggested, we will enhance this section by adding a new, targeted ablation study on the tokenizer. Specifically, we compare our triplane-based tokenizer against an alternative approach that uses point cross-attention based tokenizer, which is common in recent works like Michelangelo[3] and Craftsman[4]. The results demonstrate that for our task the triplane-based tokenizer performs significantly better. This finding confirms that the proposed shape tokenizer is crucial for capturing the constructive and symbolic nature of 3D shapes, leading to superior reconstruction accuracy and editability.  \n\n|Method|CD Loss ($\\downarrow$)|IoU($\\uparrow$)|\n|---|---|---|\n|triplane-based| **0.00069**| **0.8387**|  \n|point cross attention based|0.00089|0.8367|  \n\n**Response to errors in the code predicted and the hallucination issues**  \nYes, the model’s inference process does exhibit hallucinations, leading to execution errors in the predicted code. We have statistically analyzed this phenomenon: the proportion of erroneous code in part-level inference results is about 0.1%, while that in object-level inference results is 0.66%. The primary manifestations of hallucinations include unreasonable numerical parameter values and syntactic errors in generated code, with no occurrence of code repetition.\n\n**Response to bad case predicted in subsequent training**\nWe consider two types of bad cases for part predictions: erroneous code (as previously discussed) and suboptimal reconstructions. As noted in Appendix A.1.3, we applied a strict Chamfer Distance (CD) threshold of **0.005** for each inferred part—parts failing to meet this threshold are classified as bad cases. Notably, even predictions exceeding this threshold often yield visually similar shapes, reflecting the model’s robust approximation capability. **When constructing the object-code pairs dataset, we only include objects for which all constituent parts are good cases.** Therefore, these bad cases do not impact subsequent training processes.   \nOur evaluation rigorously uses the original Infinigen test set, which explicitly includes objects with bad-case parts to ensure comprehensive assessment. To further validate generalization, we partitioned the test set into two subsets: 1. \"All Parts as Good Cases\" (objects where all parts meet the CD threshold) and 2. \"Objects with Bad-Case Parts\" (objects containing at least one part exceeding the threshold). Performance metrics across both subsets are shown below. We observe that MeshLLM maintains reasonably good performance on \"Objects with Bad-Case Parts,\" with no significant degradation in metrics—this is because even when a shape can't be reconstructed with precise accuracy, the model is still able to generate a visually similar shape.\n\n| Method| All Parts as Good Cases| |Objects with Bad-Case Parts| |\n|---|---|---|---|---|\n|  |CD Loss ($\\downarrow$)|IoU ($\\uparrow$)|CD Loss ($\\downarrow$)|IoU ($\\uparrow$)|\n| PLAD| 0.026| 0.481|0.031| 0.473|\n| Shape2Prog| 0.056 |0.443|0.062|0.467|\n| MeshLLM| **0.00054**| **0.867** | **0.00089** | **0.76**  |\n\n**Response to the theoretical innovation**  \nWe thank the reviewer for the feedback and the opportunity to clarify our contributions' scope and novelty. Our innovation lies not in a single methodological improvement, but in introducing a complete, novel paradigm for 3D content generation/reconstruction, built on three foundations:  \n1. A highly expressive programmatic representation for 3D shapes—structured, interpretable, and compositional—offering a new theoretical basis for geometric reasoning.  \n2. A novel two-stage annotation methodology to address the field's critical data bottleneck, using an expert part-to-code model to automatically label large-scale datasets, enabling scalable training of models like MeshLLM.  \n3. MeshLLM itself, which validates this framework by demonstrating that an LLM can learn this programmatic language to generate high-quality, editable 3D assets. This holistic framework—encompassing representation, data pipeline, and generative model—pioneers a new class of 3D generative models and opens avenues for future theoretical research.\n\n[1]Lin Y, Lin C, Pan P, et al. PartCrafter: Structured 3D Mesh Generation via Compositional Latent Diffusion Transformers[J]. arXiv preprint arXiv:2506.05573, 2025.\n\n[2]Dong S, Ding L, Chen X, et al. From One to More: Contextual Part Latents for 3D Generation[J]. arXiv preprint arXiv:2507.08772, 2025.\n\n[3]Zhao Z, Liu W, Chen X, et al. Michelangelo: Conditional 3d shape generation based on shape-image-text aligned latent representation[J]. Advances in neural information processing systems, 2023, 36: 73969-73982."}]

Author rebuttal:

Meta-review: This submission proposes an object-to-code generator based on a shape tokenizer and an LLM. As part of their contributions, the authors also introduce a comprehensive set of Blender Python APIs and a pipeline to construct a large-scale paired object–code dataset for developing and training the proposed generative model. While the overall framework seems straightforward, the authors demonstrate that the Blender APIs and the large-scale dataset can enable high-quality 3D asset generation through Llama fine-tuning. All reviewers gave positive scores (5, 5, 4, 4) and agreed on acceptance. Hence, the AC recommends poster acceptance.

A reviewer requested three changes for the final version:
1. Add a note in the text clarifying that “translation” and “bridge loop” are equivalent to the more common names “sweep” and “loft.”
2. Provide an improved description of the dataset construction protocol for parts, specifically the collaboration between GPT and human experts. This could be included as an appendix for reproducibility.
3. Describe the parameter-array calling convention and its use in the dataset for reproducibility.
Decision: Accept (poster)