Gear - opensource Rigging system

[Jeremie Passerin]

Hi list, 

I've just created a first video to quickly present the opensource project I'm working on here at Studio Nest.

Gear is a rigging and animation toolset for Autodesk Softimage. The biggest part being righ now the Modular Rigging System. 

Have a look 

[Jeremie Passerin]

Hi list, 

I've just created a first video to quickly present the opensource project I'm working on here at Studio Nest.

Gear is a rigging and animation toolset for Autodesk Softimage. The biggest part being the Modular Rigging System. 

Have a look at the quick presentation on vimeo : 

http://vimeo.com/16793216

I'll do more video really soon to show you exactly the rigging features and all the tools that comes with it 

Hope you like it !

Jérémie.

[Eric Thivierge]

No link to video... :(

--------------------------------------------
Eric Thivierge
Technical Director
http://www.ethivierge.com

[Jeremie Passerin]

Woow, sorry my email seems to have been sent 2 times...

Here is the link to the video : http://vimeo.com/16793216

[Darren Macpherson]

[

This looks very cool Jeremie, thanks for sharing the link.

D

--

darren macpherson | 3d artist | +2772 355 0924 | www.darrenmacpherson.com | dar...@darrenmacpherson.com | skype: darren.macpherson

[Halim Negadi]

Looks Fantastic Jeremie, much faster than the one we developed on a Monster In Paris.

The workflow feels full of very familiar things, can't wait to play with it.

Thanks again for sharing, I would have loved to do the same thing with our previous one but the production never agreed to. Thank you for filling up that hole at very long last.

[Matt Morris]

Looks just great. Really useful, the old si rigs were ready to be retired for a while now. Thanks Jeremie and studioNEST!

--
www.matinai.com

[Christopher Crouzet]

Gear, new highlight feature of Softimage 2012?!
Does it means means 'rig' in backward? :)
Looks pretty neat, glad you've made it and to see you're having quite some fun over there!


I believe you're gonna cover all those questions in a following video, but I'm just too curious to wait.

Does a single component can handle both left and right sides or do you have to script a different component for each side? Actually I guess it's up to the user that script the component, right?

Also, how do you define a component? Do you create a class that inherits from an abstract base class where you define the interface and what should be implemented, and also give access the rig context (information about the rig model, where this component sits into the hierarchy, other cool stuff to know) ?

Actually how does a component knows how to connect to another component? I saw a 'Connector' group in your UI, so do you have to hardcode things in a connector file or can you dynamically define a list of inputs/outputs depending on what is the target component to connect to?

Is it possible to easily create layered rigs? Like splitting the controllers/drivers/deformers+geos into different models and being able to define a behavior on a top base class to tell the builder how to connect together the different layers of a same component.


Aaaah, seeing your video makes me miss XSI even more right now.

Good job!


Cheers,
Christopher.

[Nic Groot Bluemink]

Whoa, this looks awesome Jeremie. I can't wait to give it a shot!

-Nic

[Halim Negadi]

Just watched the video again, and it's really fast, I'm impressed.

Also, Christopher, you raised a subject that lead us to the most inelegant and hard coded patches in the past three years: how do components communicate with each other ?

Anyway, I'm glad to see this is becoming reality, I hope many people will use it and help it grow. 

I am happy that the solution we never got the chance to share is about to be officially outdated.

When do you guys plan to release ?

[Andy Moorer]

This is wonderful, a clean, universal and modular auto rigging system for softimage users was way up there on my wish list, it's going to be a real boon to the community. Thanks for the sneak preview!

[Christopher Tedin]

You guys at Studio Nest are really generous folks. Thank you!

[Adam Sale]

hey jeremie.. Thanks for sharing. This is a great boost for Soft.
You guys over at the nest are sure pounding away on these open source projects. !

Adam

[Helge Mathee]

Just a quick note, I am not the one to answer the questions... :)

I am really impressed with the system, Jeremie gave me a demo on friday,
I really like where he is taking this, and I have to admit it is far better than
any rigging system I have build so far. Thanks for all of the work.

I am looking forward to the release.

-H

[Jeremie Passerin]

Halim > 

Sure you will find the workflow familiar. I've started this project right after I left Monster In Paris. 

It is much faster mainly thanks to Python. JScript was definitely not the best language to try to manage classes... I was actually impressed you managed to have something like this. 

