Maybe that’s the hardcoded texture size in pssm 1.0…but you would have it with bsr too
I don’t have older hardware, that is recent enough to run JME.
I just went back and checked, for me its the basic shadow renderer that is really bad:
http://youtu.be/u_8Bm_7hN08
There are issues on the PSSM renderer too though, take a look at the shadow edges on the spheres jittering around - especially on the floor and small balls at around 20 and 30s.
http://youtu.be/r0BAsLqjqJk
(I’m running on pretty current hardware too, although the graphics driver probably could be updated)
Graphics card: AMD Radeon HD 6900 series
Driver: 8.821.0.0
@zarch that’s not an issue, that’s dither filtering…it’s ugly on round shapes.
try to use PCF filtering.
@nehon said:
Maybe that's the hardcoded texture size in pssm 1.0....but you would have it with bsr too
I don't have older hardware, that is recent enough to run JME.
running Tests, BSR works, PSSM not.
in BSR i tried 256 / 512 / 1024 and it work for all of sizes.
in PSSM i tried 256 / 512 / 1024 and it have issue for all of sizes.
as i good understand "1.0" you mean maximum 1024 like @t0neg0d mentioned.
then it should work using 1024, but it's not.
Some else worth mentioning… this has nothing to do with what you all are talking about.
In the BSR…
[java]Vector3f frustaCenter = new Vector3f();
for (Vector3f point : points) {
frustaCenter.addLocal(point);
}
frustaCenter.multLocal(1f / 8f); // <<< SPECIFICALLY THIS LINE
// update light direction
shadowCam.setProjectionMatrix(null);
shadowCam.setParallelProjection(true);
// shadowCam.setFrustumPerspective(45, 1, 1, 20);
shadowCam.lookAtDirection(direction, Vector3f.UNIT_Y);
shadowCam.update();
shadowCam.setLocation(frustaCenter);
shadowCam.update();
shadowCam.updateViewProjection();[/java]
This sets the shadow camera distance, yes? I noticed, if you divide this by higher # (like the size of the shadow map) instead of 8f you get MUCH more detailed shadows. Since it’s parallel projection… eh… you get the idea.
OK…but what’s the logic behind it?
this code is basically computing the center of the light frustum. There is 8 points, so the sum is divided by 8. What ever result it give you to divide it by 1024, it does not make much sense.
@nehon said:
OK...but what's the logic behind it?
this code is basically computing the center of the light frustum. There is 8 points, so the sum is divided by 8. What ever result it give you to divide it by 1024, it does not make much sense.
Yep... it doesn't. But the results are what I stated above. It's interesting trying things just to see what the results will be even though it makes no sense. If I had said... wow... that's not logical, I wouldn't have tried it.... and I wouldn't have seen the shadows go from extremely pixelated to extremely smooth. Bizarre stuff, eh? Trial and error sometimes works to your advantage.
But... seriously, try it... divide by 16, 32, 64, etc, etc, etc... you'll see the quality gradually increase.
@nehon said:
@zarch that's not an issue, that's dither filtering...it's ugly on round shapes.
try to use PCF filtering.
I'm just running the shadow test apps from JME3Tests. Setting was bilinear. I changed it to PCF4 and things didn't look much better, I then changed it to PCF8 and it did improve a lot but there was weird banding on the lit side of the spheres.
I've just tried turning PSSM on in my game though and it looks fine - which is odd as I thought I had tested it before and it didn't, maybe I had something wrong in the settings last time or something.
However BSR is still broken badly :)
Well people not a lot meaner than me would qualify that as a Hack.
There must be a reason behind this behavior, maybe you could search the real reason and find a proper solution.
@nehon said:
Well people not a lot meaner than me would qualify that as a Hack.
There must be a reason behind this behavior, maybe you could search the real reason and find a proper solution.
Hahaha... hack or not... it works. Even if there is a reason behind this behavior, who is to say that this isn't the "proper solution"?
Seriously?
Well i agree sometime, that it’s not because you don’t understand the logic that it’s illogical…but when it’s obviously illogical like this, you have to ask you some questions…
The thing here is that the frustum is not parallel so the more you get the center closer to the object the neater is the projected image. But that only works because the object is probably at 0,0,0.
The more you divide the center the more it get close to 0,0,0. That’s probably why…
Move the teapot to 5,5,5 in the BSR test case and i guess it’s gonna give you unexpected result.
in BSR:
moved teapot to 5,5,5 and shadow is still proper. no unexpected result.
@nehon said:
Move the teapot to 5,5,5 in the BSR test case and i guess it's gonna give you unexpected result.
Nope... works just the same.
Fine then… use it like that if you wish.
@nehon said:
Fine then.... use it like that if you wish.
Um.... ok? Look, I'm just noting the things I find in case someone else wishes to use them... or maybe has an explanation as to why it happened. I'm glad you're taking the time to bring this stuff up. I just wanted to report back what happened when I did what you said to do.
I know, I just gave up trying to convince you that it’s wrong…
What works in one specific case won’t work in other cases. Try using that modified code in an actual application and you will start seeing artifacts.
@Momoko_Fan said:
What works in one specific case won't work in other cases. Try using that modified code in an actual application and you will start seeing artifacts.
I had done this before posting the original comment (tried it in my game). I have no clue why still... but it looks and works great.