im getting a weird issue with the static mesh component not being placed in the world properly. its location and scale seems to be rounding oddly from floating point errors even though its only a scale of 4000 and a location of 20000. its almost as if its running as 16 bit rather than 32 bit as the floating point errors are extremely noticeable (off by 10 to 20 cm from where it should be).
im on v5.1 and adding the component with the “add static mesh component” node. has anyone else had this issue? does anyone have any alternatives to the static mesh that works similarly?
could this be because of nanite or some other (in this case) unwanted optimization running in the background?
Hey there @xCANAdan! Is the Add static mesh component node introducing incorrect coordinates or are vertices rounding oddly like floating point inaccuracies?
That’s excellent information! It could be that the Add static mesh node could be using 16bit floats as it’s intended to be a relative value and not really meant to go nearly that far. Generally if you wanted to do this sort of thing (but in world space) you’d spawn an actor of class (Static Mesh) then set the SM. Though, I can’t speak to if that’s been migrated up or not, my experience with numbers this high is limited. I tended to still use world origin rebasing all the way up until LWC became built in with 5.1.
yeah, i had the feeling that it was based on relative position so it was going to be a relatively low value and cap out at float 16 of precision. seems odd to me as i would have thought 32 bit was the standard.
one idea i came up with that could work is to multiply the actor scale by 10,000 and divide the mesh scale by 10,000. this would keep the relative size very low so the accuracy would go back up, but its a hacky work around and would require me to recalculate all values by 10,000, which isn’t optimal.
idk. using a mesh isnt super necessary for this instance as id obly be spawning a few hundred objects, but later ill have to come up with a new system as i want to avoid spawning actors as much as possible, they are way larger (and slower to spawn) than what i need, and iv got to spawn tens of thousands of these meshes, so its gotta be lighting fast.
I hadn’t picked through the source yet, so it could definitely be something else, but it seems like it here. For your use case, could HISMs work out? They are significantly more performant.
Oh sorry! I do the acronym thing too often! Hierarchical Instanced Static Meshes is basically just instanced static meshes, but with the added bonus of being able to have controlled LODs. HISMs are massively more performant than normal static meshes. Since you were handling this under one BP before, this won’t be much of a change. The only downside of these things is that these instances have to be one specific mesh. However, nothing is stopping you from having multiple sets of these instances. This won’t work for all use cases, but if enough of your objects are similar or the same mesh, this can help immensely!
I have no idea! I wasn’t even aware of the limitation on the SM components before you brought it up today! It makes sense from a programming perspective for relative locations being FFloat16s, but I’ve never had the use case for HISMs more than 20,000+ out. Should be relatively easy to hook up or outright replace pieces in your system you have set up, so let me know how it works out!
well, im starting from scratch so iv got lots of options available to me for how i want to do this. its 3am so i should probably head to bed, but ill check out what mesh component options are available to me in terms of floating point precision. its possible, because that’s a newer component, that its going to use 32 bit floating point precision.
Absolutely, HISMs were made with larger scaled worlds in mind whereas the older ISMs didn’t have the capability of doing multiple LODs at once so were better for smaller patches of many instances.
When you test it, I’d likely use the world space bool just to make sure there’s no difference since normally it would also be relative.
I understand that! It’s nearly 7am here and I’ll be calling it a night soon myself. Excited to hear how it goes! Have a good night!
i tried instanced static mesh as well as the hierarchical version as well and both give weird floating point errors, maybe even more so than the basic static mesh instance component. its really odd
Edit: i also went and checked if the issue occured on 5.0.3 and it does,
as a sanity check, i also checked in 4.26, which is where im migrating from, and i dont have any of these issues.
same setup and everything
Hrm, this is a bit odd. I can’t replicate the issue at all. In my 5.1 project, my test bed is a world partition base with large world coordinates already enabled, I don’t get any distortion at 200k X, 200k Y with the HISM or the SM itself. I’m going to be running more tests. It could be related to the odd scaling possibly, but it shouldn’t be.
Are you using World Composition or World partition?
im unsure. world composition? world partition?
also, for your tests, set it to a decimal number and see if you get better luck. preferably something not a multiple of 0.5 (0.3 or 0.6). also im think its scaling rather than location, so give that go. i was able to seamlessly move around the objects without issue, but scale would snap weirdly. try changing scale by 0.1 when you have it set to 5000+ and see if you get weird snapping.
i actually gave that a go a few days ago; i exported a mesh with a scale of 100 so it only needed a scale of 40.003 instead of 4000.3, but it was still scaling incorrectly.
also, i wont know the scale of the mesh before hand. this is used in a procedural use case so the mesh could be anywhere from 0.5 meters to 10,000 meters in size
i have a feeling that the math is working fine and its 64 bit before it reaches the vertices, but then the vertices break somehow.
someone else is finding this issue as well (UE-174155)
