In the r113 editor (https://threejs.org/editor/), the following issues occured:
Menubar.Edit.js:161 Uncaught TypeError: Cannot read property 'isShaderMaterial' of undefined
at Menubar.Edit.js:161
at Scene.traverse (three.module.js:5707)
at UIRow.<anonymous> (Menubar.Edit.js:157)
Sidebar.Object.js:571 Uncaught TypeError: Cannot set property 'needsUpdate' of undefined
at UIBoolean.update (Sidebar.Object.js:571)
md5-b0a707e3fb5d899f18362713d668336a
Sidebar.Object.js:571 Uncaught TypeError: Cannot set property 'needsUpdate' of undefined
at UIBoolean.update (Sidebar.Object.js:571)
md5-6895d09b06dbb4d046f3f1a3ef20f12b
three.module.js:18347 THREE.WebGLProgram: gl.getProgramInfoLog() C:\fakepath(231,25-83): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
md5-4bbdf0a3ddf43d3f9eb43572c5326992
[SW] Not cached: https://ssl.google-analytics.com/ga.js
[SW] Not cached: https://ssl.google-analytics.com/__utm.gif?utmwv=5.7.2&utms=14&utmn=1003831722&utmhn=threejs.org&utmcs=UTF-8&utmsr=1536x864&utmvp=1211x700&utmsc=24-bit&utmul=en-us&utmje=0&utmfl=-&utmdt=three.js%20%2F%20editor&utmhid=1226119357&utmr=0&utmp=%2Feditor%2F&utmht=1580941272269&utmac=UA-86951-15&utmcc=__utma%3D88431582.1846809080.1557700072.1580870481.1580938466.12%3B%2B__utmz%3D88431582.1580938466.12.8.utmcsr%3Dgithub.com%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferral%7Cutmcct%3D%2Fmrdoob%2Fthree.js%3B&utmjid=&utmu=qAAAAAAAAAAAAAAAAAAAAAAE~
Unknown
Thanks for sending these!
However, unless we know what action you did that caused these errors is hard for us to fix them.
A mix between accidentally enabling the shadow tags on the scene and
camera. The analytics issue was there from the start if I understood that
log correctly... As for the warnings, I don't know. I do know, however,
that it is stating that certain mathematical operators which require
positive/negative only are allowing both.
On Wed, Feb 5, 2020 at 7:57 PM Mr.doob notifications@github.com wrote:
Thanks for sending these!
However, unless we know what action you did that caused these errors is
hard for us to fix them.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mrdoob/three.js/issues/18553?email_source=notifications&email_token=AM6GXIY246KFJJ62HLV2DXLRBNVA5A5CNFSM4KQTOR2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK5UWLQ#issuecomment-582699822,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM6GXI6XLVAQK4RA7QQEIPDRBNVA5ANCNFSM4KQTOR2A
.
The analytics issue was there from the start if I understood that log correctly.
Yes. However, this only occurs with the hosted editor and not when using the code from the master
or dev
branch. I'm not sure it's worth to author a different sw.js
file in the github-pages
branch to avoid at least the first warning about ga.js
. AFAIK, the second auto-generated URL can't be cached anyway.
I've played around with the camera example (enabled/disabled various shadow related flags) but I was unable to reproduce the issue:
It would be great if you can list the exact steps that are necessary to reproduce the warnings.
Ah, now I can reproduce one issue. If you select 3D objects without materials and then change receiveShadows
, the following block produces a runtime error:
This should be an easy fix.
Reading the warning, it states that somewhere, you are using the pow()
command without checking if f
is negative.
This is the triangle on my end. Is this normal?
Reading the warning, it states that somewhere, you are using the pow() command without checking if f is negative.
This is a DirectX warning since you are on Windows. It does not appear e.g. on macOS or Linux.
@mrdoob I've investigate the DirectX warning a little bit more. It says:
warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
It's actually possible to avoid it if certain places in the shader code are enhanced with the suggested abs()
function. E.g. here:
So instead of pow( value.rgb, vec3( 0.41666 )
it would be pow( abs( value.rgb ), vec3( 0.41666 )
.
There are 13 places in the core where such an enhancement would be necessary. I don't think the additional calls of abs()
would noticeably affect performance. However, since it's only a DirectX issue, other platforms actually don't need these calls so they would be redundant.
As mentioned in this thread, the warning is only produced if the shader compiler deduces the first argument given to pow()
_can_ be negative. In other words, the warning does not automatically appear when using pow()
but only when the compiler thinks so based on the processed code. To avoid confusion at other places (see https://github.com/mozilla/hubs/issues/1086), I think it's okay to accept the small overhead and prevent the warnings in the first place.
@Mugen87 Thanks for digging into this! Do you mind doing a PR with the abs()
change so we can get a better picture of the changes?
@Mugen87 reported it to Chrome too.
https://bugs.chromium.org/p/chromium/issues/detail?id=1050238
The discussion at bugs.chromium.org
is already interesting 🤓. It would be great if ANGLE could automatically inject abs()
into into a pow()
statement.
Um, should I wait with a PR until it's clear how the Chromium issue is resolved?
Yes. Seems like they're going to try to hide that message.
It would be great if ANGLE could automatically inject
abs()
into into apow()
statement.
I think doing a max( 0, f )
would be safer, but we'll see what they do.
These 15 warnings look like a variation of ones seen in #18422. It may be valid to continue tracking this there.
I'm afraid the pow()
warning is unrelated to #18422.
They are a result of the same source - Both this warning, and the errors involve sign-specific operations failing to, or intentionally checking for incorrect signs.