I remember xproc was saving our life also... but this is not necessary anymore with a kick-ass language as Python.

Christopher > 

ah monsieur Crouzet, I'm not surprised you're the first one to fire with a lot of questions ! :)

Yes a unique component defines both left and right side. My component class has an attribute 'negate' to define if it should draw the rig in the 'normal' way or with negative scaling. Of course it's up to the developer to use this attribute to properly draw the negative side, but this shouldn't be to difficult. I have implemented a lot of useful methods, that takes this attribute as an argument, so you don't have to worry about it. 

Yes component are inherited from a MainComponent class that handle all the procedure. You only have to reimplement the methods that create the objects (nulls, curves...), the parameters (layout and logic), the operators (constraint, expression...) and the connector. It's really not that difficult. 

You have access to the global rig inside each component... but it's not really useful. The connector will take care of where the component sits in the hierarchy in the end.

95% of my connector are just a simple parenting. I have a generic connector that deal with that. The only expection right now being the foot to leg connection. So you can define a custom connector and do what ever you want in this. 

Also you should know that every object in the guide is linked to an object in the final rig. So if I parent my leg guide to the hip of my spine it is not the same as parenting my arms to the chest of my spine inside the guide. 

Layered rig is not the way I've decided to work. Well you have an option to have all the deformers at the same place, to easily plot them. But I didn't do it for the controlers... I don't see really anything preventing me to have it though... I just have to change the way my components are built...

Again each component being fully scripted... you can built it the way you want. But you have to script your component yourself :)

And just to remember. GEAR is not only this rigging system. It is also a lot of small handy tools for riggers and animators. I'll show more stuff really soon.

[Edy Susanto]

Looks really promising :)
Looking forward for more videos and the release of Gear itself.

[Christopher Crouzet]

Thanks for the reply Jeremaille!


For the layered rig, it won't be very easy to deal with it if it's not natively implemented. I instinctively started to work this way years ago without really noticing it until Raff showed me a more proper and defined way. Even at my new job the same concept is still present but in a different form. I believe working this way is a neat solution and is worth considering for future improvements.
Imagine it this way: to make it generic and fittable to different pipeline needs, each component could be made from one to multiple layers of rigs. It's up to the user to define the rig structure by creating a new abstract class (derived from a base RigLayer class defined in Gear) that would define the interface/behavior of each layer. Actually each layer of rig would be a separate asset by itself and you can visualize that as being a bunch of nodes that would be connected to its direct siblings as in a simple and linear DAG graph: controllers -> drivers -> whatever -> deformers/geos. So basically a component would be a package of rig layers that gets fired into a defined order and know how to connect to each other. Now imagine you've got a fully working character but just for one shot you need a different arm rig. You're happy with the deformers part but need to change the way it's being animated so what you do is just duplicating the component package of your arm, the drivers and deformers layers still points to the original package (no code duplicata) but you've got the chance to create a brand new controllers layer for that shot and that can still pickup any change you've made to the other layers! This is just one single example of the added flexibility we could get using a such system but every company will be able to find different interests in using that flexibility according to their own pipeline and needs.
The default behavior of Gear would still be a simple one-layer rig per component so it would be transparent for the normal user and companies that needs their own layers would deal with that by customising Gear.

Well I realise that it's quite some work for a feature that you don't need, but come on... maybe you could just not leave work at 3pm! :)


Also with the current simple parenting connector that you have, how do you deal with space switching? For example, if you've got an IK hand, can you determine that the hand is gonna be constrained to the world, to the pelvis, to the chest or to whatever you want?


Hehe I'll find you some more questions later if you wan't, it's running late over this side of the world now.
I was missing your frenchenglish accent btw.

Please keep up the good work!


Fromage,
Christopher.

[Jeremie Passerin]

I see your point, I know you were using this kind of approach with Raff, I remembered you showed it to me one time. I've never worked with such system, so I don't really feel confident in implementing it right now. I lack of experience to do that properly :) But if you're interested we could discuss about this and implement it together for next version (won't be in the first release thought) ;)

