All of a sudden, all of our VRML files, which are gzipped .wrl files, no longer work, and give errors on model upload.
This is using our automatic tooling, and worked up until very recently (something changed in the last few days).
Is there a reason compressed VRML is no longer supported?
Do you require a .wrz extension now? We've always used .WRL (this worked up until a few days ago) for compressed vrml - which is how many players (ever since Cosmo) expect things...
@james - I just tried uploading one with our integration (which, as I mentioned, worked up until late last week): https://sketchfab.com/models/62c385cd613d4b46b9ec159332bee7d6
In the past, this would have uploaded and processed fine. Now it gives errors. This is blocking our users, as this always worked before - so all of the released versions of our integration expect this to be working, and all of a sudden fail.
.WRL, .WRZ, and a .WRL compressed into .ZIP/.RAR/.7z should all work.
Taking a look at that last one...
Really weird. I downloaded the original file, but it looks to me like it was just the .wrl, not gzipped.
Our processing log is throwing an invalid data error, and I'm unable to open it in other software like MeshLab.
If you export and upload the same file manually, does it work?
@james Here is the same same model as before - the only difference is this one was not gzipped: https://skfb.ly/68LA7
Otherwise, it's exactly the same. I just temporarily disabled gzip in our exporter, and reran the same process.
As I said, this worked exactly the same as before.
And yes - in response to your question: If I take the model, and try to upload it, it fails. If I take the same file, then use 7-zip to extract the gzipped file, rename to wrl, and upload, it succeeds. The only difference is that anything gzipped is failing (and didn't prior to last week).
@ctech nothing changed on our side. The https://sketchfab.com/models/62c385cd613d4b46b9ec159332bee7d6 uploaded model is using the .wrl extension with gzipped content. We never processed gzipped VRML data not stating it's actually gzipped i.e. if you don't add the Ok I was not aware that this could work but just saw another sample (from the line colors thread) working just fine. However, nothing changed in the code handling wrl on our side. Do you have a link to a URL with the exact same gziped model that worked previously? .gz suffix or use the .wrz extension in place of .wrl this will simply not work. It never did on sketchfab at least and I'm not sure this is a bad thing.
Meshlab doesn't open it either.
That being said, there is a subtility when using gzip; at upload time, we rename files (to randomize names) and only keep the last extension. So if you upload model.wrl.gz our processing pipeline will receive 12c04508fc904fba9a1ce83031c43cf2.gz. If the gzip file was not created using the (default) option
-N --name
When compressing, always save the original file name and time stamp; this is the default. When decompressing, restore the original file name and time stamp if present. This option is
useful on systems which have a limit on file name length or when the time stamp has been lost after a file transfer.then, after gunziping the data, we will not have any extension and will fail to process it.
Anyway, it's not what happened on your sample as you uploaded a *.wrl file but it's probably worth to keep this in mind if you really have to use gzip.
@ctech giving another look, the issue arose not 5 days ago (nothing changed in our pipeline in this release) but ~2 weeks ago (where there were big changes in our build pipeline). So I confirm this is a regression. No fix yet and no ETA but we'll fix this.
Yes - we don't know exactly when it broke. It worked on June 5th, and was failing last week, so around 2 weeks ago makes sense.
@mrchlblng That being said, this is a complete blocker for all of our users, so if there's a way to prioritize it in the queue, that'd be nice. Until this is fixed, none of our users (including many paid ones) can use our exporter, as it always exports compressed VRML.
@ctech the problem has been identified and should be fixed next week. I'll get back to you once the fix is live.