After spending a couple of days grappling with this question, here is my perspective on it. While I may not be an expert, my response is based on my efforts to modify a color within a specific section of the resulting GTLF/GLB file.
// Traverses through the scene objects' children and parents.
const SetColorTEXTURE = (c) => {
console.log('BREAK1', c);
Viewer.scene.traverse(function (child) {
console.log('BREAK2C ', child)
if (child.name.includes('XXXXXX-PCB-XXX-XXXX')) {
for (const i of child.children) {
console.log('BREAK2B ', i)
if (i.isMesh) {
console.log('BREAK2A ', i)
i.material.color = new THREE.Color('rgb(212,175,55)');
}
}
}
if (child.isMesh) { ...
My observation led me to realize that the STEP file I was working with lacked the necessary grouping and setup for two key aspects.
- The issue of grouping the children, each carrying their own unique styling tied to the MaterialStandardMesh namespace, became apparent. I faced challenges in styling a specific
Mesh because the parent held the top-level namespace with a name of "". This lack of clear hierarchy made it difficult to apply individual styles or textures to that particular item.
Looking at how the Mesh is structured in the console for a specific item, four distinct parts are noticeable. 1. A parent: Group with a name of "", linked to a parent: scene named xx-scene, representing the main scene.
The 3. material: MeshStandardMaterial bears an empty name, further complicating the matter, as elaborated in the subsequent point.
Essentially, everything stems from the parent: Group and Scene, forming a tree structure that ties back to the main parent/scene, xxx-scene depicted in the image below.
Scene
|
-- Group
|
-- PerspectiveCamera
- Given this setup, there are two ways to isolate a specific item in the
GTFL/GLB file. One approach involves the previously discussed information. An example is presented below. The other method entails creating and naming specific material: MeshStandardMaterial properties.
Referencing items 3 and 4 in the diagram, it is evident that the lack of property naming leads to an empty namespace, resulting in uniform color/texture application across the main scene. Without distinct parent-child or material classification, separate styling proves challenging.
Consequently, cloning fails to address the issue effectively, as it perpetuates the same problem without potentially creating a new scene structure. This method did not yield the desired results in my case.
https://i.sstatic.net/D51TI.png
The code snippet above demonstrates my attempt to validate a theory by isolating a child within the parent scene. By doing so, I successfully targeted all the Mesh elements for that child, altering their properties exclusively.
In the console screenshot below, a child of the parent connected to the Scene holds its own Object3D and Mesh. Despite lacking specific material properties for each Mesh, I managed to modify the particular item successfully.
https://i.sstatic.net/XEr2g.png
The subsequent image showcases the application of three different colors using the provided code snippet and the traversal mechanism of the Viewer.scene.Traverse method.
https://i.sstatic.net/PgKmz.png