You are right IK system, is not just a simple parenting. Actually you can see how I deal with that in the video (even if I'm not explaining in this one). 

When I created the leg you see me picking the circle I've created as my main component. This is how I connect the reference of the IK. And I can select multiple one. So yes you can deal with space switching. 

I'll explain it in my next video. 

Jeremie

ps : I miss you too but I don't receive lesson from a guy who learnt English with kangaroos and now kiwis! No worries mate !

[Darren Macpherson]

[

Jeremie,

I've just watched the video again and I have to say this  is awesome!  Its amazing how you've managed to bridge the gap so elegantly between artist and rigger.

I have had the opportunity to work with StudioNest Brigks on 2 projects now (I'm still waiting to receive the end product) and I have really enjoyed working with them, they are intuitive and user friendly.  I however have one supa technical question, will Gear replace Brigks or will they work side by side and complement each other?  Looking at the video it seem like Brigks will be unnecessary? 

Thanks once again to all at StudioNest, its really refreshing to see this kind of sharing.

Darren

'It is also a lot of small handy tools for riggers and animators.'

[renato polimeno]

This looks awesome !

keep going with the good work. =]

--
> Renato Polimeno
mob. + 55 11 9675 4304
www.renatopolimeno.com (w.i.p.)
www.tribbo.com.br

[Eric Turman]

not available yet i guess

--




-=T=-

[Jeremie Passerin]

Darren > 

When I arrived at Studio Nest, Brigks was already there and I was asked to work on the Rigging System. I show them my own rigging system (quite similar to what GEAR is today) and we had some discussion about it and the limitation of one and the other. 

In the end, I decided to go with something similar to my old rigging system, I find it more flexible and more solid. 

Brigks is nice but you have to create much more components to rig different type of characters. You have to create new one every time you want to change the smallest thing. 

Also I found the matching process painful and difficult to understand.

In Brigks if you want to create a simple FK Chain with 3 bones, you create a component with a 3 bones chain. If one day you need the exact same chain but with 4 or 5 bones, you need to recreate a new component. 

In GEAR, this is one unique component that can generate your chain with as many bones as you want according to how many position you have picked during the creation of your guide. 

Sure you need some solid scripting knowledge, but the result is way more flexible and solid. 

The component I have created have settings so you can built them in different way. 

So at first GEAR was supposed to be named Brigks 2.0 but then we realized it was not the same product at all anymore and not compatible at all. I think Brigks require more technical knowledge but is nice as you don't need to script.

So GEAR can be used by almost everyone including people with almost no rigging background, but the development of new component should be left to TDs.

I'm sorry Helge and Miquel but GEAR has been created to replace Brigks :) 

Also I'm using Helge's solvers in the rig. I fixed a couple of them, added some features and create some new ones. The resulting rig is better than the default one from Brigks, more solid.

Eric > 

Not yet, but soon ! 

I'm currently testing it with some fellow riggers and animator to make sure it is reliable.

[Szabolcs Matefy]

I’m curious when it will be available to the public J

 

Szabolcs Matefy

[Phil Williams]

This looks awesome, thanks a lot Jeremie.

 

I think many people will find this very useful… a strong boost for Soft.

 

Phil

 

 

---

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Jeremie Passerin
Sent: 13 November 2010 18:41
To: soft...@listproc.autodesk.com
Subject: Re: Gear - opensource Rigging system

 

Hi list, 

 

 

I've just created a first video to quickly present the opensource project I'm working on here at Studio Nest.

Gear is a rigging and animation toolset for Autodesk Softimage. The biggest part being the Modular Rigging System. 

 

Have a look at the quick presentation on vimeo : 

 

http://vimeo.com/16793216

 

I'll do more video really soon to show you exactly the rigging features and all the tools that comes with it 

 

 

Hope you like it !

 

Jérémie.

On 13 November 2010 19:37, Jeremie Passerin <gere...@gmail.com> wrote:

Hi list, 

 

 

I've just created a first video to quickly present the opensource project I'm working on here at Studio Nest.

Gear is a rigging and animation toolset for Autodesk Softimage. The biggest part being righ now the Modular Rigging System. 

 

Have a look 

 

Tinopolis
Tinopolis Centre, Park Street, Llanelli  SA15 3YE
UK Company Reg. 03832383
________________________________________________________
This email and any files attached are strictly confidential and intended 
solely for the person or entity to whom they are addressed. They may 
contain legally privileged and/or confidential information. If you are not 
the intended recipient you must not copy, distribute or take any action 
in reliance on them. If you have received this email in error, please notify 
us as soon as possible and delete it. The views and opinions expressed in 
this email message and any attachments are the author's own and they 
do not reflect necessarily the views and opinions of Tinopolis.  

Mae'r ebost hwn ac unrhyw ffeiliau sydd ynghlwm yn gyfrinachol ac at 
ddefnydd y person neu'r corff y cyfeiriwyd hwy atynt yn unig. Gallant 
gynnwys gwybodaeth sy'n freintiedig yn gyfreithiol a/neu'n gyfrinachol 
ac os nad chi yw'r sawl y cyfeiriwyd y neges ato, yna peidiwch a chopio, 
dosbarthu na chymryd unrhyw gamau o ganlyniad a gan ddibynnu arni.   
Os ydych wedi derbyn yr ebost hwn drwy gamgymeriad, dylech ein 
hysbysu o hyn cyn gynted a phosib a'i dileu os gwelwch yn dda.  
Barn neu safbwyntiau'r awdur yw'r rhai a fynegir yn y neges ebost hon 
ac unrhyw atodiadau ac nid ydynt yn adlewyrchu o anghenraid barn neu 
safbwyntiau Tinopolis.
________________________________________________________

[Sam J. Bowling]

This looks very impressive. Looking forward to giving it a test drive.

--
Sam J. Bowling

[Ahmidou Lyazidi]

Congrats Jeremie
I love how modular Gear seems to be and how open it look like.
It is how the CHaracter SDK should have been. I can't wait to get my hands on it
and try to connect my own components in it.

Cheers  
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos

2010/11/15 Sam J. Bowling <sbow...@cox.net>

[Darren Macpherson]

[

Thanks for the info Jeremie, I look forward to playing with GEAR.  Dont worry Helge and Miquel, I got some good use out of Brigks.

D

[Simon Pickard]

Looks interesting!
Just wondering...

What rig's will this ship with? Is there a list somewhere?

Regards,
Simon

[Stefan Kubicek]

Hi Jeremie,

this looks impressive. I was wondering if you're making any use of ICE kinematics in there, and if not: why not?

I'm generally interested in learning if people are actually using ICE kinematics on a larger scale. Is it stable enough, etc.
Could you elaborate a bit on that if you can?

thanks,

Stefan

> Hi list,
>
>
> I've just created a first video to quickly present the opensource project
> I'm working on here at Studio Nest.
> Gear is a rigging and animation toolset for Autodesk Softimage. The biggest
> part being righ now the Modular Rigging System.
>
> Have a look
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Jeremie Passerin]

Simon > 

well, you will have templates.. but again it is modular so it is up to you to create the rig you want. 

But I will give some samples scenes and templates for :

- chicken

- dog

- horse

- biped

and maybe more...

You can already see the 3 first in the video. I'm currently doing the biped rig.

I'll try to post a new video tonight or tomorrow

Stefan > 

I'm not using any ICE kinematics in that rigs... this is just old school rigging. 

I can't say I have tried it myself a lot but heard a lot of people saying ICE Kinematics are not fully reliable.

So I decided to stay away from it for the beginning. 

I don't really see anything preventing it to use them to create new components though. That is something I'd like to test in a second time. 

Though, I'm using a lot the rigging solvers already released by Studio Nest, with a little upgrade on them.

[Juhani Karlsson]

It would be great if the use of ice kinematics would be possible as it is clearly the direction where the SI is heading. : )
GEAR looks great, I think its nice to have such high quality opensource tools inside SI.

2010/11/15 Jeremie Passerin <gere...@gmail.com>

[Ahmidou Lyazidi]

I don' t see why it will not, as soon as  you have your controlers/drivers position in space, it's just a matter of connecting stuff
In fact the connections script for ICE kine should be way simpler than for a regular rig, only a few lines that will apply the ICE tree, connect it to the controller, then set some parameters.
The hard part is to build the ICE Compounds and their logic to get the behavior you want.

Cheers
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos

2010/11/15 Juhani Karlsson <juhani....@talvi.com>

[John Payne]

Thank you Jeremie!  This has been long overdue in Softimage especially for those
of us working in Post who have impossible deadlines...

I would like to put in a request for an .fbx friendly module that could be exported seamlessly to Maya.
Under the hood you could have an ICE driven rig in Soft, and I would imagine that with Gear
you could also create something that would approximate the ICE based rig but still be "Old School" enough
to be exportable as .fbx and could share fcurve data and envelope weights with the ICE rig.

Thanks so much for making this open source, 
 
- John

On Sat, Nov 13, 2010 at 1:37 PM, Jeremie Passerin <gere...@gmail.com> wrote:

[Andy Moorer]

I would second the importance of doing whatever you can to provide for exchanging animation between soft and maya. In an ideal world you could even generate analagous rigs in maya off the same description to smoothly go back and forth between the two, which is hugely useful in production particularly when projects need to be scaled and only maya-trained animators are available.

[Steven Caron]

once its out in the open i will try and use it in our pipe with motionbuiler and softimage. 

s

[Helge Mathee]

Actually, to put another spin on this...

That's what would help us the most at studioNEST. Please test it in any way possible and provide valuable feedback. We love to share, and hope to thrill other studios to do the same.

Looking forward to those test results, Steven!

:-)

