Geometry is not highlighted when selecting a node

Visualization Solutions HOOPS Visualize Web
1

We found an issue in the HOOPS Web Viewer where node 301 can be successfully selected, but its geometry is not highlighted.

Please check the attached SCZ file and Assembly Tree files to investigate this issue.

Investigation results

The problematic node is:

  • Node ID: 301

  • Element ID: 1187576

  • Node type: BodyInstance

  • Node name: body

We verified the geometry using the HOOPS Web Viewer API:

getNodeMeshData(301):

Faces:
  vertexCount: 0
  elementCount: 0

Lines:
  vertexCount: 20
  elementCount: 10

Points:
  vertexCount: 0
  elementCount: 0

Therefore, node 301 contains 10 real line elements / 20 vertices, not an empty node or bounding box only. The geometry is also rendered normally when viewing the node.

The node bounding box is:

Min: (8225.7393, 8680.5947, 62)
Max: (8276.3193, 8725.7959, 62)

Size: approximately 50.58 × 45.20

view.fitNodes([301]) correctly fits the camera to the geometry, and the geometry is visible on the canvas.

Selection behavior

When selecting node 301:

selectionManager.selectNode(301);

the node is successfully selected, but no highlight is visible on its geometry.

We also tested:

  • Selecting the node directly from the Model Tree.

  • AlwaysDraw

  • DoNotOutlineHighlight

  • Node visibility

  • Node selection color

  • Node element selection color

None of these changed the behavior.

Comparison with other nodes

Other sibling nodes with similar line-based geometry can be highlighted correctly:

Node Element ID Lines Bounding box Highlight
301 1187576 10 50.6 × 45.2 No
296 1186178 7 7759.5 × 1960.4 Yes
673 9090579 30 7952.0 × 4452.1 Yes

All three nodes have 0 faces and line-based geometry. The main difference observed is the much smaller geometry extent of node 301.

Request

Could you please investigate why node 301 is selectable but its geometry is not highlighted, while similar nodes are highlighted correctly?

In particular, please check whether this behavior could be related to the small geometry extent relative to its large absolute coordinates, or to a precision/tolerance issue in the HOOPS highlight/outline rendering.

The SCZ file and Assembly Tree files are attached for investigation and reproduction. Detailed investigation results are also included in the attached document.

2

Hello,

Which version of Visualize Web are you using? At least for v2026.7.0, node 301 can be highlighted when selected:

image
image1915×912 38.8 KB

Thanks,
Tino

3

Hi @tino
Sorry, it looks like I previously provided the wrong node ID.

Could you please check the node named 5" Concrete Slab w/ Pavers - (1187576)?
I am using HOOPS 2026.3.

I re-checked this node and confirmed that it does have geometry in the converted SCZ file. I also verified it using HWV, and the geometry is present there as well.

However, when viewing the SCZ, the geometry is not displayed. In addition, when selecting this node, there is no geometry highlighted.

Could you please help check why the geometry exists in the SCZ/HWV data but is not displayed or highlighted in the viewer?

image
image1919×1079 241 KB

4

It’s still a bit unclear as to why the line is not visible in the viewer. I was able to extract the points of the polyline object by using the following code:

let nodeid = 338;
let data = await hwv.model.getNodeMeshData(nodeid);

let pointData = [];
if (data.lines && data.lines.elementCount > 0) {
    for (let i = 0; i < data.lines.elementCount; i++) {
        let lineElement = data.lines.element(i);
        let pp = lineElement.iterate();
        
        for (let j = 0; j < lineElement.vertexCount; j++) {           
            let rawpoint = pp.next();
            let p = new Communicator.Point3(rawpoint.position[0], rawpoint.position[1], rawpoint.position[2]);
            pointData.push(p.x, p.y, p.z);
        }
    }
	
	// Log once per line element after all its vertices are collected
        console.log(JSON.stringify(pointData));
}

From there I created a mesh composed of only the polyline and inserted it in the viewer:

