Download

Add collision and socket support to glTF importer

The glTF importer cannot currently bring in collision geometry or sockets like the FBX importer. This is a feature request to add that support.

I think there are two approaches that could work: [TABLE=“align: center, border: 1, cellpadding: 2, width: 95%”]

Approach
Pros
Cons

#1 Mimic the FBX importer.

		Treats nodes named SOCKET_[RenderMeshName]_## as static mesh sockets and meshes named [UBX | UCP | USP, UCX]_[RenderMeshName]_## as collision geometry.
		Familiar to content authors who already use the UE4 FBX static mesh importer.

		Requires no new glTF extensions/specifications.
		UE4 specific content authoring.

#2 Collaborate on industry standard collision and socket extensions for glTF.

		I have [logged a request for a collision specification on the glTF roadmap issue](https://github.com/KhronosGroup/glTF/issues/1051#issuecomment-554547310).
		UE4 benefits as DCC authoring tools adopt the collision/socket extension specifications.

		Since authoring tools know what they are generating, they could warn about problems (like convex hulls that are not actually convex).

		Might be a candidate for inclusion in the [glTF-Blender-IO](https://github.com/KhronosGroup/glTF-Blender-IO) (the glTF importer/exporter add-on that ships with Blender).
		DCC tools needs to enhance glTF exporters to provide industry standard collision and socket data.

		More work to coordinate with the glTF community.

		At the moment, there is no clear direction for defining collision geometry and nothing regarding functionality like mesh sockets.

I think the best solution is to start with #1, since it can actually get done in a reasonable amount of time with few external dependencies and some of the code can be lifted from the FBX importer. At the same time, pursue #2 and adopt it if it looks like it’s going to pan out.

We’re going to look at #3 where we generalize post import operations into a new system called DataPrep where all importers can be customized with what we call. import recipes:)

Excellent. So, this DataPrep effort is to generalize some of the Datasmith/UE Studio specific features into a more flexible overarching import pipeline? I didn’t see DataPrep mentioned on the UE4 roadmap, but I did see several references to it in the UE4 4.23 release notes and in github master branch, though it is not clear to me if these are referring to Datasmith’s idea of DataPrep or this more general system you mentioned (I imagine the former). Do you have any (possibly rough) ETA for this?

Although my original post was about glTF, the reason I was looking at glTF is because of some annoying behavior of Blender’s FBX exporter, which decides to treat empties/nulls as if their scales represent a length rather than a multiplier, so they multiply all the scale values on the empties by 100 when doing the Blender to FBX unit conversion. It sounds like I would be able to write something to fix this unwanted Blender scaling in a post-import recipe, correct?

Dataprep was created for unreal studio but everything is moved to a single engine since 4.24.

The Datasmith team is now responsible for the entire aspects of importing data and work on the generalization of workflow with regards to import recipes.

What works for rhino, revit, gltf will eventually work for all file formats, but our team need time to refactor and unify code bases.

For your specific problem about scale, it’s worth exploring the ability to make custom BP operators that you can use in Dataprep. I’ll try to post an example on how to do it.