Helge

[Jeremie Passerin]

yeah, also I would be really interested in people testing it with mocap. I have to admit I have no experience in that domain but the rig  can be used fully in FK... is that enough ? 

[Steven Caron]

well, it just needs to be driven by the mixer so it could be FK or IK, and i see no reason why that can't happen. our workflow is to bring in fbx data onto a motionbuilder like rig and make an action source that corresponds to the animation rig. then the animator just lets that drive the base and puts animation layers on top. mixing sources, plotting them to new sources, apply them etc.

i see no reason why it wouldn't work, but i will give it a go anyways.

s

[Mirko Jankovic]

Well you got another tester here. Always looking for nice rigging solution for fast production needs :)

Don't we all? :)

Looking forward to play with it!

By the way a bit of topic but run somewhere on weird info that studioNest is switching to Houdini? 

But no way that can be truth??

Keep rocking!

[Halim Negadi]

Glad to hear "ride by wire" rigs won't totally replace mechanical ones right away.

I think there's room for both approaches and I'm sure Gear will offer the possibility to write ICE Kine based components.

We did a lot of tests using testing ICE and ICE kinematics in our rigging system ( the one you worked on Jeremie ), here're our conclusions:

XSI doesn't like having several ICE trees to evaluate in one scene, it leads to a major increase of loading times, and I'm talking of one character, not even 3 or 4.

