GEAR question

[Steven Caron]

how are people doing shape animation with a gear rig? i need to be able to have my shapes connect to a custom parameter set on every build/rebuild.

s

[Matt Morris]

You are using an ice shape mixer right? That should connect up on re-import or with common names on a fresh mesh.

On 23 April 2013 19:50, Steven Caron <car...@gmail.com> wrote:

how are people doing shape animation with a gear rig? i need to be able to have my shapes connect to a custom parameter set on every build/rebuild.

s

--
www.matinai.com

[Steven Caron]

i am not using an ice based shape mixer, but that is a decent idea.

so you add a new gear_PSet and just get the data on those parameters? i am unsure of how well 'this_model' will work if the meshes are contained in another model first then moved. i guess we will see :)

[Alan Fregtman]

On that note, how do most of you guys approach the ICE shape mixer...

Do you directly use a controller's local transform to drive a shape, or do you use a kind of "buffer" custom parameter set to which you hook up controls via expressions?

The reason I ask is because ICE trees seem to get rather slow when you use GetDatas to get transformations from objects in the scene. I suspect it may mistakenly dirty the dependency graph and force some things to run twice.

[Miquel Campos]

I use to take the kinematics to drive the shapes :)  But never try to check if exist better way, since I didn't found any issue .

----------------------------------------------------

Miquel Campos
www.akaosaru.com

2013/4/23 Alan Fregtman <alan.f...@gmail.com>

[Matt Morris]

I tend to use a bunch of scene objects imported as a generic model, then load the ice tree onto the mesh which hooks up to the controllers. I did try a comparison test on a face rig a while back comparing playback speeds of traditional setup and ice setup and found I was getting better playback via the ice method, so haven't really investigated too much further. The characters I've rigged are much simpler than film level assets though, so ymmv. 

--
www.matinai.com

[Jeremie Passerin]

Going back to the Gear topic.

Xml shape export was planned to be part of the skin rebuild. I have most of the code ready but never got time to implement it properly :( If anyone feels like finishing the job I can share the code.

[Steven Caron]

it might be more than i need right now, i just need shapes on the meshes to be wired back up to parameters when i rebuild the rig. i am exploring using an ice tree that gets automatically resolved when gear imports the mesh/emdl.

[Jeremie Passerin]

Yeah I can imagine that. 

Honnestly I love the xml export but it's a lot of dev to have it work with everything. Once you have it working with envelopes and shapes... you still need to support ice deformers, push, relax or any deformers you might want to use... even custom stuff and weight map... That's a lot of dev...

The Blur way where you can actually rebuild part of the rigs without deleting everything is very interesting too.

[Steven Caron]

you don't have to remind me of that, i miss it sooo much. if it wasn't so tied to blur pipeline i would be using it :)

[Steven Caron]

so how do i just add simple parameters to a gear_PSet? just a flat list?

[Jeremie Passerin]

gear_PSet is a regular property that can save it's own layout. 

After adding a parameter to the property you need to make sure it's also decribe in the layout, otherwise it doesn't show up.

You can see the layout by activating the debug mode of the Gear_PSet. (I don't have gear installed here right now, but if I remember correctly you just need to select the property and in the menu you should have something like Debug Parameter Set ) Now when you open the property you should have an extra tab showing the code of the layout and the logic. Youhave a button to generate a default layout if that helps.

it's an extension of what Daniel Niero describe here : http://www.softimageblog.com/archives/172

On a side note, I'm working on new tools here at Blur and that includes a new rig builder that is more flexible and less dependant of the whole Blur pipeline stuff... I secretely hope to be able to share it once it's been tested. It's a combination of gear and Mega Rig Builder. I think you would like it.

[Steven Caron]

ok i can work with this..

so add parameters from the gui, then type in the layout and logic. click generate logic. these parameters should persist? can i reuse the existing properties? like anim_prop?

i too hope you can share it :) good luck!

s

[Jeremie Passerin]

