DeveloperError: Must define either _workerName or _workerPath for asynchronous geometry.

[HNQX]

What happened?

When i define a primitive use asynchronous: true like code below

        const primitive = new Cesium.Primitive({
            geometryInstances: instance,
            appearance: new Cesium.PerInstanceColorAppearance({
                flat: true,
                translucent: true,
                renderState: {
                    lineWidth: Math.min(2.0, viewer.scene.maximumAliasedLineWidth)
                }
            }),
            asynchronous: true,
            releaseGeometryInstances: true
        })

But browser report bug: DeveloperError: Must define either _workerName or _workerPath for asynchronous geometry.
ssandcastle_url
How or Where to define the _workerName or _workerPath var ?

[javagl]

The first question here is what you are trying to accomplish with setting it to true and not to false.

[jjhembd]

I get the same error message with asynchronous: false, so that flag is not the issue.

I don't think the RectangleOutlineGeometry.createGeometry call is needed for the Sandcastle. Here is an updated Sandcastle that uses the raw RectangleOutlineGeometry for the GeometryInstance constructor. It runs without error on my machine.

@HNQX it looks like you were following the example code in the RectangleOutlineGeometry doc. We probably need to fix that example, or at least explain it better.

[javagl]

I get the same error message with asynchronous: false, so that flag is not the issue.

That's a bit surprising. To confirm: The default value of asynchronous is true. Did you only comment out the
asynchronous: true,
part, od did you explicitly change this to
asynchronous: false,
? I checked the latter, and that worked for me...

[jjhembd]

Did you only comment out the asynchronous: true

Good catch @javagl, that is what I did. asynchronous: false lets it run through without error.

One thing I noticed looking through existing Sandcastles: I don't think we ever actually supply a Geometry to the GeometryInstance constructor, even though this is allowed according to the doc. Every example that I could find is instead supplying an implementation of the (poorly documented) GeometryFactor interface.

Perhaps this is why the bug hasn't been noticed already.