Text creation significantly slower in Babylonjs 6

Hi,

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.

Thanks,

Aaron

Would you have a repro in the Playground?

It’s definitely not normal and we should fix the problem asap if it’s on our end!

I created this PG:

But MeshBuilder.CreateText did not exist in 5.71.1, so I can’t compare with the current version.

@aabot would be great to have a repro

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.

Thanks for the quick reply.

Finally got to it. Here is the playground for Babylonjs 6 using MeshBuilder.CreateText and Meshwriter https://playground.babylonjs.com/#00N2Z9#2.

MeshBuilder.CreateText: 156 ms
Meshwriter: 301 ms

Here is the playground for Babylonjs 5 using Meshwriter: https://playground.babylonjs.com/#BVN8VV

Meshwriter: 21 ms

I used the same label. A significant increasing in latency. My rendering uses text heavily so this increase is a noticeable impact on scene loading.

Thanks.

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:

  • Path2
  • PolygonMeshBuilder
  • CSG

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).

That did it. I made the change you pointed it out and now the scene loads with the same speed. Thanks a lot for your help digging into this.