I’ve asked this question on AnswerHub, Reddit, and the C++ section here, and I have yet to get an answer that works. Maybe you guys can help.
I’m doing some procedural stuff using Instanced Static Meshes. My little modular sections are all 400x400, my code positions them 400 units away from them, and in the editor they even show up as 400 units apart. However, there is still a visible seam between each section.
It’s only when the sections are going left-right - i.e with a rotation of 90 degrees. However, as you see here, the rotation isn’t quite 90.0. Furthermore, I *can’t fix this. *Check this gfy out:
Afraid not. I just made sure again that all the verts were properly on a grid, reimported, and had no success. Furthermore, that wouldn’t explain why at 0 degrees rotation they have no seams, but at +/- 90 they do (seen here):
did you try typing exact 90 for rotation? I saw it said 89.9999 or so in one of the images. I haven’t seen this issue and I use tightly fitting meshes all the time.
Unless the matrix creation code has special cases for 90 degree and 180 degree rotations, you will not get exact rotations out of any math package.
(That’s even before we consider that degrees get turned into radians before being passed to sin()/cos().)
In general, for procedural geometry, you need to instance/create the geometry in world space, or create the matrices in your code using exact math (only translation and row transposes) OR you have to create skirts/flanges that overlap to avoid hairline cracks.
I don’t know anything about procedural generation; but out of curiosity, if you manually place that same mesh and then duplicate it and drag that copy to the edge of the first mesh, is there still a gap or does it line up properly? In the 3d program, is the mesh aligned to the center of origin properly?
That sounded so crazy I thought it might just work, and it did for a bit; however, it only works for 90 (450) degree angles, not 270 (630) degree angles.
The problem for me was that it would scale them down for some reason. They’d be perfectly placed on their pivot point and fall short by a few pixels at the end. Rotating them by an additional 360° in my blueprint fixed it somehow. The weird thing is, if you actually add a “Print String” with the rotational value it’ll both show up with the same rotational value.
Interestingly enough it worked for you with 90° and for me with 180°. I wonder if it has something to do with the rotational values ranging from -180 to 180 internally.
What I meant was that you generate new meshes with specific vertex positions, rather than just translate an instance of a mesh.
This has to do with how the matrices are generated, and floating point precision. A matrix that just offsets an object has exact “1” along the diagonal, and exact “0” in all other positions except the bottom row, where the translation lives. (Or, right-hand column, depending on which convention you use to write them out.)
Creating a “rotation” matrix and multiplying it into the translation, will cause trouble if the matrix is created through the normal “axis/angle” method (or through the “type in separate degrees” method) because the sin/cos functions are only 99.9999% accurate, not 100%. So, instead of a “1” along the diagonal, you’ll end up with a “0.99999” which will be enough to cause hairline cracks in some cases.
But, it turns out, when the rotation is exactly 90, 180, and 270 degrees, you can create this matrix in another way: by flipping and negating rows. (Or columns, in the alternate convention.)
Thus, to create a precise transformation matrix for instanced geometry, you need to create it by using only translation (position offset,) and flipped/negated matrix rows, rather than using the “rotate by N degrees” functions.
Yes, this is 3D math at the coding level!
The matrices you’ll want are:
Rotate -90 degrees around Z:
