Send to Unreal - Issue #500 - collisions aren't placed relative to parent mesh - has reappeared.

[Moonwards]

Bug - Issue #500

This is happening again with Send to Unreal 2.2.1 when using Blender 3.4.1, sending to Unreal 5.1

[james-baber]

Can you screen shot the loc/rot/scale on both the mesh and the collisions in blender?

[Moonwards]

Sure. This is split into a whole bunch of UCX meshes. I made a short video going through the list.

https://user-images.githubusercontent.com/50932660/215587522-51451026-f39d-41f7-8494-519bb21d1396.mp4

They are part of a large set of objects. By coincidence, the scene origin is not far away in this case, but it doesn't make sense for me to use that because of the scale and how it all needs to fit together.

[james-baber]

Hmm ok interesting. Are you able to upload that blend so I can look into this further?

[Moonwards]

It's a pretty big file, I'll pare it down to a few examples because it's happening with everything in it.

[Moonwards]

Alright, here are a few affected pieces It seems I can't put a .blend file here, so this is a link to it on our Google Drive https://drive.google.com/file/d/1G85QHMFgtzTLK9kZwYxSv8AAyzKYZiGF/view?usp=share_link

EDIT - yeah, I've been messing with this and I can't fix the issue that the Export folder is no longer available in the View Layer mode. I don't know if I accidentally deleted it, but it's gone, as mentioned in the next comment, which has a link to a new, working example file. I've tested that example using a fresh UE 5.1 project and the issue is the same.

[Moonwards]

Ok something funky is happening with the file I linked to above. The Export folder is in the file, I can see it in the Scenes display mode in the Outliner, I can add things to it, but it won't display in the View Layer mode.

So, I built another example file from scratch. Here is the link to it. https://drive.google.com/file/d/1Csop6bl_3ovfs2tieJ4fLX8jZ_bKoCUo/view?usp=sharing

[Arkiras]

I'm also experiencing this issue. Interestingly, it appears the problem was never fixed.

I tried testing send2ue 2.1.5 on Blender 3.2.2 (the addon/blender combination that this was supposed to be fixed in) and the issue is still present.

Edit: It works correctly if you don't make the collision shapes children of the mesh.

Tested on Windows 10 64bit and UE 5.1, using the export to disk option and manually importing.

[Arkiras]

I noticed something that may be helpful in debugging this issue: The collision appears to be getting moved twice. I assume once when the parent is moved and then again at some point to "correct" its own offset (or perhaps the other way around?)

[Moonwards]

We have had issues with splines set up using a plugin and our own BPs placing the vertices of meshes twice as far from the world partition origin point as the origin of the mesh was. This may well be noise, not relevant, so I won't try to set up a demo. Maybe it is worth saying, though, that it may easy to introduce some error or oversight in a BP that causes Unreal to display this behavior. And possibly this is related.

[james-baber]

I havent had a chance to test these files yet, but a new release just went out. https://github.com/EpicGames/BlenderTools/releases/tag/20230207033454

The use object origin option is now handled in the FBX export logic, as well as associated collision meshes, so it is worth re-testing these examples and seeing if they are fixed or still need to be addressed.

[Arkiras]

Seems to be fixed in my test :) Thank you for the update!

[Moonwards]

Yes, collisions all seem to be working fine for me now too. Thank you.

Also I'm so glad the object origin setup is now core. It will save me so, so much time and effort. It's a great day for me and Send to Unreal.

[james-baber]

Great!

[Moonwards]

Okay, I noticed a pretty important caveat and decided it merited reopening this. Collisions work fine if you don't adjust default settings, which export everything with the origins at the scene origin. The toggle to optionally export with object origin still exists, though it moved. If you check that, then the collisions aren't offset - instead, they seem to be completely gone.

I have already reexported most things with their origins now placed at the scene origin, which was the default behaviour before too. I actually am not sure what the difference here is. I had the happy thought that the object origin was somehow embedded in the mesh data or something so it would still be accessible, but from how meshes look in the mesh editor, the original object origins are just gone and replaced with the scene origin, which is the same thing that happened before.