oh maybe I misunderstood your question... the parameters won't persist if you rebuild the rigs. :(

This is just to add a parameter to an existing rig... but otherwise yeah parameter and layout will persist.

[Steven Caron]

ok, so here is where i usually get caught up in gear. don't take it personally, i am very appreciative of a free and open solution, but i usually hit this wall. i can't get the budget usually to extend gear enough to suit my needs, so i have to use it as is.

s

[Steven Caron]

hey jeremie

where should i look in the gear source if i wanted to move an existing gear_PSet applied to a guide and move it the component in the final rig? ie. add parameters using (shift+p), add layout and logic in the gear_PSet text widget. click build and this be copied up to the final rig.

[Jeremie Passerin]

First thing I would do is to grab the property from the guide. 

Right now it's only grabbing the transform, position and primitive. 

in gear\xsi\rig\component\guide.py   in setFromHierarchy()

I would had a dictionary where I could store the property

just after 

self.tra[name] = obj.Kinematics.Global.Transform

self.atra.append(obj.Kinematics.Global.Transform)

self.pos[name] = obj.Kinematics.Global.Transform.Translation

self.apos.append(obj.Kinematics.Global.Transform.Translation)

> self.properties.extend( list( obj.Properties("Save*") ) ) #you probably need to chck that the result is not None

That wouldn't work with building the rig from an xml file.. but I don't think you care about that. 

then in gear\xsi\rig\component\__init__.py   in MainComponent.step_01()

I would add an extra method that would grab this property and add the parameters the anim_prop

    def step_01(self):

        self.getHost()

        self.addParameters()

        self.addLayout()

        self.addLogic()

        self.setUI()

        > self.copyGuideProperties()

        return

def copyGuideProperties( self ):

   for prop in self.guide.properties:

      for param in prop.Parameters:

        # Do whatever is needed to copy the property

        self.anim_prop.AddParameters( #Copy of the parameter)

               

For the rest what can I say... no worries Steven, I am well-aware that gear might not suit all the needs of production.

I developed gear at sixbrids. It was supposed to be the base of our rigging and animation tool set before the company went down. We haven't used it in production and I'm sure we would have added a lot more and address all these issues if we actually used it. It's free and open source... but I'm not feeling responsible to make it work in every studio's pipeline.

You don't have the budget to extend gear, you don't have the budget to build your own solution... the problem is not gear... it's your budget. :-)

Hope it helps !

[Jeremie Passerin]

oh I said dictionary and I used a list.. 

also note that I have prefixed the property with "Save" because you don't want to save and copy all the properties form the object :)

[Steven Caron]

thanks for the tips jeremie, i am going to try this.

by the way, i already stated in an earlier email that my budget is the issue.

"i am very appreciative of a free and open solution... i can't get the budget usually to extend gear enough to suit my needs, so i have to use it as is."

as someone who gives out free and open sourced tools regularly, you don't have to justify anything to me. i appreciate all of your hard work and generosity.

[Jeremie Passerin]

really no hard feeling Steven, I know what is to work in a small studio and I know what is development ;-)

[Guillaume Laforge]

Getting Kinematics Data is not slow. Setting Kinematics Data IS slow :).

[Enrique Caballero]

Hey guys, could I ask you to show an Ice tree of your ICE Shape Mixer.

I've done extensive testing with using ICE for shapes.  Basically I just added all of the vectors together and drove them by the kinematics of the controls.  I also did my best to make sure that it didnt calculate certain things twice.

I tested it against a face rig that we use here that uses a normal mixer.  And when all 180 shapes got reconnected. The Old School Mixer was faster.

I ran 3 seperate tests and in the end the Old Mixer was faster than doing it with ice.  

I am very open minded and I may have done this incorrectly. can anyone offer suggestions or show me a tree of one of theirs?

[Simon Anderson]

The nice thing about ICE is its also easy to setup and apply repatativly as you just copy and paste your ICE setup. We used the ICE blendshapes on both Zambezia and Khumba.

