-
Notifications
You must be signed in to change notification settings - Fork 217
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
ShaderData::bindTexture texture diffuseTexture at loc=0 not ready #1848
Comments
I have tried to reproduce this with the PhongShader but I cannot. What shader are you using? Could you send me a code snippet? |
When a texture is set to null, GearVRf was not always regenerating the shader. This patch fixes that - issue Samsung#1848
When a texture is set to null, GearVRf was not always regenerating the shader. This patch fixes that - issue Samsung#1848
I think you were using the Texture shader, I reproduced it with that. PR #1850 should fix it, please check. |
Thanks, it's the Phong Shader I'm using, I've tried your fix and doesn't seem to have worked for me, I've added some logging to it to make sure I'm going through that code and it's definitely running your change. I can reproduce it in the multilight demo app, see below for changes. When the texture is set to null I see it replaced by the texture being used for the 3D character.
|
I reproduced your problem in multilight on master. Then I switched to my pull request. After that gvr-multilight switched between the texture and no texture just fine. Are you sure you had my change? It is a one liner. |
It's getting more complicated now, for the demo it seems your right and the fix does work, my demo project was still being built against 4.0.1-SNAPSHOT when I reproduced the problem. But in my own code where I still see the problem I definitely am running the fix. What I've now noticed is that after setting the texture to null it depends where I'm looking to what problem I see. It seems that any texture visible can now appear on the scene object with the null texture. In fact if I tip my head at the right angle I can see different textures being displayed for each eye, even swinging the pointer in and out of view changes what texture appears in place of the null texture. |
Here's a souped up mod to the multilight demo that shows some weirdness, not only does the astro boy texture appear in place of a the null texture, but I also get backdrops showing the wrong texture, or no texture when it should have one. Try tweaking the number of backdrops to get different behaviour.
|
I dug into this and figured out what is wrong. It is a timing issue because the app is switching textures in the framework thread and the GL thread doesn't correctly pick it up. I am investigating a fix for that. For now, if you update the textures in the GL thread, it will work. I verified this by putting updateTextures() into a Runnable and then calling GVRContext.runOnGLThread. When I did that, those messages disappear and it seems to update the textures correctly. |
Thanks, that work around is working for me okay. |
@SteveGreatApe Assuming this issue has been resolved. Planning to close in few days. |
I've removed my workaround and it seems okay. But a bit concerned there hasn't actually been a fix published for this problem. As it was a timing issue I might just be lucky at the moment to not be hitting the problem again. |
Ok, will look into fixing it. |
Bit of a strange one this, I've got a scene object where I can set it's material to either be a texture created from a bitmap, or I set the texture to null and the ambient and diffuse colours to a selected colour instead.
Setting the texture from a bitmap works without a problem, but when I try and switch from a texture to a solid colour by setting the diffuseTexture to null:
I then get this error rapidly repeating in the log:
And bizarrely the object now appears to be showing a texture from another object in the scene. If I then later try and change the colour, which also happens to set the texture to null again, this seems to fix the problem and it changes to showing the fixed colour as expected.
The text was updated successfully, but these errors were encountered: