[2.1] Morph animation status

[xissburg]

From what I've seen there isn't support for morph animation in 2.1 yet. Looking around the code it seems it'd be a big undertaking to implement this and it'd touch several parts of the engine, such as the v2 mesh, HLMS and shader templates, the instancing stuff, new animation classes... Does anybody have any idea about what exactly would need to be done to implement morphing?

Thanks

[devxkh]

Hi,
I need morph animations, too.
But you'll get an answer like: There's no ETA, mathias is very busy (what i totaly understand).
Looking at the progress over the last 2-3 years, it won't be implemented in the next 5 years.
A quick look at the progress, it's not planned to be supported: https://trello.com/c/k6aiUWFL/21-morph- ... ueue-modes.
But the old entities that no one wants to use, are supporting morph targets.
So i think it will never happen, if no one else with the skill arise and implements it ( sadly i'm not the one ).

Morph targets are one of the reasons i've started to implement a gltf loader.
gltf can handle morph targets.
looking at godot's blend shape shader, it seems there's not that much math involved:
https://github.com/godotengine/godot/bl ... shape.glsl

Another question would be, where it should be added. The current Hlms implementations are very decoupled.
If you want it for Unlit and PBS you'll have to add it to both.
If you make your own hlms, you cannot not use the official pbs and unlit and have to maintain your own.

That's the current problem with pbs,unlit.
unlit supports texture animation but not skeleton animation.
pbs supports skeletons but not texture animation...

Best would be, if it could be added optionally to the current implementations with only one time implementation.
But i think that's not possible?

Just my thoughts.

[devxkh]

http://antongerdelan.net/opengl/blend_shapes.html

this sample looks simple

[xissburg]

Even if you implement a glTF loader you still have to integrate morphing within Ogre which touches a bunch of different parts of the engine I'm afraid. I am willing to implement this into Ogre and it'd be great if Matías would give us an idea about what it takes to implement it, what really needs to be done, which parts of the engine would be involved.

[dark_sylinc]

If all you need is morph animation for 2 characters in a cinematic, then the morph animations in v1 Entity still works, the same way it did in Ogre 1.x. It will be done in software. It isn't very fast, but gets the job done.

The problem with implementing morph animation in 2.1's Items is that it isn't a trivial job, hence it needs a lot of time. There are several ways to implement them:

• SW based, similar to how V1 does. It can and should be done in a threaded way. Code would have a list of vertices to update and per morph animation, and iterate through them. Problem is, this means the vertex buffer has to be allocated as either dynamic (and thus you need to upload all vertices, even the ones not being part of the morph animation), or be done via StagingBuffers (which would be slow if the vertices to update are too sparse). There's a lot of buffer management overhead to take care of. This is what V1 Entity does.
• Update all vertices from Vertex Shader. This is relatively straightforward, but unless all vertices are animated, it does not scale well to a high number of vertices and/or number of active moprh animations, and has a lot of waste. From a glance, this is what the posted WebGL sample does. It doesn't work well beyond low poly faces and two or three, four at most, active blend shapes at the same time.
  This is because if you have 8 morph animations, you have to apply update all vertices the 8 morph targets. It's a O(N * M) operation where N is number of vertices and M number of morph animations.
• Keep a list of morph targets affecting each vertex that the vertex shader will read and then look in another buffer where the morph targets are stored and apply them. This means if a vertex is affected by 8 morph target and another is affected by 2 morph targets, then we don't waste time applying 8 morph targets in the latter one, we just apply 2. This isn't perfect because there are GPU divergency issues to consider, but more or less it works, thus it allows a much higher number of morph animations to be active at the same time. But C++ side we have to confection the lists in the GPU buffers and update them every frame.
• Apply a Compute Shader to apply morph targets to the list of vertices they affect. This is the most optimal path because it has no or little divergency problems. It would requires some changes to Ogre since during render the VAO to use would be the one with vertex buffers that have been modified by the Compute Shader, so it requires some buffer management overhead. Also it would only work on D3D11 hardware or newer (or GL4 / Metal of course) since it needs Compute Shaders.

Either way, this requires some knowledge about the topic, plus modifying several parts of Ogre (Items, Mesh, Hlms, shader, perhaps a step in SceneManager to run the morph animations). I don't want to discourage or scare away people who wants to contribute, it's just that it's not an easy feature.

Implementing something quick that supports a few morph targets is easy. Implementing a feature that can be used by many users in several use cases, with potentially lots of morph targets and active animations, decent performance and a clean API is a challenge.

[xissburg]

I am thinking of implementing #2. It might not be the most optimal but it's a start. I just want to be able to animate a spring de/compressing for my car For this particular case I also think it's the best approach since all vertices will be transformed and I have only one morph target. I'll study the code more and try to find my way around it.

Thanks

[Hrenli]

I just want to be able to animate a spring de/compressing for my car

I don't know the details, but in theory it sounds like a perfect case for skeletal animation. I'd have two bones for two different "tubes" of the shock absorber, animate them by sliding along one axis and paint the spring gradually from one bone to the other...

[xissburg]

I just want to be able to animate a spring de/compressing for my car

I don't know the details, but in theory it sounds like a perfect case for skeletal animation. I'd have two bones for two different "tubes" of the shock absorber, animate them by sliding along one axis and paint the spring gradually from one bone to the other...

That would be similar to scaling the spring, which compresses the thickness of the coils along the vertical axis and that's the reason why I prefer a morph. I know it would be hardly noticeable but I can't live with this lack of realism. I was using morph on 1.10 but now I migrated to 2.1 and I want to have the exact same effect.

[xissburg]

I have made some progress on the morph animation implementation and you can find it on my fork (morph branch). There's a sample as well showing how to use it. Just get a subItem and call setPoseWeight("poseName", weight). The poses are imported from V1 meshes.

I don't think it's ready to be merged because it needs more testing and a through review because this implementation touches some core parts of Ogre, mainly HLMS PBS, so I believe some things might be broken. Also there's only the GLSL implementation.