DLSR in 3.1 rendering inaccurately and with artefacts?

I’ve made a separate thread to sum up everything I’ve learned about the problem I’m having with the DLSR.

The basic problem:

Here’s a gif if that helps (one of the better looking examples):

One of the problems is that shadows are drawn where two geometries stick together like so (red rectangles):

This was also a very very minor issue with the jme3.0 version of the renderer but it was a lot less pronounced.

It handles flat shaded surfaces better than smooth shaded ones which mostly produce results as shown in the green rectangle.

Another odd thing I noticed is that the new DLSR doesn’t seem to render the fully obscured pixels as shown here in comparison with 3.0:

Direction of light is from the star towards the ship position.

On the left is a partially obscured setup and right is what happens when the ship slightly rolls around Z axis to obsucre most of the top from the light source.

I’ve put together a MCVE, but since the DLSR works decently on primitives I’ve included two of my models to test with. Google Drive.

I’m 99% sure this sort of stuff shouldn’t generally look like it does:

Sounds like the best course of action would be to just revert back to using the lighting materials from 3.0 and import the 3.0 dlsr too, but I’m not exactly sure which are all the files it consists of.
So far I have this list:

  • Lighting (j3md, frag, vert)
  • PostShadow (j3md, frag, vert)
  • PostShadow15 (j3md, frag, vert)
  • DirectionalLightShadowRender (.java)

I’d appreciate any help.

I think the 3.0 shadows suffer from this though

I looked into it.
Seems something is not working as intended.
use this:


in 3.1 I added something that prevent back faces shadows to be rendered (the lighting shader usually already darkens those areas and with the shadows those areas were too dark). It’s defaulted to true to have the same behavior than in 3.0 but it seems something is wrong. Forcing it to true seems to fix it.
Could you try?

EDIT: actually it’s defaulted to false…

Awesome, that’s one of the mysteries solved! Same test as before:

I’d rather use the default way with the lighting itself making the back face shadows since it sounds it should be more performant but that leaves me with double shadows in some places:

So the high ambient light + backface shadows from the DLSR always ends up looking better.

Well if that works for you that’s cool :wink:

Seems the algorithm to detect back faces is somehow not working well on every geometries…that’s a bit weird but the results speak for themselves.

I see there’s another new method here (maybe I just haven’t noticed it in 3.0) called setEdgesThickness() which is documented as:

Sets the shadow edges thickness. default is 1, setting it to lower values can help to reduce the jagged effect of the shadow edges

Does that mean negative values or what? It’s an integer after all, not a float so you can’t set it to like 0.3 or something.

Edge thickness helps you to make the blur area thicker or thinner.
default is 10.
It can help tweaking shadow edges look.

The javadoc says it’s 1 for me, might wanna take a note for future updates.

Another thing, setting setEnabledStabilization(true) makes the renderer draw no shadows. It sounds like it should be able to fix the flickering, but hmm. Is it somehow light color dependant?

uh… that’s to avoid flickering when you move the camera. That’s very weird because this one is defaulted to true. And yeah the intended effect is obviously not to not render shadows :stuck_out_tongue:

indeed that’s a typo.

I don’t know if this is general, but the minimum value when it still works for me without breaking is setEdgesThickness(3), anything lower and it won’t render.

Yeah oops, I think it was actually the edge thickness that broke it when I set it to 1 so I thought it was this instead.

Anyhow, I’m still getting these sort of artefacts:

Current setup:

    		final int SHADOWMAP_SIZE=2048;
    		dlsr = new DirectionalLightShadowRenderer(assetManager, SHADOWMAP_SIZE, 2);

The diameter of a single cube here is 2 world units if the overall scale relates to anything.

Seems like you have Z fighting… you can play with this :

 dlsr.getPreShadowForcedRenderState().setPolyOffset(5, 3);

Those params changed in 3.1 but now you can change them through the API. Those values are those used in 3.0

Not much success with that, unfortunately. :confused:

The value parameter doesn’t have much effect and the factor param just offsets the shadows.

I can get more Z fighting from it though, by setting the factor to 0 hah

Yet another thing I noticed, during warp the renderer seems to just give up.

No idea what could have caused that since I pretty much only add the radial blur filter.

the dlsr must be before the filterPostprocessor

It is. That’s been a problem in 3.0 so I’ve made it so it inserts itself to the 1st spot whenever it’s removed and readded (I use 4 different processors).

    game.getViewPort().getProcessors().add(0, dlsr);

Going to warp doesn’t change the setup in any way though, just enables the blur filter and sets the distortion factor.

The problem is still there even if I remove all the other processors so it’s probably the slight camera shake and the changing light direction (the lightdir is always the vector from the star to the ship so it changes when you move around - and warp moves you around really fast).

I think we’re pretty much at a dead end here, so I’d rather like to know if this list is complete:

Unless the 3.0 version of the DLSR somehow can’t work with 3.1…?

That could be the problem, how do you manage that with the new dlsr?

Well you can revert back yes, by using those files, but you may also have to pick the AbstractShadowRenderer. At least you can try that.

IMO you’re not that far to have it to work. Appart from what i told you the renderer is pretty much the same… so the issue may be somewhere else.


Every frame, where the container is a node that has the player’s inverse position and the star is located at 0,0,0 in that virtal coordinate system.

It’s probably a good thing to note that I use the shadowlight DirectionalLight with a black transparent color that is used only for shadow rendering. Everything is lit through a pointlight with an infinite reach from the star itself. Since the distances are large the discrepancies are small (possibly what causes the double shadows with no backfaces).

I need this system in place to light planets and large objects on the other side of the star system since they’d otherwise need a directional light each while having “local” shadows.

I haven’t looked that much into it but the Lighting.j3md seems to have been changed somewhat (changing the LightPos to LightDir and some other things) and the dlsr with it.

Since this isn’t going anywhere at all I’m trying to import the 3.0 dlsr now but that’s proving a problem as well, especially the AbstractShadowRenderer.

The thing is that the RenderQueue had a bunch of extra stuff (shadowRecv, shadowCasv) that was removed along with any access to the GeometryLists at all. So apart from having to import half of jme3/shadows there’s also this line in setMatParams:

GeometryList l = viewPort.getQueue().getShadowQueueContent(ShadowMode.Receive);

There is literally no way to get any GeometryLists out of the new RenderQueue directly. Feature request: getters for everything.

Anyhow I looked at how the 3.1 dlsr does this and I see it does the whole geometry viewport culling thing via the new


and gets a geometry list that way. I managed to get it to fetch that instead of the problematic line but the renderer doesn’t seem to like the input. Aka no shadows get rendered at all.

The code is a bit long to paste here so I just zipped it up and uploaded if you could take a look.