Instanced static mesh - instance renderings shrink depending on rotation

I have cubes with instanced static mesh instances as the sides of the cubes (Each side of the cube is an instance of a simple square instanced static mesh so that I can change the material, mesh, etc of each side of the cube independently. ) At a small scale, there is a very small seam on some of the edges. But when you scale the cube up, the seams become large gaps. I’ve confirmed that the gaps are caused by the faces of the cube shrinking depending on the relative rotation of each instance that makes up the cube faces. The recorded scale stays accurate, but the actual size of the faces that are drawn get reduced. I tried to figure out how to predict which rotation would affect the size by how much, then scale up each instance by the right amount so that it gets shrunk back down to the desired size, But I’ve had limited luck working out whatever kind of math they use to draw the faces Is there any way to fix the problem or can you think of a workaround for it?
Some links to others who have had similar problems:
[1][2]
[2][3]
[3][4]
[4][5]

update - if the mesh is rotated at only 0,90,180, or 270 degree angles, it seems to work if I simply scale up the instance by .0001 along each axis (new scale = old scale + (old scale * .0001). But if it’s at any other angle, the instances shrink more. The odd thing is that I can rotate it by 1, 45, or 89, or anything in between, and the scale change seems to be the same. It’s hard to gauge since I don’t know how to measure the actual size of the face that gets drawn to the screen. If it was the scale of the instance that was changing, I could fix that. But it’s hard to know what numbers I’m working with when it’s only the rendered faces that are affected.

-playing with these numbers has given me some nonsensical results. For example, if the block is rolled at a 45 degree angle and I slowly scale out one of the mesh instances , it’ll make no difference a few times, but then when I add the next .000001 to the scale in all axis equally, the face will suddenly jump out far along one axis but not along the others. I really have no idea what kind of math they use for drawing these instanced static meshes, but it doesn’t look like the solution can be figured out by just playing with the numbers.

Also, it seems to have some kind of snap to it. I change the scale a little at a time because it’s too small, but nothing changes. Then when I get to a certain number, the mesh is suddenly too big. I guess it’s a rounding issue? Somewhere in their calculations they round a number while they’re calculating the face transforms. It sounds like something they should have fixed by now.

I am having the same problem with gaps between rotated instances of ISMCs that shouldn’t be there, so the instances must be scaled down for some reason. Can this be fixed, please?

Just adding to this to note that the issue persists in UE4 4.22. I’m having the same issue with a simple instanced 2d tiling grid. If I rotate the instances, 90 degrees on the Z axis for example, it seems to cause a .0001 & shrinkage and you can see noticeable gaps in what should be a seamless tile. This issue does not occur when I use static meshes.

I found this related bug report (UE-17458) but will make a fresh one just in case.

My messy workaround is to automatically add .0001 to the scale if the instance is rotated.

Yep working on 4.22 with precise meshes instances and finding the same scaling problem with results in light bleeding, even adding to the scale or moving the meshes doesn’t help.

Adding .0001 to the scale in the X and Y works for me for some reason. Anyway I submitted a bug report and also saw this pull request that may fix the issue but is stuck waiting for review.

https://github.com/EpicGames/UnrealEngine/pull/4584

You can try different values describing the same rotations. Add or subtract multiples of 360 degrees. Some will cause broken scaling and some don’t. Nevertheless it’s hard to believe this issue hasn’t been fixed by now and still requires this ugly workaround.

Just following up that my bug report was accepted: UE-81897