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 am
Hey Manny,
Thanks for looking into it. I"m 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
We mostly tend to use software, by version, or patched, or by package, that
doesn't shit itself over a meager 700 curves :p
We have the same problem to some extent, but working in the thousands, and
when it's addressed it's addressed by giving people tools that key things
more conservatively. It's
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 wrote:
> I know one case:
>
>
> If you put an expression on the View Visibility, and use H to hide the
> object, Render Visibility
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 PM
-boun...@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 fa
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
m: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@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
m
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Crowson
Sent: 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
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 Sut
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 12:30
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 addi
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
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
Hey Michal,
Your definitely right. Its something we should look into
-E
On Wed, May 22, 2013 at 7:05 PM, Michal Doniec 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 the shelf vers
"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 d
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 tracking
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 h
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
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
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 stuf
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 animators
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 hosti
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 wrote:
> Good to hear that the issue has been reported. This is a big deal for us
> here too.
> We love So
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 impre
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 ta
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
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 keying.
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 aliv
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 sen
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 s
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 packa
rique 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 b
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 i
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
addr
Sent: 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
mailto:raffsxsil...@googlemail.c
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 wrote:
> 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 encountere
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
Thanks!
Sent from my iPhone, please excuse for typos.
On 20 May, 2013, at 6:02 PM, Enrique Caballero
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, ivan tay wrote:
>> Hi E
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 wrote:
> Hi Enrique,
>
> Do you have a scene file for this ?
>
> Thanks
> Ivan
> Email : ivan@nospam.autodesk.com (please remove nospam
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 P
Sorry this is in softimage 2013 sp1
On Mon, May 20, 2013 at 5:15 PM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:
> Hey everyone,
> I am running into a distressing problem.
>
> An animator just came up to me and complained about it being very slow to
> key their animation.
>
> When t
Hey everyone,
I am running into a distressing problem.
An animator just came up to me and complained about it being very slow to
key their animation.
When they select all of the controls on the rig and drag the keys around or
simply set a key there is a fairly major delay.
I just did some test
43 matches
Mail list logo