Modelling of an Assembled Product
Last updated
Was this helpful?
Last updated
Was this helpful?
A hinge for the furniture market is presented as an example of 3D modelling of an assembled product.
The hinge consists of different components listed in the table below, assembled together according to the scheme in the figure.
ID
Label
Position [mm]
Wing
1
[0, 0, 0]
WingScrew
2
[0, 5.5, -9.5]
Clip
3
[0, 3, 8]
Pin1-1
4
[0, 5.7, 12]
Connector1
5
[0, 8.42, -45.43]
Spring
6
[0, 6.25, -38.68]
Pin1-2
7
[0, 2, -35]
Connector2
8
[0, 12.26, -37.35]
Pin1-3
9
[0, 9.5, -25]
Box
10
[0, -0.22, -47.11]
Hook
11
[-1, 22.02, -44.18]
Three hinges are included in the scene as assets (Hinge_1,Hinge_2,Hinge_3), all of them cloning the same 3D model Hinge.glb.
One hinge is included in the scene as asset (Hinge) and the positions of hinge components are modified with respect to the default values specified in the Hinge.glb file. This can be done by explicitly defining the hinge components as assets in the spreadsheet and .json file. In particular, the hinge components are characterized by the following properties:
inScene set to 1
parentObject to properly map the hierarchy of assets
position to customize the (x,y,z) coordinates that are relative to the asset identified by property placementRelTo.
Two hinges are included in the scene as assets (Hinge1, Hinge_2), but not all the hinge components are actually included in the scene. This can be done by explicitly defining the hinge components as assets in the spreadsheet and .json file. In particular, the hinge components are characterized by the following properties:
inScene set to 0 so that it is not included in the scene
parentObject to properly map the hierarchy of assets
The 3D model of the Hinge has been prepared according to the workflow described in section and is according to the gLTF format.
The 3D model of the Hinge can be employed to characterize assets populating a scene. Herein three examples are described to highlight different features of data formalization based on a and . The resulting scene can be visualized using the web application (remote version), thus the path of the Hinge.glb file is defined according to the file system of the server where VEB.js is running.
It is not necessary to explicitly define all components as child assets in the spreadsheet or .json file because child nodes in the hierarchy of the .glb file are automatically cloned. VEB.js redefines the ID of cloned components by adding upfront the ID of the root node plus a dot (e.g. "Hinge3.Clip" clones node "Clip" in the hierarchy of asset "Hinge3"). The and are available.
The scene can be visualized in VEB.js either with the command "Import Scene" (and selecting the .json file) or by opening .
representation as a node in the .glb file (e.g. Hinge.glb#Clip), as and
The and . are available.
The scene can be visualized in VEB.js either with the command "Import Scene" (and selecting the .json file) or by opening .
representation as a node in the .glb file (e.g. Hinge.glb#Clip), as and
The and are available.
The scene can be visualized in VEB.js either with the command "Import Scene" (and selecting the .json file) or opening .
