Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Character Head Changing Functionality #192

Open
Cheeseness opened this issue Mar 2, 2014 · 19 comments
Open

Character Head Changing Functionality #192

Cheeseness opened this issue Mar 2, 2014 · 19 comments

Comments

@Cheeseness
Copy link
Contributor

We've been getting a lot of head contributions lately, and with @ChrAfonso looking at some early implementation in #186, now looks like an important time to start to iron out our requirements and address what's involved.

Ideally, we should have some solution that is scalable to an arbitrary number of heads, capable of bringing across blendshapes ( #59 ), and doesn't require manually packing every model into one prefab.

@ChrAfonso
Copy link
Contributor

Thanks for opening this up, Cheese! Small correction: I believe you wanted to reference pull request #186 :)

I agree that a more programmatically modular approach would be more flexible to allow drop-in heads, so my current solution is more of an interim test. As I understood it from the IRC discussion, this would be tightly embedded in the instantiation code of the other objects (cart, body, ball) currently in the network code, which is up for refactoring, so I thought it best to leave that alone for the time being.

Regarding blend shapes, the current head prefabs already have the FaceState script attached, but it would be easy to do this via code when instantiating a new head, as long as it has the shapes defined.

@Cheeseness
Copy link
Contributor Author

Ha ha, whoops! :D

It'd be good to get comments from @ErikBehar and @bobsayshilol as we try to nail this down.

@DMann3D
Copy link

DMann3D commented Mar 3, 2014

This might be something to look into for this issue: http://forum.unity3d.com/threads/16485-quot-stitch-multiple-body-parts-into-one-character-quot

I haven't had a chance to read it entirely yet as I'm at work, but I hope it's helpful if someone else has the time to read through it before I do.

@ChrAfonso
Copy link
Contributor

Nice find! If we go the route of adding rigged heads to a rigged body via script and having them animate from one rig, this will be very helpful. However (to recap some irc discussion from yesterday), I would suggest we avoid having to rig/skin each head separately, as this adds an extra step (that can only be done in Maya?) to the process (after modeling the head with blendshapes) before getting it useable in the game. But that's just my personal view on the matter - if it leads to better-looking results, forget everything I said :)

I think it was @ErikBehar who summarized that this hinges on the question, do we want to transform the neck area (individually for each head) during animations, or can we keep it static? If the neck belongs to the body and is the same for each character, than we can take unrigged neckless heads and just pop them onto the body rig's head bone.

@DMann3D
Copy link

DMann3D commented Mar 3, 2014

I personally would prefer skinning the head/neck to the identical rig, because A) I already modeled out Anna and Dave's necks ;) and B) If we can do that and get the parts interchangeable in Unity, it'd make further, more unique character art easier down the road. ie, interchangeable bodies, clothes, etc, since the scripting and functionality would already be handled in Unity for the heads.

As far as only being done in Maya, I don't /think/ that's true-- I know you can skin in Blender as well, though I don't use Blender at all-- I'm just not sure if there's something it does differently on export that it might break the identical elements between the base rig and the cloned/head rig. (Does that makes sense? Like, maybe it possibly rejiggers vert order or something? I doubt it, I just don't know)

@ChrAfonso
Copy link
Contributor

Valid points :) If we can implement this and leverage it for future enhancements, that would be great! I've actually done some rigging/skinning in Blender, I just don't have any experience yet getting that into Unity (thus my comment), but if we get the "merged rig" thing working with the assets from Maya as a proven reference, I'd love to try making it work from Blender, too :) From what the author of the article in your link says, animations are assigned by bone name, so hopefully it works when using the same names.

@DMann3D
Copy link

DMann3D commented Mar 7, 2014

So I've been doing a bit more research and came across this:

http://youtu.be/ObZy5ZDSHFc

Which I think confirms my idea of multiple meshes sharing the same rig (ie, we don't need to save all the mesh parts in the same FBX). As long as the two parts (in our current case, that's the Patrick body and whichever head we choose) are skinned to identical rigs, the head's rig just needs to be parented to the body's rig in the Hierarchy. The problem then becomes, how do we allow players to control customization that and it propagate to other players? I'm sure our code gurus can figure that out, but it's beyond me.

But then I found this:

https://www.assetstore.unity3d.com/#/content/11808

Which is almost exactly what we need (or at least, what I would like us to have), except it's $30 :(

Good things: It doesn't need Unity Pro, it seems pretty feature-full, it's set up using MecAnim to change specific parts of the character, then saves that Character Set and builds it in the level. I'd say the cons are cost and (for my non-coding little brain) the fact that it would somehow need to be scripted to strip some of the default features we wouldn't need (changing hair color, for instance) as well as just getting it to work in our game in general.

Now, I could get this myself and mess with it/learn to integrate it, but as I said, I can't do coding/scripting at all. I'd like to learn, but I'm afraid I would get nowhere fast if I use this part of a group project to learn-- especially if I'm the only one who has a license. I'd be more comfortable learning scripting on my own project, that I could make contributions here in a reasonable amount of time.

What do you guys think?

@ErikBehar
Copy link
Contributor

We can probably do something similar to what the wolf guy video did no problem.
If we want to get fancier and used a package, I suggest we look into UMA https://www.assetstore.unity3d.com/#/content/13930 which is open source !

