Gltf-pipeline draco compression too slow in server(DigitalOcean)

I’ve implemented draco compression for models uploaded in my app using gltf-pipeline. While running locally, this took me about 30 minutes for a certain model (nearly 150MB). So, i was under the assumption when implemented in a server hosted on DigitalOcean it should speed up by many times. But seems that the same model takes even longer. This is not suitable for my app. Maximum of 10 minutes conversion time is acceptable for me. Is there a way to improve performance. Is this totally server related?

Um, have you considered report this issue at the official repository?

I mean if you can reproduce this issue on multiple devices, then there could be a (performance) issue with the tool.

I had reported an issue at the official repository too simultaneously.
I have a doubt, if this is actually a performance issue with the tool, it is then possible to increase the performance by increasing the performance of my server right?
if my server is really powerful, is it possible to bring down the time taken really by a big amount?

What does that mean? Can you share some figures about the hardware?

Well, that depends. I was never in the situation to process such large files with gltf-pipeline.

I feel this is too far removed from threejs discussion. Questions that I would ask if I was willing to help, which I am not, not in this space:

  • What server specs are you using
  • What are the specs of your model, vertex count etc.
  • What software versions are you using, what node version

This would be the barest minimum. :disappointed:

Also, you pay money to DO but expect free help from completely unrelated community?


Servers are generally not very powerful. Unless you’re paying DigitalOcean quite a lot of money, a low-end developer laptop is probably much faster. For example, specs similar to my 8-year-old laptop would cost $80–$160/month on DigitalOcean.

Maybe try gltfpack or even just Gzip? These probably won’t compress your geometry as tightly as Draco, but should run faster.