With 2011 ICE features, we're now allowed to set data outside of the operator context without making the application freak out. That feature allows to embed all the logic part ( I like to call it electronic, in opposite of mechanic ) in one single ICE tree per rig. 

Bright side is that it allows to have very lightweight hierarchies easy to read by animators but do we really need this? With synoptic views, animators are not using schematic views anymore. Even with a simplified hierarchy, I'm not sure they'll spontaneously go back to that visualisation. 

Dark side of that approach, you'd better build your ICE Tree using a script and the rig itself won't be breakable and modular anymore. If one part gets missing, the whole ICE tree eveluation may get corrupted. 

For ICE Rigging, we're using groups a lot and it would be great to have the possibility to parent/cut groups in the explorer view. I'm not talking about any memberships or property inheritance but just display, a lot of groups underneath a model makes the explorer view slightly unreadable. Something like selection sets in Maya would be great.

[Steven Caron]

ya group management becomes quite difficult along with general explorer browsing. i dont really have a suggestion on how to improve but it needs to be reviewed by development as ICE continues to grow in use over all of softimage

s

[Simon Pickard]

Just one question..

Did the ICE rigs have a faster playback speed?

Regards,
Simon

[Raffaele Fragapane]

If you can do something relatively simply without ICE, the ICE rig won't beat the performance of that in any common situation.
For "normal" rigging tasks ICE doesn't scale across multiple trees, making the fetching and setting of data an overhead you can't afford.

It starts shining with deformers, especially how quickly you can put them together, or as a development tool if you can't/don't know how to develop certain constraints or operators that aren't present in OOTB XSI. And it does ok if you can abstract very large chunks of the rig to a single very large graph, especially if you work around the expensive data handling by using interim point clouds to store and manipulate data.

