Issues with Sky Cloud and SVOGI

Lumberyard 1.27
Maybe I’m missing something, please advise if you were able to resolve.
Sky Cloud component seem to render last over anything else, any geometry for example when its bounding box is large around 100x100:

Maybe I misunderstood, and it meant to be used as 1 cloud per entity, so if I want many clouds throughout the sky, and just need to have many smaller entities with that component?

For SVOGI I enabled its Gem, disabled CryEntity removal gem and other settings as recommended in

There still seem to be no bounce to the sun or other light:

Tried svoToggleShowVoxels in console and it displayed nothing
r_ShowRenderTarget svo_fin render targets also just black.
I see in known issues:
“The Mesh component doesn’t voxelize into the SVOTI Global Illumination buffer in order to contribute to lighting.”

so I tried with white box and vegetation components, but they also seem not affected.
Is SVOGI functional at this point, or I’m missing something?


I was able to get SVOGI to voxelize the level, but does seem to voxelize only terrain:


off with env probe(just for comparison):

Since it only voxelizes terrain, light bounces only off the terrain:

terrain above the floor, bounces light back to the ceiling:

terrain lower then floor, light is not bouncing:

Also when SVOGI does work, it kind of sporadic, and bounced light appear and disappear, and it keeps revoxelizing whole terrain if camera position changes.

I would appreciate any info as to if SVOGI being on a roadmap to improve or likely to be deprecated in the future?

1 Like

Also looking at Sky Cloud manual,
Sky Cloud - Lumberyard User Guide (

I tried placing several clouds in a similar way, as you can see from this angle, they are on the edges of the terrain and most are far above it:

But with camera close to even the middle of the terrain, they are clipping through it and other objects:

From some angles, clouds are not not clipping through, and then it looks nice:

Does it work properly for anybody else, or its just me? If this is a bug, is there any info on its fix timeline/priority?

  • SVOGI works
  • SVOGI doesn’t work

0 voters

  • Clouds work properly
  • Clouds clip through objects

0 voters

1 Like

I have also noticed this cloud issue. It’s really bad. I hope there’s a fix available soon.

1 Like

Found a workaround for clouds.

  1. Make a duplicate of volumeobject.cfx shader as volumeobject2.cfx
    (you can follow this link on how to do that)

  2. Comment out line 126:

That removes clouds clippings in the center of the screen for me.
But they still clipping on the sides of the screen

  1. I think this next variable that we need to change, stands for pixel depth, though not sure, you can set it to const value 800.0 or 200.0 worked ok for me, but the draw back is that it will not draw clouds that are far away from the camera, so I capping it at minimum of 800.0 seem to work ok, it still draws clouds far away, but it will not draw them closer than that. So this is not perfect solution, but works if you are only planning to keep clouds far from the camera:

  2. Duplicate volumeObject.mtl and set new one to use the new shader Volumeobject2
    Make sure to toggle Soft Intersections, or it will still be clipping:

  3. Set Sky Cloud component to use the new material:

  4. With these changes I was not able to recreate any clipping:

If you know how to modify this shader to draw clouds near and far properly, without issues, please share.

1 Like

Looking more into SVOGI, when stepping through its logic with a debugger, it does seem to go though meshes and tries to voxelize them, I think I see why expected effect is not visible though.

I set SVOGI to integration mode 2, which would reflect gathered voxels in mirror like materials, turned off screen space reflections and setup a bunch of mirrors throughout the level. Also had to set hdr max to very dark, otherwise reflected voxels are too bright, but that is why example below is so dark.

You can see below that part of the red sphere is being revoxelized as I move it, but

  1. Only parts of it(It doesn’t voxelize more with time).
  2. The mirror on the right is away and quite a bit above the sphere, so it should not be reflecting it at that position, so its like voxels are positioned somewhere away from their originating meshes.
  3. When spehere is moved along x(red) axis, it moves in the opposite direction in the reflection, so maybe thats part of the issue, x axis is somehow flipped for voxel vs meshes?
  4. The voxel bricks(yellow) are not square, they are squished for some reason, that seem to also contribute to the incorrect voxelization.

From other posts It sounds like after LY 1.14, SVOGI was moved to its own GEM and kind of got broken in the process, there are few posts, but here is a good example:
How can we get the same effects in 1.16 with 1.14 by setting SVOGI parameters? - Lumberyard Discussion / Art & Graphics - Amazon Lumberyard Game Dev Community (
Also I see some recommend to increase shadow bias and SSDO for better results. As I understand, shadow bias simply makes shadows less dark, and SSDO amount property there to reduce non GI AO, not to increase it, since SVOTI is suppose to bring more of its own AO, ssdo can be increased without svoti on.

I tried getting 1.14 from GitHub to compare visual results, but supporting files for git_bootstrap.exe are no longer available for that version, so I’m unable to compile/build it.

In any case, I would love to see maybe a separate website specifically for features and GEMs for LY, where feature requests can be submitted, upvoted/downvoted, also existing features and GEM’s can be rated, or show/let submit current issues that also can be rated by importance to users. I would think that would help LY team to determine what is in demand or currently is not working for many users, helping to shape the roadmap in a flexible way.


It looks like the squished voxels creating a lot of the issues.
Code inits main voxel node from terrain bounding box, which is not cube, but like the flatter shape in the post above, so all the child voxels keep the flat shape. If init the main parent node as cube, using terrains width, voxels end up cube shaped and seem to voxelize meshes in the correct position.
Although it would still look like meshes would not voxelize most of the time, (mostly they would if moved under the terrain). After I set max terrain height to 0, meshes would all start to voxelize fine:


On and off:

So its kind of working I guess, if you are ok with everything floating about 200 meters over the terrain. Probably can be improved by adjusting logic that voxelizes the terrain, problem seem to be somewhere there.