function createTriangleMeshData() {
    const polylineData = [
    8225.7392578125, 8680.5947265625, 0,
    8225.7392578125, 8680.5947265625, 0,
    8225.7392578125, 8680.5947265625, 0,
    8225.7392578125, 8680.5947265625, 0,
    8264.9560546875, 8705.236328125, 0,
    8264.9560546875, 8705.236328125, 0,
    8256.8583984375, 8696.671875, 0,
    8256.8583984375, 8696.671875, 0,
    8247.44140625, 8689.583984375, 0,
    8247.44140625, 8689.583984375, 0,
    8247.44140625, 8689.583984375, 0,
    8247.44140625, 8689.583984375, 0,
    8264.9560546875, 8705.236328125, 0,
    8264.9560546875, 8705.236328125, 0,
    8256.8583984375, 8696.671875, 0,
    8256.8583984375, 8696.671875, 0,
    8276.3193359375, 8725.7958984375, 0,
    8276.3193359375, 8725.7958984375, 0,
    8276.3193359375, 8725.7958984375, 0,
    8276.3193359375, 8725.7958984375, 0
];

    const meshData = new Communicator.MeshData();
    meshData.setFaceWinding(Communicator.FaceWinding.Clockwise);
    meshData.addPolyline(polylineData);
    meshData.setBackfacesEnabled(true);
    return meshData;
}

var triangleMeshData = createTriangleMeshData();
var triangleMeshId = await hwv.model.createMesh(triangleMeshData);

var meshInstanceData = new Communicator.MeshInstanceData(triangleMeshId);
meshInstanceData.setLineColor(Communicator.Color.red());
var node0 = hwv.model.createNode(hwv.model.getAbsoluteRootNode(), "node0");
var nodeId = await hwv.model.createMeshInstance(meshInstanceData, node0);

The line in question can then be visualized in red and circled in yellow:
image
The line itself looks a little wonky. How was this drawing generated? Was converter/libconverter used to generate it or did you author it using libsc?

5

Hi tino,

Thanks for confirming the polyline data — to answer your question: the SCZ was not generated using the HOOPS Converter/libconverter. We extract the geometry from the Revit model via ODA (including hidden-line removal matching the sheet’s view style), and then author the HOOPS/SCZ model ourselves directly through the Communicator SC::Store API (libsc) — e.g. dc_polyline/dc_polygon calls — not through HOOPS Exchange’s converter or publish pipeline.

Regarding the “wonky” shape you noticed: I believe that’s an artifact of how the reproduction concatenates the data, rather than something wrong with the original polyline. getNodeMeshData(337) reports 10 separate line elements, each with vertexCount:2 (20 vertices total, no degenerate 0-vertex elements) — i.e. 10 independent 2-point segments. If all vertices from data.lines.element(i) are pushed into one flat array and passed to a single addPolyline() call, that draws implicit connecting segments between the end of one 2-point element and the start of the next, even though they aren’t actually connected in the source data — which would explain the zig-zag. The underlying segment structure itself isn’t degenerate.

We’ve done some additional investigation on our side that may help narrow this down faster:

  1. Node 337 (BodyInstance of “5” Concrete Slab w/ Pavers - 1187576") does render its own geometry correctly when the camera is fit to it (view.fitNodes([337]) + redraw shows the 2 curves at the correct location, unselected). So the geometry isn’t just present in the data — it draws normally.

  2. The failure is isolated to highlighting: hwv.model.setNodeLineHighlighted(337, true) throws inside the library itself:

    TypeError: Cannot read properties of undefined (reading 'constructor')
at hoops-web-viewer.mjs:3183

    called from highlightElements (:47820) via _setNodeLineHighlighted (:16769) → setNodeLineHighlighted (:16761) — this happens from calling the public API directly, not from any custom rendering code on our side.

  3. We compared this node against 2 sibling nodes of the exact same element type (same family, same sheet, same 0-face/line-only structure):

    Node (BodyInstance) Element bbox size (device units) lines (element/vertex) Highlight on selectNode()?
    337 1187576 (failing) 50.6 × 45.2 10 / 20 No
    332 1186178 7759.5 × 1960.4 7 / 14 Yes
    730 9090579 7952.0 × 4452.1 30 / 60 Yes

    All three are structurally identical (0 faces, only 2-vertex line elements, same visibility/color/culling-vector settings). The only measured difference is that node 301’s bounding box is roughly 150x smaller than its siblings, while all three sit in the same large absolute coordinate range (~8000–13000 device units). That pattern — very small physical extent at large absolute coordinates — looks like a floating-point precision issue in a highlight/outline render pass.

  4. We also tried the two InstanceModifier options documented for small/culled geometry (AlwaysDraw and DoNotOutlineHighlight) on node 337 — neither changed the result; the highlight still doesn’t appear.

Given points 2–4, could you check whether this is a known issue/limitation in highlightElements/setNodeLineHighlighted for line-only geometry with a very small bounding box relative to its absolute coordinates? And is there any supported workaround beyond the two InstanceModifiers we already tried?

Happy to share more detail on the ODA extraction/SCZ authoring pipeline if useful, but based on the above we don’t think the issue originates from how the geometry was generated — the structure is identical to two working siblings; the only difference is physical size.