as noted, we have had lots of issues with this, but if we strip an offending
scene down to just an animated null/root, the unwanted behaviour ceases
this makes it VERY difficult to send a low complexity scene to support for
repro
having already lost PLENTY of production time to this bug,
this makes it VERY difficult to send a low complexity scene to support for
repro
I don't mean to sound like a smartarse, but why not send a high complexity
one then? :)
DAN
On Tue, Feb 5, 2013 at 12:20 PM, adrian wyer adrian.w...@fluid-pictures.com
wrote:
** ** **
as noted, we have had
My guess would be that you need to send the whole production pipeline in
order to be able to replicate it. It's rare that you have everything inside
a Softimage DB.
I haven't seen this on a Linux box though, anyone here that uses Linux that
are experiencing the same thing?
regards
stefan
On
shitty BT broadband doesn't play well with a 300+Mb scene file. ;o)
and my usual preference is to eliminate any extraneous junk from the scene
to make it easier to trace the problem for support
a
_
From: softimage-boun...@listproc.autodesk.com
Hey everyone
I'm searching for a Job as Softimage TD/VFX artist and Character
Animator so I thought I give it a try and ask here.
You can find out everything about me on my website:
www.marioreitbauer.com
If you're searching for an Artist or you know someone who is just send
me an email
Hi
I already sent a repro scene to Autodesk, so they have at least one.
And I did try muting all the events. In fact, the problem is repro if
you load just sitoa.dll and nothing else.
Thanks
// Stephen
// Solid Angle Support
On 05/02/2013 5:48 AM, adrian wyer wrote:
shitty BT broadband
...just sitoa.dll and with all events muted..
On 05/02/2013 6:23 AM, Stephen Blair wrote:
Hi
I already sent a repro scene to Autodesk, so they have at least one.
And I did try muting all the events. In fact, the problem is repro if
you load just sitoa.dll and nothing else.
Thanks
//
Stephen,
U sent it to Manny?
On 5 Feb, 2013, at 7:24 PM, Stephen Blair
stephenrbl...@gmail.commailto:stephenrbl...@gmail.com wrote:
Hi
I already sent a repro scene to Autodesk, so they have at least one.
And I did try muting all the events. In fact, the problem is repro if you load
just
Chris,
It is logged by Stephen in beta forum on mon.
-Ivan
On Tue, Feb 5, 2013 at 8:23 PM, Chris Chia chris.c...@autodesk.com wrote:
Stephen,
U sent it to Manny?
Hi list,
first of all: thanx again for bringing PyQT to Softimage!
(it's just so much nicer to be able to do UIs for SI, Nuke and Maya in _one_ go
:))
But: I was wondering if someone else is having trouble getting QIcons to show in
PyQT for Softimage?
I have some code that runs fine in Maya and
Hi. Did you receive this? Cause I didn't.
Also, if you know where to get RC1 please let me know.
-manny
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Chris Chia
Sent: Tuesday, February 05, 2013 7:23 AM
To:
Crap !$@
Was meant for Chris.
-manny
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Manny Papamanos
Sent: Tuesday, February 05, 2013 4:42 PM
To: softimage@listproc.autodesk.com
Subject: RE: Fcurve editor crashing soft
Hi. Did you
Hi Kris.
After spending some time troubleshooting this one.
The head element FR_head is not disappearing but deforming the verts to
infinity due to the MetaMouthOperator.
Looks like it may be due to a crappy value someone may have set inside the
MouthAdjustProperties operator that FR is not
Hey Philipp,
you might want to make sure that your path is ok (file exists and so on),
and maybe try using
*addFilehttp://qt-project.org/doc/qt-4.8/qicon.html#addFile
*on your QIcon object ...
I doubt that might be the case, bus maybe you need to cast your path to a
QString *QIcon
I remember having some issues early on getting QIcons to work. But they
work fine now, This is the method that I used
# set the icons
import os.path
imgpath = os.path.split(
T://WG//RTR_WG//Application//Plugins//img )[0] + '//img//'
self.setWindowIcon( QIcon(
You're not doing anything particularly wrong.
There is nothing that locks the parameters that are ICE driven. It's weird
and annoying. Don't touch them or you'll be asking for funkyness.
Your tree looks fine and is correct so to speak, but you may wanna use the
Add Constraints compound and work
Alan is right, the parameters wont be locked.
Also in 2013 there seem to be 2 UV to Location Nodes,
One is a conversion and the other is a geometry query
If I use the geometry query one it wont actually update my UV location at
all.
If i use the conversion one it works properly
Its working
In my experience, if I am setting an object(null)’s transforms via ICE, I
had to create the ICE tree on a separate/different object. Then, everything
would work as expected, null’s transform properly locked and all.
I am guessing in your example you created the ICE tree on the null you are
trying
Yeah i think it's because the transform space can't be calculated
accurately if you're working in the one you're driving as well. Like a
dependency cycle.
Eric Thivierge
http://www.ethivierge.com
On Tue, Feb 5, 2013 at 9:25 PM, Jack Kao
If the graph lives on the object it transforms, the graph is evluated after
your manipulation in the view dirties it.
That usually means you see the result only after a parameter or something
else is changed.
It shouldn't spazz out though.
As for the other question, we are using ICE kine in rigs
when working with ice kinematics you have to follow one rule. set up the
connection, and don't touch it again. ever.
there is something really wrong in the kinematics stack when force feeding
through ice.
but still the possibilities overweight, and by following this one rule i do not
have any
Not sure I follow. What you mean with connection and not touching?
On Wed, Feb 6, 2013 at 1:58 PM, Sebastian Kowalski l...@sekow.com wrote:
when working with ice kinematics you have to follow one rule. set up the
connection, and don't touch it again. ever.
there is something really wrong in
That's more or less true for any pull only DAG in regards to multiple
outputs, SCOPs in example (or any op really) will do the same. The issue is
some times you have to do it that way when order of execution gets really
dodgy and you need to rule a certain way.
I'm still waiting in trepidation for
it seems soft gets confused when an ice operator feeds the kinematic stack.
normally when working with constraints, we can't change the values, the
transform is locked.
that should be the same when feeding the kinematics via ice.
generally speaking there is no difference between a constrain or
Not sure what's going on here, but periodically when I calling one of
our plugins in Softimage, I get the error message below. I can always
reload the plugin from the plugin manager and it will work fine. And it
fact, everything usually goes swimmingly. But it's happened 3-4 times in
the last
Correction. I just double-checked and reloading the plugin manually does
NOT fix this. I have to restart Soft to get around it.
-Tim
On 2/5/2013 9:39 PM, Tim Crowson wrote:
Not sure what's going on here, but periodically when I calling one of
our plugins in Softimage, I get the error message
Triple post!
It seems to fail in my second instance of Softimage. I'm guessing I
missed the fine-print about running PyQtForSoftimage under two instances
of Soft
-Tim
On 2/5/2013 9:41 PM, Tim Crowson wrote:
Correction. I just double-checked and reloading the plugin manually
does NOT fix
Can't say I've seen that problem.
Working on a fairly large and involved piece of ICE kine right now in fact,
and I constantly twitch a reset all in the process.
Constraints and ice kine ops though are not the same thing, nor they work
the same way AFAIK, but only someone with a fair knowledge of
A couple of things to check:
- Are you sure PyQtForSoftimage plugin is loaded before your plugin?
- *Application.Plugins( 'MD_PublishRenderLayers_Qt' ).OriginPath*is a valid
path?*
** - whatever/MD_PublishRenderLayers_UI.ui* file exist?
BSPR-7495 : Softimage freezes when you type numeric values in the Fcurve
Editor.
It has been logged as SOFT-8283.
On Tue, Feb 5, 2013 at 10:43 PM, Manny Papamanos
manny.papama...@autodesk.com wrote:
Crap !$@
Was meant for Chris.
-manny
From: softimage-boun...@listproc.autodesk.com
30 matches
Mail list logo
