// Background story… you may skip
I am doing some optimization for laptops, because they have very low performance GPU and while I was fiddling around, I DISCOVERED one of the most insane performance related thing that has been sitting right in front of my eyes for MONTHS. I was wondering why shadows looked broken or way over-darkened and no matter what I was trying to do to my shadow filter, it would never look OK, always too dark or VERY rough edges and my high-end 250$ GPU was not performing right… WELL GUESS WHAT… stupid me, I never knew SkyControl was taking care of shadows by itself already! So I had 2 shadow filters running one on top of each other for MONTHS and I was complaining… god sometimes I really don’t know what I’m doing.
SO… I was wondering if there was a way to completely remove shadow filters (and/or renderers) out of SkyControl so that I manually take care of it. If it’s not possible, I will use SkyControl’s instead and delete all my shadow code I had before elsewhere in my project (lol stupid me).
Here are 2 screenshots. IN NONE OF THEM do I have a shadow filter or renderer ANYWHERE in the code. So here’s the comparison between WITH SkyControl first and then WITHOUT SkyControl. As you may see, SkyControl comes tied with a shadow filter, even tough I do not have any in my own code and that I have set this: sky_control.getUpdater().setShadowFiltersEnabled(false);
As a matter of fact, I do not know what sky_control.getUpdater().setShadowFiltersEnabled(false); is supposed to do, doesn’t seem to change anything in my case.
WITH SkyControl (see the shadows on bottom right? Not intended to be there.)
WITHOUT SkyControl (no shadows, which is good. Also, look at this IMPRESSIVE +1000fps, this means SkyControl is taking 200fps to render, probably less if we find a way to disable the shadow filter/render)
I’m puzzled by your request because, despite your insistence, SkyControl does NOT provide a shadow filter. TestSkyControl has an addShadows() method which can instantiate one for demonstration purposes, but that’s because SkyControl itself does not provide shadows.
What leads you to believe there’s a shadow filter in your app? Looking at the two screenshots, I don’t see shadows in either of them. For instance, none of the trees casts a distinct shadow on the ground. Some portions of the trees and ground are darker than others; this might be due to shading, which (believe it or not) has nothing to do with shadows.
When you removed SkyControl, you got a black sky; this might because your view port’s background color is black. It’s unlikely to be caused by a shadow filter on the view port.
If setShadowFiltersEnabled(false) has no effect, that might be because there are no shadow filters for the updater to disable.
Actually SkyControl itself does take very little time in your example, at 1000 fps every frame takes 1 millisecond to render with the SkyControl it takes 1.25 milliseconds or 800 fps.
Performance shouldn’t be measured in frames per second, for example losing one frame at 30 fps, your render time will go from 33.3 ms to 34.5 ms costing more than 1 ms.
@sgold, I’m very surprised that you’re saying SkyControl does not create a shadow filter by itself… BTW I’m not talking about the black background at the top of the picture. Look at the bottom left on the grass, you can see the difference. First image has shadows, second does not. That’s the issue I’m inquiring about. Disabling SkyControl makes the shadows on the grass disappear. That’s pretty weird…
EDIT: Wait, maybe I got you wrong, but are you implying that the black background can cause like… shadow occlusion on the terrain even tough I do not have any shadow filter or renderer in my code?
@Perjin, this is not the issue… tough your calculation seems pretty wrong to me. Let’s put it this way. Every second, SkyControl spends 0.2s doing its job. That’s 1/5th or 20% of the whole game process. Not sure if you understand my point of view. I’m not saying 200fps is a big loss because OBVIOUSLY on another GPU which the game would run on at 100fps, SkyControl would take 20fps to do its job, but… as you can see 20% of the whole game process is quite something. BUT… Like I said, this is not the issue…
The issue is that if I comment out the SkyControl instanciation lines, shadows disappear, so my question was how to disable them, but if Stephen says there are no shadows created by SkyControl and that I have absolutely no shadow filter and no shadow renderer in my own code, where are those coming from and why are they disappearing when I comment out SkyControl?!
SR is ShadowRenderer. I was testing the performance difference on my scene between the filter and the renderer and I had the text block at the top like: (is_using_shadow_filter ? “SF” : “SR”) but I had commented out all occurences of both, so the boolean just printed SR while it was really “None” if you will.
Newer screenshots (frustumFar is 4x larger, hence the lower fps if anybody asks)
Since SkyControl creates absolutely no shadow renderer/filter then is it possible that SkyControl’s directional light causes implicit ambiant occlusion or something? I do not have any SSAO filter activated in my code, so I’m wondering if the terrain shader could implicitely take SkyControl’s light and do some voodoo automagical shadow with it?
Yes, the directional light is EXACTLY the same in both screenshots as the only thing that changes the light direction is the time of the day (see the HEURE variable in the top right text block) it’s like 10:00 AM if you will. I am manually incrementing 1 hour steps with my keyboard so it’s precisely the same time, thus the same light direction.
Tree billboards do NOT cast ANY shadows yet so it’s not that. As a matter of fact, here are screenshots of the same test without the tree billboards, rocks, flowers, literally ONLY including the terrain quads:
In the second screen shot there seems to be almost no lighting at all.
…if only there were a way to step through the code and see what it was actually doing… oh, wait.
Edit: also in screen shots like that it’s better if you leave the JME stats on. We could get some good clues from the triangle counts between the two views.
I’m more and more convinced it’s the fragment shader that’s INVENTING shadows by itself now. Not sure why it wouldn’t do that before. It must be my new AMD card that’s playing tricks on me again. Everything shadow related has been an HORRIBLE, HORRIBLE route to go and fix, and after 2 weeks, I’m still not done yet. For instance, j3o models that were PERFECT before on my GTX card are now shadowed all wrong and I see quite a good amount of triangle faces flashing back and forth between COMPLETELY BLACK to normal shadow, to no shadow at all, it’s pretty random when the camera is approaching them, a little like if normals were shifting orientation or something. Maybe it’s the way AMD GPU’s calculate floats or round off errors or something… I really have no clue for now, but I’ll investiguate more, it’s probably my AMD card.
I’ll check it out on a friend of mine that has a GTX card, if it’s not doing this on his computer, I’ll blame my card, but… the problem is… I can’t tell potential game buyers that they have to ditch their AMD card to get a nVidia one you know? It has to work correctly on the 2 major gaming graphics card vendors.
TTYL, thank you very much for reassuring me by telling me SkyControl has NOTHING to do with those out of nowhere shadows.
I +1’ed for the effort and information regarding SkyControl.
@.Ben. said:
I'm more and more convinced it's the fragment shader that's INVENTING shadows by itself now.
wow...that's pretty powerful...but i honestly doubt it.
@.Ben. said:
Not sure why it wouldn't do that before. It must be my new AMD card that's playing tricks on me again. Everything shadow related has been an HORRIBLE, HORRIBLE route to go and fix, and after 2 weeks, I'm still not done yet. For instance, j3o models that were PERFECT before on my GTX card are now shadowed all wrong and I see quite a good amount of triangle faces flashing back and forth between COMPLETELY BLACK to normal shadow, to no shadow at all, it's pretty random when the camera is approaching them, a little like if normals were shifting orientation or something. Maybe it's the way AMD GPU's calculate floats or round off errors or something... I really have no clue for now, but I'll investiguate more, it's probably my AMD card.
I’ll check it out on a friend of mine that has a GTX card, if it’s not doing this on his computer, I’ll blame my card, but… the problem is… I can’t tell potential game buyers that they have to ditch their AMD card to get a nVidia one you know? It has to work correctly on the 2 major gaming graphics card vendors.
TTYL, thank you very much for reassuring me by telling me SkyControl has NOTHING to do with those out of nowhere shadows.
I +1’ed for the effort and information regarding SkyControl.
That sounds like you're using normal maps and didn't generate the tangents for the models. Nvidia is sometime too nice with developers, I already noticed that models without tangents were looking almost good. Lighting was not really accurate but nothing compared to the mess they were on Ati.
Anyway...try to generate the tangents for those models.
For the terrain though…not sure this is the issue. Do you use normal map for the terrain? It doesn’t look like but you never know…if you do try to generate the tangents too.
First screen shot looks like there is a directional light coming from top left shading the ground. i agree it does looks like shadows in the far distance…but that looks more like wrong lighting.
The second looks like you have just and ambient light.
What’s with the black dots on the first shot?
How is this terrain generated?
Normals are maybe wrong…
LLLLLOLLLLL… the black dots are FLIES! No joke. I made a particle emitter that mimics flies hahahaha… >.< I thought it was hilarious so I left it there. At night, those become green/blue fireflies. Pretty cool what you can achieve with a particle emitter.
It’s basically a terrain quad, nothing fancy. I’m really wondering maybe its fragment shader is done wrong and treats lighting and shadows in the same pass… which seems like it’s a good thing, but is also a bad thing at the same time because it would make the shadow filter useless and apply double the shadow on the terrain.
I messed a little with the fragment shader and found out that if I tweak values here and there I could make lighting work and get rid of shadows. My question is, and I’m sorry if I’m wrong or being very noob about this, but why aren’t all shaders programmed like this? Lighting and shadow in the same pass? I find it’s in fact a very pratical thing, no? It would save so many render passes no?
@.Ben. said:
LLLLLOLLLLL... the black dots are FLIES! :D No joke. I made a particle emitter that mimics flies :D hahahaha... >.< I thought it was hilarious so I left it there. At night, those become green/blue fireflies. Pretty cool what you can achieve with a particle emitter.
It’s basically a terrain quad, nothing fancy. I’m really wondering maybe its fragment shader is done wrong and treats lighting and shadows in the same pass… which seems like it’s a good thing, but is also a bad thing at the same time because it would make the shadow filter useless and apply double the shadow on the terrain.
I messed a little with the fragment shader and found out that if I tweak values here and there I could make lighting work and get rid of shadows. My question is, and I’m sorry if I’m wrong or being very noob about this, but why aren’t all shaders programmed like this? Lighting and shadow in the same pass? I find it’s in fact a very pratical thing, no? It would save so many render passes no?
Because in the general case it can’t be done… at least not at interactive framerates. You’d have to trace a ray through the scene to every light source. There will always need to be a separate shadow rendering pass. It could be done before the regular pass and then applied then but really the application of the shadows is the quick part.
It’s sometimes possible with heightmapped based terrain to have the terrain self-shadow itself because you can sample around. It’s either imperfect or expensive to do this in a shader unless it’s preprocessed. But it won’t shadow anything else and you’d have to set the terrain to cast and not receive… and then couldn’t use the post filter version of shadows.
Yeah, which means that this is probably not what is happening here, even if it’s possible, it’s not practical so it’s highly doubtful it was designed like this.
What I have to start wondering is why you haven’t run this in the debugger, set a breakpoint, and then just looked at what scene processors and filters are employed.
I guess I could have… this will sound very dumb, but I am uncertain about how to exactly do that. To be honest, I’ve been doing System.out.println()'s since the very first day I used JME3 and always got out of the trouble quite fast, but this problem is not about Java, it’s about GLSL and it’s really hard for me to debug, there aren’t any ways I know of to set breakpoints inside a shader! I know for a fact that there aren’t any shadow processors (renderer/filter) involved in the WHOLE application, since Stephen said SkyControl does not create one by itself and I do not have any in my whole code.
I have modified the terrain shader and it looks like it was creating self shadow! I tweaked it to cancel the effect and let the standard JME3 pipeline cast shadows on it. Now it looks normal like it should. Not sure why my GTX card was not drawing them but oh well. Case closed. Thanks all. I +1’ed all of you once for the explanations and suggestions.
SkyControl does include its own shaders. I suppose it might be possible for one shader (SkyControl’s, for instance) to interfere with another shader (Lighting.vert or whatever you use for terrain) if one or both were buggy.
