So I’ve made a simple plane to act as a wall in a randomly generated first person maze. The plane lines up with itself perfectly when manually placed in the world, but when using an instanced static mesh, there appear to be weird slits/gaps where you can see through the wall between planes. As stated previously, the maze is randomly generated, and rather large, so using an instanced static mesh is the only good option for performance. Here is the plane mesh below, as well as an image showing the problem.
The problem is not in my mesh or my blueprints. It appears that when you plug in rotators of 90, 180, 270, etc. into a make transform node, the rotation seems to change ever so slightly. This is shown in the printed text in the second screenshot. It appears to be a strange floating point rounding bug. (I call it a bug because discrete values like 90 and such really should not have weird rounding going on.)
A couple other things to note:
This “rounding” does not occur when using rotators. Unfortunately, since I’m using instanced static meshes, I don’t have the option to set only rotation (all instanced static mesh nodes only take in transform).
I could work around this by modeling/importing 4 separate wall meshes for each cardinal direction. That way, I wouldn’t have to deal with rotating any of them, and could keep the rotation values at 0.0 (which works fine). I don’t like this workaround, as I plan to make multiple wall/floor types, and having to make 4 times as many models does not seem like a viable solution. (This workaround also causes a performance hit)
Does anyone know if I can get instanced static meshes to have perfect rotations of 90 degrees? I’m using 4.25 in this project. If you’d like to try to reproduce the error, simply print out transform values and change the yaw rotations to be discrete numbers, as shown below. When you play the project, see if the rotation stays the same, or if there is weird floating point rounding going on.
Just for testing purposes, I tried spawning the walls in as components using transform (instead of using an instanced static mesh). The slits were no longer present. This means you are right, this does not appear to be an issue with the rotation.
I’m not sure the issue would be with the lighting or any external source, since swapping the instanced static mesh for individual components seems to fix the issue. Perhaps it is a bug with instanced static meshes? I did find another thread that suggests there is some scaling bug with instanced static meshes.
Okay, I’ve tested scaling up the instanced static meshes that have been rotated (according to that forum, instanced static meshes that were rotated were scaled down ever so slightly).
It looks like setting the scale of instanced static meshes that have been rotated to 1.000001 undoes the slight shrinkage. The models aren’t “too big” either, as there is no visible clipping of planes along the corner in the screenshot.
I’ll go ahead and mark this as the solution.
The difference in rotation you see printed on the screen comes from the internal conversion of FQuat to FRotator. The conversion most likely doesn’t happen when you set the rotation of your meshes and even if it did a 0.000015 wouldn’t make any difference, the engine will only consider rotations in the first decimal places because anything else is imperceptible even on very high resolution monitors. I don’t know where your problem comes from (probably a lighting issue) but I am sure it doesn’t come from the rotation of your mesh.