So the short answer is: It's not worth it for "normal" rigs, and won't be until it will scale better when you have many trees, and possibly until you can control evaluation. It's not a trivial problem to solve, so it might not be for another couple versions before you see anything considerable in those regards.
Soft is aware of it and quite a few people have talked about it and submitted suggestions.

It still has its uses, just it's not a replacement for the whole rigging system... yet.

[Ahmidou Lyazidi]

It depends, for simple and basic one, I'd say no,
but but if you have a complex hierarchy with scripted ops, it should be faster
not blazing fast, but faster.

Cheers
Ahmidou Lyazidi
Director | TD | CG artist
http://vimeo.com/ahmidou/videos

2010/11/15 Simon Pickard <ma...@simonpickard.co.uk>

[Kai Wolter]

First off, really nice work Jeremie. I like the clear work flow and looking forward to seeing your next video.

One question, do you have an API or commands in place to execute the build without any UI? Like for doing farm or batch builds in general?

As far as ICE rigs is concerned I can only second what Raff and Ahmidou said.

What I would really like to see in the future is a better usage of the multi-core machines we have under our desks. 

It is nice to have multiple threads all working on the result of a deformer, like in some custom operators or ICE, but when I have a scene with two, three or more characters and only see one core being utilised, it is just a waste of resources. I know it is a complex topic, but how great would be if each character/model would be handled in a separate thread? Of course, you need to use barriers or join the work partially/temporally when one character is constrained to the other, and that adds complexity, but I think it can be dealt with.

The main issue is the shift in paradigm, which is probably impossible to add without a rewrite of certain core systems.

This is probably worth discussing in a new thread anyway :-)

Just my 2 cents,

Kai

2010/11/16 Ahmidou Lyazidi <ahmid...@gmail.com>

[Jeremie Passerin]

Hi Kai !

I've built a complete API to use the system through scripting.

You won't find that much code inside my XSI plugins... everything has been designed right from the beginning to be easily used through scripting. 

You know how I hate to do the same things again and again ... ;)

And this is not only for the rigging system but every single tool that comes with GEAR. 

[Kai Wolter]

This is what I wanted to hear :-)

Looking forward to having a look at it.

Kai

[Meng-Yang Lu]

First of all, this is amazing stuff.  Great work. 

You guys are making Softimage even more of an amazing package with your contributions to the community.

-Lu

[Jeremie Passerin]

2 new videos :

http://vimeo.com/16953680

http://vimeo.com/16937983

[Gene Crucean]

This looks soo frigging good Jeremie. Thanks!

Do you have any idea of when you'll release it?

--
[Gene Crucean] - [VFX & CG Supervisor/Generalist]
** Freelance for hire **

[Darren Macpherson]

[

Woohoo, nice morning treats.  Thanks Jeremie, going to watch it with a kick start coffee

D

[Jeremie Passerin]

Gene > 

Release should be next week, or at worst the week after. 

--

darren macpherson | 3d artist | +2772 355 0924 | www.darrenmacpherson.com | dar...@darrenmacpherson.com | <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2;

...

[Message clipped]  

[Helge Mathee]

Damn. Frigging good... GIVE ME MY ATTENTION BACK, JEREMIE... :-)

No seriously, cool stuff mate.

[Darren Macpherson]

