Skinning + Morph Targets, only minor refactoring needed (sic!)

[apendua]

I finally managed to get it to work :) It turned out that the main obstacle in making these two types of animation cooperate with each other has always been the fact that the boneMatrices passed to the shader represent bones' transforms in global (world) space, while it seems more appropriate to pass the relative offsets of bones, i.e. bone's skinMatrix, with respect to the bone's rest position. If this approach is taken, the process of skinning vertex reduces to

vec4 skinned = boneMatX * skinReference * skinWeight.x;
skinned += boneMatY * skinReference * skinWeight.y;

where skinReference represents the "original" position of a vertex. So, not only does this approach allow us to use the morphed vertex as the skinReference in the skinning procedure (yes, the morph targets should go first), but also it denies any need of using the (large!) skinVerticesA/B arrays. This should be considered as a huge advantage, at least as long as someone needs to add more bone influences (still marked as TODO somewhere in the code).

A working example may be found here: (the model is pretty high poly, so please ignore any low frame rate issues)

http://oniostudio.com/skinning/

By the end of the week I should be able to clean up the code. The changes also include modified normal vectors (for basic shaders) and correct shadow maps generating. If you are interested in applying these changes to the project, please let me now what can I do to help in this process.

[alteredq]

@alteredq I think it's because I'm currently having some problems with crlf EOL conventions :(

Aha, that explains it, also in some of your other branches / commits I noticed that problem.

Is there an easy way, to restore my dev branch to be an exact copy of @mrdoob's dev?

Maybe you could just delete your local dev branch and then create it anew based on @mrdoob's dev?

Just make sure you keep your real changes somewhere, doesn't have to be in the repo.

Since I already have altered it a little, I'm afraid that git pull won't do the job, right?

I usually do fetch and then merge, not pull. I find it easier to manage with a separate step of getting changes to local system and then dealing with branches.

Any time, I try to create a pull request, I get a pretty huge list of commits, which I don't actually want to include.

Proper way should be: keep your dev in sync with @mrdoob's one. Then when you are doing some new feature / major fix, create a new branch with some descriptive name, do changes just there and once done create a pull request.

Now, important thing, once done with that feature, stop doing any commits to that branch. Pull request is just a dumb label, it doesn't encapsulate state of the repo at the moment of creation, it just tells "here in this branch something is going on" and everything that's going on there will keep being added to the pull request.

[apendua]

@alteredq Thank you for this explanation. I think I'll stick to Tortoise from now on :)