Three.js: ThreeJS loading CTM files in Safari bug

Created on 30 Jan 2015  路  21Comments  路  Source: mrdoob/three.js

Attached sample: https://www.dropbox.com/s/la872z9x6gfnxbw/CTMBadLoadingExample.zip?dl=0

We have a cloud product that uses three.js with OpenCTM meshes (http://openctm.sourceforge.net/, specifically using js-openctm https://code.google.com/p/js-openctm/). We recently discovered some strange behavior on some of our meshes when run on Mac OS Safari. The position vertices of some meshes would occasionally explode out to enormous values and we would end up with something like the result below:
http://i.imgur.com/Bo7fDpE.png
It鈥檚 supposed to look like this (note that both of these screenshots are from the same sample webpage using the same meshes, the only difference is the browser and platform):
http://i.imgur.com/KMDAGqV.png

To reproduce, I am just hosting the attached webpage sample (based on the threejs CTM loader example available here: http://threejs.org/examples/webgl_loader_ctm.html) and opening it in Mac Safari. If it doesn't show right away, try closing Safari, opening it again, and going directly to the sample again. I've seen it take a few tries. If that still doesn鈥檛 show the issue, try clearing your cache and trying again. However, for the attached demo page it seems to happen pretty consistently every time. Strangely, I can make the issue stop by reloading with the Safari Developer Tools open (which of course makes it difficult to actually debug). When this was showing in our cloud product, I was actually able to prevent the issue from showing by adding a whole bunch of console log statements inside the ctm.js file that loads CTM files (specifically within the CTM.restoreVertices function) which makes me think there鈥檚 some sort of timing issue happening.

I spent a lot of time trying to debug the issue, but so far I've been unable to determine the root cause. I can say that I inspected each CTM file in the OpenCTM viewer (available here: http://openctm.sourceforge.net/?page=download) and they all loaded and looked fine. It might be useful to know that we are using the MG2 method of compression for the CTM files. Also, I inspected the threejs scene object when the issue was showing and confirmed that the mesh position vertices were sometimes huge numbers, far larger than they should have been.

So far, I suspect a Safari bug, mostly because the issue is only reproducible in Safari and because it does not show when the Safari developer tools are open. I made a bug report with Apple, but I thought I should share here too.

Specs:
When reproducing the issue I am running Safari Version 8.0.2 (10600.2.5) on a Mac Mini running OS X Yosemite Version 10.10.1. A coworker also reproduced the issue on his Mac, but I don鈥檛 have his specs. I am using ThreeJS r70.

Thank you for your time,
Max Strater on behalf of the Autodesk Configurator360 team

Bug

Most helpful comment

Update: 'try-catch' stuff is completely fixed this issue.

All 21 comments

Removing

loadCTM("Spring_ 2.75in lg.A56F7DAADE2182474D94FCFBF4ED05F3.ctm");

the problem appears to go away for me in Safari on OS X. Not sure what is going on.

Well, for one thing, #5605 has not been addressed.

I think you're onto it. I checked through the models loaded and that spring model is the only one with more than 65k vertices. It's still curious why it would happen inconsistently though. Is this likely an issue with support for OES_element_index_uint (Mr. Doob mentioned not all machines support it in the issue you linked)?

I do not believe the "spring model" has more than 65K vertices.

You're right. Sorry, I misunderstood the meaning of the mesh geometry attributes. The CTM model has 55,637 vertices.

So then how does #5605 apply to this case?

I do not have an explanation for what we are seeing.

I can also reproduce the issue in Safari 7.1.2 (OS X 10.9.5). My guess is that Nitro (Safari's JavaScript engine) is optimizing something incorrectly in the CTMLoader code.

Thanks a lot for looking into this. I also made a report to Apple and I'll report back if they respond.

Many thanks!

Hi,
Any progress in this issue? I am also facing similar issue with ctm meshes.

I haven't had any progress. Apple hasn't responded to my bug report yet.
I've been meaning to try something like what is discussed here (wrapping things in try catch blocks to push Safari into better behavior): http://stackoverflow.com/questions/13147026/disabling-jit-in-safari-6-to-workaround-severe-javascript-jit-bugs/13275130, but I haven't had time and I don't know if it would have any effect.

@mstrater Could you please provide link to your bug report to Apple? I have the same issue.

Apple's bug reporting system is private so I can't. My report has the ID 19657253 and is titled "Loading CTM meshes through ThreeJS fails strangely in Safari 8.0.2". I originally submitted it 29-Jan-2015 and I don't think it's been touched since. :(

Very-very-very bad news :( Thanks. Please keep me informed about any updates.

I did not get the chance to try that no. Sorry :(

Two weeks ago I created the same bug in Apple with our conditions but still didn't get any response. ID 24522782.

Version:
OS X Yosemite, version 10.10.5.

Configuration:
MacBook Air 11 inch (mid. 2013), processor 1.3 GHz Intel Core i5, memory 4 GB 1600 MHz DDR3, Graphics Intel HD Graphics 5000 1536 MB

Update: 'try-catch' stuff is completely fixed this issue.

Great news! Can you share specifically what you did?

@mstrater here is an example for adding meshes to Polymer view with CTM loader. try and catch should be added where THREE.CTMLoader() is used:

function drawObjects(objects, meshArray) {
    var view = this.$.view;

    try {
           var loader = new THREE.CTMLoader();

           $.each(objects, function(index, obj) {
                view.addMesh({
                    meshGeometry: loader.loadFromUint8Array(meshArray[obj.meshId])
                });
            });
        } catch (e) {
            console.log(e);
        }
    }
Was this page helpful?
0 / 5 - 0 ratings