Shape Key Support

Expanding and utilizing the engine via C++.
4 posts Page 1 of 1
TorqueFan
Posts: 87
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Sat Mar 05, 2016 2:27 am
Greetings! Hopefully this is in the relevant sub-forum. I have an inquiry about Shape Keys( more commonly known as morphs ) and utilizing their data in Torque 3D.

What a Shape Key( or morph ) will allow us to do is have various arrangements of vertexes in a mesh object. So, just by altering the Shape Key value( i.e. 0.0f - 1.0f ) a mesh can be deformed, squashed, stretched, you name it. I am using meshes with various Shape Keys which hold settings like eye scale, jaw width, etc. for character customization.

As far as I could gather, Torque3D has no support for such Shape Key/morph data. I couldn't find any place in the T3D source in which this was implemented. So this leads me to:

My Implementation - Blending
Since I couldn't find any way to utilize Shape Key/morph data in Torque 3D, I went about trying to figure out how I could adjust a mesh's vertex data on the fly. What I came up with was a sort of 'brute force' method that just uses Torque's existing Blend functionality.

So, what I've done is made bones in the model that will adjust certain vertex groups. Then I've keyframed animations to hold the bone's info, like: all the way up is eyeScale 1.0f and all the way down is eyeScale 0.0f.

Then I just added those animations to the player object, set all the variables up on a GUI, and set the player to blend those animations into the "base" one.

The Question:
What I've described above seems to work fine. I've extended the GuiObjectView to support all of this( plus much more =P ) and all seems to be okay.

My question is whether or not there is some negative reason I had to increase the max count of threads on ShapeBase objects to blend in a bunch of "customization animation threads".

I'd just like to be sure, before I go much farther on this path, that all those simultaneous threads won't be a problem for some reason later. I mean, I manage all the threads( seemingly ) without errors so far and haven't noticed any sort of immediate performance hit. Bear in mind each animation I've blended in this way is extremely minimal in the data it contains. i.e. Only one bone controlling data for one value at a time, like location X or scale.

So, has anyone else encountered this and found a good approach? Is there Shape Key/morph support already embedded in Torque I hadn't noticed?
chriscalef
Posts: 341
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Mon Mar 07, 2016 8:23 pm
Torque is supposed to have vertex morphing, although I haven't used it or thought about in a long time, so I can't guarantee it still works. It was definitely in there back in the day though.
chriscalef
Posts: 341
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Mon Mar 07, 2016 8:31 pm
If you search around on garagegames.com's forums, you might find some information, although everything I found was very old and it didn't seem like they ever worked all that well. Here's a link to something by Adam DeGrandis that might be useful. I used the term "vertex morphing" to get some results, for some reason the simple word "morph" returned nothing.

http://www.garagegames.com/community/blogs/view/11087
TorqueFan
Posts: 87
Joined: Thu Apr 30, 2015 5:35 am
by TorqueFan » Tue Mar 08, 2016 4:04 pm
I researched around the GG boards as you recommended, Chris, and you were correct about morph support once being there. I found a thread explaining( in a nutshell ) how it was removed due to performance reasons. It was reported that the added vertex data was causing .dts files to become overly large as well. All of that makes sense considering how far back Torque's roots run, but I am certain the implementation at that time wasn't quite up to par with what it could be today. By today's standards, if vertex morphing is handled correctly engine-side it actually costs less performance-wise to apply a morph than it does to animate a bone. Vertex information is applied to a mesh prior to bone weights/animation and never referenced again.

I digress. Seeing evidence in Adam's posting( and another I found on GG boards ) that basically just using bones is a norm for Torque re-assures me though. I mean, if you break it down what I'm doing by blending in face bones isn't putting much( if any ) pressure on performance. You start the blend, it 'morphs' the face, and you can even call to stop the thread so it's basically just a bone that was moved once and parked. Heck, in the stock Torque soldier model you've got animated bones for little things like the shoulder pad bouncing as you walk. These blended bones aren't even moving =)

Thanks for your feedback Chris. I suppose that unless something glaringly obvious comes up as an issue, for now I'm going to carry on assuming that blend animations are the way to handle this using Torque. Given a greater supply of patience and alcohol, if one insisted they could potentially nab the morph data out of .dae files on import by extending the source code. For all intents and purposes here( a few facial customization options ) I'll content myself with using blends =).
4 posts Page 1 of 1

Who is online

Users browsing this forum: No registered users and 3 guests