Hi,
is there a way to increase the precision in the rendering of shadows? I have set a high epsilon to make shadows very near to planes, because I have to handle planes for a card game, and I have to put multiple planes one on top of the other, keeping the shadow between the planes to define the borders. Currently, as soon as a card goes a bit far from the camera the shadow jumps upon the card. I have decreased the camera “far” parameter as much as possible to keep everything inside the camera range (thus increasing the accuracy, I suppose), but it is not sufficient yet.
Do I have to manipulate frustum or something like that?
I am using a DirectionalLight + StaticLightPicker + TripleFilteredShadowMapMethod, but if you have a different combo to suggest I can change them, I just need to lighten a table from top, a very simple scene.
Do you have a simple example you could share demonstrating the shadow quality issues.
As you’ve mentioned, there are various shadow mappers & methods that you could try which may help as some (but maybe untested) have additional params e.g. the NearDirectionalShadowMapper takes a coverageRatio that is used to ‘to indicate the ratio of the view frustum that needs to be covered by the shadow map’ (from the comments)
Doing some tests I have noticed that the problem is caused by the material of the plane that I use to catch the shadows of the cards: I use a white ColorMaterial with blendmode MULTIPLY, so I can use it to simulate the shadows on the prerendered 3D background (a sort of primitive ShadowMaterial). More in detail the problem is caused by the blendmode: if it is enabled the shadows are rendered in front of the cards, while if I disable it the shadows are perfect. @singmajesty is playing with Away3D now, let’s wait and see, in the meanwhile I will have to find an alternative way to draw shadows on the prerendered background, because Away3D can’t use ShadowMaterials at the moment.
Well, the problem I described is a weird one caused by material blendmode. I have tried 3-4 other methods, one crashes at runtime, but the other seem to work, I just have to test and learn more.
I did the original Away3D haxe/openfl port but haven’t had a lot of time to play with it more, especially since it moved into the OpenFL repos - although I really want too.
I’ve been a bit distracted recently on the more physical side of things - 3D printing but I need to get back to doing some dev.
I’d really like to integrate oimo physics and also perhaps get a CSG library integrated too. But also it’d be great if Away3D could have a pure GL (or other) renderer rather than just Stage3D/AGAL. So plenty of ideas - just need more hours in the day
As for limitations of of Stage3D over GL, my main interest is of course the shaders. I’ve always found AGAL a pain in the a**.
I’m sure there would be more flexibility but it’ll be initially confined to the way Away3D is implement - depending how easy it is to pull the rendering out. GL is only one option too as HxSL would be cool, maybe even kha.
I’m in the process of trying to combine our core GL rendering (for the display list) with Stage3D into one single renderer. One thing I’m hoping/expecting to come out of this would be (at the very least) some combination of the current shader system into Program3D, as simple as program3D.upload (glslFragment, glslVertex), or something using macros like openfl.display.Shader
but are shadows broke at the moment?
