Closed jeromeetienne closed 12 years ago
apparently this is image.crossOrigin = '' in src/extras/ImageUtils.js; which cause the issue...
not sure how you want to fix the issue ?
--- a/src/extras/ImageUtils.js
+++ b/src/extras/ImageUtils.js
@@ -10,7 +10,7 @@ THREE.ImageUtils = {
var image = new Image(), texture = new THREE.Texture( image, mapping );
image.onload = function () { texture.needsUpdate = true; if ( callback ) callback( this ); };
- image.crossOrigin = '';
+ //image.crossOrigin = '';
image.src = path;
return texture;
I think we should consider this whenever it reaches beta. Chances are is just a temporal bug.
Hmmm, it may depend on interpretation of specs. I asked on Chromium issue tracker:
http://code.google.com/p/chromium/issues/detail?id=82042
If this is intended behavior, we would have to ask for CORS resource only in cases when they are indeed cross-domain.
A patch has been created for WebKit. Phewww...
I think it's now fixed. It's working again on Chromium 17.0.931.0.
cool lets close it then :)
I am still facing this issue with Chromium 18.0.1025.168 m
Using following code I am getting this error: Cross-origin image load denied by Cross-Origin Resource Sharing policy. And instead of drawing image on plane, it draws black colored plane.
var texture = THREE.ImageUtils.loadTexture('cursor2.png', {}, function() {renderer.render(scene);}),
material = new THREE.MeshBasicMaterial({map: texture}),
// material = new THREE.MeshPhongMaterial({color: 0xCC0000});
geometry = new THREE.PlaneGeometry(1, 1),
mesh = new THREE.Mesh(geometry, material);
Please Help.
THREE.ImageUtils.loadTexture('cursor2.png', {}, function() {renderer.render(scene);})
{}
?? Where did you get that from? Try with this:
THREE.ImageUtils.loadTexture('cursor2.png', new THREE.UVMapping(), function() {renderer.render(scene);})
If that doesn't change anything. Could you put the test live somewhere?
I am facing this issue as well, just cloned the repo and went to file://localhost/Users/felipe/Data/Projects/three.js/examples/webgl_geometry_cube.html
I guess I need a web server for this or it should work with file://
?
I got this working. And you are right, you need a webserver, it will not work with file://
It's Chrome issue not Three.js You need to host that webpage on some webserver be that IIS or Apache. For example host "examples" directory of Three.js on IIS as http://localhost:80/examples/ Then access your page using http://localhost:80/examples/webgl_geometry_cube.html
Your image will load in browser.
@milanchandna thanks, I installed lighttpd and got it running smoothly :)
I added some instructions to the wiki page https://github.com/mrdoob/three.js/wiki/How-to-run-things-locally
@felipecsl nice post.
I re-encountered this issue again today. Three.js r49 and Chrome 21.0.1180.75 on mac.
This time, I was using ImageUtils.loadTexture with a DataURL from a canvas on the same page.
I worked around the cross-origin error produced by Chrome by commenting out image.crossOrigin = 'anonymous' in ThreeExtras.js... Obviously not a good long-term solution.
Perhaps setting the .crossOrigin property on the image before load should be optional?
The dev
branch has this fixed already:
https://github.com/mrdoob/three.js/blob/dev/src/loaders/ImageLoader.js#L35
Outstanding! Keep up the good work.
I have read through the post and concluded that building from the dev branch would fix my problem. Unfortunately, my texture would still not load because of that image loading denial thing. I am on Chrome 21.0.1180.79.
Here is the code I am working from: https://github.com/tparisi/WebGLBook/blob/master/Chapter%202/example2-2.html
I also tried to run through a web server thinking it might be a security thing with local files but it does not seem to help much. Anything I might be doing wrong?
If you switch to r50 (current stable) it should work.
Thanks for your prompt answer. It works but it was not related to the build. First of all, you cannot load local files. I suppose this is for security reasons and setting up a MAMP should fix this. The thing is that I was actually referencing images stored online when I first had the issue. I realized that only certain image URL would load.
For instance the following texture will not display: http://25.media.tumblr.com/tumblr_m8x5bz2sXg1qhccbco1_r2_250.gif
Whereas this one will: https://lh5.googleusercontent.com/-2r7nkB71SpM/AAAAAAAAAAI/AAAAAAAAExc/Avog9qId-tQ/s250-c-k/photo.jpg
I am sure there is some subtleties at work here that I do not fully understand.
Ah yea. That's why we have this:
https://github.com/mrdoob/three.js/wiki/How-to-run-things-locally
More heare:
I did fall on this page when looking for an answer but it did not help me understand why I am getting the error message when trying to load a texture from a web address.
EDIT: Just realized you have this in the docs. I went to go edit the docs to put it and saw it was already there - nevermind me.
Hey guys - I ran into this issue myself and I did not want to use either of your solutions. Changing my Chrome security settings was out of the question and I keep all my git files in a desktop folder because I play with them all the time. So I use a really simple python server to just start a local host in any working directory - works like a charm. Check it out here:
http://www.linuxjournal.com/content/tech-tip-really-simple-http-server-python
Hope that's useful! Threejs is super fun, it's too exciting to have to run through steps to get it working :-)
After upgrading recently (from r48 to r58) I started getting this error again in my app: "Cross-origin image load denied by Cross-Origin Resource Sharing policy."
I'm on Chrome Version 27.0.1453.116 on Mac.
It's because of this change (which according to the discussion above seems to be a regression): https://github.com/mrdoob/three.js/commit/145427e37923d1db74a7f6f665becb60754eba0d
I've added this line to the beginning of my app:
THREE.ImageUtils.crossOrigin = "";
This is slightly sad, but will hopefully shield my app from future thrash.
Thanks again for three.js
, it saves my team time literally every day, and has been a great foundation for the rendering portion of our work. Take care.
You team... at NVIDIA? :O What do you guys use the lib for?
Heh, while I still have connections at NVIDIA, I'm no longer a part of any team there in any official capacity.
My team that uses three.js is at another (decidedly smaller) company called AgentSheets Inc. (http://www.agentsheets.com).
We build educational software for the teaching and learning of of math, logic, processes, and computer science.
The main idea is that students can program their own games and simulations with our tools to learn about these things.
The lib provides 3d rendering for our online tool, here's an example of an interesting simulation: http://bit.ly/18LuL1Q
You can press the green 'play' button to see it run, use the camera controls to explore the 3d world, and even use the pencil tool to add more 'wires' to the simulation.
Our main arcade, with thousands of games made by students with various versions of our tools is found here: http://scalablegamedesign.cs.colorado.edu/arcade/
So, while I'm not at NVIDIA any more, I do bring years of experience in computer graphics from that company and several others (I've worked on XBox and PlayStation games at Microsoft, Lucas Arts, etc...) to the table. ;)
Take care.
Sweet! I think one of the non-written goals for the library is to be helpful not only for newbies for also for people with lots of experience with graphics :)
@mrdoob; you should feel good, because from our perspective that goal has been met.
Here are the two biggest (as yet unsolved) surprises: https://github.com/mrdoob/three.js/issues/1595 https://github.com/mrdoob/three.js/issues/2916
They are nowhere near catastrophic. Overall, using the library has been a huge boon for us.
Our team could solve the first one by implementing our own shader material that would more closely match traditional OpenGL semantics. (but it hasn't been high enough priority on our end to do this)
The second one does put an unfortunate bound on the performance of a certain class of games and simulations, but many of the projects don't have enough colored meshes in them to suffer from the problem.
A thousand thanks again. Take care.
same problem on the mac at google chrome version 31.0.1650.63
worked with python simple htttp server and problem is gone. thanks.
I have the same issue when creating a new texture.
You should use CORS headers... however...
You can draw the texture into a canvas and use that canvas has a texture.
Example: loading an image from the Google Maps static image API
var path = "http://maps.googleapis.com/maps/api/staticmap?center=39.06029101581083,-94.59737342812502&zoom=15&size=512x512&sensor=false&key=AIzaSyDk3wbT2nVVWhpmPjOb_3DbtrIQBXcsxtk&format=png";
var geometry = new THREE.PlaneGeometry(200, 200);
var material = new THREE.MeshLambertMaterial({ map: loadImage(path) });
var plane = new THREE.Mesh(geometry, material);
scene.add(plane);
function loadImage(path) {
var canvas = document.createElement('canvas');
canvas.style.position = 'absolute';
canvas.style.top = '0';
canvas.style.left = '0';
//document.body.appendChild(canvas);
var texture = new THREE.Texture(canvas);
var img = new Image();
img.crossOrigin = ''
img.onload = function() {
canvas.width = img.width;
canvas.height = img.height;
var context = canvas.getContext('2d');
context.drawImage(img, 0, 0);
texture.needsUpdate = true;
};
img.src = url;
return texture;
};
@andrevenancio : Very helpful !! Thanks a lot. In your example, is url == path ? i replaced url by path and changed "MeshLambertMaterial" by "MeshBasicMaterial" and it worked perfectly !
many examples fails on 17.0.919.0 canari mac
"Cross-origin image load denied by Cross-Origin Resource Sharing policy."
http://mrdoob.github.com/three.js/examples/webgl_flycamera_earth.html http://mrdoob.github.com/three.js/examples/webgl_geometries.html
This one does work tho
http://mrdoob.github.com/three.js/examples/webgl_geometry_minecraft.html