@DMann3D
Copy link

DMann3D commented Mar 7, 2014

ooh! I forgot about UMA-- someone in the thread for that Custom Character Kit mentioned it and I forgot to look it up. Seeing it now, I'd say that's best because it's free!!

However, I'm not thinking we need anything super fancy-- the most functionality I'm imagining for choosing characters is swapping heads, swapping bodies, and changing the color of their clothes like we have now.

It seems that essentially the wolf guy's method is doing what we're doing now, only that he's parenting the accessory to the main rig & mesh after exporting it separately, where we are adding the accessory (the head) to the main rig & mesh before exporting the FBX. Which isn't a big deal or a wrong way or anything, but I think it'd be nice to have the functionality for artists to add heads that are, essentially, automagically added to the roster for player selection-- without the need to constantly update the one main file containing the body and the original rig. Like I said before, if we can get this functionality into our head import and selection methods, then we can potentially mimic these methods for body customization (as a nice-to-have).

@ChrAfonso
Copy link
Contributor

I'm repeating myself, but again, nice find, David! The way I understand the "wolf method" (without having tried it, so I might be wrong), in Unity, each bone relevant to the head (neckbone, headbone, jawbone, ...) is "ripped" out of its original hierarchy and parented to the same bone from the body rig, while the head mesh is parented to the body mesh. This way each head-mesh bone (unanimated) copies the animation movements of its parent body-mesh bone, affecting the head mesh in the same way as if it was animated directly.
Thinking about the programmatic side of this, the difference between this method and the one in the first link you found a few days ago (as I understand) would be that with this method, we would traverse the head rig and change the parent of each bone to the same-named one in the body rig, if it exists, while with the other method, we would just read the bone names and actually reassign the head mesh's references to point to the bones in the body object (correct?), thus discarding any rig animations previously assigned to the head mesh.
If I understand this right, unlike the "reassign bone references" method, the "wolf" method would allow several kinds of customization: If the creator of a head wants to alter the existing animations (e.g. adding a headbanging animation to the normal head moves), he can create an animation for those, which will be added onto the base animation of that bone. If they want additional animations (waving hair? wagging ears?), those can just be done for new bones, parented to the existing "standard ones". And to override any body rig animations (perhaps for a stiff-necked character who can't turn his head, but does some other thing (like jerky neck movements) instead), the bone's name can just be changed.

Sorry for the long brain dump, I hope there's something useful in there :) Thanks again for the thorough (and inspiring) research!

@ChrAfonso
Copy link
Contributor

Quick update: I tested the wolf method with a crude dummy model (rigged and animated in Blender), and it works fabulously :) For now, I applied the bone-parenting by hand, next step is a script for automating this (and testing with our real models).
Demo video: http://www.youtube.com/watch?v=odji2PMm1Ek
The head/neck is nicely animated/deformed by the body rig animation, if all bones are parented separately.

@ChrAfonso
Copy link
Contributor

Ok, I'm a bit stumped now - some weird stuff is happening when the rig integration is done (live) via script and not by hand: http://www.youtube.com/watch?v=XPjogH9gFgA
Something seems to get mangled in the transforms, perhaps due to the mid-animation reparenting (?). If anybody wants to have a look, here's the branch:
https://github.com/ChrAfonso/bad-golf-community-edition/tree/rigtest
(script IntegrateHead.cs in Assets/art/characters/_rigtest_xexano, scene test/rigtest_xexano has the body with script attached, hit H to attach head)

@DMann3D
Copy link

DMann3D commented Mar 9, 2014

What happened to all of ChrAfonso's responses? :( He was doing some awesome things!

@thegsm
Copy link
Contributor

thegsm commented Mar 9, 2014

I'm getting a 404 when trying to see his account.
I have his responses on email, but he didn't make a pull request for this issue. Without that we can't really use what he has done.
Hopefully it's a mistake and his account will be back. I suggest you contact him on the DF forum.

@ChrAfonso
Copy link
Contributor

Strange... is it working again? I'm seeing everything I wrote still there.

@OrbitalBliss
Copy link

I am seeing you too, ChrAfonso. Something strange indeed.

@DMann3D
Copy link

DMann3D commented Mar 9, 2014

Yeah you're back now! Strange...

Also, nice work! Thanks for looking into this stuff!

@ChrAfonso
Copy link
Contributor

I poked around a bit more and got it working without distortions now - turns out you have to reset the automatic transform modifications Unity does during reparenting (see pull request #221).
I think it's a good time now to integrate this into the game - where would be a good place for that? I think the current head model and game object should go into networkVariables/PlayerInfo. With the needed parameters, HeadHandler.AddHead() and HeadHandler.RemoveHead() can now be called on the static class.

@Cheeseness
Copy link
Contributor Author

I think the current head model and game object should go into networkVariables/PlayerInfo.

This seems like the right approach.

I'm getting a 404 when trying to see his account.

This happened to me during our second week when GitHub's bot detection stuff flagged me as a suspect account. I'm not sure what kind of behaviour triggered it, but by the looks of things, the user's every action is temporarily removed until the account is identified as being real or not. When it happened to me, all the issues I'd created disappeared \o/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants