Modifying Static Mesh to use Morph Targets (like ABZU)

[AmbiguousInt]

One thing I’m interested in is trying to modify the FBX import code to allow animations to be play via a unique animation morph system. It seems like you can modify the FBX import process to push the morph targets through normal static meshes.

Creating the Art of ABZU

It definitely is possible thanks to the GDC17 of ABZU, a title made in UE4. They modify the source to push that morph target data into the static mesh, expose the morph target window. With that you can use the data to create assets to animate them that way. You can push that to HISM to allow a lot more of them on screen than skeletal meshes ever could. I’m wondering if anyone else has done this as well that could tell me little bit how these edits were done.

[MostHost_LA]

First of, material shaders already allow for most of what he was showcasing with the fish swim cycle.

Morph targets and vertex shader are very similar/they do the same thing differently.

Second of, you dont need a skeletal mesh to have morph targets since a few versions ago. If you import as a skeletal mesh you do get your morphs without bones.
that’s what you want. The name of the mesh doesn’t need to be “static” to get all the benefits of not having to animate the bones of 1000 fish as described in the video above.
-unfortunately this does create a useless empty skeleton. Apparently though this doeant matter if you use 3dsmax.

you can check static mesh morph targets in the docs for the 3dismax script to do this, and the nodes to manipulate it in the material.

Having a quick look at the 3dsmax code. This works by packing the morph target data into the vertex color channels (so on a static mesh you have limited morphs).
The help button text explains this rather well.

“Written by Jonathan Lindquist at Epic Games. \r\rData Format Notes:\r\rThe morph target 1 models normals are packed into the in-game models vertex colors. Morph target 1 is stored in UV channel 3(V) and UV channel 4. Morph Target 2 is stored in UV channels 2 and 3(U). Leaving the second morph target unpicked will leave the second uv channel untouched. To retain the models original vertex colors uncheck ‘‘Store Morph 1 Normals’’. \r\rStoring the pivot point will disable the ability to store a second morph target. The pivot point information will be stored in UV channels 2 and 3(U). \r\rNormals Note:\r\rThe morph target normals work on meshes that have one smoothing group and do not use normal maps.”

While it sounds like a nightmare, I’ll give some serious though about porting this to blender…

The hard part and the most interesting part to me is when he talks about schooling and the idea of adjusting the memory position of each fish so they can look up each other faster. That’s all levels of nice/crazy. And probably something you really need to modify the engine for…

[AmbiguousInt]

@MostHost_LA

First of, material shaders already allow for most of what he was showcasing with the fish swim cycle.

Morph targets and vertex shader are very similar/they do the same thing differently.

Second of, you dont need a skeletal mesh to have morph targets since a few versions ago. If you import as a skeletal mesh you do get your morphs without bones.
that’s what you want. The name of the mesh doesn’t need to be “static” to get all the benefits of not having to animate the bones of 1000 fish as described in the video above.
-unfortunately this does create a useless empty skeleton. Apparently though this doeant matter if you use 3dsmax.

you can check static mesh morph targets in the docs for the 3dismax script to do this, and the nodes to manipulate it in the material.

Having a quick look at the 3dsmax code. This works by packing the morph target data into the vertex color channels (so on a static mesh you have limited morphs).
The help button text explains this rather well.

While it sounds like a nightmare, I’ll give some serious though about porting this to blender…

The hard part and the most interesting part to me is when he talks about schooling and the idea of adjusting the memory position of each fish so they can look up each other faster. That’s all levels of nice/crazy. And probably something you really need to modify the engine for…

Yeah I’m aware of the material shader stuff, also packing the vertex animation with the 3DMAx script but I do not use 3DMax, as well as I just feel like its dated in general. The skeletal mesh route is not optimal due to the fact you’d still be rendering non-instanced which mean you’d have be allowed only so many. That is probably the key thing you’d be looking for in all this.

[MostHost_LA]

Isn’t instancing already allowed via the foliage tool for instance?
they added BP support to it a while ago, I believe creating stuff with that is instanced - at least in my current project it only adds to the rendering when I spawn too many instances.

[AmbiguousInt]

@MostHost_LA

Isn’t instancing already allowed via the foliage tool for instance?
they added BP support to it a while ago, I believe creating stuff with that is instanced - at least in my current project it only adds to the rendering when I spawn too many instances.

Yeah it is, but not skeletal meshes. That isn’t supported.

[MostHost_LA]

Cool, makes sense.
So you would be left with packing up to 2 morphs inside the vector paint unless you start messing around with the static mesh component c++

You know though, merging one to the other shouldn’t be too hard considering the code in the skeletal mesh for morphs can probably be ported straight into the code for the static mesh…
sort of makes you wonder why Epic didnt just do that. There must obviously be more of a hurdle in actuality…

It may be more worth to look into this than adding the packing to blender’s FBX though. Afterall even 3 morphs would hardly be enough…

[AmbiguousInt]

@MostHost_LA

Cool, makes sense.
So you would be left with packing up to 2 morphs inside the vector paint unless you start messing around with the static mesh component c++

You know though, merging one to the other shouldn’t be too hard considering the code in the skeletal mesh for morphs can probably be ported straight into the code for the static mesh…
sort of makes you wonder why Epic didnt just do that. There must obviously be more of a hurdle in actuality…

It may be more worth to look into this than adding the packing to blender’s FBX though. Afterall even 3 morphs would hardly be enough…

Yeah that is what I’m trying to look into with the morphs ported to static mesh. You can only have so many morphs in UVs so it wouldn’t be worth going that route as well. I’m just wondering if anyone else is interested in this as well so we can hopefully make it a reality.

[MostHost_LA]

Count me in.
I have to fix my ocean issues this week, but this would also benefit that.
Being able to use a morph or 8 to generate directional morphs based on direction to nearest surface would pretty much solve the shorewave issue without math… currently I do not really want to replace my ocean mesh with Skeletal types ones.

[AmbiguousInt]

@MostHost_LA

Count me in.
I have to fix my ocean issues this week, but this would also benefit that.
Being able to use a morph or 8 to generate directional morphs based on direction to nearest surface would pretty much solve the shorewave issue without math… currently I do not really want to replace my ocean mesh with Skeletal types ones.

Well I’ve been looking into the skeletal mesh info, and it looks like its mostly straight forward. Just a couple of variables adding to some FBX imports, modifying the static mesh itself by copying over the morph arrays and what not. Though the problem is making sure it doesn’t require the skeleton itself.