Gltf-build-pipeline 2.15.0+ regression

Running into a regression during compressed export. Using my newly acquired knowledge about the npm versions inside the exporter’s package.json I tried to narrow it down a bit for you:

I didn’t test each version but somewhere between 2.15.0-next.18cdb52 and 2.15.0-next.c62661b it started:

error: Packing of "foobar.glb" using version 2.15.0 failed with error:
EBUSY: resource busy or locked, unlink 'C:\Users\blah\AppData\Local\Temp\gltf-transform\82qMBV\Rp5WrJ_31.jpg'
Error: EBUSY: resource busy or locked, unlink 'C:\Users\blah\AppData\Local\Temp\gltf-transform\82qMBV\Rp5WrJ_31.jpg'
    at unlinkSync (node:fs:1953:11)

It sounds like you’re encountering an issue related to file locks during the packing process of gltf-transform when exporting a GLB file between certain npm version ranges. This error message indicates that there’s a file lock on one of the temporary files used during the export process.

Have you checked if any other processes might be using those temporary files? It could be that another process is locking the file temporarily, causing the gltf-transform to fail when it attempts to delete it.

To help diagnose and potentially fix this issue, consider the following steps:

  1. Check for Conflicting Processes: Ensure no other software is locking the temporary files. You can monitor which processes have open handles on specific files using tools like Process Explorer.

  2. Clear Temporary Files: Manually clear the contents of the %TEMP% directory (usually C:\Users\yourusername\AppData\Local\Temp) and try running the export again.

  3. Update Dependencies: Ensure all dependencies are up-to-date. Sometimes dependencies other than gltf-transform itself can cause conflicts.

  4. Try a Different Export Version: Since the issue started somewhere between 2.15.0-next.18cdb52 and 2.15.0-next.c62661b, you might want to try reverting to the previous version (2.15.0-next.18cdb52) or continuing forward to see if the issue persists.

  5. Custom Error Handling: Implement custom error handling in the exporter to retry the operation after a delay if such errors occur, or to log the details of the failed operation for further analysis.

If these steps do not resolve the issue, please provide more details about your environment, and any additional logs or error messages you encounter. This will help in identifying the root cause more precisely.

Sources: Needle Engine Docs (55%), Needle Engine Docs (54%), Needle Engine Docs (54%), Needle Engine API (53%)

1 replies left - Become PRO for more replies.
Reply to this post directly if you need further help (bottom right button)

Hey, which Needle Engine version are you using?

There are already releases for 2.15.5 - please note that we’re still working on a release for the next Needle Engine version and 2.15 is not yet used by the engine (only in latest alpha which isnt production ready)

Needle Engine 4.16.x did use 2.15.0-next.9714120 which is basically just a slightly upgraded 2.14 version. The versions you shared above should not be used (as said, we’re still working on it) and they’re not automatically installed - did you manually install them or modify the versions?

Engine 4.16.6. And yes, I can see 2.15.0-next.9714120 is in the package.json. And it gets picked up now and the compression succeeds.

(Some detective work later…)

You know what, I have NO clue whatsover why a higher version of gltf-build-pipeline was picked in the first place. I just checked in Unity’s Editor.log as I did not restart the editor since and I can confirm for some reason 2.15.5 was executed even though the package.json was not modified.

(Some more detective work later…)

Ok so the 2.15.0-next.9714120 is correctly picked up when executing an export (e.g. using Alt+B). It uses the one set in exporter’s package.json.

But but but! When doing a build using the Build Window this line here smells suspicious:

Running compression locally using version 'stable'

ending in

error: Packing of "blah.glb" using version 2.15.5 failed with error:
...

This might be @nostalgicbear 's culprit as well.


Edit. build-pipeline.js:

        // Otherwise we default to the stable version on npm
        if (!version) version = "stable";

And this seems to be the default for all local builds.

Hi, thanks, actually 2.14.0 should be used - I’ve checked and the stable tag got moved to 2.15 - just reverted that. We’ve fixed this issue in Needle Engine 4.17 alpha where the locked version from the package version was not used by the vite plugin (which chooses ‘stable’ here). I’ll make sure to backport it tomorrow (so just to clarify: stable now points to 2.14 again which should work as before and tomorrow a fix for Needle Engine 4.16 will be available which pins this version for the future)