New SkyControl releases


Today (14 January) I released version 0.9.8 of SkyControl. It fixes a bug that could cause an IllegalArgumentException during cloning.

Find it on GitHub at:

Find it on Bintray at:

I’m hoping today was an auspicious day for software releases!


It’s a busy month for SkyControl. Today (25 January) I released version 0.9.11 of SkyControl. This version removes all dependencies on Bullet Physics, as requested.

Find it on GitHub at:

Find it on Bintray at:



When using the cartoon edge filter, the edges of the sky are thickened.

Do you think it would be possible to avoid this problem ?

Capture du 2018-02-15 12-37-28




I’ve never used JME’s cartoon edge filter and don’t know how it works. Do you have any idea what’s causing the edges to thicken?

My hunch is that you may want to increase the TopVerticalAngle. If that doesn’t help, I’ll investigate and let you know what I find.



Good evening,

If I’m not mistaken, the filter changes the entire scene is thickened all ends of the objects, stops are thickened.

The stops of the sky are naturally thickened too.

Without certainty, I will see by modifying the setQueuBucket of DomeMesh. I have the impression that by setting a node to Translucent, the stops are not modified.

I will try to modify your code and do the tests



I had another idea this morning. Perhaps you’re seeing edges of the star cube. Setting the starMotion parameter of the SkyControl constructor to false (if it isn’t already) should eliminate the star cube. Perhaps that will solve your issue.



I modified the QueuBucket in Translucent on the Geometry Dome in the getBottomDome and getTopDome methods of the SKyControleCore class.
With this, the edges of the dome are no longer affected by the filter but the problem is that the objects in the scene are no longer visible.

I do not see how to fix this problem



Have you tried my 2 suggestions yet?


I thought the cartoon filter was a post-processing filter… which means it can’t be doing anything strange with edges and it would have to be based on depth and/or some normal pass.

…I wouldn’t think that either of those would affect sky boxes as they should generally be rendered without depth or at a constant depth. Are they in the sky bucket? (That bucket forces a constant depth.)


I’m fairly sure that all geometries added by SkyControl are in the sky bucket.


Then in theory, the problem might be fixed by turning depth write off… but really I was pretty sure depth was constant in the sky bucket.


In the image you posted, I see two types of edges highlighted by the cartoon-edge filter. I see the horizon, and I see three edges of the star cube. I haven’t figured out how to prevent the filter from highlighting the horizon. However, I’ve confirmed that setting starMotionFlag to false eliminates the star cube and prevents the filter from highlighting the star cube’s edges.

In case you wish to combine star motion with the cartoon-edge filter, I’ve developed a solution for that case. My solution involves adding a new constructor for SkyControl. Once I’ve finished testing the changes, they’ll appear in version 0.9.12 of SkyControl.

[Solved] Simple sky with color gradient

Version 0.9.12 of SkyControl is now ready.

If you’re using an edge filter, I recommend using the new constructor with the TwoDomes option, like so:


new SkyControl(assetManager, cam, cloudFlattening, StarsOption.TwoDomes, bottomDome);

The new option emulates my old (pre-March 2017) approach of using a pair of domes to render moving stars. This approach uses more triangles than a star cube. But with domes, there are no sudden changes in normal/depth to trigger a filter’s edge-detection algorithm.

I’ll deprecate the old constructor eventually, so now might be a good time to become familiar with the new one:

  • Wherever you used false for the 4th (starMotionFlag) parameter, now you use StarsOption.TopDome.
  • Wherever you used true for the 4th (starMotionFlag) parameter, now you use StarsOption.Cubes.

The serialization format changed, but with backward compatibility: old J3O assets should still load with the new library.

Find it on GitHub at:

Find it on Bintray at:


Why do they have normals?


… because they’re constructed from meshes designed for general utility.

I tried simply removing the normals, and it wasn’t sufficient.


…which I think may deserve some deeper investigation because the cartoon edge filter works on normals. If a fragment’s normal is sufficiently different than the surrounding normals: draw a dark line.


@Nehon indicated that both depth and normals are used to render the borders.


yes but without normals it shouldn’t work


I’ve started a new topic for the cartoon-edge filter issue:

CartoonEdgeFilter detects edges of meshes without normals


Super, it works well, a big thank you !!!