-
-
Notifications
You must be signed in to change notification settings - Fork 35.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Texture render issue on latest Chrome [Version 50.0.2661.75 m] #8666
Comments
Do you mind doing a |
Also, have you tried with the build in the |
I have just created Using the build in I guess there may be something different in shadow handling after Chrome updating. Also, removing any of the spot lights will make all warning disappeared. Hope there information help. |
I can duplicate the warning using the After removing the directional light, the scene renders normally, but the warning remains. OS X 10.11.4, Chrome 50.0.2661.75 (64-bit). |
Yes! It renders black in |
I'm having this today as well, chrome updated over night: It's worth reiterating that this only happens ~50% of the time so it might take a few refreshes to reproduce |
Seems to be the same issue as #8670. |
Loading image textures via TextureLoader and warning '[.CommandBufferContext]RENDER WARNING: there is no texture bound to the unit 1' - are different problems and should have different issues. First can be solved if convert textures to some compressed format like 'dds' and use DDSLoader. But even with correctly loaded textures usage of shadow map generates those warnings. |
@Linkedz I agree.
Here are 2 new tests, simpler than the previous ones (only 2 spot lights and 1 plane in them): I just noticed something strange:
but if I set the first spot light
I don't know what does that mean by now. I am still looking into shaders and shadow map. Not sure whether this is relative to the TextureLoader issue. The guess is something is not right and stop loading following textures, or maybe in the opposite way. I will run after the warning message, hopefully it could lead me to some interesting result. |
Hi all. The only difference is lacking of these 2 line of code in sample-warning.js
It looks like there is a different mechanism to handle multiple textures in latest chrome. So the links to multiple "shadow textures" may be broken in this way. |
Well, I misunderstanded what @Linkedz mean. These 2 issues are not unrelated. Thanks for the suggestion of dds. |
Could this be some load order thing. I seem to get this more if I disable network cache in the Chrome dev tools network tab. If you disable it it is more likely to happen. I'm using this page to test http://threejs.org/examples/#webgl_loader_obj The I can repro getting the black texture more often and those warnings if I disable cache (though not every time). This could be some kind of timing issue. The OBJLoader is doing this https://github.com/mrdoob/three.js/blob/master/examples/webgl_loader_obj.html#L93-L110 So when it it not read quickly from cache the material is initialized in render before the texture is in place. Futhermore our app loads the textures to the material fully before its set to any meshes. Hence they will be initialized in render() only when textures are in place. It looks like we dont get these warnings even if cache is disabled. Some code that does not follow this pattern did produce the warnings :P Just my 2 cents. Might be something that happens if Edit: Sometimes with cache disabled you can see the black texture there for a moment, then get few of those warnings, then the real texture is updated. Most times the last step is not done and you end up with black. |
This console log from the above when cache is disabled I think is helpful:
This is a run where it was black (2x + 26x render() calls), but then loaded the texture and it stopped printing warnings. Usually WebGL says "too many warnings, no more will be printed", but this run it stopped because the cause of the warning went away. If that makes sense. Looks to me like its related to using materials with unfinished (null texture units) texture loads in them. Then afterwards updating the texture and |
I found a temporary solution (thanks @hbriceno), don't know how useful it is for you guys, but this solves the problem for me.
Here I removed the onload event listener, as the problem is this event not being triggered at all. |
Is the global THREE.Cache enabled by default in the latest release? |
This is good idea @aramavetisyan . In my own project, I used dds files instead. That did solve part of the problem (and I met another problem of loading blender models with dds texture). And the empty (black) texture issue is not relative to the warning message. The test I gave before just reproduce the warning message, not the texture problem. At first I thought the black texture may be caused by a broken shadow map, but this is not true. For texture problem: go to #8670 for more details. |
Nope. As previously noted, this is a Chrome regression. It's been fixed already in beta/dev and they are trying to backport to Chrome 50. |
Cool, do you have link to their tracker or something. Would be interested to read more. |
@jonnenauha should be this one #604944 |
Thanks. That looks like a pretty serious bug :) I cant really tell if its just webgl related, related or any load event listener (I would doubt that). But looks like they agree this should go to a 50 update (https://bugs.chromium.org/p/chromium/issues/detail?id=586183#c43). Now that I think of it, I actually got this while working on my objloader PR branch, was wondering what the hell was going on. Had to hit F5 a lot of times before getting all the model textures loaded to take screenshots. |
Can we expect chrome guys to give an update anytime sooner? It is becoming a blocking issue as many systems are on auto update for chrome. If chrome would delay its update will have to figure out some kind of work around. Any suggestions plz? |
@admin-3dphy The workaround for the Chrome 50 loading bug is to retain a reference to the image in order to avoid premature garbage collection. See an example workaround for THREE.ImageLoader in #8670. |
As far as I understand this bug is not about Chrome skipping texture loads (see #8670 for that).
in Chrome (M50 + Canary) but none in Firefox Nightly. |
I'm seeing the same infinite warning message. After reading this thread and trying different things to debug and get rid of that warning, I'd have to say this a Chrome issue. I only started seeing TextureLoader malfunctions after the most recent Chrome update. I don't know if the webGL warnings are related though. |
@carstenschwede the workaround in #8670 did solve the problem with texture loading. I modified Threejs image loader function and retained a local copy of the image. Thanks.. |
In Chrome 50.0.2661.94 (64-bit) on MacOS ( MacBook Air ) it was not fixed, http://threejs.org/examples/#webgl_animation_cloth - still has a warnings |
Also reproducing on Chrome Canary... /ping @kenrussell |
Fixed! |
I dont know if this helps but I added needsUpdate to all my material maps and the material itself.. ex. same for emissiveMap, map, bumpMaps etc. This got rid of all the warnings |
…TURE_CUBE_MAP this time. See mrdoob#8121 mrdoob#8578. Fixes mrdoob#8666.
Hi, Just to let you know, it looks like the fix is not working on mobile ( or perhaps I missed something ). Thanks |
Same bug reproduces when I have changed order in which lights are added to scene: |
This has been fixed in the |
By the way, the new Chrome version (v51) has been pushed by Google on mobile also, and fixed the pb... |
Description of the problem
Hi there. This is the error message:
I try to ignore these warnings, but sometimes (more than 50% time in my 3D Game) it will stop loading textures. It drove me crazy for a whole day and finally found it was caused by the latest Chrome update [Version 50.0.2661.75 m]. (Chrome was updated from [Version 49.0.2623.110 m])
This is my test code for the issue:
test link for [r75]
test link for [dev]
It is a simple environment to reproduce the issue. It looks fine in this example, but if the scene is complex enough, some textures will be missing.
Three.js version
Browser
OS
Hardware Requirements
Hardware isn't relevant.
The text was updated successfully, but these errors were encountered: