Maximum call stack size exceeded with ...vertices spread operator in BVH

[Glidias]

It happens for a large data set i'm working with.

For the interest of performance/stability, would converting the spread operator line at https://github.com/Mugen87/yuka/blob/master/src/math/BVH.js#L84 to something like for (let e of vertices) this.root.primitives.push(e); suffice?

possibly related: nodejs/node#16870

[Mugen87]

It happens for a large data set i'm working with.

I'm curious. How many entries do you have in the vertices array?

According to the discussion it seems a for loop should solve this problem. I'll fix this 👍

[Mugen87]

We are using the spread operator at other places, too. But since its syntax is so elegant, I would only provide further patch if you run into the same issue elsewhere.

Fix a505f08. I'll also upgrade the npm package.

[Glidias]

How big the data set? I'm not sure if it happens for the first BVH case or the second BVH case.

• 22603 tris , 67809 soup vertices : Initial Navmesh polygons of test floor area
• 44647 tris , 133941 soup vertices : Extruded Navmesh borders (extruded polygon extents) for borders/chamfering corners of navmesh when accounting for specific agent radius (car width size..).

A visual cap (entire land area of a re-generated navmesh from floor-area accounting for specific agent radius Regenerated Navmesh = ((Triangles ∈ Navmesh) ¬ (borders + chamfers)) ):

Closeup:

On a sidenote for potentially future framework consideration, it'd be cool if CellSpacePartioning and BVH (or whatever partitioning implementation, etc.) could adopt some common interface methods (similar to Graph search implementations), so Navmesh could swap various partitioning strategies interchangably. I understand that BVH is a completely different implementation as of now outside the partition package.