Now on to the next thing.
I’m seeing some weird shadow casting.
In this example the entire wall should be shadowed. You can see from the cast.
.setShadowMode(ShadowMode.CastAndReceive);
All the walls are set with CastAndReceive.
Does something have a quick idea what it might be.
Without knowing more detail, my guess would be that your walls are essentially single quads with backface culling turned off. JME does no special rendering of “back faces” and so it will have the same lighting as the front-face normals indicate.
To fix this, you can either hack the shader to deal with backface lighting or just double up your quads and leave backface culling on instead of turning it off. (ie: render both sides of the wall.)
Yes. It is about the hundreds of Quads that don’t have backs to them. Thanks, that gets me down a path to figure it out.
The shadow renderer class also has a renderBackFacesShadows option – dunno if toggling that would be relevant here?
I tried that and it didn’t work. pspeed was correct and JME is rendering is based on the back face instead of using the front face.
That would be if the front face is to the back of the light direction, so there is no normals or face towards the light. So JME thinks there really isn’t a reason to cast a shadow.
I’m thinking of changing the Walls from Quads to Box with a depth of something like 0.01f, I"ll play around it to see if it works, I would bet the shadow casting would work out correctly, just need to make sure it doesn’t change the feel of the game.
I’m not to worry about the weird casting on the walls, all the models that are in the game receive shadows correctly. JME just doesn’t cast shadows correctly on Quads when they do not face the light. I can understand.
But the quads do not have the cast correctly.
This is a pixel 8bit/16bit game, so not being 100% kind of gives to the feel of the game.
Why not just double them up and flip the duplicates? (Edit: though to be fair, depending on how your walls will be viewed, some thickness might not be a bad thing.)
Just to clarify because I could read your comment a couple different ways.
JME’s materials assume that the normals point in the front-face direction and will render lighting according to that. When rendering the back faces, the normals are not flipped so they still point in the front-face direction… and thus lighting looks “backwards” on the back faces.
Taking into account you already wrote your own engine, maybe adding a oneliner to the fragment shader does not scare you away. There is gl_FrontFacing available to the fragment shader that is true when the fragment(s) currently rendered are front facing. Basically
normal *= float(gl_FrontFacing) * 2.0 - 1.0;
before using the normal in calculations should do the trick, without having to send twice the amount of quads or an unneccessary amount of vertices that come with the box approach. Have not tested it though
It should work. Life only gets more complicated if normal maps or parallax mapping are ever required.
…it also may still confuse shadow rendering but I guess shadow rendering must normally account for this for inside out models.
The main down side of the double quads approach is just memory. Effectively the same number of triangles are rendered either way. This seems like a pretty low number of triangles from other posts and double quads is very straight-forward otherwise.
yes the double quads approach is definitely handy and probably the easiest way.
I just gave the suggestion because OP seems like someone who might like to play around with GL stuff
Im not sure though it would be a problem when using normalMaps. Whats read from the normalMap is in tangentspace anyway and for backfaces that in the game are treated like usual front faces the normal for constructing the TBN should be flipped anyway, probably before crossing it with the tangent, shouldnt it?
I think it should be after crossing it with tangent because space is backwards. It would need to be tested for sure and then if you are new to shaders it’s a “did I do it wrong or is the approach wrong?” territory that can be tricky to work out.
…worse still is that tangent space errors can be tough to spot… and by their nature these would only manifest on half the faces.
Anyway, not a problem if normal/bump maps are not used… but if they are or will be then it may be a point in favor of just doubling+flipping the quads.
Doubling quads do not work. In those pictures, they are quads but on the other side of the wall that you see is another quad facing the opposite of the wall in the picture.
So I have 2 quads back to back with normals sticking straight out. Nothing other than DiffuseMap.
Here is another example of something that Quads do, I don’t see this as an error for JME but limitation of Quads.
Now check it out. Go around to the other side of the Quad and see the view.
It is funny…
Your view shows that there is no quad facing in the other direction. Something is wrong in your code.
If you put one quad facing west and one facing east then from the west you will see a quad and from the east you will see a quad. The one thing I can guarantee is that if you do not see one of those quads then it is not there.
It is an odd game, everything is Quads. There are “ONE WAY” walls. So there is not always an EAST/WEST Quad. So the player see an open path and walks through and then they turn around there is now a Quad.
Basically a secret one-way entry or exit into an area. I did it in my own engine because it was simple and would not require any form of control to make things visible or not, culling would take care of it.
So if you imagine if such a thing could exist in real life then it would definitely cast a shadow. The light hitting it from the visible side would have to bounce off… otherwise it would be black.
So if what you are now complaining about is that a half-visible wall is casting a shadow then I don’t know what to tell you… a half visible wall WOULD cast a shadow.
I thought you were complaining about back faces looking lit when they shouldn’t.
I was not complaining about anything when it comes to the blank Quad casting a shadow. I understand that and was commenting it was funny to see.
My real issue with the picture above with the Tree. The walls behind the tree are in shadow but they are not drawn with a shadow on it. You know I use Quads, but on the other side of that wall is Quads facing out. So the view from the sun will see a wall of Quads and on the opposite side has more Quads. So they are EAST/WEST Quads. But the shadow doesn’t cast on the back Quad.
From your other thread, I think that’s because you have your ambient cranked up, no?
100% ambient = ignore all directional lighting. You shouldn’t need shadows to get “facing away from the light” to be dark.
And normally even if you really did want this for some strange reason, you could turn on back face shadows as from earlier in the thread… but I think the fact that your walls have no thickness might confuse that.
Edit: it is important to keep track of the difference between lighting and shadows. They are not the same thing in 3D graphics.
