New SkyControl releases

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


1 Like

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.)

1 Like

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.

1 Like

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.


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:
Release SkyControl v0.9.12 and jme3-utilities-debug v0.8.8 · stephengold/jme3-utilities · GitHub

Find it on Bintray at:
Version SkyControl/0.9.12 - stephengold

Why do they have normals?

1 Like

… 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.

1 Like

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

yes but without normals it shouldn’t work

1 Like

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 !!!



so, how to solve your problem in the result?

Are you asking me? Or Thoced?

sorry, I asked @thoced :slight_smile:

1 Like


Using the update of Skycontrol 0.9.12


Version 0.9.13 of SkyControl is now ready. The old SkyControl constructor is now deprecated, as promised.


Sorry for bumping this thread

@sgold any way I can use SkyControl with PBRLighting ?

1 Like