This may be a corner case, or it may become common that this is an issue. I preferred to go to all the trouble before of exporting with object origins and then manually placing every single mesh by copying over coordinates, because I feared if I did not, performance would be affected because maybe Unreal doesn't deal well with objects whose origin point is hundreds of meters away. I mean, if it doesn't, how would I ever know? My game will just be slow and I won't be able to diagnose it. I make things that are several hundred meters across, and sometimes want to place very large things very precisely in a world that is 24 km across right now, and will soon be even larger. I have to set up marker meshes in order to do that. In their case, they can be 10 or 15 km from the origin of the scene in Blender. Trying to deal with placing things on this scale using Unreal's manipulators is a fool's errand made far worse if the mesh's origin has been moved waaaay over there to the origin of the world, or even to the origin of a scene that is 'only' 500 m across.

I have decided to go with this for now, mostly. I just position everything in Blender, hope like hell I can avoid having to mess with it in Unreal, and keep in the back of my mind that if there is a slowdown later, maybe I'll need to test whether this is the issue by moving a whole bunch of origins again and manually placing them again. So far performance has been fine, maybe that part is a non-issue. I'm just sayin' - giant worlds are going to become a thing and it's going to be nice to have the option of keeping your origins in your objects so they are easy to work with, without that imposing a bothersome extra workflow.

[james-baber]

I cant tell from your comment if your making a feature request for placing in the level https://github.com/EpicGames/BlenderTools/issues/551 https://github.com/EpicGames/BlenderTools/issues/522

Or what the exact steps are to reproduce this issue your experiencing. Sounds like your collisions are showing up, but its working fine for me.

What tends to be the most effective is if you can reproduce the issue using the test assets in the repo and re-post the file saved right before you run the send to unreal operation. https://github.com/EpicGames/BlenderTools/blob/main/tests/test_files/blender_files/cubes.blend

We test against these, and if you can reproduce the issue with one of these simple examples it makes it easy to fix

[Moonwards]

Alright - To make it easy I got your test file and reproduced the issue. https://github.com/Moonwards/BlenderTools/blob/d8a9728b8e54d18e45681d6ac39ce6bc8872d9a9/tests/test_files/cubes_origins_collisions.blend

If you toggle on 'use object origin'

• On Cube1, UBX_Cube1_02 works fine, but UBX_Cube1_01 moves to a point relative to the original scene origin.

• Cube 2 fails to export, with the following error message:

  Python: Traceback (most recent call last): File "C:\Users\win8s\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\send2ue\operators.py", line 71, in modal raise error File "C:\Users\win8s\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\send2ue\operators.py", line 61, in modal function(*args, **kwargs) File "C:\Users\win8s\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\send2ue\core\export.py", line 222, in export_mesh export_file(properties, lod) File "C:\Users\win8s\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\send2ue\core\export.py", line 164, in export_file export_fbx_file(file_path, export_settings) File "C:\Users\win8s\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\send2ue\core\export.py", line 83, in export_fbx_file io.fbx.export( File "C:\Users\win8s\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\send2ue\core\io\fbx.py", line 522, in export export_fbx_bin.save(self, bpy.context, **keywords) File "C:\Program Files\Blender Foundation\Blender 3.4\3.4\scripts\addons\io_scene_fbx\export_fbx_bin.py", line 3240, in save ret = save_single(operator, context.scene, depsgraph, filepath, **kwargs_mod) File "C:\Program Files\Blender Foundation\Blender 3.4\3.4\scripts\addons\io_scene_fbx\export_fbx_bin.py", line 3131, in save_single fbx_objects_elements(root, scene_data) File "C:\Program Files\Blender Foundation\Blender 3.4\3.4\scripts\addons\io_scene_fbx\export_fbx_bin.py", line 2929, in fbx_objects_elements fbx_data_mesh_elements(objects, me_obj, scene_data, done_meshes) File "C:\Program Files\Blender Foundation\Blender 3.4\3.4\scripts\addons\io_scene_fbx\export_fbx_bin.py", line 1069, in fbx_data_mesh_elements scene_data.settings.report( File "C:\Users\win8s\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\send2ue\core\utilities.py", line 1128, in report_error raise RuntimeError(message + details) TypeError: unsupported operand type(s) for +: 'set' and 'str'

Cube2 will successfully export if there is 1 collision shape, but not with 2.

I wanted to explain why using object origins is important in our use case, but I'll put that comment in the thread for the feature request. Suffice to say here that the default export behaviour does NOT preserve the object origin point, so much so that I don't understand why it is described as now being the case.

[james-baber]

Ok thanks!

The stack trace seems to be related to this https://github.com/EpicGames/BlenderTools/issues/565

Ill follow the steps and take a look at this soon.

[james-baber]

Ok these are the same issue, closing this and you can follow #565