[

Just finished watching.  Are we allowed to swear here?  Cause F@*%ing hell that is Awesome!  Nice work Jeremie, look forward to playing around with it.  Really nice that there's a mirror in synoptic.  It looks really well thought out. Thanks for sharing this.

D

--

darren macpherson | 3d artist | +2772 355 0924 | www.darrenmacpherson.com | dar...@darrenmacpherson.com | skype: darren.macpherson

[Jeremie Passerin]

Hey hey hey, 

Helge is jalous because we haven't seen such a good opensource project since... Kratos :)

by the way, I wanted to quickly give some credits to people I had the chance to work with.

Thanks to all the people who directly or indirectly contribute to this project. We always forget people when making a list but I’ll try anyway. Sorry for the missing ones.

Thanks to the riggers and developers for the good tips, the great discussions that result in a lot of exiting ideas (Alphabetic order) :

Sylvain Audi, Aloys Baillet, Chris Breitling, Miquel Campos, Cyril Cosenza, Christopher Crouzet, Raffaele Fragapane, Cyril Gibault, Nicolas Langlois-Demers, Benjamin Malartre, Josh Murtack, Halim Negadi, Catalin 'Nick' Niculescu, Christophe Petit,  Jo Plaete, Helge Mathee, Rémi Munier, Sascha Robitzki, Adam Ryan, Tek2Shoot (Steph, Greg, Nico and Seb), Kai Wolter.

Thanks to the animators because we share the same passion and they always push the quality higher (Alphabetic order again) :

Llorenç Borràs, Vincent Caudeville, Florent de la Taille, Jonathan Delval, Jerome Dernancourt, Jerome Duraud, Fabrice Joubert, Mathieu Ménard, François-Xavier Nhieu, Yohann ‘Yop’ Pelladeau, Thomas Price.

And of course thanks to Studio Nest who supported me and allowed me to make this project open source.

[Szabolcs Matefy]

Amigos you made my day. I can’t wait to test it, and send this beast against our max boys here...:D

 

Szabolcs Matefy

[Gerbrand Nel]

You sir, have blown my mind!!!
Thanks to everyone involved!!!
G

On 2010/11/18 09:05 AM, Jeremie Passerin wrote:

---

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1153 / Virus Database: 424/3263 - Release Date: 11/17/10

[Darrin Hofmeyr]

A big thank you from myself to you and StudioNEST - you guys rock.

On 18/11/2010 10:47, Jeremie Passerin wrote:
>
>
> And of course thanks to Studio Nest who supported me and allowed me to
> make this project open source.
>
>
>
>
>
>

--
Darrin Hofmeyr
Animation Supervisor
BlackGinger
+27 21 4881188

[Simon Anderson]

HAHA...

cant wait for gear :) time to dive under the hood and learn

[Duncan Greenwood]

Wow. This makes the last 2 months or so of my work pretty much obsolete...
I'm really looking forward to playing around with this rigging solution.

Thanks Jeremie, and Studio Nest. You Rock!

On 18/11/2010 12:15, Darrin Hofmeyr wrote:

A big thank you from myself to you and StudioNEST - you guys rock.


On 18/11/2010 10:47, Jeremie Passerin wrote:

And of course thanks to Studio Nest who supported me and allowed me to make this project open source.

--
Duncan Greenwood
Technical Director
BlackGinger

[Daniel H]

Hmmm... well I don't know Jeremie... I mean c'mon dude, Helge pumped out like 18 support videos on "HIS" open source project, and well you have like a measly 3 so far. I mean seriously man, why so lazy? He he... kidding you brotha :) Very happy to be getting GEAR. Those videos are getting RT'd all over on Twitter. I can't wait to see the new GEAR logo on the OpenSourceArea page. StudioNEST rules, it rules!

-Daniel 

[Jeremie Passerin]

Well, lets take it the other way... 

If you need 18 videos to explain your stuff, maybe this is not exactly the easiest tool on earth. Mine doesn't require more than 3 ! :) 

On the other hand, we could already do one full length video with Helge's rigging phone.

;)

But anyway, I'll do more videos soon to explain how to create new components, and probably another one to show the rest of the tools that comes with GEAR.

I just don't know yet if it will be before or after the release that should happen soon (next week hopefully)

Also I'd like to mention that I received a lot of feedback from people who wants to contribute to GEAR or have been motivated sharing their own tools. That is really existing ! I'm really glad to see other people getting involved in that opensource experience.

[Helge Mathee]

At least my phone can rig, what can your's do?

Pfffff. I guess I shouldn't have started this flame-opensource-war.

[Gene Crucean]

Mine fetches me cold beers. Yes... there was an app for that.

[jm khayat]

Salut Jeremie !

Thanks for this, it really seems to be a very promising set of tool for Softimage.
Making it opensource is also very exciting ! this could provide a very complete toolkit for everyone, when new features will be added by users. And I will certainly be one of them

You seem to have thought of a lot of cool features for the rig itself.
Can you actually key between FK and IK seemlessly in a same animation ?
Same question for features like Base/Top Squatch & Strech ?

Also is the biped sinoptic view generated at the same time the guide becames a reel rig or is it a separate set of tools ?

Thanks again for this great input, can't wait to try it out

jm

2010/11/19 Jeremie Passerin <gere...@gmail.com>

[Jeremie Passerin]

Hi jm,

not sure to understand your questions.

