So I’ve been trying to build an automated system that spawns a street with sidewalks and buldings. Streets and sidewalks are done now, but I have found a weird bug.
So first the basics:
my street tiles are 700 units in lenght on the Y-axis
the sidewalks have the same length
on the right hand side of the road I have the sidewalks places on the same location as the street due to their pivots
on the left hand side of the road the sidewalk is turned by 180 degrees and offset by -700 on Y
This system works like a charm except for 1 thing:
the sidewalks on the left hand side of the road are roughly 0.35 units shorter than they should be. Notice that the geometry isn’t offset, the starting points are always where they should be, the geometry just falls short. I found a rough number of the gap by actually ofsetting them bit by bit out of curiosity.
I also found a work around:
if I turn the road by 540 degrees (3 times 180) this doesen’t happen. Even though the Yaw in the output log shows up as 179.999985 in both examples, which is actually a clever way of handling bigger numbers I guess.
I just reproduced it and will follow up with a step by step
I’m not sure how many assets this could actually affect, but since it’s reproducable in an empty scene, I guess it could happen with any object.
So here’s how to do it:
In Maya I created two Planes, one with 350x700 and the other with 1400x700. The first will be the Sidewalk and the second is the Street. Afterwards I just exported them from Maya as an FBX and imported them into a fresh Unreal Project that just had the Starter Content in it. The Version is still 4.11 Preview 4.
I applied a simplified version of my Blueprint structure that only has the basic nodes to actually place the objects.
I’ll attack a .txt file with the pasted nodes. link text
I also noticed that the overall orientation of the geometry isn’t causing it. I was able to replicate it with the exact same oriantation and a different one (i.e. both planes turned by 90degrees around Z and flattened transforms).
Unfortunately I have not been able to reproduce this error on my end. I created two planes in Blender following the sizes you described and copied the nodes as you described, but everything seemed to work as I would expect. Can you send me the assets that are specifically causing this error to occur? I’ll be happy to take a look.
You can the assets into a file and post that here or, if privacy is a concern, message me a link to a dedicated FTP service such as dropbox or google drive on the forums (same account name). I’ll be able to pull the file from the link and test the assets.
Okay here’s the link. This has just the assets as .uasset file for the meshes, materials and textures. I already altered the bluprint so it’ll not be attached, but the posted nodes should do the trick anyway.
For the Blueprint I just crated a standard actor class blueprint and added two instanced static mesh components that use the linked meshes, this might be of importance.
If this still doesn’t help I’ll probably have upload the whole project, just in case.
Unfortunately this does not appear to be a bug with the editor. After looking over this extensively, I believe the error may be related to the logic flow you are currently using and the assets pivot point. The asset is trying to take the new rotation into account as it moves based on local rotation/transform as opposed to world location/transform. Once it has rotated to the new rotation, you have to account for the change. I did this by removing the current x float and replacing it with (x= 1400, y = -700, z = 0). This placed the sidewalk at the correct 180 Y rotation and on the opposite end of the street without changing the meshes scale. I would recommend checking how you are calling the assets and where you may be setting scale unintentionally to see if there are any locations that can be rewritten to account for this. I will leave this open for a few days to give you time to test, if you believe this is definitely a bug report, please post your project here along with detailed steps I can take to reproduce this on my end and I’ll be happy to take another look.
so I’m not really sure how to set it up differently, but with the workaround it’s fine, I guess. Thanks anyway.
The thing is that the actual scale doesn’t seem to be affected according to the output logs it’s (1,1,1) for both. So it has to happen somewhere under the hood.
Thank you for providing that information, 0000. I’ve reproduced the issue and placed a report in for it. You can find the report here: UE-40476. In the meantime I would suggest continuing to use 540 to workaround this.
This doesn’t just happen at 180 degree. I’m getting the same gaps on instanced static meshes for 90 degree rotations.
I am trying to seamlessly (and procedurally) put wall and floor segments together. Some are rotated 90 degree on the Y axis and some on the Z axis. Since I am setting transforms by code/blueprint and not manually in the editor, the workaround doesn’t work for me, because the values get restricted to +/- 180 degree or something like that.
Conventional static meshes don’t cause the problem. Instances of an ISMC receiving the same transforms do. Instances with identity-rotation produce no gaps. I also noticed the floating point accuracy issues producing values like 89.999(…), although they don’t seem to be an issue for normal static meshes (as far as I can tell atm). Maybe they are treated with different accuracy or “error compensation methods” in rendering or storing transform data?
This bug report was marked as Won’t Fix and was given a workaround to help with the issue. The workaround was using 540 rotation instead of 180. I assume you could do the same by using 450 instead of 90. This only works when giving it the values. If a value exceeds the limit set for that, it will reset to the other end of the spectrum and continue adding rotation. This is why adding 360 ends up giving you the same rotation.
Sorry, but how can it not fix? Maybe somone has to fix it…
The problem was fixed for conventional (non-instanced) static meshes
What reason could there be that it’s not fixable for instanced static meshes???
It’s kind of a big deal: a game engine that scales meshes on rotating is pretty flawed
Instancing is very important for performance after all. And like I said, the workaround doesn’t work for me, because I can’t simply set the value in the editor when geometry segments get placed procedurally at runtime.
There is a difference between Won’t fix and cannot fix. This is marked as Won’t Fix as the developers responsible for this system decided that this issue is not important. All that is required to workaround this, if you are placing procedurally, is to add 360 to any rotation that is done when they are created, which should be possible if you have access to what is determining their transform when they are created. That is what the workaround is in the first place and the amount that needs to be added does not change.
Just confirming that the work around works for rotations that aren’t multiples of 180. This absolutely does not work on multiples of 180, I went all the way up to 1620 and the issue remains.
Hello, to anyone experiencing this issue, please refer to this other thread where this issue was also reported. I’m currently re-investigating this issue since we are getting reports that the workaround is no longer working.
