-
-
Notifications
You must be signed in to change notification settings - Fork 35.5k
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
Fog and Whites r72 #7111
Comments
Can't see the your example: |
Fixed. |
I noticed the reverse to be true as well. Dark colors pierce through whiter shadows. |
@WestLangley maybe this has something to do with the color space change? |
Changing the the float depth = 130.0; // gl_FragCoord.z / gl_FragCoord.w; So, maybe it has something to do with the animation changing the coordinates? Do you see this effect also with static meshes? |
That was the first thing that came to my mind, too, but |
That doesn't seem to be it. |
Seems ok with skinning switched off (which triggers all the animation staff, right?) var mat = new THREE.MeshPhongMaterial({map:tex,skinning:false}); |
That's it. Yup looks fine with |
What does skinning have to do with it? |
That is the question, for now it is just an observation that with skinning disabled there is no odd effect. |
Anyone have any ideas on this? This really makes my scenes look stupid, and again was not an issue till r72. |
It happens with both I was going to say that maybe skinning is normalising the normals, but I don't think that's it. |
Update fiddle for 74dev: http://jsfiddle.net/d6mjj33a/ Old expected behavior (r71): http://jsfiddle.net/7hjo3u7k/ |
I'm not seeing anything poking through the fog. But your |
Why is that? r74dev (You may need maximize this to see) I tested in this fiddle http://jsfiddle.net/xdc1c4xq/ changing |
The object of interest is 10 pixels high. I changed the camera field-of-view. I also changed the fog constant and stopped the animation, as the amimations are different in the two fiddles. Also removed the directional light. The fog appears to be affecting the brighter colors the most which looks suspeciously like a gamma-related issue. I am not sure how that can be, however, given the demo settings. updated r.71: http://jsfiddle.net/7hjo3u7k/1/ updated r.74dev: http://jsfiddle.net/d6mjj33a/1/ BTW, I get this warning in the console:
|
In this example the object of interest may look insignificant, but in application where there are hundreds of objects in the fog, it looks quite silly. Changing the field of view appears to just hide the issue in this particular example. I don't believe this actually solves the problem, but instead sweeps it under the rug.
I am not sure which animation is playing is relevant. I will make sure they are playing the same animation however when I get home from work to prove this. The playing of an animation is important as the effect looks even worse with it.
The opposite effect is true as well. Through a lighter fog (0xdddddd ) for example, the issue is reversed where darker objects inappropriately "poke" through. I would like it if one of you guys would recognize (as @arose) pointed out; that setting material.skinning to false "fixes" the issue, whereas simply not playing the animation does not. This leads me to believe (though I am probably wrong) that this is a material or some subset of a material issue. |
Apparently you do not realize that I am trying to identify the cause of the problem for you. : - ) To do that, I needed to create an example that was actually visible. I also needed to eliminate parts of the code that appear to have nothing to do with the issue. Yes, setting three.js .r71 with some fog, skinning true, ambient light only, and no Dev branch with some fog, skining true, ambient light only, and no EDIT: I am not sure which one is correct -- or if neither are. |
I know =]
EDIT. NEVERMIND... sigh. I am at work and access to my site via domain name is restricted.. Back to the issue... (updated to domain name to IP hehe, stupid firewall) I believe your edits make better light of the issue (no pun intended). I believe the 71 example is correct though I cannot say this for certain. One would think this is the appropriate look considering there is no directional light or map. The 74 version looks like the fog is somehow being adjusted by a non-existent directional light. I'm seeing depth when I should not, correct? All I can say is in a full scene that has a terrain of dimensions anywhere from 2000 x 2000 with several moving animated objects looks just bad in fog (from a distance, objects up close seem fine) using 72+ compared to 71 and prior. |
Not exactly. Fog is a function of depth. The depth appears to be (nearly or exactly) constant in the 71 version and highly variable in the 74dev version. |
Interesting. With this in mind, it would appear that the depth of the fog is not entirely taking into consideration the distance from the camera relative to an animated object (superficial observation). What really baffles me is why |
Just as in #7197, if you don't convert to |
Just as in #7197, my bet is that |
You are correct, though your fiddle is broken (assigns The fix (with proper render): http://jsfiddle.net/90g09p4r/ Using So as you pointed out there is
If |
Hack to pre-normalize weights and use r.74dev: http://jsfiddle.net/d6mjj33a/7/ Compare with r.74dev without pre-normalizing: http://jsfiddle.net/d6mjj33a/2/ |
Indeed it does. Everything looks great in app after applying the hack. In fact it fixed another issue I was having in addition to #7197 that I have not posted yet for I wasn't yet sure if it was of my doing =] As for the next step I suppose |
Can this assumption really be made? Perhaps the current Blender exporter supplies normalized weights, the old one (r68) does not. I would prefer not to re-export hundreds of meshes if avoidable. The current exporter has so many problems with skeletal animations (particularly with multiple animations) that this wouldn't really be a viable option anyway. So I beg you to consider auto-normalization for the sake of backwards compatibility. All that being said; the hack works well enough, so do what you must =] |
I believe we can just normalize the resulting normal after the skinning code in the glsl code? Always normaling the normal once after all of our modifications (displacement, normal mapping, bump mapping, skinning) is likely a good idea anyhow. Shouldn't cost much at all either. |
I think as well have an optional function call to "normalizeSkinWeights()" is a useful function as well and won't hurt. But it would be optional because it will slow down loading unnecessarily when people know they already have good normals. |
What likely happened is that we removed an normalization of the normal somewhere that used to be there. We should just add it back. |
This all came from using
This would be great if the method belonged to |
@bhouston If the weights are not normalized, this affects not only the normals but the vertex positions too. Correct? Is it ever appropriate to have a model with non-normalized weights?
@titansoftime I think is would be more correct to say that |
Yes, agreed. |
Are only the normals affected or the positions as well? The two jsfiddles you posted seemed to have the same positions, just the normals changed. Or maybe the positions changed too and it was very subtle.
It happens. Would be cool to be robust in that situation if it didn't incur a runtime penalty and was easy to do. But I am not really able to engage on this topic, so what ever you guys decide. |
Taken from #7197:
I've been staring at this animation for over a year or so and can barely tell the difference, but there seems to be a subtle one. |
OK. Here is what I propose we do: continue to normalize the weights in the @mrdoob Does that make sense to you?
Unless I am mistaken, the new animation system produces different vertex positions than the old one (#7197 -- look at the sail). |
Sounds good! |
Fixed in #7679 |
It seems that whiter colors can pierce through the fog in 72. This was not an issue in 71.
http://jsfiddle.net/titansoftime/nu1217ch/
Changing to the master build provides expected results. This bug makes scenes with fog (most of mine) look kinda odd.
The text was updated successfully, but these errors were encountered: