Hey everyone,
So we are currently working with Autodesk to try to find a solution to
this issue. We have made this issue the #1 priority for one of our TD's.
And for those of you who are also suffering from this problem
ie. Jeremie Passarin, Rafaele Fragapane.
This is what we have found.
I
I did - and we locked everything that was not supposed to move/key.
Worked fine and it is not so difficult to write the tools to do a model
update. Also one BIG plus to this method against referencing is that
you avoid surprises when something changes in the rig that affects
animation and it
That's only an issue with live referencing, which is a pretty bad way to go
about it.
Versioned referencing will not hold any surprises as you control when a rig
reaches what shots. It's a matter of asset management, not of referencing
VS localized.
If anything localizing takes a liberty away from
Yep you are right Raff - but at that time we did not have any asset
system going, ask Simon - he and I had the brunt of that.
S.
On 22/05/2013 09:51, Raffaele Fragapane wrote:
That's only an issue with live referencing, which is a pretty bad way
to go about it.
Versioned referencing will not
We do live referencing here as we don't have much for versioning control at
this small studio. Its worked fine for us so far as our rigs are pretty
simple and eventually development stops for them on a project.
Eventually we might do versioned referencing but it would require some
asset
Eventually we might do versioned referencing but it would require some
asset tracking tools that we just don't have.
I'd start with some off the shelf version control software to do half of
the work for you (perforce, maybe svn etc.), a rather simple database on
top of this and some UI usually
Hey Michal,
Your definitely right. Its something we should look into
-E
On Wed, May 22, 2013 at 7:05 PM, Michal Doniec doni...@gmail.com wrote:
Eventually we might do versioned referencing but it would require some
asset tracking tools that we just don't have.
I'd start with some off
I totally agree with Raff. Versionned reference is the way to go. We don't
have it here either and it's already an issue on some projects.
I am not happy with animators creating local copy of the rigs, but I'm not
with them all day long to check how they work. I discovered they were doing
that, I
Just to make sure I understand the terminology... when you say
'versionned' referencing, do you mean a workflow that uses controlled
'resolutions'?
-Tim C.
On 5/22/2013 11:30 AM, Jeremie Passerin wrote:
I totally agree with Raff. Versionned reference is the way to go. We
don't have it here
Tim - it would be a system that controls VERSIONS of rig models for
e.g., they would be tested, then passed on to become the 'current'
version, which would then update the references. Basically to avoid say
a rigger just writing out the model that is used by a bunch of
animators, possibly
Thus you make it so they have no choice but to use the approved method
by only allowing motion to be checked in from ref models or only
allowing importing of the models via a scene assembler UI. :D
Eric Thivierge
===
Character TD / RnD
Hybride Technologies
On 22/05/2013
Gotcha. Just making sure the vocab was clear. Yeah that's just asset
management then... I have to say we don't have a good system in place
for asset versioning either (also a small shop with real constraints),
but it's something we're aware that we need.
-Tim
On 5/22/2013 11:55 AM, Sandy
: Wednesday, May 22, 2013 1:07 PM
To: softimage@listproc.autodesk.com
Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model
Gotcha. Just making sure the vocab was clear. Yeah that's just asset management
then... I have to say we don't have a good system in place for asset versioning
...@listproc.autodesk.com] On Behalf Of Manny Papamanos
Sent: Wednesday, May 22, 2013 2:25 PM
To: softimage@listproc.autodesk.com
Subject: RE: Setting and Manipulating Keys Very slow in Referenced Model
Hi Enrique.
I repro the issue in 2013SP1 QFE1 x64 with your test scene sent to support.
The keying issue
Could you elaborate with some examples of tools that fail? I haven't
experienced this myself so I'm wondering which ones they are and which
ones to look out for.
Eric Thivierge
===
Character TD / RnD
Hybride Technologies
On 22/05/2013 5:43 PM, Matt Lind wrote:
We used to use
...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Wednesday, May 22, 2013 2:50 PM
To: softimage@listproc.autodesk.com
Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model
Could you elaborate with some examples of tools that fail? I
I know one case:
If you put an expression on the View Visibility, and use H to hide the
object, Render Visibility rightfully toggles off, but if you tap again, it
won't come back on.
Remove the expression from ViewVis and it'll hide and unhide correctly
again.
On Wed, May 22, 2013 at 5:49
Forgot to say, it's the same deal if you lock the param value. (Rightclick
on the green square, Locks, Param Value)
On Wed, May 22, 2013 at 6:23 PM, Alan Fregtman alan.fregt...@gmail.comwrote:
I know one case:
If you put an expression on the View Visibility, and use H to hide the
object,
Hey Manny,
Thanks for looking into it. Im going to send you a video later today
showing you just how slow it is. Its more than just having too many
parameters set to keyable.
Your point about limiting the keyable parameters is 100% true and I should
have locked several of them out.
But with
HI,
Had an exchange with Enrique. This is a known issue - logged as SOFT-7029 -
Key Referenced Parameter Slower.
Thanks for bringing this up.
-Ivan
On Tue, May 21, 2013 at 11:44 AM, Raffaele Fragapane
raffsxsil...@googlemail.com wrote:
Even with no C++ knowledge you should be able to take
Good to hear that the issue has been reported. This is a big deal for us
here too.
We love Softimage referencing system a lot but are in a situation now where
animator are creating local copy of the rigs just to work around the issue,
which is obviously a big problem for us.
The new team has
Yep they are also being incredibly helpful with me. Thanks Softimage Team.
I'm getting our IT guy to fill out the paperwork for a QFE now
On Wed, May 22, 2013 at 12:59 AM, Jeremie Passerin gerem@gmail.comwrote:
Good to hear that the issue has been reported. This is a big deal for us
here
Regardelss of whether one might or might not be happy with the feature
list, I think it should be given to the team that they have put some
serious effort into keeping in touch with the community and going out of
their way to integrate into it, even in the face of some serious negativity
(the
Btw, until we get the QFE, I did a very aggressive removal of keyable
parameters and that helped significantly.
Which is something I should have done a while ago. I was letting them
scale every controller in the rig, as I don't like limiting the animators
freedom.
Instead i went to the
Jeremie, I considered letting them animate in local mode but i decided that
the risks outweighed the benefits.
I am just 100% uncomfortable with trusting the animators with Local models.
They will start deleting objects and changing heirarchy.
So instead I stripped down the rig of unecessary
Hi Enrique,
Do you have a scene file for this ?
Thanks
Ivan
Email : ivan@nospam.autodesk.com (please remove nospam from email)
On Mon, May 20, 2013 at 5:33 PM, Enrique Caballero
enriquecaball...@gmail.com wrote:
Sorry this is in softimage 2013 sp1
On Mon, May 20, 2013 at 5:15 PM,
Hey Ivan,
Thank you, Yep I do, I will send it to you in a few minutes, just
packaging up the referenced models
On Mon, May 20, 2013 at 5:54 PM, ivan tay ivansoftim...@gmail.com wrote:
Hi Enrique,
Do you have a scene file for this ?
Thanks
Ivan
Email : ivan@nospam.autodesk.com
Thanks!
Sent from my iPhone, please excuse for typos.
On 20 May, 2013, at 6:02 PM, Enrique Caballero enriquecaball...@gmail.com
wrote:
Hey Ivan,
Thank you, Yep I do, I will send it to you in a few minutes, just packaging
up the referenced models
On Mon, May 20, 2013 at 5:54 PM,
How many custom attributes and specifically some feeding into ICE do you
have?
And how many FCurves at a time are we talking about?
We encountered several related issues (and occasionally solved or had
confirmation of them, and some QFEs that helped a lot)
On Mon, May 20, 2013 at 8:57 PM, Ivan
I heard the same thing here, and also heard it's much faster in 2014. Have
you tested that ?
On 20 May 2013 16:20, Raffaele Fragapane raffsxsil...@googlemail.comwrote:
How many custom attributes and specifically some feeding into ICE do you
have?
And how many FCurves at a time are we talking
: Monday, May 20, 2013 4:28 PM
To: softimage
Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model
I heard the same thing here, and also heard it's much faster in 2014. Have you
tested that ?
On 20 May 2013 16:20, Raffaele Fragapane
raffsxsil...@googlemail.commailto:raffsxsil
There are two issues, a regression, which Matt does a good job of pointing
out and that should be fixed in 2014 (to my knowledge, but haven't tested),
and other things we found out when a mix of ICE and custom parameters are
involved (which is not related to ICE slow at setting them, which was
well its a gear rig so there are a fair but of custom parameters. but not
an obscene amount. And as far as I know, no parameters driven by ICE.
although I am using the dual quaternion skinning compound for the envelope.
I've already tested with this removed and it wasnt the issue.
I have tested
Caballero
Sent: Monday, May 20, 2013 8:16 PM
To: softimage@listproc.autodesk.com
Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model
well its a gear rig so there are a fair but of custom parameters. but not an
obscene amount. And as far as I know, no parameters driven by ICE
Have you tried changing how the keys are set?
150 objects with the entire local transform set isn't that many curves, we
have had issues but that's with thousands piled up on more thousands.
Lastly, is that with the FCurve editor open or not?
I suggest you send the scene to Soft if it can be
thanks guys,
yep I've already sent the scene to Softimage. Its definitely a Softimage
2013 Sp1 issue though and not scene related.
The parameters that the animators can key is already fairly limited as I'm
pretty careful with keyable parameters. but I will strip down what i can
for now.
It is
the keys are being set just by pressing the K key and the keying mode set
to Key all Keyable
this is the command that gets spit out
Application.SaveKeyOnKeyable()
On Tue, May 21, 2013 at 11:30 AM, Enrique Caballero
enriquecaball...@gmail.com wrote:
thanks guys,
yep I've already sent the
Sounds like a regression.
I've had rigs with controls in the hundreds of objects with quite a few
added properties and custom parameters, adding up to packs of thousands of
keyframes at a pop. It's never been blazing fast, even with rig-centric
dedicated commands, but I would have been skinned
Thanks raf and everyone for the advice, its really helpful.
I will now reduce their ability to key scaling on the majority of the rig.
I will also try to code my way around it, problem is I don't know c++ so
I'm stuck with python which I doubt will be able to save me when it comes
to slow
Even with no C++ knowledge you should be able to take different routes
around it, just to see if the bottleneck is specifically in one of the
wrappers or far enough upstream. Give it a shot.
On Tue, May 21, 2013 at 1:40 PM, Enrique Caballero
enriquecaball...@gmail.com wrote:
Thanks raf and
40 matches
Mail list logo