--
-------------------
Simon Ben Anderson
blog: http://vinyldevelopment.wordpress.com/

[Enrique Caballero]

Yep that is definitely a huge plus. But writing a script to recreate a mixer wouldn't be that painful.

I work for a very small shop. We concentrate on doing quality work on low budgets.

So I am always trying to squeeze every last FPS out of our rigs, as I strongly believe that a fast rig has a very large effect on company moral, and production costs.

So when I did my ice tests for our face rigs, i lost about 3 frames per second in the end. 

I know it doesnt sound like a lot. But fight tooth and nail for every fps so losing 3 hurts :P

i bet im just making the ice trees incorrectly though, there might be something im missing

[Raffaele Fragapane]

You might very well be doing everything right. If there's anything I would go for ICE shapes over anything else for, it's not raw speed (which on low density meshes with many simple shapes and 1:1 controls make bugger all difference), it's because you can usually, considerably, reduce the number of shapes, often by a factor of 2 or more.

Combinatorial systems go from a major pain to set up and a delicate thing, to being wired on the fly with just a couple reference meshes as templates and very quick wiring in and out.

It's far from a given that, in a 1:1 scenario, ICE will zip past the mixer in performance. It much depends on context, rig and geo.

--
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

[Enrique Caballero]

Very good point.  And the plug-in play nature of an ICETree compound is incredibly attractive.

 I'm always open to trying something new and different if time allows.

If anyone can screenshot how they set up their ICE Tree Shape mixer that would be awesome.  I think my knowledge about optimising ICETree's is quite lacking

[Sandy Sutherland]

I did a rigging job recently with several characters needed to be rigged pretty quickly - so I went the ICE tree setup - worked really well - saved out a compound and could script in a rebuild that read it in and stuck it onto the new character - obviously naming convention needed to be pretty solid, but I built it so that one node fed the entire tree name wise so that if needed I could correct that in one go!

S.

[Sandy Sutherland]

Enrique -

Here are 3 snips - the one is showing the very basic compound that I
load in when first building the tree that allows me to connect a shape
on one input and a controller on the other - then the shape is hooked up
ready to go! Second one is in that basic compound and the third one is
modified to allow inputting one shape such as a blink modelled both
sides and splitting it using a weight map, instead of using modulate by
weight map and making two shapes - this one also allows a switch so you
switch which side you want the shape to be! This sort of stuff is so
easy using ICE, as you can also use this method to modify a shape with a
weight map rather than makng a new shape! Notice alsoe the rescale node
this allows me to use controllers that go negative values say - in my
example the Face GUI had the controllers working in the direction the
shape would go i.e. cheeks puffing to make it intuitive for the
animators - I then rescale 0 to -1 to +1 and done! Beats the hassle of
wiring up a linked setup!

S.

[Sebastian Kowalski]

when performance is an issue with an ice shape rig, try to freeze the shape clusters into ice attributes ;)
a smart setup would allow regeneration or addition of new shapes.

sebastian

Am 24.04.2013 um 10:24 schrieb Sandy Sutherland <sandy.m...@gmail.com>:

> Enrique -
>

> Here are 3 snips - the one is showing the very basic compound that I load in when first building the tree that allows me to connect a shape on one input and a controller on the other - then the shape is hooked up ready to go! Second one is in that basic compound and the third one is modified to allow inputting one shape such as a blink modelled both sides and splitting it using a weight map, instead of using modulate by weight map and making two shapes - this one also allows a switch so you switch which side you want the shape to be! This sort of stuff is so easy using ICE, as you can also use this method to modify a shape with a weight map rather than makng a new shape! Notice alsoe the rescale node this allows me to use controllers that go negative values say - in my example the Face GUI had the controllers working in the direction the shape would go i.e. cheeks puffing to make it intuitive for the animators - I then rescale 0 to -1 to +1 and done! Beats the hassle o!

