OK... got self-shadowing working. It has some issues with moire, but I'm not sure how much of that is the shader, and how much of it's Spring's borked shadow volume becoming really visible.
It's not quite right, basically, but it's a step forwards nonetheless.
I don't see any shadows in that screenshot. Make sure to enable shadows with /shadows 1.
And yeah, there is weirdness with water. But ... hell, there's weirdness with water4 even with the old ARB shaders. I don't know why, and it makes very little sense, frankly.
I have observed that Units in motion aren't having their shadowmaps updated correctly (it's like they're being rotated to a different matrix, or something).
This is apparently an engine bug- I've seen it on the regular, non-shader Units as well, now that I know what I'm looking for. It's just less apparent with the regular shadows, because of a couple of things that were done to reduce moire.
I've made a post about it.
V1.0 is almost done. Yup... going to Beta status after that.
I should put up some screens, showing how cool Chickens look with normalmaps. I have maybe half of the World Builder stuff normalmapped now- P.U.R.E.'s stuff will take longer.
Allright - as a sidenote you might want to add some kind of shader LOD that either does provide less precise results or entirely shuts off at a respecitve viewing distance. Might be a bit early to talk about this but if there's a need for any basis inside the shaders it should be done now rather than later...
This certainly would help improve performance either in heavy scenes or on slow computers. It also would make it possible to generate a dynamic detail level depending on e.g. the fps...
Well... I could do LODs for the shader itself, and cut it down. But if you can run the shader at all, you probably have hardware where it's nearly free to run vs. the ARB shader, on your graphics card.
Most of the cost of any Lua shader is CPU-side, and no matter what Unit shader you run, you can't avoid that overhead.
The key, going forward, is to develop a system like LUPS, where it's managed, so that multiple shaders can be run on a given Unit simultaneously without adding a lot of CPU cost. That's the biggest issue with this demo- the lighting system eats CPU, and so does the Unit shader.
V1.0 (beta) has been reached. I finally fixed teamcolor, I think.
Click to enlarge. Even rudimentary normalmapping like this (I did this in maybe 10 minutes of airbrush grayscale) can make a big difference. This shot highlights the feel, but to be frank a lot of it's stuff you see when the units are in motion- the difference in lighting is a really big deal then.
I have observed that Units in motion aren't having their shadowmaps updated correctly (it's like they're being rotated to a different matrix, or something).
from what i see your shadow texcoords are totally broken -> check how the shadow is correctly projected to the ground and your incorrect selfshadowing.
I got proof that the shadows are an engine bug, not a shader bug!
Here is the same object, moving, without the GLSL shader... and the very same shadow bug! You'll have to look closely, but you can see that the shadow is being projected onto the model geometry to the upper-left, whereas the shadow is towards the lower right!
Users browsing this forum: No registered users and 3 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum