# edgeGeometry mergeVertices

**URL:** <https://discourse.threejs.org/t/edgegeometry-mergevertices/16697>\
**Category:** Questions\
**Tags:** geometry\
**Created:** [June 30, 2020, 8:28pm UTC](https://discourse.threejs.org/t/edgegeometry-mergevertices/16697 "2020-06-30T20:28:19Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![user123](https://avatars.discourse-cdn.com/v4/letter/u/ed655f/32.png) [@user123](https://discourse.threejs.org/u/user123)\
**Post date:** [June 30, 2020, 8:28pm UTC](https://discourse.threejs.org/t/edgegeometry-mergevertices/16697/1 "2020-06-30T20:28:19Z")

</div>

I’m creating edges for my models (which can contain 50+ meshes), in a loop in the following way…

```
 let edges = new THREE.EdgesGeometry(mesh[i].geometry, 40);
 let bufferGeometry = new THREE.BufferGeometry();
 bufferGeometry.attributes = edges.attributes;
 lines = new THREE.LineSegments(bufferGeometry, lineBasicMaterial);
 edges.dispose();
 mesh[i].add(lines);

```

it works fine however on some models it hangs for 1-2 minutes creating the edges, causing chrome to moan about it being unresponsive. When running the chrome performance tools I could see it was mergeVertices that was causing the delay when it creates the new THREE.edges geometry.

so my questions…

1. Can I control the mergeVertices that is occurring at all in the hope to improve performance (change the tolerance maybe?)?
2. What factors affect the mergeVertices, is it purley the quantity?
3. Is the above still the appropriate way to create edges for my meshes (each mesh has to have separate edge lines so i can fiddle with them independently later)

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [July 1, 2020, 8:39am UTC](https://discourse.threejs.org/t/edgegeometry-mergevertices/16697/2 "2020-07-01T08:39:55Z")

</div>

> [@user123](#):
>
> Can I control the mergeVertices that is occurring at all in the hope to improve performance (change the tolerance maybe?)?

No, since the merge is required to produce unique edges.

> [@user123](#):
>
> What factors affect the mergeVertices, is it purley the quantity?

Yes. The more vertices and faces a geometry has, the more complex is the processing. However, the runtime complexity is manageable. It should be something like O(n+m) where n is the number of vertices and m the number of faces.

> [@user123](#):
>
> Is the above still the appropriate way to create edges for my meshes (each mesh has to have separate edge lines so i can fiddle with them independently later)

Yes 😊.

---

<div class="post-metadata">

**Author:** ![user123](https://avatars.discourse-cdn.com/v4/letter/u/ed655f/32.png) [@user123](https://discourse.threejs.org/u/user123)\
**Post date:** [July 1, 2020, 9:51am UTC](https://discourse.threejs.org/t/edgegeometry-mergevertices/16697/3 "2020-07-01T09:51:34Z")

</div>

Great, thanks for the response.

I’m thinking of investigating webworkers to hopefully improve performance. On my quick and simple experiment I can see I will run into issues (for example passing buffer geometry to it)… before I go off and dedicate time to look further, it would be handy if anyone knows whether it’s a complete non starter/waste of time to do such a task in a webworker.

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [July 1, 2020, 11:05am UTC](https://discourse.threejs.org/t/edgegeometry-mergevertices/16697/4 "2020-07-01T11:05:18Z")

</div>

> [@user123](#):
>
> before I go off and dedicate time to look further, it would be handy if anyone knows whether it’s a complete non starter/waste of time to do such a task in a webworker.

Well that depends. It always a matter if an existing _unit of work_ is large enough for a thread in order to outweigh the thread communication overhead. For this particular use case, it makes probably only sense for very complex geometries. I guess you have to try and see how it goes.