Odd Scaling Bug with Rotated Instanced Static Meshes

Good Evening,

I built a map generator that takes random walks and lays down tiles, and then adds walls along the borders. While testing, I discovered a “leak” along all the walls that required rotation. (The northern walls, aka spawned with no rotation, are fine). All the other walls (the ones that require rotation) have this issue.

On inspection of the walls, I discovered that it seems they have all been scaled down ever so slightly (probably to something like 99% of their original size). This also occurs on a different mesh I use as a “corner” piece to fill in the gaps for outside corners.

Don’t worry about the perceived weird angle in the top right of that image, that’s Z-Fighting as the green portion here is for developer purposes only. As you can see, the mesh instances don’t go all the way to the edge, despite being specifically designed to do so.

Some information about the mesh:

Built in Modo:
Size: 512x512x16 (they should be flush with the borders of each “cell”)
Required a 270 degree rotation on the X axis in import settings.
The pivot point lands where the center of each “cell” would be.

Some information about the setup:
Each cell is a 512x512x512 area.
Construction script takes a random walk of n steps, and assigns values to an array of vectors (0,1,0 etc).
Each element of the array of vectors is eventually multiplied by my grid size (512) and plugged into a transform.
When necessary, I use a custom built function “Instanced Rotation” to avoid an issue where the walls originally rotated around the world origin.

Here is the code for “Instanced Rotation”:

All it does is break the transform out into it’s parts, then makes a new transform while keeping the location, and changing the rotation based on the value I feed it.

So is this a bug with transforms/rotations in UE4?
Am I doing transforms wrong? (Certainly possible I created a function that appears to work but screws with scale somehow.
Is this a problem with my export settings in Modo, or my import settings in UE4?

I seriously doubt it’s the latter two, as the northern walls (with a default rotation) are completely flush. It also doesn’t seem to be a problem with my “Instanced Rotation” function, as I applied the same function to the northern, 0 rotation walls and they’re still fine.

Any help would be appreciated.

Found this: Unreal Engine Issues and Bug Tracker (UE-40476)

The work around doesn’t seem to have any effect. Any other ideas for how to fix this?

Given the small discrepency, I suspect the problem lies in floating point accuracy. I would build my tiles with a slight edge so that they overlap ever-so-slightly. This will ensure there are no gaps.

Thank you for your reply. Indeed based on what I read in that bug report and a few others it seems to be the case.

A few questions about what you’ve said:

-When you say rebuild the tiles, do you mean increase the size of the mesh in my modeling program and re-import? Or do you mean something else?
-Would applying a slight scale on all axis of say .0001 (whatever the round-off number goes up to) have the same effect as resizing the mesh itself?
-Given that this seems to apply on the rotation, would the same thing happen if I instead built a series of different “Wall” actors where the mesh was pre-rotated?

I’m hoping the last solution works, because the first two strike me as really hacky and the type of thing that will spin out of control over the course of a large project. Also, if I may editorialize, I can’t believe Epic seems to think such a bug is acceptable, given their proposed work-around doesn’t actually work, and that modular mesh design and making good use of instancing is such a popular design tactic. There must be another way of doing what I’m doing without running into the scaling error, because rotating instanced static meshes must get done A LOT.

Just an update: It seems like the scaling issue goes away if I instead call “Add Child Actor Component” with a “Wall” actor, rather than “Add Instanced Static Mesh” this was what I was going to move toward anyway in the long run so this is fine.