Yes you can key the blend from IK to FK and can animate with the two of them in the same scene.

Same with spine base/top and the squash and stretch

The synoptic are not automatically generated. They are automatically connected. 

I have created a bank of synoptic views and I can select the one I want to use for my character from the list I'm showing at the beginning at the video.

That is fairly easy to use but you still have to create synoptic view yourself if the one I'm providing doesn't match your character. 

Gear has now it's own vimeo channel. There is no new video right now, but you can see the nice logo create by Olga :

http://vimeo.com/channels/geartoolset

 I'm currently writing a little bit of documentation and debugging. 

[Olivier Jeannel]

Hello list,

I'm playing around with the Move Toward Goal.
I'm trying to make the emited particles stick to the Goal object, but
only on an area defined by a weightmap (on the Goal geometry).

Maybe it is obvious, but no success untill now.... Can someone point me
to a method ?

Thank's a lot.

Olivier

[Olivier Jeannel]

Ok, I think I just find a way. Probably most unelegant.
I had to go inside the MoveTowardsGoal Compound.
Then Inside the SetParticleGoal Compound.

Then I just filtered the GetGeometrySample with a Weightmap.Weights.

...seems to work.

Le 07/12/2010 12:10, Olivier Jeannel a �crit :

[Daniel Rajcic]

Hello Olivier
Personally, I like your approach better, but here is a setup that I used a
while ago.
It's basically cycling through the weightmap values and changes the goal
position until the value is 0.5 or higher.
Two problems I see with my setup:
- too many calculations (might be solved with an if statement)
- it might take a couple of frames until all particles found a point on the
goal that have an appropriate weightmap value (in my tests usually never
more than 3frames).

But anyway, here it is. Just wanted to share my solution.

cheers,
Daniel

p.s. grid has a weightmap and is the goal in my graph

--------------------------------------------------
From: "Olivier Jeannel" <olivier...@noos.fr>
Sent: Tuesday, December 07, 2010 7:39 PM
To: <soft...@listproc.autodesk.com>
Subject: Re: Ice : Move toward Goal, filtered by weightmap

[Olivier Jeannel]

Hey Daniel,

Thank you for your answer. I do apreciate your screen capture, but your
skills are far beyond mine ! I get the overal idea.
May I ask you what does "GetThis.Goal.Location" stands for ? The name is
obvious, but is this a special Get Data created by you ? Is "This" a
syntax word like "self".

Sorry for the basic questions ^^

Thank you

Olivier

Le 07/12/2010 15:53, Daniel Rajcic a �crit :

[Guillaume Laforge]

Typical ICE keywords :

This or Self : to get the object on which the ICETree is applied
This_Model : to get the model of the object
This_Parent : to get the parent.

You can use lowercase or uppercase for those keywords.

La bise Mr Jeannel ;)

Guillaume Laforge
Software Developer / Développeur de logiciels
Softimage

Autodesk Canada Co.
10 Duke Street
Montreal, QC, H3C 2L7

Direct 514 954 7195

-----Original Message-----
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Olivier Jeannel
Sent: Tuesday, December 07, 2010 12:44 PM
To: soft...@listproc.autodesk.com
Subject: Re: Ice : Move toward Goal, filtered by weightmap

Hey Daniel,

Thank you for your answer. I do apreciate your screen capture, but your
skills are far beyond mine ! I get the overal idea.
May I ask you what does "GetThis.Goal.Location" stands for ? The name is
obvious, but is this a special Get Data created by you ? Is "This" a
syntax word like "self".

Sorry for the basic questions ^^

Thank you

Olivier

[Daniel Rajcic]

Hi
"goalLocation" is not a special attribute created by me. It's a default attr
you have access to in ICE.
Get a "get data" node and then click on "Explorer". If you select your
pointcloud in the list, you can see all sort of ICE attributes you can use.
And if you don't wanna click through the list until you see your pointcloud,
you can just type "self." or "this." before you click the "Explorer" button.
I hope this is not too confusing. It's much simpler when you do it, than
when you have to describe the steps.

And as Guillaume already said, "this" or "self" just means "the current
object where this ICE tree is attached to".

cheers,
Daniel

--------------------------------------------------
From: "Olivier Jeannel" <olivier...@noos.fr>

Sent: Wednesday, December 08, 2010 1:43 AM