f wiring up a linked setup!
>
> S.
>
>
> On 2013/04/24 5:15 AM, Enrique Caballero wrote:
>> Very good point. And the plug-in play nature of an ICETree compound is incredibly attractive.
>>
>> I'm always open to trying something new and different if time allows.
>>
>> If anyone can screenshot how they set up their ICE Tree Shape mixer that would be awesome. I think my knowledge about optimising ICETree's is quite lacking
>>
>>
>>
>

> <Shape_TREE_one.JPG><Shape_ICE.JPG><Shape_TREE_three.JPG>

[Peter Agg]

I'd also avoid doing things with weightmaps as much as possible - far better to do all those calculations outside the rig and then freezing the shape on export. It's better to keep them live when you're working on the rig as then any changes you make to the reference mesh will be carried over without needing to re-make the cluster.

[Enrique Caballero]

Thanks Guys this is very helpful.

Thanks for the explanation and screenshots Sandy. 

The major difference between your approach and mine was that you use Linear Interpolate.  And I was multiplying the shape vectors by the scalar that was returned from the controller position.

I wonder if that could be part of the cause of my rigs slowness

[Miquel Campos]

hello,

I am a little late on the conversation, but here is a screen capture of our facial template

http://2.bp.blogspot.com/-kzEZDSsRCio/T0VISL78wgI/AAAAAAAAAQw/d-ik9QG3LLc/s1600/gear-custom-modules-02.jpg

It is a mix between ICE and Gear custom components. For this specific case , everything is pre assembled, for make the rig faster. With the system Left and Right  shapes are split automatic and later I am using some wmaps and a dummie envelope to split more some of the shapes. I remember this approach was discuss here before :P

----------------------------------------------------

Miquel Campos
www.akaosaru.com

2013/4/24 Enrique Caballero <enriquec...@gmail.com>

[Alan Fregtman]

I really dig this idea. It's too bad writing attributes was only made decent in SI|2013.

[Steven Caron]

ok so i have made some changes, not exactly as you have suggested cause i wanted to support layout and logic too, but i can't even get a single parameter to be copied up.

so i added a new attribute to the component guide class, and i am collecting the gear_PSets added. moving forward if the custom property has 'gear_' in front then its to be copied...

>gear\xsi\rig\component\guide.py

self.tra[name] = obj.Kinematics.Global.Transform

self.atra.append(obj.Kinematics.Global.Transform)

self.pos[name] = obj.Kinematics.Global.Transform.Translation

self.apos.append(obj.Kinematics.Global.Transform.Translation)

gearProps = obj.Properties.Filter(c.siCustomParamSet, c.siPropertyFamily, "gear_*")

self.cpsets.extend(list(gearProps))

then in main component class, i added three new methods

def step_01(self):

    self.getHost()

    self.addParameters()

    self.addLayout()

    self.addLogic()

    self.addCustomParameters()

    self.addCustomLayout()

    self.addCustomLogic()

    self.setUI()

    return

lets ignore layout and logic at this time and look at adding simple new parameters...

def addCustomParameters(self):

    

    for cpset in self.guide.cpsets:

        for param in cpset.Parameters:

            # skip string type ie. layout and logic params, also skip debug flag

            if param.ValueType == c.siString or param.Name == "debug":

                continue

            self.addAnimParam(param.ScriptName, param.ValueType,\

                param.Value, param.Min, param.Max, param.SuggestedMin,\

                param.SuggestedMax)

i chose to use addAnimParam thinking it would fall in line better with the GEAR system. also so i can have the setUI() take care of the gui. i tried adding the parameters after the setUI() and used AddParameter2() softimage method directly on the anim_prop but it seems to get overwritten. the build doesn't fail, all my code is being executed (some debug log messages helping me here) and the final result doesn't have my parameters. it looks like it is getting overwritten or discarded in some later process/step. 

ideas?

[Jeremie Passerin]

Hey Steven, 

I've seen your email... sorry I'm super busy right now.. but I'll try to have a look at what you did when I have a minute... hopefully next week.

[Steven Caron]

no sweat, i have worked around it.