I have a 5.57.1 project using MeshWriter to create 3D text. Today, I upgraded to the latest 6.20.1 version and experienced a very large increase in the time to create the 3D text (orders of 20x). I tried switching to MeshBuilder.CreateText and experienced they same latency increase from 5 to 6.
Under 5.57.1, here are some measurements logs
main.210aef27800935fc.js:1 .. create text mesh took "23 msecs".
main.210aef27800935fc.js:1 create node "switch_vlans_asn200" took "25 msecs"
main.210aef27800935fc.js:1 .. create text mesh took "38 msecs".
main.210aef27800935fc.js:1 create node "VLAN200: 200.200.1.0/28" took "38 msecs"
main.210aef27800935fc.js:1 .. create text mesh took "26 msecs".
main.210aef27800935fc.js:1 create node "NEXTHOP-100.100.1.1" took "27 msecs"
main.210aef27800935fc.js:1 .. create text mesh took "20 msecs".
main.210aef27800935fc.js:1 create node "NEXTHOP-200.100.1.1" took "20 msecs"
Under 6.20.1, here are the same measurement logs
main.9fc8d5d9662b0db9.js:1 .. create text mesh took "360 msecs".
main.9fc8d5d9662b0db9.js:1 create node "switch_vlans_asn200" took "361 msecs".
main.9fc8d5d9662b0db9.js:1 .. create text mesh took "631 msecs".
main.9fc8d5d9662b0db9.js:1 create node "VLAN200: 200.200.1.0/28" took "632 msecs".
main.9fc8d5d9662b0db9.js:1 .. create text mesh took "280 msecs".
main.9fc8d5d9662b0db9.js:1 create node "NEXTHOP-100.100.1.1" took "280 msecs".
main.9fc8d5d9662b0db9.js:1 .. create text mesh took "238 msecs".
main.9fc8d5d9662b0db9.js:1 create node "NEXTHOP-200.100.1.1" took "239 msecs".
Has anyone else experienced this? Any idea on what can be causing this? Since the meshwriter version did not change, I figured there is some refactor in one of the babylonjs methods that is causing this large increase in time.
I will be able to work on the repo in a few days. For 5.71.1, I am using meshwriter, see meshwriter - npm. When I upgraded to 6, meshwriter took that long (10x latency increase). I switched over to the new meshbuilder.CreateText method and saw the same latency as the meshwriter for 6.
The log entries you see for 5 and for 6 are using the meshwriter library. I will work on the playground you created.
I dug a little deeper adding timing hooks inside the meshwriter code. Here is what I saw:
Babylonjs 5:
renderer-assets.service.ts:743 constructLetterPolygons: 15 ms
renderer-assets.service.ts:743 makeSPS 4 ms
renderer-assets.service.ts:746 … create text mesh took “19 msecs”.
renderer-assets.service.ts:422 create node “NEXTHOP-200.100.1.1” took “20 msecs”
Babylons 6:
renderer-assets.service.ts:754 constructLetterPolygons: 233 ms
renderer-assets.service.ts:754 makeSPS: 27 ms
renderer-assets.service.ts:757 … create text mesh took “260 msecs”.
renderer-assets.service.ts:433 create node “NEXTHOP-200.100.1.1” took “261 msecs”.
I traced through constructLetterPolygons and here are the babylonjs objects I saw used:
Since version 6.4.1, when MeshBuilder.CreateText was added, we’ve also added a few new mathematical functions, such as addQuadraticCurveTo.
In the MeshWriter package, the author uses the existing function if it exists, and implements it if it does not. The problem is that his implementation uses a default number of subdivisions of 6 whereas we use 36 => I’ve tested locally that if I manually replace 36 with 6, I get the same performance after 6.4.1 as before.
So the solution would be to update the MeshWriter package to explicitly pass 6 as the number of subdivisions when calling addQuadraticCurveTo, since on our side we can’t change the 36 to 6 (that would be a breaking change).