-
Notifications
You must be signed in to change notification settings - Fork 22
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
Migrating from v1.0.2 to v2.0.0 bugs the shadows #20
Comments
@swift502 i tried to test a lot on customSplitCallback but unfortunatly i feel that is not the problem anymore. :/ P.S. : This is Vivasvan from your Discord. :) |
Hi, could you please provide a more detailed explanation of your problem? What exactly is broken, what version of three.js you are using in your project, what have you already tried to fix it, etc. Also it would be nice if you could provide a demo. |
There are 2 issues according to me.
Both are visible in the image. I am using v0.145.0 for three js https://www.npmjs.com/package/three Thing i tried:
Will send you a demo link shortly. |
I believe the only issue is just an extremely large shadow texture size.
How far is the clipping distance of the CSM? Can it maybe be reduced and the shadow map resolution increased? |
Another idea: have you been changing the glb models? are you sure you aren't importing another light sources from the glbs? In the vanilla sketchbook demo, nothing is ever perfectly black, like the tunnel shadow in your picture. I don't see how that could happen, except if multiple shadow casters were combined to turn the tunnel floor completely black. |
This is most likely related to |
Thank you guys for your reply.
@swift502 Yeah I am sure there is not light i removed the hemi-light and i am using your original glb.
I tried everything from 0 to camera.far( i.e. 1010) ....weirdly this parameter doesnt seem to change anything.
shadowBias: |
I wrote this small demo .... why is the shadow still blur in this? https://codepen.io/vivasvan100/pen/BaxPeLb?editors=1010 not sure but it could be the same effect. |
@ultWorld I think it works just fine. Using the settings from my Sketchbook demo, you get shadows as you see them in my demo. // I had to slightly modify this function, the "target" parameter is new in v2
let splitsCallback = (amount, near, far, target) =>
{
for (let i = amount - 1; i >= 0; i--)
{
target.push(Math.pow(1 / 4, i));
}
};
let csm = new THREE.CSM({
maxFar: 250,
cascades: 3,
shadowMapSize: 2048,
lightDirection: new THREE.Vector3(1, -1, 1).normalize(),
camera: camera,
parent: scene,
mode: 'custom',
customSplitsCallback: splitsCallback,
lightFar: 5000,
lightNear: 1,
shadowBias: 0,
});
csm.fade = true; As I suspected, your maxFar is far too far (funny, I know), set maxFar to 10 and see how sharp the shadows immediately become. shadowBias really isn't the main issue here, of course you'll have edge leaks if a shadow pixel is as big as the entire wall it's cast from. Same with the character model. So obviously CSM works, now it's about how you allocate the splits, and how much resolution you give the shadow maps. Finally, in my Sketchbook demo I got away with the highest shadow resolution I could, while already sacrificing a lot of performance. @StrandedKitty always emphasized how "unoptimized" this system essentially is, and that it's performance penalty might always be quite high compared to the results. |
@vivasvan1 Now, are these demo settings the same as in your Sketchbook fork? |
PS: While you can tie shadow maxFar to camera.far, I think most games don't do that. Usually the shadows can disappear quite a bit before camera.far, and it still looks acceptable. And you save lots of shadow resolution and performance. Maybe modern games do it differently, but traditionally I think it's just done like this. |
PPS: The reason the official Basic example works with a 1000 maxFar is because it must be absolutely massive compared to your cube in the codepen, or even the Sketchbook world. So scaling up your 3D scene should work just as well as lowering the distance parameters in the CSM. That's my theory anyways. |
@swift502 Thank you so much. It did work. Amazing work.
hahah. Yes, this is correct. This is what was going on in both the demo and my fork. reducing the maxFar to 300 from camera.far worked. Also the leak on the edge seems to be reduced quite a bit.
This is also helps. I changed it 2048 -> 4096. and the shadows look pretty much how i desired. On my laptop the performace drop is hardly noticible but maybe will set it 2048 or even less for mobile devices. This works now but would it be possible dark shadows like the once you have in your original work?And again thank you so much to both of you. Really appriciate your help <3 👍 P.S.
This was the perfect question. Its crazy to me how you figured it out only from this 😎 |
Cool!
What's odd to me that in some places the shadow darkness is correct right? Generally for darker shadows, you would just decrease the hemi light intensity. |
Oh, well, could it be the new fading feature? Do the shadows look different when you set |
@ultWorld Hi, did you manage to fix these problems with shadows? |
@StrandedKitty yes i did manage to fix it ... check the ongoing PR on the Sketchbook's repository. |
Hi, i am working on a fork of sketchbook and want to migrate to latest versions of the libraries.
Do you have any idea on what can i do to fix?
The text was updated successfully, but these errors were encountered: