Re: [Maya] Freeze cycle equivalent?

[Enrique Caballero]

You can bake the animation,  animation tab/key menu/bake animation

On Mon, Feb 3, 2020 at 12:35 AM David Saber  wrote:

> Hello again , hope I'm not dogging you with my Maya questions.
>
>
> In Soft, in the animation editor, we could set the animation to cycle
> between , for example, frames 1 to 24. Then we could freeze the cycle ,
> say , from frame 1 to frame 144.
>
> Is there anyway to do this in Maya? I searched in the graph editor's
> menus but could not locate any equivalent...
>
>
> Thanks
>
> David
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: pointcloud meshing trouble

[Enrique Caballero]

EMpolygonizer should do it. It's installed with Softimage uner the FX tab,
in Create I think.  it will generate geometry out of your point clouds

On Sun, Jan 19, 2020 at 7:55 AM balazs kiss  wrote:

> Hi all,
>
> I was wondering if I'm missing something obvious regarding the
> subject. My goal is to mesh a pointcloud in a way, that each particle
> becomes a vertex, and the closest points are connected, like an
> icosahedron.
>
> Turns out it's not as easy (for me) as I thought. Isn't there an
> option in topolizer or somewhere, where I forgot to look?
>
> Also (in theory), isn't particle orientation should make it possible
> to create concave meshes when the pointcloud is a bit messy?
>
> Cheers,
> b
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: OTish - Maya namespaces - clearing that up

[Enrique Caballero]

Hope it helps.
  We track our assets using a line of JSON that is stored under the
ROOT_NUL of the asset, this stores the asset name, type, path, what project
it goes to etc.

All of our tools read this JSON line and interpret it for us, and we have
coded some nice front-end tools so that the animator doesn't really need to
use the outliner much.

Coming from Softimage, I was shocked at how name dependent Maya was, and
how hopelessly crazy the outliner can become with all of the SETS and the
super long name spaces.

So we basically worked around it, but yah... every one of our assets has
identical naming for the ROOT_NUL and for the basic structure.  Its that
JSON line that has the real asset info.
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: OTish - Maya namespaces - clearing that up

[Enrique Caballero]

Namespaces are annoying.

When building assets, what I do to deal with them is I bind a hotkey to
collapse all namespaces, as sometimes when you are building an asset, you
are drag and dropping several other assets into the scene and
frankensteining them together.  You then end up with a huge nested tree of
namespaces that just takes forever to delete one at a time in the namespace
editor.  I will share my script for collapsing namespaces at the end of
this email.

As annoying as they are, you can disable viewing namespaces in most
editors,  and I recommend that you use them for your referenced assets,
otherwise you will end up with name clashing on the scene Root.

For example, the root object of all of our rigs is named "ROOT_NUL"

If we didnt use namespaces, each one of those would get a number appended
to them once imported.  Not the end of the world, but I don't want my
referenced assets to go around changing their naming randomly.

yes we could use more unique names for our ROOT_NULS, like putting the
asset name in there, but I rather just let the namespace handle that, and
keep all of our assets and rigs standardised.




script for collapsing namespaces follows:


"""

Collapses all namespaces (including nested) to root.

"""


# Recursively collect all namespaces.

def get_all_namespaces(iter_nsp=[":"]):

for nsp in iter_nsp:

yield nsp

all_nested_nsp = cmds.namespaceInfo(nsp, listOnlyNamespaces=True) or []

for nested_nsp in get_all_namespaces(iter_nsp=all_nested_nsp):

yield nested_nsp

default_namespaces = [":", "UI", "shared"]


scene_namespaces = list(get_all_namespaces())


for nsp in reversed(scene_namespaces):


if nsp in default_namespaces:

continue

print "Removing namespace {}".format(nsp)

cmds.namespace(removeNamespace=nsp, mergeNamespaceWithRoot=True)










On Thu, Jun 14, 2018 at 4:47 PM, Stefan Kubicek 
wrote:

> Everybody hates Namespaces, but you don't necessarily need to use them.
> First of all: Maya is more permissive with regards to duplicate names since
> it only demands an objects “Full Name” (i.e. the name of the object
> prepended by all it's parent's names) to be unique in a scene. In
> Softimage, an objects name needs to be unique within it's Model,
> irrespective of it's location in the hierarchy under that model, which is
> of course a more deterministic way of identifying objects with regards to
> file referencing, the animation mixer, etc, but that's not the point here.
>
> In Maya, just like in 3dsMax or Softimage (or any other 3d package I
> think), you get automatic numbering of objects in case of a name clash
> (i.e. when the full name of the new object is similar). That usually occurs
> when creating or duplicating an object or node, importing or referencing a
> file, or rearranging objects in a hierarchy. The closest thing to the
> Softimage Model paradigm in Maya you can get is to use groups. For example,
> instead of maintaining your character rig and meshes under a model in Soft,
> you do the same under a group in Maya. There is even an option to
> automatically group objects on import, which is what I usually do, and/or
> to rename (i.e. number) clashing names on import, which is less tidy but
> also helpful sometimes. That's it.
>
> Stefan
>
> PS: I still hope to find out the address of that moron at Alias one fine
> day who decided that namespaces are a clever way to handle scene complexity.
>
> On 14.06.2018 09:56, Morten Bartholdy wrote:
>
> I am sure I am not the only one finding Mayas namespaces extremely
> annoying.
>
> If I do a search on Maya namespaces, numerous hits explain how namespaces
> are annoying and how to handle them and/or get rid of them via built-in
> tools, scripts, or other methods – one of these even come from an Autodesk
> Technical Specialist: https://area.autodesk.com/
> blogs/the-maya-blog/maya_2012_namespace_and_prefix_tips_and_tricks/
> 
>  3A__u7507473.ct.sendgrid.net_wf_click-3Fupn-3D5SmYwFIJXHmC5X9wAP0G6ui9ndn-
> 2D2BrPckKmQuMExySxDcB-2D2B2Cv43FA1Cl3CAceI0DUKvGEyTF
> paxxyHOzrsJPBkmw8ivBqIosXKC6PGdBtnsN407Paq9UtwShjpFRRsmi19O8
> ieW0TuwT44wrPXhckQ-2D3D-2D3D-5FAiuOPJnPrj4wc3JxtM6Fu4BFTLWf
> PgU-2D2BZSdmfLFS5-2D2BsJ3JlitusvKzDTX4sOR42u811Ikqqfqfz0-
> 2D2By5Zky5FBVUhYfw

Re: Facial rigging.

[Enrique Caballero]

Jeremie, I'm confused.  You guys rig in Maya but animate in Softimage?

On Sun, May 20, 2018 at 5:46 PM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> That is super generous, wish more people would share comprehensive artist
> friendly stuff
>
> On Sat 19 May 2018, 20:43 Jeremie Passerin,  wrote:
>
>> Anytime. Blur is not keeping much secret. We believe the talent of our
>> crew and constant search for innovation is what keeping ahead of the game.
>> Our blend shape solver is open source and works in Softimage and Maya.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_blurstudio_Simplex&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=A6i0Eh_b5LRtfYvLhTOjMwfLchpggiTVI59LVQxzcXg&s=CM_1MDGYJ2yHGd80OJ_aI_Fz0-5RrxoO36Ss1PTrDFQ&e=
>> 
>>
>> On Sat, May 19, 2018, 8:38 AM Sebastien Sterling <
>> sebastien.sterl...@gmail.com> wrote:
>>
>>> Well, thanks for your time in answering these questions Jeremie. Best of
>>> luck to you guys at blur.
>>>
>>> On Sat 19 May 2018, 15:49 Jeremie Passerin,  wrote:
>>>
 In our case it wouldn't be possible to model the 500 shapes I mentioned
 on each character for each project considering our tight deadline.
 We've developed some techniques to create a standard set of blend
 shapes that we can transfer from one character to the other.
 The transfer is usually good enough for background characters and
 simple expressions but we have to clean the shapes for hero characters.That
 means you always start with a base and you clean the deformations and match
 the references.

 The sculpting of the shapes is done in Maya. Because you already have a
 base, we usually don't need to use deformers, it's all hand sculpted. We
 used deformers to create the first set of shapes though.
 The mesh is dense but Maya sculpting tools are pretty good. We still
 animate in Softimage so we have tools to transfer over the shapes and build
 the facial rig.

 Note that the facial modeler is not necessarily the facial rigger.
 Those are different skills and not everyone can do both. Our best facial
 modeler has studied facial anatomy for years and that's pretty much all it
 does. Even our top modelers can't do what he does, and I certainly can't do
 any of that.


 On May 18, 2018 11:23 PM, "Sebastien Sterling" <
 sebastien.sterl...@gmail.com> wrote:

 To jeremie.

 When someone comes to work for you, do you train them in-house on your
 methods ? Do you have an in-house training Manuel to such effect detailing
 the various expressions and breakdowns e.g lip curled in/out mouth corners
 up/down... and how to make them using deformer as supposed to just manually
 moving point, which doesnt reaĺy work if you are working with very dence
 meshes and trying to keep your blending smooth.

 I'm sure you have proprietary tech you don't want to share with other
 studios, and this is not what I am asking for. I just want to know how
 shapes are built using deformers and the breakdown of which shapes are 
 used.

 E.g. when you are making the eyes open, you paint the entire closed eye
 cluster, then place the pivot in the cent

Re: Set Driven Key Copy/Paste in Maya

[Enrique Caballero]

Let me know if it does burn you as I am curious but not brave enough to try
in production.

I actually quite enjoy rigging in Maya now, once I redid all of the stupid
hotkeys and wrote some scripts for collapsing namespaces I'm near as fast
in Maya as I was in Softimage.

In some ways i prefer rigging in Maya, it's not as intuitive or user
friendly,  and how it hides stuff is ridiculous.  (inheritted visbility?
seriously?)

But what I may lose in efficiency I get rewarded in the end with rigs that
calculate much faster than they did in Softimage.

Making a rig with full facial, lots of blendshapes and decent deformation
in Softimage, it was very difficult to keep it over 30 fps.And I am
quite meticulous in my attempts to keep rigs light and efficient.

In Maya without even trying too hard my rigs end up being around 50 fps if
not faster.

It is in part due to parallel evaluation, which is a relatively new
addition, but it does work as long as you are careful to follow the
guidelines

On Sat, May 12, 2018 at 2:20 AM, Adam Sale  wrote:

> It hasn't bitten me yet.. .touch wood, but in the absence of any sort of
> duplicate symmetry tool that works, and rebuilding the entire opposite side
> from scratch, I haven't found a better solution, unless its the old Maya
> adage of 'just writing a tool for that '
>
> Adam
>
>
> On Fri, May 11, 2018 at 12:00 AM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> I've been avoiding negative scaling in Maya as it's not as forgiving as
>> Softimage was with that.
>>
>> I used to mirror rigging components in softimage by scaling (-1,-1,-1)
>> and rotation x by 180.
>>
>> Worked just fine, used that technique in multiple productions (happy
>> feet, legend of the gaurdians used that as well)
>>
>> The only time that hurt me was when we wrote an animation library that
>> appended animation in space, and we needed to do a slightly different
>> calcultation for the right side of the body.  Still no biggy.
>>
>> I've been too scared to do it in Maya though.  I actually manually
>> rebuild the component in Maya with a different orientation.
>>
>>
>> I don't know if I'm being anal retentive, but when it comes to Maya I
>> tend to try to avoid shortcuts with transformations like that, as whenever
>> I try it tends to burn me
>>
>> On Fri, May 11, 2018 at 12:30 AM, Adam Sale  wrote:
>>
>>> Duplicate special with input graph checked on is the key to mirroring
>>> more complex hierarchies in Maya.
>>> That, and making sure every striking element involved in the rig needs
>>> to be parented under a group node that is at the origin.
>>> This group node and children is what you duplicate special with input
>>> graph selected, and then do the whole scale across X to -1.
>>>
>>> Everything comes across fine if you go that route, nodes, driven keys,
>>> etc. .. Of course then you also have to be aware of Joint orients flipping
>>> 180.. and address if necessary.
>>>
>>> I've kind of gotten used to Maya rigging now, but I really do miss the
>>> simplicity of our dearly departed XSI.
>>>
>>> Adam
>>>
>>> On Wed, May 2, 2018 at 2:46 AM, Anto Matkovic  wrote:
>>>
>>>> Copy-paste of selected nodes, makes a copy of everything connected to
>>>> selected nodes, including hidden connections to layers, Node Editor
>>>> bookmarks, so on. ''Safe way''  could be saving a copy of scene, deleting
>>>> everything else (including layers and such), copying back to original
>>>> scene. Fortunately Maya could copy entire rig or elements from scene o
>>>> scene.
>>>> Duplicate in Node Editor makes a duplicate of only selected nodes, but
>>>> leaves them unconnected.
>>>> As alternative, it worth to try 'duplicate special' (from edit menu)
>>>> with some of available options, while this, by default, makes a copy of all
>>>> hierarchy bellow.
>>>>
>>>> IMO scripting for such tasks is usable if someone wants to follow some
>>>> exact tutorial or example, or someone is able to visualize complete rig
>>>> without even using Maya - but not really for experimenting and expecting
>>>> the 3d app to help in this process. Perhaps that addiction to scripting
>>>> could explain why almost all Maya rigs are not inventive, not original copy
>>>> of actual crap from Pixar or so. Individuality 

Re: Set Driven Key Copy/Paste in Maya

[Enrique Caballero]

I've been avoiding negative scaling in Maya as it's not as forgiving as
Softimage was with that.

I used to mirror rigging components in softimage by scaling (-1,-1,-1) and
rotation x by 180.

Worked just fine, used that technique in multiple productions (happy feet,
legend of the gaurdians used that as well)

The only time that hurt me was when we wrote an animation library that
appended animation in space, and we needed to do a slightly different
calcultation for the right side of the body.  Still no biggy.

I've been too scared to do it in Maya though.  I actually manually rebuild
the component in Maya with a different orientation.


I don't know if I'm being anal retentive, but when it comes to Maya I tend
to try to avoid shortcuts with transformations like that, as whenever I try
it tends to burn me

On Fri, May 11, 2018 at 12:30 AM, Adam Sale  wrote:

> Duplicate special with input graph checked on is the key to mirroring more
> complex hierarchies in Maya.
> That, and making sure every striking element involved in the rig needs to
> be parented under a group node that is at the origin.
> This group node and children is what you duplicate special with input
> graph selected, and then do the whole scale across X to -1.
>
> Everything comes across fine if you go that route, nodes, driven keys,
> etc. .. Of course then you also have to be aware of Joint orients flipping
> 180.. and address if necessary.
>
> I've kind of gotten used to Maya rigging now, but I really do miss the
> simplicity of our dearly departed XSI.
>
> Adam
>
> On Wed, May 2, 2018 at 2:46 AM, Anto Matkovic  wrote:
>
>> Copy-paste of selected nodes, makes a copy of everything connected to
>> selected nodes, including hidden connections to layers, Node Editor
>> bookmarks, so on. ''Safe way''  could be saving a copy of scene, deleting
>> everything else (including layers and such), copying back to original
>> scene. Fortunately Maya could copy entire rig or elements from scene o
>> scene.
>> Duplicate in Node Editor makes a duplicate of only selected nodes, but
>> leaves them unconnected.
>> As alternative, it worth to try 'duplicate special' (from edit menu) with
>> some of available options, while this, by default, makes a copy of all
>> hierarchy bellow.
>>
>> IMO scripting for such tasks is usable if someone wants to follow some
>> exact tutorial or example, or someone is able to visualize complete rig
>> without even using Maya - but not really for experimenting and expecting
>> the 3d app to help in this process. Perhaps that addiction to scripting
>> could explain why almost all Maya rigs are not inventive, not original copy
>> of actual crap from Pixar or so. Individuality is not allowed in Maya
>> world
>>
>>
>>
>> --
>> *From:* "p...@bustykelp.com" 
>> *To:* Ben Barker ; Official Softimage Users
>> Mailing List. 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21forum_xsi-5Flist&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=wW5laUMCCTu5EOuEoUq_ftd264aSHGvFDwHVs8V-Jgw&s=8ecNZHsGd-XzIHoZj9L1SfXazwRINsaLyop8RoOvoRA&e=
>> 
>> 
>> *Sent:* Tuesday, May 1, 2018 4:32 AM
>> *Subject:* Re: Set Driven Key Copy/Paste in Maya
>>
>>
>> Thanks.
>> I decided to redo it  with the Node editor.. Thinking it might work a bit
>> like ICE. However, after completing one leg, I discovered that you can’t
>> just copy and paste that stuff either as it makes all kinds of new stuff in
>> the scene. What a mess. I just don’t understand how Maya works at all.
>>
>> I’m not going to make a scripted rigging pipeline, its not my thing. I
>> like being able to invent/experiment on the fly. I don’t think I’m going to
>> last long with Maya at this rate.
>>
>>
>>
>>
>> If you'd like to unsubscribe and stop receiving these emails click here
>> 

Re: ignoring error in deadline

[Enrique Caballero]

If that doesn't work I would convert it to an alembic cache, it can handle
dynamically changing topology, and then push that through

On Thu, Apr 26, 2018 at 6:39 PM, Kris Rivel  wrote:

> Awesome thanks! I'll give that a shot!
>
> Kris
>
> On Thu, Apr 26, 2018 at 4:13 AM, Ola Madsen 
> wrote:
>
>> Hi Kris,
>>
>>
>>
>> In the Deadline > Configure Plugins > Softimage settings, Disable Strict
>> Error Checking. And that should fix your problems…
>>
>>
>>
>>
>>
>> O
>>
>>
>>
>>
>>
>> *Från:* softimage-boun...@listproc.autodesk.com <
>> softimage-boun...@listproc.autodesk.com> *För *Kris Rivel
>> *Skickat:* den 26 april 2018 06:05
>> *Till:* Softimage List 
>> *Ämne:* ignoring error in deadline
>>
>>
>>
>> Hey all...been ages! I know this is a stretch maybe but curious if anyone
>> has a solution. I'm submitting a scene that is using a cached polygonizer5
>> mesh from Mootzoid. Works and looks great. Problem is that for some
>> reason...the render is failing on deadline. The only thing I can figure out
>> is a strange error I get when rendering through the UI that seems to not
>> effect anything. My thought is this error is just a warning but deadline is
>> seeing it as a problem and killing the render. Rendering through UI is
>> fine. Any suggestions how to ignore this error and force it to just keep
>> going? Thanks!
>>
>> Kris
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>> with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: OTish - Maya equivalent to weightmap in Softimage?

[Enrique Caballero]

Morton,

Try Vertex Color Sets.

We found that this was the closest to an equivalent.  We use that and then
use that to drive various things similar to a weight map

it's under the mesh display tab, there is also a Color Set editor that you
can use to organise them.

On Wed, Aug 9, 2017 at 3:22 PM, Morten Bartholdy 
wrote:

> Thanks Steve. Given the quality of the Maya documentation this might
> easily slip under my radar :)
>
> MB
>
>
>
> > Den 8. august 2017 klokken 18:27 skrev Steve Parish <
> porkypar...@gmail.com>:
> >
> >
> > If using Arnold hit "Export Vertex Colors" under the Arnold property on
> the
> > object.
> >
> > Steve
> >
> > On Tue, Aug 8, 2017 at 9:45 AM, Morten Bartholdy 
> > wrote:
> >
> > > Thanks for clarifying Anto - I sort of suspected that much :/
> > >
> > > MB
> > >
> > >
> > >
> > > > Den 5. august 2017 klokken 00:13 skrev Anto Matkovic <
> a...@matkovic.com
> > > >:
> > > >
> > > >
> > > > There is no weight map property usable for everything in Maya,
> neither
> > > in Max. Weight map for modulating the deformer, like blend shape, is
> tied
> > > to deformer, perhaps even stored with deformer node. For Hypershade and
> > > rendering, you can use vertex colors and vertex color painter, if your
> > > renderer has appropriate shading node, I think it's aiUserColor for
> Arnold.
> > > Maybe there's utility around, able to exchange these maps.
> > > >   From: Morten Bartholdy 
> > > >  To: softimage@listproc.autodesk.com
> > > >  Sent: Wednesday, August 2, 2017 11:37 AM
> > > >  Subject: OTish - Maya equivalent to weightmap in Softimage?
> > > >
> > > > I am learning Maya atm and have run into a snag (one of many). I
> would
> > > like to use weightmaps in Maya like I am used to in Softimage. Our Maya
> > > artists have no clue what I am talking about, so no help there.
> > > >
> > > > It looks like I can paint attributes on geometry using Artisan paint
> > > tools, but the proces (from reading docs and forums) is not so
> > > straightforward.
> > > >
> > > > Am I correct in assuming I should apply a paintable attribute to the
> > > shapenode(!?) and then use a silly mel command (as opposed to have it
> > > paintable when applied, or at least via a button) to make it
> paintable? And
> > > how do I then grab the painted values in the Hypershade or for an
> operator?
> > > >
> > > > Could someone who has been there quickly run through the steps, or
> point
> > > to a different workflow to achieve something similar?
> > > >
> > > > Thanks!
> > > >
> > > > Cheers
> > > > Morten
> > > > --
> > > > Softimage Mailing List.
> > > > To unsubscribe, send a mail to softimage-request@listproc.
> autodesk.com
> > > with "unsubscribe" in the subject, and reply to confirm.
> > > >
> > > >
> > > >--
> > > > Softimage Mailing List.
> > > > To unsubscribe, send a mail to softimage-request@listproc.
> autodesk.com
> > > with "unsubscribe" in the subject, and reply to confirm.
> > > --
> > > Softimage Mailing List.
> > > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> > > with "unsubscribe" in the subject, and reply to confirm.
> > >
> > --
> > Softimage Mailing List.
> > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: Strange Double Click Issue with Explorer

[Enrique Caballero]

thanks everyone, all very good advice.

in the end it turned out to be something weird.

he disconnected from the workgroup, reconnected, and everything is fine now.

strange

On Tue, Apr 7, 2015 at 11:29 PM, Ponthieux, Joseph G. (LARC-E1A)[LITES] <
j.ponthi...@nasa.gov> wrote:

>  In explorer it’s normal for property page to appear after
> single-clicking the object icon.
>
>
>
> However, in explorer you must double-click the object name to open the
> property page.
>
>
>
>
>
> In schematic if you have icons displayed (View->Show Icons)
> single-clicking the icon will raise the pp.
>
>
>
> But in schematic the object “rectangle” or “name box” must be double
> clicked to raise the pp same as object name in explorer.
>
>
>
>
>
> If single clicking a folder on the desktop does not open the folder
> immediately it’s probably not a Windows or Mouse setting causing the issue.
> If it does I’d look to Windows, the hardware, or the hardware driver as
> potentially the cause.
>
>
>
> If this is only occurring with Softimage, and not occurring in any other
> app or Windows, then potentially it is specific to the application.
>
>
>
>
>
> Since Soft has a methodology for single clicking items via their icons, vs
> double-clicking their names, in both schematic and explorer, it’s
> conceivable that Soft could be confused regarding icon/name management
> overlays in the display. It’s a stretch, but is there any chance you’ve
> made changes to the graphics card or graphics drivers recently?
>
>
>
> --
>
> Joey Ponthieux
>
> LaRC Information Technology Enhanced Services (LITES)
>
> MYMIC Technical Services
>
> NASA Langley Research Center
>
> __
>
> Opinions stated here-in are strictly those of the author and do not
>
> represent the opinions of NASA or any other party.
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Enrique Caballero
> *Sent:* Tuesday, April 07, 2015 6:07 AM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Strange Double Click Issue with Explorer
>
>
>
> Hey everyone,
>
>   This is a bit of a weird one.
>
>
>
> One of our animators has an issue where when he selects anything in the
> explorer, with a single click. It automatically opens up the Property Page
> for it.  This also happens for the Schematic View
>
>
>
> But not for the viewport.
>
>
>
> It's as if hes double clicked it, or pressed enter, but he hasn't.
>
>
>
>
>
> I checked every preference that I could think of, but I cant seem to stop
> it from happening.
>
>
>
> We have also changed his mouse and keyboard, as well as played with his
> Windows Settings, no go.
>
>
>
> Anyone seen this before or have any idea of what it might be?
>

Strange Double Click Issue with Explorer

[Enrique Caballero]

Hey everyone,
  This is a bit of a weird one.

One of our animators has an issue where when he selects anything in the
explorer, with a single click. It automatically opens up the Property Page
for it.  This also happens for the Schematic View

But not for the viewport.

It's as if hes double clicked it, or pressed enter, but he hasn't.


I checked every preference that I could think of, but I cant seem to stop
it from happening.

We have also changed his mouse and keyboard, as well as played with his
Windows Settings, no go.

Anyone seen this before or have any idea of what it might be?

Re: dual quaternion enveloping

[Enrique Caballero]

ive used it many times in production, i had no issues with it.

just blend between dual quat and linear with an envelope and you should get
some really nice deformation

it flips when you rotate something past 180 though, so dont use it if your
character is especially twisty

On Wed, Oct 29, 2014 at 3:22 AM, Grahame Fuller  wrote:

> Scaling should be OK, but don't touch bone lengths.
>
> gray
>
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman
> Sent: Tuesday, October 28, 2014 1:42 PM
> To: softimage@listproc.autodesk.com
> Subject: Re: dual quaternion enveloping
>
> I seem to remember weirdness if dragging the model null around.
> On Tue Oct 28 2014 at 11:02:25 AM Matt Morris  matt...@gmail.com>> wrote:
> Hi chaps,
>
> I'm very tempted to use this on some characters here, I read that it does
> now support scaling, are there any remaining caveats still out there to be
> aware of?
>
> Cheers,
> Matt
>
>
> --
> www.matinai.com
>

Re: dual quaternion enveloping

[Enrique Caballero]

err meant to type weightmap not envelope

On Wed, Oct 29, 2014 at 3:31 PM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> ive used it many times in production, i had no issues with it.
>
> just blend between dual quat and linear with an envelope and you should
> get some really nice deformation
>
> it flips when you rotate something past 180 though, so dont use it if your
> character is especially twisty
>
> On Wed, Oct 29, 2014 at 3:22 AM, Grahame Fuller <
> grahame.ful...@autodesk.com> wrote:
>
>> Scaling should be OK, but don't touch bone lengths.
>>
>> gray
>>
>> From: softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman
>> Sent: Tuesday, October 28, 2014 1:42 PM
>> To: softimage@listproc.autodesk.com
>> Subject: Re: dual quaternion enveloping
>>
>> I seem to remember weirdness if dragging the model null around.
>> On Tue Oct 28 2014 at 11:02:25 AM Matt Morris > matt...@gmail.com>> wrote:
>> Hi chaps,
>>
>> I'm very tempted to use this on some characters here, I read that it does
>> now support scaling, are there any remaining caveats still out there to be
>> aware of?
>>
>> Cheers,
>> Matt
>>
>>
>> --
>> www.matinai.com<http://www.matinai.com>
>>
>
>

Re: Softimage to Maya Equivalents

[Enrique Caballero]

Thanks for the info guys,  This is super helpful.

I just played around with List Reference Edits in the Reference Editor.

You can  list and remove edits in there

Seems similar to a delta in there. Just far less readable. But when I
remove edits, I dont have to update referenced model to see an update.

I'll play around with that for a while and see if it has what i need.

Thanks for the info Raf.  I want to use Assets, as i like the black box
feature. I still have a lot of experimenting to do before i start moving
forward with anything though


On Tue, Sep 16, 2014 at 3:22 PM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> Some day something will have to replace it, please god we can not keep
> going like this ! :(
>
> On 16 September 2014 07:34, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> 1) Assets sort of work now. Studios aren't using them because very few
>> places are using recent versions of Maya, and they have been a buggy
>> disgrace for a while from what a lot of people who tried told me.
>> I've started testing them and so far so good, but it's a metric ton of
>> work to build around them.
>>
>> 2) It's not so much weaker, as much as it's not neatly organized.
>> Nearly everything in Maya is a DG or DAG node. Deltas in Maya are the
>> nodes that exist in a scene that don't correspond to the summation of all
>> nodes present in the assets imported.
>> A lot of places did just that (scanned the scene for that difference and
>> saved out the lot) for a long time, actually.
>> No, there isn't anything quite like delta, but the difference is recorded
>> in terms of nodes connected to a referenced asset. The contents aren't
>> always clear cut though, and there are quite a few nodes that will behave
>> buggily or get completely creamed out if added.
>>
>> 3) Yes, OM2 is OK and quite fast at a few things, but not yet all
>> pervasive, and it generally writes and reads like the arse of a homeless
>> leper, and when prototyping has the agility of a brick on sandpaper. I
>> simply gave up on Python in Maya at this point to be honest and simply go
>> straight to C++ even for trivialities, with the exception of Qt/UI work.
>>
>> On Tue, Sep 16, 2014 at 1:21 PM, Enrique Caballero <
>> enriquecaball...@gmail.com> wrote:
>>
>>> Hey guys,
>>>   I am biting the bullet and transitioning our pipeline over to Maya
>>> with the support of Fabric a lot of our RnD Development.
>>>
>>> I have a few questions that I can't seem to find concrete answers for
>>> that I was hoping you guys could help me out with, I know that this is a
>>> Softimage mailing list, but because of that I expect that you guys will
>>> have the context necessary to help me out.
>>>
>>> Here are my questions
>>>
>>> 1. Is there an equivalent to Models in Maya?  How do they encapsulate
>>> rigs and assets?  I have looked at the Assets feature that came out in Maya
>>> 2011 and there is some pretty impressive stuff in there, but it seems that
>>> none of the big studios are using that.  Are the studios simply using
>>> Namespaces?  Cuss that seems pretty horrible.
>>>
>>> 2.  Referencing seems much weaker in Maya, I guess that there is no
>>> Delta.  If not, where is the Delta information stored?  My friend Daniele
>>> says that it's just nodes in the scene, and is saved with the scene. Is
>>> there no centralised menu or place where I can find the connections to the
>>> scene and the referenced object,  basically... is there ANYTHING like a
>>> delta?
>>>
>>> 3. Is it worth me learning Pymel?  I have started and it seems pretty
>>> easy to transition over. The syntax is actually pretty simple.   But the
>>> studios that I'm talking to seem to all use the native Python integration.
>>>
>>>
>>> Thanks in advance for any information shared.
>>>
>>> best,
>>>  Enrique
>>>
>>>
>>>
>>
>>
>> --
>> Our users will know fear and cower before our software! Ship it! Ship it
>> and let them flee like the dogs they are!
>>
>
>

Softimage to Maya Equivalents

[Enrique Caballero]

Hey guys,
  I am biting the bullet and transitioning our pipeline over to Maya with
the support of Fabric a lot of our RnD Development.

I have a few questions that I can't seem to find concrete answers for that
I was hoping you guys could help me out with, I know that this is a
Softimage mailing list, but because of that I expect that you guys will
have the context necessary to help me out.

Here are my questions

1. Is there an equivalent to Models in Maya?  How do they encapsulate rigs
and assets?  I have looked at the Assets feature that came out in Maya 2011
and there is some pretty impressive stuff in there, but it seems that none
of the big studios are using that.  Are the studios simply using
Namespaces?  Cuss that seems pretty horrible.

2.  Referencing seems much weaker in Maya, I guess that there is no Delta.
 If not, where is the Delta information stored?  My friend Daniele says
that it's just nodes in the scene, and is saved with the scene. Is there no
centralised menu or place where I can find the connections to the scene and
the referenced object,  basically... is there ANYTHING like a delta?

3. Is it worth me learning Pymel?  I have started and it seems pretty easy
to transition over. The syntax is actually pretty simple.   But the studios
that I'm talking to seem to all use the native Python integration.


Thanks in advance for any information shared.

best,
 Enrique

Re: Humanize Maya project

[Enrique Caballero]

this gui looks cool, but i would stay away from it. Depending on what type
of artist/td you are, you will spend a lot of time at other peoples desk,
especially if you deal with animators.

I believe that a TD should use the standard hotkeys and the standard gui as
much as possible. Otherwise he will be useless when it comes to helping an
animator out with a problem.

When the animators get a bit too crazy with their hotkeys and UI  they
actually affect how quickly they can get support, but that is their choice
and they pay the price for it, me as a TD i think that I should be prepared
to offer support as quickly as possible.

Also if a person is making the switch to maya. they should whole heartedly
make the switch and let go of any preconceived ideas of what they want the
package to be.  Instead they should face reality and learn it inside and
out.

At least IMO




On Fri, Apr 11, 2014 at 7:34 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> They chose to show it now because it's, for the first time, somewhat worth
> showing.
> Presto isn't that old, Marionette was its predecessor and it's been the
> main package only a few years ago. Presto is being shown in tandem with
> Pixar's GPU push and new "openness" trying to drive industry standards
> aligned with their intenral standards, and because nVIDIA is a partner.
> I seriously doubt it'll go commercial any time soon, AFAIK the rigging and
> animation components are incredibly intertwined, and not many people will
> even conceive working like that. There would also be hardly any return to
> it most likely, it's a completely different scenario compared to PRMan.
>
> But yeah, you can always hope, weirder things have happened, but I
> wouldn't stay up at night for this one ;)
>
>
> On Thu, Apr 10, 2014 at 6:45 PM, Cristobal Infante wrote:
>
>> It did make me think when I saw the PRESTO demo, why are they showing all
>> this tech us now after all this years of secrecy?
>>
>> Let's not forget they sell RenderMan, and I am sure the've lost a hell of
>> a lot of business to Solid Angle's Arnold.
>>
>> Could this be a strategy to get back in? We can only hope right ;)
>>
>>
>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Do UV's enable us ?

[Enrique Caballero]

we use ptex here in some situations, and although you do save time from not
needing to create UVS, uv's are a bit friendlier when you change topology.

cutting a new edge into a piece of geometry is usually not too big of a
deal, as long as you are not deleting a UV border edge.  Usually with uvs
you can make minor change to topology with minimal redoing of UV's required.

but with Ptex as soon as you make any change to the topology you lose major
areas of texturing, dude to ptex working with an adjacency table of
polygons.

so basically, you better have your topology absolutely perfect, and rig
tested before you start using PTEX.


we still use UV's half the time here, and ptex the other half


On Tue, Apr 8, 2014 at 10:58 PM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> Does anyone know if PTEX workflow currently allows for as much control as
> UV ?
>
> or does it by its nature have limitations.
>
> Where it is relatively easy to animate a texture and subsequent
> deformation, how does one go about this in PTEX ?
>

Re: A confession

[Enrique Caballero]

if i need to use the cluster constraint i usually use an intermediary mesh,
and wherever i constrain i create a poly with a kind of star pattern to it.
 i find that it gives me a more stable rotation with minimal flipping.

its not the ideal solution im sure, but im always in a rush, and it seems
to work well.

with that said, i avoid it like the plague


On Sat, Mar 22, 2014 at 7:23 AM, soni...@gmail.com wrote:

> Hi all:
>
> I'm not sure, but I personally find the point to poly constraint very
> unreliable/unpredictable (also I believe that relies on uvs and geometry
> density as well). I don't want to keep sounding like I'm preaching, but the
> hyperrealmeshparent script by Terence Jacobson has saved me a few times
> already when I've needed such a function that standard hair follicle rivets
> could not solve.
>
> Yes, its not available ootb, but it hasn't failed me so far, so there's
> that... :p worth at least trying out!
>
>
> - Reply message -
> From: "David Gallagher" 
> To: 
> Subject: A confession
> Date: Fri, Mar 21, 2014 13:11
>
>
>
> That looks good!
> I haven't been keeping up with new features in Maya, so that's great.
>
>
> On 3/21/2014 1:48 PM, Adam Sale wrote:
>
> Point to poly constraints?
> On Mar 21, 2014 12:15 PM, "David Gallagher" 
> wrote:
>
>>
>> Let me know if you find one.
>>
>> On 3/21/2014 12:51 PM, Matt Lind wrote:
>>
>>  I think the key phrase is 'Maya renderer' - who uses that anymore?
>>
>>
>>
>> I'm almost positive there is an equivalent to object to cluster
>> constraint out of the box in Maya.  I think it's classified as a deformer
>> for meshes (wrap?), but I cannot say for sure as it's been many years since
>> I've had to use  it.
>>
>>
>>
>>
>>
>> Matt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* softimage-boun...@listproc.autodesk.com [
>> mailto:softimage-boun...@listproc.autodesk.com]
>> *On Behalf Of *Jordi Bares
>> *Sent:* Friday, March 21, 2014 11:47 AM
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: A confession
>>
>>
>>
>> You must be joking!!!
>>
>>
>>
>> :-ARghghhgh
>>
>>
>>
>> Jordi Bares
>>
>> jordiba...@gmail.com
>>
>>
>>
>> On 20 Mar 2014, at 16:59, David Gallagher 
>> wrote:
>>
>>
>>
>>
>> Exactly. For example, in Maya there is no object to cluster constraint,
>> so you have to use a 3rd party tool Rivet to attach things to geometry. But
>> if you need to apply a Smooth to render it in the Maya renderer, it
>> explodes.
>> So, don't use the Maya renderer, or...
>> You can use djRivet, which uses follicles intead of edges, but which
>> relies on UV's being present.
>> Works great.. until you change the UVs in any way.
>>
>> Not really a non-linear workflow. It's more like a circular workflow.
>>
>>
>>
>> On 3/20/2014 10:22 AM, Adam Sale wrote:
>>
>>   Something I have found in the last couple weeks, which I personally
>> find mind numbing is how tied to UVs some tools are.
>>
>>
>> Hair work... try and groom something, and then realize you need to tweak
>> your UVs. Gotta start over
>>
>> Painting weights. Gotta have UV's to do smoothing.  - Edit the Uv's..
>> start over.
>>
>>
>>
>> On Thu, Mar 20, 2014 at 9:02 AM, Mirko Jankovic <
>> mirkoj.anima...@gmail.com> wrote:
>>
>> but why scripting is new artist tool!
>>
>> REAL artist model in full screen text editor! who needs viewport at all
>>
>> start notepad, and begin typing coordinates for each vertex...
>>
>> that is how REAL hardcore stuff is done.
>>
>>
>>
>> buttons are for p...
>>
>>
>>
>> On Thu, Mar 20, 2014 at 4:34 PM, Morten Bartholdy 
>> wrote:
>>
>> +1
>>
>>
>>
>> IMHO scripting is for making crappy software work at all (Maya) and for
>> creating something special with good software that has buttons for all the
>> ordinary stuff (XSI).
>>
>> I simply don't have time to learn scripting, not least because my mind
>> doesn't lend itself to that kind of thinking and remembering syntax etc. My
>> time is better spent figuring out how to do great stuff with ICE. The only
>> scripting I do is some half arsed copy pasting from the script editor to
>> facilitate unified pass setups across multiple shots and similar stuff on
>> that level. That I can do :)
>>
>>
>>
>> Morten
>>
>>
>>
>>
>>
>>
>>
>>
>> Den 20. marts 2014 kl. 13:42 skrev Greg Punchatz :
>>
>>  "Just learn to script"
>>
>>
>>
>> It's not that easy for every one...
>>
>>
>>
>> My brain simply does not work that way, I would rather keep polishing my
>> art skills and learn all the amazing new painting tools  than learn to
>> script. Being person with dyslexia makes its more than a bit difficult for
>> me to jump on the scripting train.
>>
>>
>>
>> All this talk of the reality of the need for constant scripting as part
>> of your daily work flows in Maya makes me literally sick to my stomach
>>
>> Sent from my iPhone
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: Softimage user "migrating" to Maya

[Enrique Caballero]

i am a modeller who over the last several years has switched over to TD,
and somehow I landed in a supervisor role with very little experience as a
TD or as a ;eader.

One of the main reason that I have survived and even thrived is due to this
list.

 Every time I was faced with a problem that had me out of my depth, I could
send an email to this list, and I would get at least 4 solid replies, each
from a different perspective, each correct in its own way.

i took that information, absorbed it and tried to come up with the best
solution for my studios problems.

i love this list. in part, I owe my livelihood to it.

And because of this, I have to agree with Raff.

 There is way too much poison being thrown around here.  This place should
not degenerate into this.  At the very least you guys should take this to
PM.  This sounds like more of a personal issue.

Even though we are all moving to other packages, I hope that this list will
remain, and continue to be a source of knowledge, as I have grown to rely
on everyone here.



On Fri, Mar 21, 2014 at 11:24 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> Wow wow, are you on crack or something?
>
> I have not ONCE replied to BK/Paul Smith on this list. I've talked to him
> several times and there is no measure to how much I respect the guy. I sure
> as hell haven't called him stupid publicly or privately, EVER.
> That is some seriously shitty and absolutely unfounded accusation right
> there. WTF?
>
> And yes, I replied to Alok's thread, who's an ex alumni of mine for the
> record, and another person I have respect for and he knows it, only to the
> extent of mentioning that I believe TDs in the near future would have made
> better use of their time divesting and reskilling themselves.
> Given I sell training for TDs in XSI you'd think if I had any interest
> outside helping my peers I would encourage people to do just that and buy
> my shit instead of telling them to look elsewhere, don't you?
>
> I have not ONCE treated you as imbeciles or said you should migrate and
> that you don't know in the industry, where the hell you got that I have no
> idea, you seem to simply decide to take everything personally and
> aggressively, apparently from well before I even ever addressed you or your
> comments.
> Don't make it a me vs whatever the hell you think your "us" is.
>
> As for the LEGO movie, seriously, how the hell is that MY success or has
> changed one bit my behaviour? I just did RnD work on components, maths,
> pipe and auxiliary tool, didn't even supe it.
> You are being extremely insulting and assuming right there. If I -ever-
> even mentioned it it's because everybody and their dog keeps mentioning it
> like it was an all XSI production, and it's therefore become a completely
> mis-placed flag for "the rebellion".
>
> Dude, you seriously need to chill and stop making wild accusations.
> As for who you insulted personally, pretty much every single AD employee
> who ever posted, regardles of what they were saying or doing or whether you
> even knew who the hell they were (some of them were on our side... WERE).
>
> I explained why I find posts like yours disruptive and poisoning, and your
> reply is an ad hominem where you accuse me of calling Paul stupid? Come on,
> if ever there was a "point in case" moment.
>
> As for what I have done for the people here, I'm doing my best to remain
> reasonable and give advice dispassionately. You see it as me betraying the
> cause, I'm sure, but I see it as trying to help.
> I also got Brad Peebler in touch with the list, contacted and started
> initiatives in other regards I can't discuss publicly, and I refrained from
> telling sources of information key to this list to crawl under a rock.
> I reckon I'm coming out on top insofar. What have you EVER done, if I may
> ask?
>
> Have a great day.
>
>
>
>
> On Fri, Mar 21, 2014 at 1:50 PM, Emilio Hernandez wrote:
>
>> Thx Dave that was the point. To bring a little humor in a non personal or
>> direct way.  But for some high heels people it is an insult.
>>
>> @Raffaele
>>
>> Again with all my respect.  And now that you brought this to a more
>> personal level.
>>
>> Tell me who I have insulted in this list according to you.  Less to say,
>> I have seen really unprofessional post of the high gurus around here. You
>> are the one jumping everywhere you can, playing your Zeuz of the list role.
>>
>> At first, you treated us like imbeciles that have nothing to do with "the
>> industry" telling us to migrate.  You even went on Alok telling him, in
>> your great elloquent writing that he was a stupid for start developing
>> tools for Softimage for free.   Super constructive coming from you...
>>
>> Then Paul Smith came in telling that he is opening a new studio based on
>> Softimage and again with your high quality prose, you told Paul, who really
>> has created the most extensive free Softimage tutorials on line
>> library, that he was another stupid for foun

Re: Listening

[Enrique Caballero]

haha this is entertaining.  Although I definitely understand where Mihai is
coming from.  The decision for killing softimage was probably made in some
board room, by a bunch of bean counters that know little about our industry
and are definitely not here for anything other than making money.

i dont think any of those people would bother coming into this list and
trying to speak with us, they are probably too busy at some Eyes Wide Shut
event sacrificing small puppies and counting their money.

So attacking Chris is both unfair and unkind.  This is this guys job,
 we've all worked for a companies in the past where we did not agree with
the management.

He probably has kids to feed, and a family to support.  Be kind to the guy
and lets not make his day shit.


On Sat, Mar 8, 2014 at 1:57 PM, Gerbrand Nel  wrote:

> Wow.. that just happened.. the subtle thunderous crack of the AD whip...
> Hold on guys. I need to get some popcorn for this!!
>
>
>
> On 2014/03/08 01:54 AM, Chris Vienneau wrote:
>
>> Hi Mihai,
>>
>> You are listed on your online profile as an employee of next limit. I
>> can't find your seats in our database. You have made good points. We don't
>> mind keeping this forum open for discussion about alternatives and AutoDesk
>> bashing without moderation as we are looking into some of the other ideas
>> that have come up.
>>
>> Cv/
>>
>> Sent from my Windows Phone. Yes I said windows phone.
>> 
>> From: Mihai Iliuta
>> Sent: 2014-03-07 6:22 PM
>> To: softimage@listproc.autodesk.com> autodesk.com>
>> Subject: Re: Listening
>>
>> "but maybe,with some of the element from the Softimage dev team,something
>> good could be done and maybe we'll see some huge improvement on Maya and
>> Max"
>>
>> You know, it would be interesting to know the thoughts of those
>> developers. How do they feel working for this company now? Especially ex
>> XSI devs. I would still like to think the talented people that create this
>> software do it because of passion, and that they truly care about their
>> product. I haven't seen any other 3D app come close to the thoughtfullness
>> that went into every aspect of XSI. And why I picked up within days of
>> trying it out. Everything else compared to it was clunky mess. You felt it
>> was created by artists, not accountants with no damn idea of ergonomics. To
>> see that kind of talent which created such software, be assimilated and
>> forgotten in the abysmal hole that is this company would be the saddest
>> thing of this whole mess.
>>
>> So, yes, what are the developers thinking right now would be interesting
>> to know
>>
>>
>> On Sat, Mar 8, 2014 at 12:05 AM, Nicolas Esposito <3dv...@gmail.com
>> > wrote:
>>
>> Hey Mihai,
>> >From one side its clear that they put one guy to explain a bit better
>> the transition situation and,of course,tale a bunch of shit because they
>> sure were expecting this
>>
>> If mr Vinneau want to still work for AD even if they are corporate
>> business who don't care at all about their customer I don't care that
>> much,is his decision,so if he get a check for all the shit I don't
>> care,because I strongly doubt that who pulled the plug on Softimage will
>> never go out public and say "I'm responsible for the shutdown of Softimage"
>>
>> What I would like to see however is one fo the AD CEO make a video for
>> the entire situation,and explain why greed is good (Wall Street reference
>> :-p )
>>
>> If we're talking about corporate aholes you would also keep your money
>> under the bed amd grow your own food
>>
>> Its business,Softimage never was the first choice for AD,we all know why
>> they bought it,and it was a matter of time
>>
>> What I meant abot the "big hit on subscription" was related to the fact
>> that,if they start to loose customers fast,maybe they'll start to do
>> something about the situation
>> Softimage wont be resurrected,but maybe,with some of the element from the
>> Softimage dev team,something good could be done and maybe we'll see some
>> huge improvement on Maya and Max
>> But they better do something quick,because everyone now realized what AD
>> is really aboutmoney money money
>>
>> Il 07/mar/2014 23:05 "Mihai Iliuta" mailto:mih
>> ai...@gmail.com>> ha scritto:
>>
>> Nicolas, I'm not sure I understand your position here. On one hand you're
>> saying:
>> "personal attacks to someone who's not responsable of the entire
>> situation is just wrong"
>>
>> on the other:
>> "but in this case I really hope that AD will receive a huge hit in
>> subscriptions and l'ora of developers switch to other companies,because
>> this is a really really bad decision"
>>
>> So on one hand, poor Mr Vienneau is not responsible, but you still wish
>> that eventually enough people will leave that AD goes bankrupt and
>> Mr.Vienneau looses his job.
>>
>> That's kind of more personal than my words :P And btw, I hope for t

Re: Retirement.....

[Enrique Caballero]

hopefully you all will stick around on this list, or move as a group. as
I've grown to rely on this mailing list whenever I've had trouble or needed
some advice. I don't think I could match this community if i tried.



On Wed, Mar 5, 2014 at 12:27 AM, Doeke Wartena  wrote:

> They should have included a free version for maya and max users years ago.
> That way the might have could sink another boat by now.
> I will switch in 2 years to modo or houdini.
>
> Sad softimage was sold to satan.
>
>
> 2014-03-04 17:24 GMT+01:00 Daniel H :
>
> Ok Ed. This is the stage I'm at.
>>
>> 10 LET denial = 1
>> 20 LET anger = 0
>> 30 GOTO 40
>> 40 IF denial = 1 THEN GOTO 50
>> 50 LET anger = anger + 1
>> 60 PRINT "HATE, HATE, HATE, BUT LOATHE AUTODESK ENTIRELY!"
>> 70 PRINT anger
>> 80 IF anger >= 1 THEN GOTO 50
>> 90 END
>>
>> You can paste it here: http://www.calormen.com/jsbasic/ It runs. :)
>>
>> Daniel
>> VFXM
>>
>>
>>
>> On Tue, Mar 4, 2014 at 9:36 AM, Ed Manning  wrote:
>>
>>> Stage 1 lasted nearly 5 years. It's only natural to spend a few days in
>>> stage 2.
>>>
>>>
>>> The stages, popularly known by the acronym *DABDA*, include:
>>>
>>>
>>
>

Re: Maya Questions: Ref Models/Resolutions in Soft vs. Ref Scenes/Assets/Assemblies in Maya

[Enrique Caballero]

this is very helpful thank you siew yi liang


On Tue, Mar 4, 2014 at 3:37 AM, Tim Crowson
wrote:

>  Thanks! That's actually the kind of info I'm looking for. Would love to
> hear what anyone else has to add!
> -Tim
>
>
> On 3/3/2014 1:17 PM, Siew Yi Liang wrote:
>
> In Maya, file referencing is handled via namespace: nodes are prefixed
> with a colon indicating their namespace.
>
> For example, a node with parentNamespace:nodeName indicates that it
> belongs to the parentNamespace namespace. There is no concept of
> encapsulation like XSI's Model system. This is both good and bad. Good
> because it lets you make a lot of edits to references that would otherwise
> have been impossible in XSI (re-parenting rigs' hierarchy etc. and having
> those changes not break the rig). Bad because...you never know when a
> change WILL break stuff due to Maya not being able to reconcile your edits.
> (It's a little complicated, so I would advise reading up on referenceEdits
> and the fosterParent node in Maya.)
>
> Edits made to references are stored in a referenceEdit node and connected
> to them whenever the scene is loaded. They are equivalent to XSI's Deltas,
> but have their own quirks to deal with...
>
> Maya does not support UNC file paths afaik. Instead, if you open any .ma
> file with references, you will see things like:
>
> file -rdi 1 -ns "shark" -rfn "rig_shark_proxyRN"
> "C:/Users/j.zoepfl/Desktop/goochy/production/maya/goochyMayaProject//scenes/rigs/
> rig_shark.ma";
>
> the double slash before //scenes will tell Maya to use the currently
> defined project location to replace everything before it. This is a crucial
> detail when you send your scenes to renderfarms/run scripts/all sorts of
> things, really. It's a little annoying how the namespace system works, but
> as long as you're aware of it, you should be fine.
>
> While it is possible, I would not do references-within-references. They
> are extremely prone to having problems with re-connecting referenceEdits,
> in my experience, especially with regards to animation. I still haven't
> figured out why...
>
> Scene Assemblies, however, are a fairly recent addition, being only added
> to 2013 SAP1 and onwards. As such, they are not as widely used in pipelines
> (including my current project, as I mandated that we use 2013 SP2. Welcome
> to fragmentation between versions ;) ) However, they provide a quick and
> cheap way to handle a lot of references and their LOD modes in your
> viewport, if you don't have a TD on hand to make an alternative control to
> handle proxies for your referenced models. They still use the same
> reference system underlying concept, however, so you should be fully aware
> of how that works before you use SA features.
>
> Obviously I will not pretend that this is the workflow used in all studios
> (as far as I'm aware most game studios just use maya references and nothing
> else) but maybe someone in more complicated projects can help correct me,
> I'm always curious as to how pros do it as well. :D
>
> Sorry for the long post! Tried to summarize what I've found best workflow
> so far!
>
> Yours sincerely,
> Siew Yi Liang
>
> On 3/3/2014 9:34 AM, Tim Crowson wrote:
>
> I should add quickly that we're not jumping the gun on anything here. We
> plan to stick with Soft for the foreseeable future. I'm just trying to
> educate myself, and I'd rather do it sooner than later!
> -Tim
>
> On 3/3/2014 11:32 AM, Tim Crowson wrote:
>
> So with all this jibba-jabba about R.I.P. Soft and
> 'Better-start-planning-to-move' language, I figured I should brush up on
> the latest Maya changes to see what's new. First of all, I'm glad to see
> NEX was finally integrated. That's a big deal in my book. But I was also
> curious about Scene Assemblies in Maya, and the relationships between
> Referenced Scenes, Assets, and Scene Assemblies. At first glance, Scene
> Assemblies seem to be similar to our Referenced Models with Resolutions. We
> use Referenced Models a lot in our pipeline, and I'm curious to hear from
> those of you who have been exposed to the Maya side of life 1) how can we
> best translate our referenced model workflow into Maya and 2) how might we
> improve upon it given the different paradigm of scene referencing?* I
> realize this is a very pipeline-specific question*, but I'm curious to
> get more down-to-earth details from guys in the trenches about the
> interplay between Scene Referencing, Assets, and Scene Assemblies.
>
> --
>
>
>
>
> *Tim Crowson **Lead CG Artist*
>
>
> *Magnetic Dreams, Inc. *2525 Lebanon Pike, Bldg C, Suite 101, Nashville,
> TN 37214
> *Ph*  615.885.6801 | *Fax*  615.889.4768 | www.magneticdreams.com
> tim.crow...@magneticdreams.com
>
> *Confidentiality Notice: This email, including attachments, is
> confidential and should not be used by anyone who is not the original
> intended recipient(s). If you have received this e-mail in error please
> inform the sender and delete it from your mailbox or any other stora

Re: ICE migration thread. no tears here )))

[Enrique Caballero]

i agree completely, i just had never put it into words before. thats
exactly right.

softimage feels like its crafted. not slapped together.  in many ways its
the best designed package ive ever used


On Sun, Mar 2, 2014 at 9:57 PM, Stefan Kubicek  wrote:

>  It's not solely features I'm looking for, it's paradigms I'm interested
> in. When I discovered Softimage XSI for me (version 4, long before ICE)
> it wasn't feature complete by a long shot, neither compared to Maya or
> Max, but it had the freshest concepts, concepts that  I considered
> forward-looking and long-lasting, especially in terms of usability. And the
> company/team developing it managed to display the right attitude - by the
> way they communicated with their community and the way they approached and
> imlemented new features, and improved existing features (even rewriting
> whole portions of the software when design flaws became too obvious). I
> don't see such concepts and attitude in Maya's development atm, but I can
> see them more and more in Houdini and even Modo to a certain degree. It's
> not what they can do right now, more what they most likely will be capable
> of doing the future when they keep following their general direction of
> development.
> As for replacing ICE in particular, I will be looking more into Houdini in
> the future (I always wanted to and never had a good excuse), and above all
> FE.
>
> checking the expansive list of new features on latest Houdini release...
> this is what all releases should be like :P
>
>
> On 1 March 2014 17:20, Enrique Caballero wrote:
>
>> Houdini.  SideFX has been a pleasure to deal with and they are still
>> innovating and being competitive.  I'll also keep a close eye on Fabric,
>> although I suspect I'm not a good enough coder to be great at it
>>
>>
>>
>> On Sat, Mar 1, 2014 at 11:51 PM, olivier jeannel > > wrote:
>>
>>>  If I'd had to change, I might have a look at C4D Expresso thing. I
>>> think it's close to TP. I wonder if it is that different (in phylosophy)
>>> from Ice.
>>> Houdini is tempting as well, but as mentionned before I'm a bit affraid
>>> of the "exclusive" aspect of it, no modeling or rigging. Need a software
>>> for the every day common things.
>>>
>>>
>>>
>>> Le 01/03/2014 16:12, Francisco Criado a écrit :
>>>
>>> Sorry for the noise in last mail, just wanted to add a coment to Paul's
>>> question.
>>> A future without ice? i think best two choices are Houdini or Fabric
>>> Engine, the second one is more open to other software, not like houdini.
>>>
>>>  F.
>>>
>>>
>>> On Saturday, March 1, 2014, Nika Ragua  wrote:
>>>
>>>>  aha, great, more opinions !!! and its great that a more human-like
>>>> thoughts started to appear,actually i started to regret when i saw all this
>>>> EFFECTIVENESS,POSSIBILITIES,
>>>>  INDUSTRY posts - c`mon guys , not everybody are beasts with universe
>>>> in mind - what about the ones like you and me - little guys, nothing
>>>> global, just write the button
>>>> to fix the lopsided stuff, everyday routine, add a little nice feature
>>>> and so on
>>>>
>>>>
>>>> 2014-03-01 5:45 GMT+04:00 Francisco Criado :
>>>>
>>>> I think that exist on the softimage market, or better on the 3d market
>>>> a lot of artists that have technical tendence but not a drop of programming
>>>> knowledge and ice in my case was exactly the door for "playing and
>>>> learning" without the frustration in scrpting and going wrong.Even ice was
>>>> the portal for make me curious about programming.
>>>> houdini? didn't like the ui, and based on my xsi experience ui makes
>>>> the difference ;)
>>>> If you find that spot Paul, i want a seat.
>>>> Sorry for my english!
>>>>
>>>> F.
>>>>
>>>>
>>>> On Friday, February 28, 2014, Paul Doyle  wrote:
>>>>
>>>> Just to get the thread on track a bit (sort of) - would people share
>>>> what it is they like/dislike about ICE (or any other visual programming
>>>> system)? My experience is there are often two camps: one group that are not
>>>> programmers (not even python), so ICE gives them a level of customization
>>>> previously closed to them. The other group like the emergent/tinkering
>>>> behaviour that node systems provide. 

Re: ICE migration thread. no tears here )))

[Enrique Caballero]

Houdini.  SideFX has been a pleasure to deal with and they are still
innovating and being competitive.  I'll also keep a close eye on Fabric,
although I suspect I'm not a good enough coder to be great at it



On Sat, Mar 1, 2014 at 11:51 PM, olivier jeannel wrote:

>  If I'd had to change, I might have a look at C4D Expresso thing. I think
> it's close to TP. I wonder if it is that different (in phylosophy) from Ice.
> Houdini is tempting as well, but as mentionned before I'm a bit affraid of
> the "exclusive" aspect of it, no modeling or rigging. Need a software for
> the every day common things.
>
>
>
> Le 01/03/2014 16:12, Francisco Criado a écrit :
>
> Sorry for the noise in last mail, just wanted to add a coment to Paul's
> question.
> A future without ice? i think best two choices are Houdini or Fabric
> Engine, the second one is more open to other software, not like houdini.
>
>  F.
>
>
> On Saturday, March 1, 2014, Nika Ragua  wrote:
>
>>  aha, great, more opinions !!! and its great that a more human-like
>> thoughts started to appear,actually i started to regret when i saw all this
>> EFFECTIVENESS,POSSIBILITIES,
>>  INDUSTRY posts - c`mon guys , not everybody are beasts with universe in
>> mind - what about the ones like you and me - little guys, nothing global,
>> just write the button
>> to fix the lopsided stuff, everyday routine, add a little nice feature
>> and so on
>>
>>
>> 2014-03-01 5:45 GMT+04:00 Francisco Criado :
>>
>> I think that exist on the softimage market, or better on the 3d market a
>> lot of artists that have technical tendence but not a drop of programming
>> knowledge and ice in my case was exactly the door for "playing and
>> learning" without the frustration in scrpting and going wrong.Even ice was
>> the portal for make me curious about programming.
>> houdini? didn't like the ui, and based on my xsi experience ui makes the
>> difference ;)
>> If you find that spot Paul, i want a seat.
>> Sorry for my english!
>>
>> F.
>>
>>
>> On Friday, February 28, 2014, Paul Doyle  wrote:
>>
>> Just to get the thread on track a bit (sort of) - would people share what
>> it is they like/dislike about ICE (or any other visual programming system)?
>> My experience is there are often two camps: one group that are not
>> programmers (not even python), so ICE gives them a level of customization
>> previously closed to them. The other group like the emergent/tinkering
>> behaviour that node systems provide. I'm just wondering if the 'where do we
>> go next?' question is going to vary between those two sets.
>>
>>
>> On 28 February 2014 17:09, Emilio Hernandez  wrote:
>>
>>  I consider my work serious film work also.  Maybe not as that as
>> complex as  Elysium or so,  but some time TV commercials are more time
>> demanding for the time you have to deliver.  You need to work faster,  with
>> lower prices and deliver the same quality as "serious film work".
>>
>>  I will not be changing to Maya only because "serious film work" is done
>> by a big studio.
>>
>>
>>
>>
>>
>>
>>
>>
>> 2014-02-28 16:00 GMT-06:00 Sebastien Sterling <
>> sebastien.sterl...@gmail.com>:
>>
>>  All that beautiful Studio Nest stuff sigh, no no ...kids games :P
>>
>>
>> On 28 February 2014 22:57, Emilio Hernandez  wrote:
>>
>>  Hey Eric you meant if Softimage disappears right?
>>
>>  Serious film work is very ambigous, don't you think?  What is "serious"
>> film work.  Only the big studios and the guys that outsorce when a big
>> production is going on?
>>
>>
>>
>>
>>
>>
>> 2014-02-28 15:51 GMT-06:00 Nika Ragua :
>>
>>  emmm...no no no, i meant the ICE-natural TDs - people like me, who can
>> exist only in visual programming environment and can`t(don`t want) to code
>>
>>
>>  2014-03-01 1:47 GMT+04:00 Mirko Jankovic :
>>
>>  On the other hand I found both rigging and animation in Maya makes me
>> vomit. But that may be due to fact that never mastered rigging in Maya
>> myself as after trying it in SI it was whole new world.
>> As for animation... ALL rigs I ever had to work with in Maya were made by
>> riggers that should better stay away from any rigging at all. Half-riggers
>> that makes half done, bad rigs that breaks and brings any comp to crawl
>> with like 4fps playback.
>> So unless you have like master rigger at hand.. don't count on good
>> animation in Maya.
>> And trust me most of small to medium studios and freelancers don't have
>> access to good rigger. And that is when nightmare starts and never ends
>>
>>
>> On Fri, Feb 28, 2014 at 10:41 PM, Eric Thivierge 
>> wrote:
>>
>>
>>
>

Re: GEar again

[Enrique Caballero]

yep i agree, dont let the modeling department dictate what your neutral
pose is.  that can lead to expensive issues down the line


On Sat, Feb 22, 2014 at 12:25 AM, Matt Morris  wrote:

> You kick it back to the modelling department and tell them to make the
> hands in line with the forearm.
>
> Seriously ;)
>
>
> On 21 February 2014 16:20, Szabolcs Matefy  wrote:
>
>> Ok, you must annoyed, but...
>>
>>
>>
>> How can I set a different hand orientation? I mean, now the arm plane
>> defines the orientation of the hand, and thanks to the character artists,
>> they invented some idiot pose for the arms and hands that is quite
>> impossible to rig normally (just for visualize the issue. Stand up, drop
>> your arm. When your hand is quite relaxed, raise your hand only, trying to
>> maintain a more or less 45 degree angle between your arm and body. Now,
>> move your hand closer to your body along an imaginary line between your
>> wrist and shoulder, but maintain the hand orientation (the back of the hand
>> points about the sky, no tilt, no pitch. If you are doing it fine, your
>> elbow start to drop. Now that's the pose I need to rig)
>>
>>
>>
>> So how can I do it with Gear, where the hand orientation is achieved
>> apparently from the arm's IK resolution plane?
>>
>>
>>
>>
>>
>> Cheers
>>
>>
>>
>>
>> Szabolcs
>> ___
>> This message contains confidential information and is intended only for
>> the individual named. If you are not the named addressee you should not
>> disseminate, distribute or copy this e-mail. Please notify the sender
>> immediately by e-mail if you have received this e-mail by mistake and
>> delete this e-mail from your system. E-mail transmission cannot be
>> guaranteed to be secure or error-free as information could be intercepted,
>> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
>> The sender therefore does not accept liability for any errors or omissions
>> in the contents of this message, which arise as a result of e-mail
>> transmission. If verification is required please request a hard-copy
>> version. Crytek GmbH - http://www.crytek.com - Grüneburgweg 16-18, 60322
>> Frankfurt - HRB77322 Amtsgericht Frankfurt a. Main- UST IdentNr.:
>> DE20432461 - Geschaeftsfuehrer: Avni Yerli, Cevat Yerli, Faruk Yerli
>>
>
>
>
> --
> www.matinai.com
>

Re: Survey - how would you do this?

[Enrique Caballero]

id go with what jeffrey said, but that doesnt protect against collisions.

honestly, im using ICE alot with Unity. No biggy,

If your working with a pointcloud, just take that data along with ice
kinematics, and plot the information out onto the actual assets. then
export to the game. I think you can still use ice and then just bake that
out to a game


On Wed, Feb 12, 2014 at 11:37 PM, Jeffrey Dates wrote:

> Hmm..  I don't know why.. I must not understand the challenge.  How I'd do
> it is:
>
> 1) duplicate your astroid(s)  ( in this case not instances for
> art-direction )  # of times you want.
> 2) select all, and path constrain to a Circle Curve. ( roughly 40 units )
> 3) Multi-select their constraint, and set the length to r(0,100)
> 4) Then set the translation along the bias, and normal to be r(-5,5)
>  you'll have to play with the values to get a proper dispersion.
> 5) now you have a ring of astroids randomly distributed along a torus.
>
> You can animate the ring to get them all moving.
> You can set keys using the random property...
>
> *shrug*  I must not fully understand the problem.
>
>
> On Tue, Feb 11, 2014 at 2:23 PM, Matt Lind wrote:
>
>> An artist came to my desk yesterday asking how to do what I felt was a
>> simple task, but after getting 80% through it I ran into a speed bump
>> realizing it needed custom scripting or other advanced tools to fully
>> resolve to satisfaction.  I had to give him a procedure that was 'good
>> enough'.  This problem has multiple solutions, but I am curious how others
>> would solve it:
>>
>>
>>
>> The problem:
>>
>>
>>
>> Artist must create an asteroid belt around a planet.  The asteroids are
>> likely 2D sprites which must face the camera and tumble as they orbit, but
>> could be 3D objects as well.  Asteroids must vary in size, shape, and
>> animation speed (linear as well as rotational).  Asteroids cannot collide
>> with anything.  Movement is generally slow - like a screen saver for your
>> computer desktop.  Asteroid positions are jittered within the belt.
>>
>>
>>
>> The question:
>>
>>
>>
>> Dispersing objects into a ring is fairly straightforward through a number
>> of techniques, but how do you apply the random jitter to the object
>> positions?
>>
>>
>>
>> The rules:
>>
>>
>>
>> -  Cannot use ICE
>>
>> -  Cannot use custom scripts, custom operators, or shaders.
>>
>> -  Must only use tools out of the box that a junior or staff
>> level artist would know how to use.
>>
>> -  Must be able to create the asteroid belt, from scratch to
>> completion, in less than 30 minutes - and be iteration friendly to react to
>> art director feedback.
>>
>> -  Ideally, the belt could be made a child of the planet in
>> encompasses so it can be reoriented with respect to changes in the planet's
>> size/shape/tilt/orbit.
>>
>> -  Final output must be able to exist with full integrity on its
>> own in a vacuum.  Cannot not have dependencies on custom code, external
>> assets, or special case logic.
>>
>> -  Asteroid belt fits within the default grid as seen in the
>> scene camera.  Think torus with diameter 40 SI units, and cross section of
>> roughly 3 SI Units diameter
>>
>>
>>
>>
>>
>> Ready.GO!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Matt
>>
>
>

Re: Gear Head question

[Enrique Caballero]

the head or chest curve icons that live above your character i meant to type


On Fri, Feb 7, 2014 at 2:45 PM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> im pretty sure that option already lives under your anim setup property
> page.  just select the head or chest and press f3, open up the property
> page. there are like 4 different orientation options already built in
>
>
> On Thu, Feb 6, 2014 at 7:05 PM, Szabolcs Matefy wrote:
>
>> Hey Gear riggers
>>
>>
>>
>> So I have a cartoony character, and we'd like to have few options when
>> animating the spine
>>
>>
>>
>> 1.   The head and neck follows the movement of the spine
>>
>> 2.   The neck follows the movement of the spine, but keeps
>> orientation to the world
>>
>>
>>
>>
>>
>> Option 1st is achieved easily, but 2nd seems to be tricky. The neck
>> effector stays in place, so the neck is bending in the opposite direction
>> as the spine, and it looks terrible...
>>
>>
>>
>>
>>
>> Any idea?
>>
>>
>>
>>
>>
>>
>>
>> Cheers
>>
>>
>>
>>
>>
>> Szabolcs
>>  ___
>> This message contains confidential information and is intended only for
>> the individual named. If you are not the named addressee you should not
>> disseminate, distribute or copy this e-mail. Please notify the sender
>> immediately by e-mail if you have received this e-mail by mistake and
>> delete this e-mail from your system. E-mail transmission cannot be
>> guaranteed to be secure or error-free as information could be intercepted,
>> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
>> The sender therefore does not accept liability for any errors or omissions
>> in the contents of this message, which arise as a result of e-mail
>> transmission. If verification is required please request a hard-copy
>> version. Crytek GmbH - http://www.crytek.com - Grüneburgweg 16-18, 60322
>> Frankfurt - HRB77322 Amtsgericht Frankfurt a. Main- UST IdentNr.:
>> DE20432461 - Geschaeftsfuehrer: Avni Yerli, Cevat Yerli, Faruk Yerli
>>
>
>

Re: Gear Head question

[Enrique Caballero]

im pretty sure that option already lives under your anim setup property
page.  just select the head or chest and press f3, open up the property
page. there are like 4 different orientation options already built in


On Thu, Feb 6, 2014 at 7:05 PM, Szabolcs Matefy wrote:

> Hey Gear riggers
>
>
>
> So I have a cartoony character, and we'd like to have few options when
> animating the spine
>
>
>
> 1.   The head and neck follows the movement of the spine
>
> 2.   The neck follows the movement of the spine, but keeps
> orientation to the world
>
>
>
>
>
> Option 1st is achieved easily, but 2nd seems to be tricky. The neck
> effector stays in place, so the neck is bending in the opposite direction
> as the spine, and it looks terrible...
>
>
>
>
>
> Any idea?
>
>
>
>
>
>
>
> Cheers
>
>
>
>
>
> Szabolcs
> ___
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message, which arise as a result of e-mail
> transmission. If verification is required please request a hard-copy
> version. Crytek GmbH - http://www.crytek.com - Grüneburgweg 16-18, 60322
> Frankfurt - HRB77322 Amtsgericht Frankfurt a. Main- UST IdentNr.:
> DE20432461 - Geschaeftsfuehrer: Avni Yerli, Cevat Yerli, Faruk Yerli
>

Re: Re[2]: Set Dressing Tool Ideas

[Enrique Caballero]

Thanks everyone,
  I tried Vue for a few hours, it was impressive, but decided not to go
with it, due to stability issues and user friendliness.  Plus I rather not
go to my boss and ask him for 2k for the program.

I don't think the actual foliage scattering is that hard to replicate with
ICE.

For now i have gone with a combination of Dart Throw and Scatter tools to
give me most of the control that I need.  Actually its pretty nice so far

With some minor adjustments and some scripting to make the process easier I
think its actually a pretty decent system to get us some quick set dressing
of forests and bushes etc...




On Mon, Feb 3, 2014 at 8:02 PM, Eugen Sares  wrote:

>  Ozone... good for generating some HDR skies, but the connection plugin
> for Soft is crappy. Can crash on load or save, is modal... handle with
> care, if at all.
>
>
> -- Originalnachricht --
> Von: "Stefan Kubicek" 
> An: softimage@listproc.autodesk.com
> Gesendet: 03.02.2014 12:55:56
> Betreff: Re: Set Dressing Tool Ideas
>
>
> If you want to save yourself some major headaches I recommend keeping your
> hands off of Vue and related products (e.g. Ozone, Carbon Scatter).
> I and others I know have given it a shot in the past repeatedly and every
> single time were turned off by poor stability.
> I've heard better things of Terragen, but I admit I have never used it.
>
>
>  Thanks Nick and Jordi,
>   I will check out scatter tools now.
>
> Jordi I agree completely with what you say, and at One Animation I usually
> only get about 1 to 2 weeks to develop anything. So I am very willing to
> try an out of box solution.
>
> I started playing with Vue Extreme today,  it seems pretty powerful, but
> wow its not enjoyable at all to use,  I will keep experimenting with it
> until i understand it better.
>
> I will also try world builder now thanks to your recommendation.
>
> -E
>
>
> On Sat, Feb 1, 2014 at 10:55 PM, Jordi Bares  wrote:
>
>> Very impressive tools.. :-) Sill amazed by what people produce with ICE
>>
>>  Jordi Bares
>> jordiba...@gmail.com
>>
>>  On 1 Feb 2014, at 11:58, Nick Angus  wrote:
>>
>>   Milan Vasek's Scatter Tools are my best friend when it comes to this
>> sort of stuff. https://vimeo.com/36612233
>> He has created some pretty astounding imagery with them also
>> http://www.milanvasek.com/?p=355
>>
>> More advanced stuff that uses libraries of assets would have been used by
>> the folks at Whiskytree, Steve Caron might be able to elaborate.
>> But if you combine Scatter tools with Arnold instancing you pretty much
>> have the best solution out of the box in my opinion.
>>
>> Cheers, Nick
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:softimage-
>> boun...@listproc.autodesk.com] *On Behalf Of *Enrique Caballero
>> *Sent:* Saturday, 1 February 2014 3:50 PM
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Set Dressing Tool Ideas
>>
>>  Hey everyone,
>>I was hoping to pick your brains.
>>
>>
>> I am currently doing some research on how to simplify, and make cheaper
>> our set dressing process over at this small shop that I work at.
>>
>>  In the old days, when we did small simple shows, set dressing wasn't
>> very difficult for us as there were limited amounts of props and
>> environment pieces.  We would just import referenced models and place them
>> by hand/
>>
>>  But now that we do full forests and large amounts of rocks and plant
>> life, we need to upgrade our techniques. As our original techniques are no
>> longer sufficient.
>>
>>
>>
>>  I am looking at how ICE can help us with the initial set dressing.
>>  Maybe by painting weight maps we can spawn different types of mushrooms
>> and trees etc.
>>
>>
>>  I am currently experimenting with Dart Throw, and it looks very
>> promising. Thanks Julian!
>>
>>  Although I need to figure out how to get it to switch between different
>> geo types, IE. Trees, mushrooms, etc.  Currently I can only get it to spawn
>> one geo type at a time.
>>
>>  I was wondering if anyone had any ideas about how we could simplify
>> this stuff,  as I said before, currently I am looking at Dart throw and
>> ABScatter to see if they can help us out, but I am open minded.  Has anyone
>> tried Vue Studio or anything similar that they can recommend?
>>
>>  best,
>>  Enrique
>>
>>
>>
>
>
>
>  --
> ---
> Stefan Kubicek
> ---
> keyvis digital imagery
> Alfred Feierfeilstraße 3
> A-2380 Perchtoldsdorf bei Wien
> Phone: +43/699/12614231
> www.keyvis.at ste...@keyvis.at
> -- This email and its attachments are --
> --confidential and for the recipient only--
>
>
>
> --
><http://www.avast.com/>
>
> Diese E-Mail ist frei von Viren und Malware, denn der avast! 
> Antivirus<http://www.avast.com/>Schutz ist aktiv.
>
>

Re: Set Dressing Tool Ideas

[Enrique Caballero]

Thanks Nick and Jordi,
  I will check out scatter tools now.

Jordi I agree completely with what you say, and at One Animation I usually
only get about 1 to 2 weeks to develop anything. So I am very willing to
try an out of box solution.

I started playing with Vue Extreme today,  it seems pretty powerful, but
wow its not enjoyable at all to use,  I will keep experimenting with it
until i understand it better.

I will also try world builder now thanks to your recommendation.

-E


On Sat, Feb 1, 2014 at 10:55 PM, Jordi Bares  wrote:

> Very impressive tools.. :-) Sill amazed by what people produce with ICE
>
> Jordi Bares
> jordiba...@gmail.com
>
> On 1 Feb 2014, at 11:58, Nick Angus  wrote:
>
> Milan Vasek's Scatter Tools are my best friend when it comes to this sort
> of stuff. https://vimeo.com/36612233
> He has created some pretty astounding imagery with them also
> http://www.milanvasek.com/?p=355
>
> More advanced stuff that uses libraries of assets would have been used by
> the folks at Whiskytree, Steve Caron might be able to elaborate.
> But if you combine Scatter tools with Arnold instancing you pretty much
> have the best solution out of the box in my opinion.
>
> Cheers, Nick
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:softimage-
> boun...@listproc.autodesk.com] *On Behalf Of *Enrique Caballero
> *Sent:* Saturday, 1 February 2014 3:50 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Set Dressing Tool Ideas
>
> Hey everyone,
>   I was hoping to pick your brains.
>
>
> I am currently doing some research on how to simplify, and make cheaper
> our set dressing process over at this small shop that I work at.
>
> In the old days, when we did small simple shows, set dressing wasn't very
> difficult for us as there were limited amounts of props and environment
> pieces.  We would just import referenced models and place them by hand/
>
> But now that we do full forests and large amounts of rocks and plant life,
> we need to upgrade our techniques. As our original techniques are no longer
> sufficient.
>
>
>
> I am looking at how ICE can help us with the initial set dressing.  Maybe
> by painting weight maps we can spawn different types of mushrooms and trees
> etc.
>
>
> I am currently experimenting with Dart Throw, and it looks very promising.
> Thanks Julian!
>
> Although I need to figure out how to get it to switch between different
> geo types, IE. Trees, mushrooms, etc.  Currently I can only get it to spawn
> one geo type at a time.
>
> I was wondering if anyone had any ideas about how we could simplify this
> stuff,  as I said before, currently I am looking at Dart throw and
> ABScatter to see if they can help us out, but I am open minded.  Has anyone
> tried Vue Studio or anything similar that they can recommend?
>
> best,
> Enrique
>
>
>

Set Dressing Tool Ideas

[Enrique Caballero]

Hey everyone,
  I was hoping to pick your brains.


I am currently doing some research on how to simplify, and make cheaper our
set dressing process over at this small shop that I work at.

In the old days, when we did small simple shows, set dressing wasn't very
difficult for us as there were limited amounts of props and environment
pieces.  We would just import referenced models and place them by hand/

But now that we do full forests and large amounts of rocks and plant life,
we need to upgrade our techniques. As our original techniques are no longer
sufficient.



I am looking at how ICE can help us with the initial set dressing.  Maybe
by painting weight maps we can spawn different types of mushrooms and trees
etc.


I am currently experimenting with Dart Throw, and it looks very promising.
Thanks Julian!

Although I need to figure out how to get it to switch between different geo
types, IE. Trees, mushrooms, etc.  Currently I can only get it to spawn one
geo type at a time.

I was wondering if anyone had any ideas about how we could simplify this
stuff,  as I said before, currently I am looking at Dart throw and
ABScatter to see if they can help us out, but I am open minded.  Has anyone
tried Vue Studio or anything similar that they can recommend?

best,
Enrique

Re: Importing of Models Deathly Slow

[Enrique Caballero]

I found the problem.


While going through the process of going through the list you supplied, I
found the major source of the problem.

For some reason the eyelid geometry was slowing down things when I would
switch rig resolutions.

I set up a test scene with 2 identical rigs in each resolution slot,  1 and
2.

I would switch the resolutions back and forth and time it.

there was no delta, undo's set to 0, and the rig was in the neutral pose,
and the rigs were stored locally on the machine, so that network lag could
not be a factor.

It was 96 seconds to switch resolutions.

I took the eyelid geometry, exported it out as OBJ, reimported it,
reapplied its ICETrees and Weightmaps by hand, and then tried again

now its 21 seconds to switch resolution. Still a bit slow, but at least
bareable.  I will keep trying to make it faster but at least this was the
major culprit.

I suppose that the original eyelid GEO was made a very long time ago.
Possible even in Softimage 2010.

I am now going to script this across all of the rigs, and update the
geometry for every piece that I can.

Sadly we don't really have a rig building system here, so we can't easily
rebuild a character rig when we update versions of Softimage, every now and
again some geometry goes bad for some reason.

With our very limited resources I don't really think I can get a rig
building system up and running here in any decent time.  I will probably
look into retrofitting gear to work more comfortably in our pipeline, and
hopefully I can rely on that.


Thanks for everything Matt, your list was massively helpful and it gave me
a lot of food for thought.





On Thu, Jan 30, 2014 at 12:22 PM, Matt Lind wrote:

> The litmus test would be to compare FCurves being loaded directly on the
> parameters vs. those applied from a source such as a mixer source.  If the
> raw FCurve parameters take a long time while the mixer source loads
> instantly, then you have a smoking gun.  Otherwise, it's not that.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Enrique Caballero
> *Sent:* Wednesday, January 29, 2014 8:20 PM
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Importing of Models Deathly Slow
>
>
>
> ... this sounds very likely.
>
>
>
> i will test now.
>
>
>
> great stuff, thank you
>
>
>
> On Thu, Jan 30, 2014 at 12:14 PM, Matt Lind 
> wrote:
>
> If switching resolutions is the issue, consider if there is FCurve
> animation data being loaded onto parameters in the model.
>
>
>
> There is a known issue in 2013 with generation of FCurve data taking
> ridiculously long (5000% longer - no exaggeration).  I had to write a C++
> command to work around the problem as our imports were taking forever.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Enrique Caballero
> *Sent:* Wednesday, January 29, 2014 8:09 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Importing of Models Deathly Slow
>
>
>
> Matt your awesome,
>
>  Thanks for all of the information, I am checking everything on the list
> now.
>
>
>
> I've just discovered that if i load a model in using the import menu, or
> via scripting it takes 7 seconds, but if i drag and drop it in, it takes 46
> seconds for some reason.
>
>
>
> Not a big deal that one though.
>
>
> It seems the real heavy toll is taken when we switch model resolutions.
>
>
>
> Importing a vanilla referenced model takes about 7 seconds with no delta
> changes.
>
>
>
> Switching that same referenced model to another resolution, with no
> significant entries in the model delta, takes about 45 seconds.
>
>
>
> The resolutions that im switching to and from are both animation rigs,
> very light,  and the delta has basically nothing in it
>
>
>
> Anyway I'll play around with it. And test against all of your suggestions.
> Thanks alot :)
>
>
>
> -E
>
>
>
> On Thu, Jan 30, 2014 at 11:53 AM, Matt Lind 
> wrote:
>
> We're using 2013 SP1 (32 bit) and not experiencing any deathly slow
> imports.  We have environments with 5,000+ referenced models, and while
> they do take a while to open because of their size, nothing along the lines
> of what you're reporting.
>
>
>
> I would check a few things that have caused us grief in the past:
>
>
>
> 1) Lights: for whatever reason if a model has a light and is imported into
> a scene as a referenced model, performance slows dramatica

Re: Importing of Models Deathly Slow

[Enrique Caballero]

... this sounds very likely.

i will test now.

great stuff, thank you


On Thu, Jan 30, 2014 at 12:14 PM, Matt Lind wrote:

> If switching resolutions is the issue, consider if there is FCurve
> animation data being loaded onto parameters in the model.
>
>
>
> There is a known issue in 2013 with generation of FCurve data taking
> ridiculously long (5000% longer - no exaggeration).  I had to write a C++
> command to work around the problem as our imports were taking forever.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Enrique Caballero
> *Sent:* Wednesday, January 29, 2014 8:09 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Importing of Models Deathly Slow
>
>
>
> Matt your awesome,
>
>  Thanks for all of the information, I am checking everything on the list
> now.
>
>
>
> I've just discovered that if i load a model in using the import menu, or
> via scripting it takes 7 seconds, but if i drag and drop it in, it takes 46
> seconds for some reason.
>
>
>
> Not a big deal that one though.
>
>
> It seems the real heavy toll is taken when we switch model resolutions.
>
>
>
> Importing a vanilla referenced model takes about 7 seconds with no delta
> changes.
>
>
>
> Switching that same referenced model to another resolution, with no
> significant entries in the model delta, takes about 45 seconds.
>
>
>
> The resolutions that im switching to and from are both animation rigs,
> very light,  and the delta has basically nothing in it
>
>
>
> Anyway I'll play around with it. And test against all of your suggestions.
> Thanks alot :)
>
>
>
> -E
>
>
>
> On Thu, Jan 30, 2014 at 11:53 AM, Matt Lind 
> wrote:
>
> We're using 2013 SP1 (32 bit) and not experiencing any deathly slow
> imports.  We have environments with 5,000+ referenced models, and while
> they do take a while to open because of their size, nothing along the lines
> of what you're reporting.
>
>
>
> I would check a few things that have caused us grief in the past:
>
>
>
> 1) Lights: for whatever reason if a model has a light and is imported into
> a scene as a referenced model, performance slows dramatically.
>
>
>
> 2) Model delta:   If users have manipulated many parameters within a
> model, that will load up the delta property with many logged entries which
> you can think of as a pseudo construction history.  The more entries, the
> more overhead you will have with referenced models.  When a user does
> something, then undo's it, the end result will be correct, but an entry
> will be recorded for the modification, then another entry for the undo
> operation to undo it.  Double the fun.  I'd look for those entries and
> delete both instances to lighten the load.
>
>
>
> If the models aren't intended to be modified once referenced, for example,
> they're only placed in an environment.  Then there is no reason for the
> delta to be loaded with many parameter entries.  That's a sign of a user
> improperly selecting and moving the model around.  For example, selecting
> the objects in multi-mode and dragging them into position as a set which
> would record 3 parameters for each object, instead of middle clicking to
> select the model and move it as a branch selection which records a total of
> 3.
>
>
>
> 3) Operators:  look for performance intensive operators such as the
> Tangents operator used for baking normal maps with ultimapper.  Any
> operator which modifies clusterproprety data on sample clusters (UV, Vertex
> Color, User normal) will be very computationally expensive.
>
>
>
> 4) Undo history:  Default is 50.  In the old days we got away with 10.
> The more undo's you have the more memory you consume and the more work
> Softimage has to do with updating the stack when each action is performed.
> Shouldn't be an issue with your scenes, but doesn't hurt to check by
> setting undo history to zero, then load the scene.
>
>
>
> 5) Events:  I found this one the hard way.  If you have any events to
> process the scene when importing or exporting a file (eg;
> siOnBeginFileImport, siOnEndFileImport, siOnBeginSceneLoad,
> siOnBeginSceneSave, siOnEndSceneSave, ...) it might be getting triggered when
> a model is loaded as a referenced model.  Softimage treats loading of a
> model as a file import regardless of context.  So whether you're importing
> the model, loading a scene, fabricating a new referenced model, updating
> referenced model in the scene, etc...  so

Re: Importing of Models Deathly Slow

[Enrique Caballero]

Matt your awesome,
 Thanks for all of the information, I am checking everything on the list
now.

I've just discovered that if i load a model in using the import menu, or
via scripting it takes 7 seconds, but if i drag and drop it in, it takes 46
seconds for some reason.

Not a big deal that one though.

It seems the real heavy toll is taken when we switch model resolutions.

Importing a vanilla referenced model takes about 7 seconds with no delta
changes.

Switching that same referenced model to another resolution, with no
significant entries in the model delta, takes about 45 seconds.

The resolutions that im switching to and from are both animation rigs, very
light,  and the delta has basically nothing in it

Anyway I'll play around with it. And test against all of your suggestions.
Thanks alot :)

-E


On Thu, Jan 30, 2014 at 11:53 AM, Matt Lind wrote:

> We're using 2013 SP1 (32 bit) and not experiencing any deathly slow
> imports.  We have environments with 5,000+ referenced models, and while
> they do take a while to open because of their size, nothing along the lines
> of what you're reporting.
>
>
>
> I would check a few things that have caused us grief in the past:
>
>
>
> 1) Lights: for whatever reason if a model has a light and is imported into
> a scene as a referenced model, performance slows dramatically.
>
>
>
> 2) Model delta:   If users have manipulated many parameters within a
> model, that will load up the delta property with many logged entries which
> you can think of as a pseudo construction history.  The more entries, the
> more overhead you will have with referenced models.  When a user does
> something, then undo's it, the end result will be correct, but an entry
> will be recorded for the modification, then another entry for the undo
> operation to undo it.  Double the fun.  I'd look for those entries and
> delete both instances to lighten the load.
>
>
>
> If the models aren't intended to be modified once referenced, for example,
> they're only placed in an environment.  Then there is no reason for the
> delta to be loaded with many parameter entries.  That's a sign of a user
> improperly selecting and moving the model around.  For example, selecting
> the objects in multi-mode and dragging them into position as a set which
> would record 3 parameters for each object, instead of middle clicking to
> select the model and move it as a branch selection which records a total of
> 3.
>
>
>
> 3) Operators:  look for performance intensive operators such as the
> Tangents operator used for baking normal maps with ultimapper.  Any
> operator which modifies clusterproprety data on sample clusters (UV, Vertex
> Color, User normal) will be very computationally expensive.
>
>
>
> 4) Undo history:  Default is 50.  In the old days we got away with 10.
> The more undo's you have the more memory you consume and the more work
> Softimage has to do with updating the stack when each action is performed.
> Shouldn't be an issue with your scenes, but doesn't hurt to check by
> setting undo history to zero, then load the scene.
>
>
>
> 5) Events:  I found this one the hard way.  If you have any events to
> process the scene when importing or exporting a file (eg;
> siOnBeginFileImport, siOnEndFileImport, siOnBeginSceneLoad,
> siOnBeginSceneSave, siOnEndSceneSave, ...) it might be getting triggered when
> a model is loaded as a referenced model.  Softimage treats loading of a
> model as a file import regardless of context.  So whether you're importing
> the model, loading a scene, fabricating a new referenced model, updating
> referenced model in the scene, etc...  softimage treats it the same under the
> hood - it'll trigger any event that deals with file import/export.
>
>
>
> If you're event script does something time consuming such as scan the
> scene or call databases, and you have many models in the scene, the event
> will be called once for each  model.  If you have events implemented,
> scrutinize the code with a fine toothed comb.
>
>
>
> 6) User interface:  If you have a lot of views open, or performance
> intensive views like the FCurve open in a viewport, expect draing loading
> the scene.  If you have realtime shaders enabled (such as High Quality
> viewport) or other shading intensive option, that puts load on the scene as
> the UI gets updated with each model imported.  Set shading to wireframe.
> When in doubt, put UI to factory defaults.
>
>
>
> 7) Network:  If data is coming from a server, check your network
> connection.  Do you have any computers mapped which are not accessible, or
> slow?
>
>
>
>
>
> There's more, but I cannot remember

Re: Importing of Models Deathly Slow

[Enrique Caballero]

Thanks Min Rui,
  I will set up an example scene and send it your way.

best,
 Enrique


On Tue, Jan 28, 2014 at 2:21 PM, Min Rui Tan wrote:

> Hi Enrique,
>
> If you have a consistent repro case, you can forward it to me and we'll
> investigate if something is broken from 2013.
>
> Thanks!
> Min Rui
>
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Enrique Caballero
> Sent: Tuesday, January 28, 2014 9:51 AM
> To: softimage@listproc.autodesk.com
> Subject: Importing of Models Deathly Slow
>
> Hey everyone,
>   We are having a recurring problem here that I have just learned to live
> with, but am hoping maybe someone can shed some light on it for me.
>
> Importing of referenced models has always been slow in Softimage, but
> around 2013 it got much slower for us.
>
>
> This is with extremely lightweight rigs as well.  Simple props with
> limited geo, and usually incredibly few deformers. Nothing fancy.
>
> It is normal for it to take up to 3 minutes for us to load a scene that
> has maybe 10 simple props and 2 simple characters.
>
> The problem is worse if we try to switch rig resolution.
>
> And the problem becomes far worse if we import a character that has fur
> (ice strands), this can take significantly longer.
>
> Does anyone have any tips on alleviating this, or know if it possibly has
> something to do with our config?
>
> Our network is quite fast here, its actually very impressive hardware for
> such a small shop. So I would be surprised if its network related.
>
> Thanks,
>  Enrique
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

dont forget me :) ill buy several as well


On Wed, Jan 22, 2014 at 6:53 PM, Ahmidou Lyazidi wrote:

> I'm on it :)
>
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
> http://www.cappuccino-films.com
>
>
> 2014/1/21 Matt Morris 
>
>> bump! Would love to hear if you're getting anywhere with this, definitely
>> got a few seats ready to purchase here :)
>>
>>
>> On 10 December 2013 02:57, Enrique Caballero 
>> wrote:
>>
>>> yay!
>>>
>>>
>>> On Tue, Dec 10, 2013 at 10:56 AM, David Rivera <
>>> activemotionpictu...@yahoo.com> wrote:
>>>
>>>> YES!! Awesome news!!
>>>>
>>>>
>>>>
>>>>
>>>>   On Thursday, December 5, 2013 6:23 PM, Ahmidou Lyazidi <
>>>> ahmidou@gmail.com> wrote:
>>>>   Hey everyone,
>>>> Sorry for the (very) late reply! I've been extended on the project I
>>>> was working on and didn't found the time to polish things, but the
>>>> prototype is still there and functional,
>>>> The good news is I'm finishing next week for good, and will have a few
>>>> weeks off to finish this thing. I'll keep you informed as soon as I'll be
>>>> on this project again.
>>>>
>>>> Cheers
>>>>
>>>> ---
>>>> Ahmidou Lyazidi
>>>> Director | TD | CG artist
>>>> http://vimeo.com/ahmidou/videos
>>>> http://www.cappuccino-films.com
>>>>
>>>>
>>>> 2013/12/3 David Rivera 
>>>>
>>>> YES!! Grease pencil, PLEASE Totally useful for the 2D artist to
>>>> motion the 3D model!
>>>>
>>>>
>>>>
>>>>
>>>>   On Monday, December 2, 2013 5:05 AM, javier gonzalez <
>>>> javi09warr...@gmail.com> wrote:
>>>>   Any news?
>>>>
>>>>
>>>> 2013/12/2 Sebastien Sterling 
>>>>
>>>> +1
>>>>
>>>>
>>>> On 2 December 2013 09:13, Enrique Caballero >>> > wrote:
>>>>
>>>> still interested in this btw :)
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 11:58 AM, Enrique Caballero <
>>>> enriquecaball...@gmail.com> wrote:
>>>>
>>>> hows the grease pencil plugin lookin? The animators here are eagerly
>>>> looking forward to it
>>>>
>>>>
>>>> On Mon, Jul 1, 2013 at 8:30 PM, Enrique Caballero <
>>>> enriquecaball...@gmail.com> wrote:
>>>>
>>>> awesome ahmidou :) keep us posted.
>>>>
>>>>
>>>> On Mon, Jul 1, 2013 at 9:52 AM, Ahmidou Lyazidi 
>>>> wrote:
>>>>
>>>> Hi Enrique,
>>>> I'm working on it on my spare time, all the interactive manipulation is
>>>> working, and I'm currently on the window resizing part.
>>>> the next steps are:
>>>> - a custom display host to display when not manipulating
>>>> - some way to move the keys, there are differant way to do that, it's
>>>> not fixed yet, but I was thinking using the animation mixer
>>>>  or a pyQt view, or even the netview.
>>>>
>>>> it's probably going to be released sometime in august :)
>>>>
>>>> Cheers.
>>>>
>>>> ---
>>>> Ahmidou Lyazidi
>>>> Director | TD | CG artist
>>>> http://vimeo.com/ahmidou/videos
>>>> http://www.cappuccino-films.com
>>>>
>>>>
>>>> 2013/6/28 Enrique Caballero 
>>>>
>>>> After reading a recent thread about 3rd party plugins, it reminded me.
>>>>
>>>> Totally still willing to buy this plugin for our 25+ animators, if you
>>>> are developing it.
>>>>
>>>> -Enrique
>>>>
>>>>
>>>> On Mon, Apr 22, 2013 at 2:03 PM, Enrique Caballero <
>>>> enriquecaball...@gmail.com> wrote:
>>>>
>>>> Hey Ahmidou, I will ask the animators for their feedback and forward
>>>> you the results.
>>>>
>>>>  That sounds pretty awesome already :)
>>>>
>>>>
>>>>
>>>> On Fri, Apr 19, 2013 at 7:36 PM, Sebastien Sterling <
>>>> sebastien.sterl...@gmail.com> wrote:
>>>>
>>>> i just gota say this is pretty heart warming to see, i think I'll buy
>>>> one on principal even if I'm not necessarily an animator these days, i can
>>>> use it to mark stuff out on models :)
>>>>
>>>>
>>>> On 19 April 2013 09:50, Ahmidou Lyazidi  wrote:
>>>>
>>>> Hi Enrique, good to know :)
>>>> Do you have any special special expectation on it? currently I'm
>>>> planning those features:
>>>>
>>>> 2D paint and erase
>>>> screen space
>>>> onion skin
>>>> scene persistance
>>>> ability to move frames on the timeline
>>>>
>>>> I'll eventually add those in a second time:
>>>> multi layers
>>>> per layer depth distance
>>>> per layer opacity
>>>> surface object space strokes (to draw on objects)
>>>> wacom presure
>>>>
>>>>
>>>> Cheers
>>>> ---
>>>> Ahmidou Lyazidi
>>>> Director | TD | CG artist
>>>> http://vimeo.com/ahmidou/videos
>>>>
>>>>
>>>> 2013/4/18 Enrique Caballero 
>>>>
>>>> Not to drive the point too strongly, but if you make this tool Ahmidou
>>>> and you do a really good job on it, and price it reasonably, I can promise
>>>> to buy between 30-40 licenses of it.
>>>>
>>>>  The animators here are driving me absolutely insane about the topic
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> www.matinai.com
>>
>
>

Importing of Models Deathly Slow

[Enrique Caballero]

Hey everyone,
  We are having a recurring problem here that I have just learned to live
with, but am hoping maybe someone can shed some light on it for me.

Importing of referenced models has always been slow in Softimage, but
around 2013 it got much slower for us.


This is with extremely lightweight rigs as well.  Simple props with limited
geo, and usually incredibly few deformers. Nothing fancy.

It is normal for it to take up to 3 minutes for us to load a scene that has
maybe 10 simple props and 2 simple characters.

The problem is worse if we try to switch rig resolution.

And the problem becomes far worse if we import a character that has fur
(ice strands), this can take significantly longer.

Does anyone have any tips on alleviating this, or know if it possibly has
something to do with our config?

Our network is quite fast here, its actually very impressive hardware for
such a small shop. So I would be surprised if its network related.

Thanks,
 Enrique

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

yay!


On Tue, Dec 10, 2013 at 10:56 AM, David Rivera <
activemotionpictu...@yahoo.com> wrote:

> YES!! Awesome news!!
>
>
>
>
>   On Thursday, December 5, 2013 6:23 PM, Ahmidou Lyazidi <
> ahmidou@gmail.com> wrote:
>  Hey everyone,
> Sorry for the (very) late reply! I've been extended on the project I was
> working on and didn't found the time to polish things, but the prototype
> is still there and functional,
> The good news is I'm finishing next week for good, and will have a few
> weeks off to finish this thing. I'll keep you informed as soon as I'll be
> on this project again.
>
> Cheers
>
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
> http://www.cappuccino-films.com
>
>
> 2013/12/3 David Rivera 
>
> YES!! Grease pencil, PLEASE Totally useful for the 2D artist to motion
> the 3D model!
>
>
>
>
>   On Monday, December 2, 2013 5:05 AM, javier gonzalez <
> javi09warr...@gmail.com> wrote:
>   Any news?
>
>
> 2013/12/2 Sebastien Sterling 
>
> +1
>
>
> On 2 December 2013 09:13, Enrique Caballero wrote:
>
> still interested in this btw :)
>
>
> On Wed, Sep 4, 2013 at 11:58 AM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
> hows the grease pencil plugin lookin? The animators here are eagerly
> looking forward to it
>
>
> On Mon, Jul 1, 2013 at 8:30 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
> awesome ahmidou :) keep us posted.
>
>
> On Mon, Jul 1, 2013 at 9:52 AM, Ahmidou Lyazidi wrote:
>
> Hi Enrique,
> I'm working on it on my spare time, all the interactive manipulation is
> working, and I'm currently on the window resizing part.
> the next steps are:
> - a custom display host to display when not manipulating
> - some way to move the keys, there are differant way to do that, it's not
> fixed yet, but I was thinking using the animation mixer
>  or a pyQt view, or even the netview.
>
> it's probably going to be released sometime in august :)
>
> Cheers.
>
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
> http://www.cappuccino-films.com
>
>
> 2013/6/28 Enrique Caballero 
>
> After reading a recent thread about 3rd party plugins, it reminded me.
>
> Totally still willing to buy this plugin for our 25+ animators, if you are
> developing it.
>
> -Enrique
>
>
> On Mon, Apr 22, 2013 at 2:03 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
> Hey Ahmidou, I will ask the animators for their feedback and forward you
> the results.
>
>  That sounds pretty awesome already :)
>
>
>
> On Fri, Apr 19, 2013 at 7:36 PM, Sebastien Sterling <
> sebastien.sterl...@gmail.com> wrote:
>
> i just gota say this is pretty heart warming to see, i think I'll buy one
> on principal even if I'm not necessarily an animator these days, i can use
> it to mark stuff out on models :)
>
>
> On 19 April 2013 09:50, Ahmidou Lyazidi  wrote:
>
> Hi Enrique, good to know :)
> Do you have any special special expectation on it? currently I'm planning
> those features:
>
> 2D paint and erase
> screen space
> onion skin
> scene persistance
> ability to move frames on the timeline
>
> I'll eventually add those in a second time:
> multi layers
> per layer depth distance
> per layer opacity
> surface object space strokes (to draw on objects)
> wacom presure
>
>
> Cheers
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
>
>
> 2013/4/18 Enrique Caballero 
>
> Not to drive the point too strongly, but if you make this tool Ahmidou and
> you do a really good job on it, and price it reasonably, I can promise to
> buy between 30-40 licenses of it.
>
>  The animators here are driving me absolutely insane about the topic
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

still interested in this btw :)


On Wed, Sep 4, 2013 at 11:58 AM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> hows the grease pencil plugin lookin? The animators here are eagerly
> looking forward to it
>
>
> On Mon, Jul 1, 2013 at 8:30 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> awesome ahmidou :) keep us posted.
>>
>>
>> On Mon, Jul 1, 2013 at 9:52 AM, Ahmidou Lyazidi wrote:
>>
>>> Hi Enrique,
>>> I'm working on it on my spare time, all the interactive manipulation is
>>> working, and I'm currently on the window resizing part.
>>> the next steps are:
>>> - a custom display host to display when not manipulating
>>> - some way to move the keys, there are differant way to do that, it's
>>> not fixed yet, but I was thinking using the animation mixer
>>> or a pyQt view, or even the netview.
>>>
>>> it's probably going to be released sometime in august :)
>>>
>>> Cheers.
>>>
>>> ---
>>> Ahmidou Lyazidi
>>> Director | TD | CG artist
>>> http://vimeo.com/ahmidou/videos
>>> http://www.cappuccino-films.com
>>>
>>>
>>> 2013/6/28 Enrique Caballero 
>>>
>>>> After reading a recent thread about 3rd party plugins, it reminded me.
>>>>
>>>> Totally still willing to buy this plugin for our 25+ animators, if you
>>>> are developing it.
>>>>
>>>> -Enrique
>>>>
>>>>
>>>> On Mon, Apr 22, 2013 at 2:03 PM, Enrique Caballero <
>>>> enriquecaball...@gmail.com> wrote:
>>>>
>>>>> Hey Ahmidou, I will ask the animators for their feedback and forward
>>>>> you the results.
>>>>>
>>>>> That sounds pretty awesome already :)
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 19, 2013 at 7:36 PM, Sebastien Sterling <
>>>>> sebastien.sterl...@gmail.com> wrote:
>>>>>
>>>>>> i just gota say this is pretty heart warming to see, i think I'll buy
>>>>>> one on principal even if I'm not necessarily an animator these days, i 
>>>>>> can
>>>>>> use it to mark stuff out on models :)
>>>>>>
>>>>>>
>>>>>> On 19 April 2013 09:50, Ahmidou Lyazidi wrote:
>>>>>>
>>>>>>> Hi Enrique, good to know :)
>>>>>>> Do you have any special special expectation on it? currently I'm
>>>>>>> planning those features:
>>>>>>>
>>>>>>> 2D paint and erase
>>>>>>> screen space
>>>>>>> onion skin
>>>>>>> scene persistance
>>>>>>> ability to move frames on the timeline
>>>>>>>
>>>>>>> I'll eventually add those in a second time:
>>>>>>> multi layers
>>>>>>> per layer depth distance
>>>>>>> per layer opacity
>>>>>>> surface object space strokes (to draw on objects)
>>>>>>> wacom presure
>>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>> ---
>>>>>>> Ahmidou Lyazidi
>>>>>>> Director | TD | CG artist
>>>>>>> http://vimeo.com/ahmidou/videos
>>>>>>>
>>>>>>>
>>>>>>> 2013/4/18 Enrique Caballero 
>>>>>>>
>>>>>>>> Not to drive the point too strongly, but if you make this tool
>>>>>>>> Ahmidou and you do a really good job on it, and price it reasonably, I 
>>>>>>>> can
>>>>>>>> promise to buy between 30-40 licenses of it.
>>>>>>>>
>>>>>>>> The animators here are driving me absolutely insane about the topic
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Non-spherical eye while keeping iris circular

[Enrique Caballero]

thanks everyone, these are all really useful ideas. i will try them out and
see which one i go with

chris, i remember your eye rig from animal :) i was considering going a
similar route as well!


On Tue, Nov 19, 2013 at 9:49 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> If you have no textural detail in the eye and therefore can afford some
> discontinuity in the tension it's easy enough to achieve.
> Use one mesh for the deforming eye, a second one that's a proper sphere
> with the iris centered around the iris, bind it to the stretchy mesh from
> the iris out so the iris receives minimal distortion (that can then be
> trivially made perfectly circular if you want absolutely zero distortion
> with an ICE op), then project the rest on the deformed sphere.
>
> It takes some monstrous extreme before you get collisions (area around the
> Iris crashing into the iris), but if that happens you can still run several
> iterations of smooth and reproject as a final pass.
>
> Alternatively yes, you can do it with a shader and have a representation
> of that on a mesh with an equivalent OGL shader or with a simple
> approximation on a mesh for just the iris for animators and render it
> flawlessly as displacement and geo culling at rendertime (something we also
> have a shader to do here), but it's not really necessary unless you have
> some stringent requirement for surface tension being extremely uniform.
>

Re: Non-spherical eye while keeping iris circular

[Enrique Caballero]

hey oliver,
  Thanks for the reply, that would work if the pupil was a separate piece
of geometry and is exactly how i do it on other characters.

Sorry I should have been more specific.

Basically I'm trying to make the Pixar eyes.  Where the iris is cut into
the eyewhite, and actually goes inside of it.  This one i have not been
able to figure out for a while.



On Mon, Nov 18, 2013 at 6:51 PM, olivier jeannel wrote:

> I'm not a specialist in toon, but I would keep the Lattice on the Eye (the
> white deformed sphere) and make a separate Iris object that would be
> "shrinkwarped" on it. So that the Roundness of the Iris wouldn't be
> affected by the stretch of the global eye.
> Maybe a ClosestLocation in Ice would give even more control and speed...
>
>
> Le 18/11/2013 10:58, Enrique Caballero a écrit :
>
>  Hey everyone,
>>   Does anyone have any tips on how to rig a non spherical eye while
>> maintaining a perfectly circular iris?
>>
>> I have done it in the past with starting with a spherical eye, using a
>> lattice to deform it and then using blendshapes to counter the squashing
>> effect on the iris. But this method is clunky and you can see discrepancies
>> in the interpolation.
>>
>> Any tips would be welcome, this question has bothered me for some time.
>>
>> -E
>>
>
>

Non-spherical eye while keeping iris circular

[Enrique Caballero]

Hey everyone,
  Does anyone have any tips on how to rig a non spherical eye while
maintaining a perfectly circular iris?

I have done it in the past with starting with a spherical eye, using a
lattice to deform it and then using blendshapes to counter the squashing
effect on the iris. But this method is clunky and you can see discrepancies
in the interpolation.

Any tips would be welcome, this question has bothered me for some time.

-E

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

hows the grease pencil plugin lookin? The animators here are eagerly
looking forward to it


On Mon, Jul 1, 2013 at 8:30 PM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> awesome ahmidou :) keep us posted.
>
>
> On Mon, Jul 1, 2013 at 9:52 AM, Ahmidou Lyazidi wrote:
>
>> Hi Enrique,
>> I'm working on it on my spare time, all the interactive manipulation is
>> working, and I'm currently on the window resizing part.
>> the next steps are:
>> - a custom display host to display when not manipulating
>> - some way to move the keys, there are differant way to do that, it's not
>> fixed yet, but I was thinking using the animation mixer
>> or a pyQt view, or even the netview.
>>
>> it's probably going to be released sometime in august :)
>>
>> Cheers.
>>
>> ---
>> Ahmidou Lyazidi
>> Director | TD | CG artist
>> http://vimeo.com/ahmidou/videos
>> http://www.cappuccino-films.com
>>
>>
>> 2013/6/28 Enrique Caballero 
>>
>>> After reading a recent thread about 3rd party plugins, it reminded me.
>>>
>>> Totally still willing to buy this plugin for our 25+ animators, if you
>>> are developing it.
>>>
>>> -Enrique
>>>
>>>
>>> On Mon, Apr 22, 2013 at 2:03 PM, Enrique Caballero <
>>> enriquecaball...@gmail.com> wrote:
>>>
>>>> Hey Ahmidou, I will ask the animators for their feedback and forward
>>>> you the results.
>>>>
>>>> That sounds pretty awesome already :)
>>>>
>>>>
>>>>
>>>> On Fri, Apr 19, 2013 at 7:36 PM, Sebastien Sterling <
>>>> sebastien.sterl...@gmail.com> wrote:
>>>>
>>>>> i just gota say this is pretty heart warming to see, i think I'll buy
>>>>> one on principal even if I'm not necessarily an animator these days, i can
>>>>> use it to mark stuff out on models :)
>>>>>
>>>>>
>>>>> On 19 April 2013 09:50, Ahmidou Lyazidi  wrote:
>>>>>
>>>>>> Hi Enrique, good to know :)
>>>>>> Do you have any special special expectation on it? currently I'm
>>>>>> planning those features:
>>>>>>
>>>>>> 2D paint and erase
>>>>>> screen space
>>>>>> onion skin
>>>>>> scene persistance
>>>>>> ability to move frames on the timeline
>>>>>>
>>>>>> I'll eventually add those in a second time:
>>>>>> multi layers
>>>>>> per layer depth distance
>>>>>> per layer opacity
>>>>>> surface object space strokes (to draw on objects)
>>>>>> wacom presure
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>> ---
>>>>>> Ahmidou Lyazidi
>>>>>> Director | TD | CG artist
>>>>>> http://vimeo.com/ahmidou/videos
>>>>>>
>>>>>>
>>>>>> 2013/4/18 Enrique Caballero 
>>>>>>
>>>>>>> Not to drive the point too strongly, but if you make this tool
>>>>>>> Ahmidou and you do a really good job on it, and price it reasonably, I 
>>>>>>> can
>>>>>>> promise to buy between 30-40 licenses of it.
>>>>>>>
>>>>>>> The animators here are driving me absolutely insane about the topic
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

awesome ahmidou :) keep us posted.


On Mon, Jul 1, 2013 at 9:52 AM, Ahmidou Lyazidi wrote:

> Hi Enrique,
> I'm working on it on my spare time, all the interactive manipulation is
> working, and I'm currently on the window resizing part.
> the next steps are:
> - a custom display host to display when not manipulating
> - some way to move the keys, there are differant way to do that, it's not
> fixed yet, but I was thinking using the animation mixer
> or a pyQt view, or even the netview.
>
> it's probably going to be released sometime in august :)
>
> Cheers.
>
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
> http://www.cappuccino-films.com
>
>
> 2013/6/28 Enrique Caballero 
>
>> After reading a recent thread about 3rd party plugins, it reminded me.
>>
>> Totally still willing to buy this plugin for our 25+ animators, if you
>> are developing it.
>>
>> -Enrique
>>
>>
>> On Mon, Apr 22, 2013 at 2:03 PM, Enrique Caballero <
>> enriquecaball...@gmail.com> wrote:
>>
>>> Hey Ahmidou, I will ask the animators for their feedback and forward you
>>> the results.
>>>
>>> That sounds pretty awesome already :)
>>>
>>>
>>>
>>> On Fri, Apr 19, 2013 at 7:36 PM, Sebastien Sterling <
>>> sebastien.sterl...@gmail.com> wrote:
>>>
>>>> i just gota say this is pretty heart warming to see, i think I'll buy
>>>> one on principal even if I'm not necessarily an animator these days, i can
>>>> use it to mark stuff out on models :)
>>>>
>>>>
>>>> On 19 April 2013 09:50, Ahmidou Lyazidi  wrote:
>>>>
>>>>> Hi Enrique, good to know :)
>>>>> Do you have any special special expectation on it? currently I'm
>>>>> planning those features:
>>>>>
>>>>> 2D paint and erase
>>>>> screen space
>>>>> onion skin
>>>>> scene persistance
>>>>> ability to move frames on the timeline
>>>>>
>>>>> I'll eventually add those in a second time:
>>>>> multi layers
>>>>> per layer depth distance
>>>>> per layer opacity
>>>>> surface object space strokes (to draw on objects)
>>>>> wacom presure
>>>>>
>>>>>
>>>>> Cheers
>>>>> ---
>>>>> Ahmidou Lyazidi
>>>>> Director | TD | CG artist
>>>>> http://vimeo.com/ahmidou/videos
>>>>>
>>>>>
>>>>> 2013/4/18 Enrique Caballero 
>>>>>
>>>>>> Not to drive the point too strongly, but if you make this tool
>>>>>> Ahmidou and you do a really good job on it, and price it reasonably, I 
>>>>>> can
>>>>>> promise to buy between 30-40 licenses of it.
>>>>>>
>>>>>> The animators here are driving me absolutely insane about the topic
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

After reading a recent thread about 3rd party plugins, it reminded me.

Totally still willing to buy this plugin for our 25+ animators, if you are
developing it.

-Enrique


On Mon, Apr 22, 2013 at 2:03 PM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> Hey Ahmidou, I will ask the animators for their feedback and forward you
> the results.
>
> That sounds pretty awesome already :)
>
>
>
> On Fri, Apr 19, 2013 at 7:36 PM, Sebastien Sterling <
> sebastien.sterl...@gmail.com> wrote:
>
>> i just gota say this is pretty heart warming to see, i think I'll buy one
>> on principal even if I'm not necessarily an animator these days, i can use
>> it to mark stuff out on models :)
>>
>>
>> On 19 April 2013 09:50, Ahmidou Lyazidi  wrote:
>>
>>> Hi Enrique, good to know :)
>>> Do you have any special special expectation on it? currently I'm
>>> planning those features:
>>>
>>> 2D paint and erase
>>> screen space
>>> onion skin
>>> scene persistance
>>> ability to move frames on the timeline
>>>
>>> I'll eventually add those in a second time:
>>> multi layers
>>> per layer depth distance
>>> per layer opacity
>>> surface object space strokes (to draw on objects)
>>> wacom presure
>>>
>>>
>>> Cheers
>>> ---
>>> Ahmidou Lyazidi
>>> Director | TD | CG artist
>>> http://vimeo.com/ahmidou/videos
>>>
>>>
>>> 2013/4/18 Enrique Caballero 
>>>
>>>> Not to drive the point too strongly, but if you make this tool Ahmidou
>>>> and you do a really good job on it, and price it reasonably, I can promise
>>>> to buy between 30-40 licenses of it.
>>>>
>>>> The animators here are driving me absolutely insane about the topic
>>>>
>>>>
>>>>
>>>
>>
>

Re: Softimage ProjectManager Project List Not Saving

[Enrique Caballero]

awesome, thanks everyone. i bet you its one of these suggestions.

raf sadly we are still on windows!


On Sat, Jun 22, 2013 at 4:22 AM, Stephen Blair wrote:

>  Hi
>
> The project list comes from the various .xsiproject files. In particular,
> the one in the factory location and the one in the user location (as well
> as any found in workgroup or addon locations).
>
> For example, on Windows:
>
> C:\Program Files\Autodesk\Softimage 2014 SP1\Data\factory.xsiprojects
> C:\Users\SOLIDANGLE\Autodesk\Softimage_2014_SP1\Data\default.xsiprojects
>
> So I'd look into what is happening with those files. Softimage reads them
> at startup to populate the project list, and writes to them when you add a
> new project  (unless of course Softimage doesn't have permission to write
> to the file).
>
>
> With the more recent versions of Softimage, you can start XSI.exe and it
> will figure out the right User folder eg
> C:\Users\SOLIDANGLE\Autodesk\Softimage_2014_SP1
>
>
> ciao
>
> Steve
>
>
>
> On 21/06/2013 1:51 PM, Matt Lind wrote:
>
>  I’ll take a stab and guess he pinned Softimage to the windows taskbar
> with the shortcut pointing to xsi.exe instead of xsi.bat.
>
> ** **
>
> Failure to do that one simple thing causes Softimage to revert to default
> settings and use C:\users\\softimage as the profile folder with
> factory default settings instead of C:\users\\autodesk\softimage.
> 
>
> ** **
>
> ** **
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [
> mailto:softimage-boun...@listproc.autodesk.com]
> *On Behalf Of *Enrique Caballero
> *Sent:* Friday, June 21, 2013 1:15 AM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Softimage ProjectManager Project List Not Saving
>
> ** **
>
> Hey everyone,
>
>   I have a bit of a strange problem here.  
>
> ** **
>
> One of our artist here, everytime he reopens Softimage, his project list
> in the project manager is empty, reset to defaults.
>
> ** **
>
> We have deleted his user preferences, created new ones,  reinstalled the
> computer.
>
> ** **
>
> For some reason it happens everytime, and only to him.
>
> ** **
>
> With that said. I must also point out, that in every company there are 2
> or 3 artists/animators that somehow always find a way to break things in
> the most obscure and random ways possible.
>
> ** **
>
> This guy is one of my 3 that always figure out how to break things in
> interesting ways.
>
>
> Does anyone have any ideas as to what could be causing this?
>
> ** **
>
> Thanks,
>
>   Enrique
>
>
>

Softimage ProjectManager Project List Not Saving

[Enrique Caballero]

Hey everyone,
  I have a bit of a strange problem here.

One of our artist here, everytime he reopens Softimage, his project list in
the project manager is empty, reset to defaults.

We have deleted his user preferences, created new ones,  reinstalled the
computer.

For some reason it happens everytime, and only to him.

With that said. I must also point out, that in every company there are 2 or
3 artists/animators that somehow always find a way to break things in the
most obscure and random ways possible.

This guy is one of my 3 that always figure out how to break things in
interesting ways.

Does anyone have any ideas as to what could be causing this?

Thanks,
  Enrique

Re: Mirror weights causes Unspecified failure

[Enrique Caballero]

I wouldnt edit that code even if you could.

This has happened to me before, and it was related to a corrupted piece of
geometry.  That asset may have been created in a previous version of XSI,
who knows.

Our methods here at very cavalier, as every modeller/TD has their own
techniques, so its quite common for geometry to get corrupted somewhere in
the process.  Once it happens, usually envelope operations will stop
working properly.

Basically, I just export out as OBJ, reimport, Gator everything across, and
its fixed.

best of luck,
 E


On Thu, Jun 20, 2013 at 5:16 PM, Szabolcs Matefy wrote:

> Hey folks,
>
> ** **
>
> I want to mirror skinning from a portion of the mesh to the opposite side.
> However, after the Create symmetry template dialog box (and prior creating
> the symmetry map itself) the operation cancels saying that unspecified
> error occurred…
>
> ** **
>
> This is the code part where it fails (enveloping.vbs)
>
> ** **
>
> function get_deformers   (in_obj, out_deformers )
>
> ** **
>
> dim deformers, myenv, weights, i
>
> ** **
>
> set deformers = CreateObject("XSI.Collection")
>
> set myenv =
> in_obj.activeprimitive.constructionhistory.find("envelopop")
>
> Weights = myenv.Weights.Array
>
> ** **
>
> weights = myenv.Weights.Array
>
> ** **
>
> For i = lbound(weights ,1) to ubound(weights ,1)
>
> '   87892:   The fact that we didn't mirror
> effectors caused scenes that have envelope weighting on effectors not to
> symmetrize correctly. 
>
> '   Enabling
> symmetry on effectors.
>
> '   if( myenv.deformers(i).type <> "eff" ) then
> 
>
> deformers.add
> myenv.deformers(i)  
> ß
> Line of failure is this
>
> '   End if
>
> next
>
> ** **
>
> set out_deformers = deformers
>
> ** **
>
> end function
>
> ** **
>
> At first glance what hit my eyes is that once deformers is a collection,
> and then deformers is a property of the myenv object. Can it cause an
> issue? I can’t do any edit, since the folder is read only, and our admin
> doesn’t let me play with the rights in my Softimage folder…
>
> ** **
>
> ** **
>
> Cheers
>
> ** **
>
> ** **
>
> Szabolcs
> ___
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message, which arise as a result of e-mail
> transmission. If verification is required please request a hard-copy
> version. Crytek GmbH - http://www.crytek.com - Grüneburgweg 16-18, 60322
> Frankfurt - HRB77322 Amtsgericht Frankfurt a. Main- UST IdentNr.:
> DE20432461 - Geschaeftsfuehrer: Avni Yerli, Cevat Yerli, Faruk Yerli
>

Re: Anyone done corrective shapes when SecondaryShapeModeling is not an option?

[Enrique Caballero]

Awesome thanks raff, will mess with this today. I need to watch week 7 too!


On Tue, Jun 18, 2013 at 8:16 PM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> Actually:
> "but instead of using one transform for the whole set, those vectors are
> saved after a local transform for each point is obtained"
> You will need to test yourself. The principle is what I describe, but I
> don't remember if Soft saves the transformed vectors or uses the transforms
> at the end of the process and leaves the displacement vector otherwise
> unaffected before then.
>
> It's easy enough to test with X, Y and Z aligned unit vectors in the
> shapes and a deforming mesh. I'm quite, but not 100% positive they are
> pre-transformed when saved, but it's been a long time since I checked :p
>
>
> On Tue, Jun 18, 2013 at 10:13 PM, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> I think I go over it in week 7 actually, and I know you do have it
>> already so not like I'm peddling :p
>>
>> But in terms of shape animation, you have three modes in Softimage.
>> Global and Object are fairly self explanatory in how the displacement
>> vector that moves one base point to its target shape is oriented. If shapes
>> happen before other deformations, those are fine.
>>
>> However, if you save a displacement vector moving a point on the top of a
>> head by one unit in Y, oriented to the object, when the envelope bends that
>> head forward and you apply the shape AFTER the envelope, you are left with
>> a stray point still moving in object Y.
>>
>> Local relative shapes in Soft still save a displacement vector like the
>> other modes, but instead of using one transform for the whole set, those
>> vectors are saved after a local transform for each point is obtained, so
>> that if you move a set of points, that vector multiplied by the transform
>> of each point will still produce a displacement similar to the one intended.
>>
>> Now, points don't have a full transform, they have a position, and
>> possibly a normal and a set of edges coming off it, so you have to figure
>> out a coherent, repeatable (after points move) transform with those.
>>
>> AFAIK Soft uses a simple system, Normal = Y axis, first edge projected on
>> the normal plane then normalized = X axis, the cross product between the
>> two (with the right handedness and normalized again for good measure)
>> produces the Z. You can then transform your displacement in object space by
>> the inverse of that transform, and it will become "point neutral" in a way,
>> at least for storage.
>> When time comes to re-apply it, after the mesh has deformed, you
>> re-derive that point's transform the same way, and multiply that vector by
>> it, and it will be "mesh relative".
>>
>> Of course it comes with fringe cases (IE: first edge aligned to the
>> normal, resulting in a 0 vector for X), but those fringe cases would
>> normally imply someone who modelled, or subsequently deformed the mesh
>> needs to be chemically castrated ASAP, lest they have kids just as stupid.
>>
>>
>>
>>
>> On Tue, Jun 18, 2013 at 9:54 PM, Enrique Caballero <
>> enriquecaball...@gmail.com> wrote:
>>
>>> raff thats really interesting and explains why in some of my shapes my
>>> method doesn't work. properly
>>>
>>> *(normal - normal x 1st edge - previous axis x normal)*
>>>
>>> could i ask you to go into more detail on this please.
>>>
>>>
>>> On Tue, Jun 18, 2013 at 12:02 PM, Raffaele Fragapane <
>>> raffsxsil...@googlemail.com> wrote:
>>>
>>>> Duplicate mesh twice, fix one, subtract point pos of one from the
>>>> other, freeze, transfer frozen ice attributes to original mesh.
>>>> Works fine for world and object. For component relative (equivalent to
>>>> local) it's a bit trickier as you will have to transform the resulting
>>>> vector (object space) by the inverse of the component transform (normal -
>>>> normal x 1st edge - previous axis x normal), and then transform it by the
>>>> component transform on the mesh it's applied to, but can still be done.
>>>>
>>>> Corrective shapes are best done in ICE :p
>>>>
>>>>
>>>> On Tue, Jun 18, 2013 at 5:27 AM, Alan Fregtman >>> > wrote:
>>>>
>>>>> Hey guys,
>>>>>
>>>>> I'm curious if anyone has already tackled the problem of cr

Re: Anyone done corrective shapes when SecondaryShapeModeling is not an option?

[Enrique Caballero]

raff thats really interesting and explains why in some of my shapes my
method doesn't work. properly

*(normal - normal x 1st edge - previous axis x normal)*

could i ask you to go into more detail on this please.


On Tue, Jun 18, 2013 at 12:02 PM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> Duplicate mesh twice, fix one, subtract point pos of one from the other,
> freeze, transfer frozen ice attributes to original mesh.
> Works fine for world and object. For component relative (equivalent to
> local) it's a bit trickier as you will have to transform the resulting
> vector (object space) by the inverse of the component transform (normal -
> normal x 1st edge - previous axis x normal), and then transform it by the
> component transform on the mesh it's applied to, but can still be done.
>
> Corrective shapes are best done in ICE :p
>
>
> On Tue, Jun 18, 2013 at 5:27 AM, Alan Fregtman wrote:
>
>> Hey guys,
>>
>> I'm curious if anyone has already tackled the problem of creating a
>> corrective shape (that is, a shape difference in a pose that has been
>> readjusted to be relative to the neutral character pose) when
>> SecondaryShapeModeling isn't viable?
>>
>> If you use classic envelopes and the ClusterShapeCombiner, you can make
>> adjustments in SecondaryShape mode and store a shape that is automatically
>> adjusted to the neutral pose for you, and that's cool, but if you have
>> anything much fancier, it doesn't do the neutralization right.
>>
>> I'm contemplating perhaps storing the shape vector difference relative to
>> the PointReferenceFrame matrices; maybe that'll do it. Any other/better
>> ideas?
>>
>> Cheers,
>>
>>-- Alan
>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Anyone done corrective shapes when SecondaryShapeModeling is not an option?

[Enrique Caballero]

alan all the time this is how i do it

duplicate the mesh twice

1. neutral pose
2. posed where it needs the corrective shape
3. duplicate 2 again

create the corrective shape on # 2 mesh.  You now have a mesh that is
posed, and has the fix applied

create the corrective shape on it.

you now have

1. neutral pose
2. posed mesh with corrective shape on it
3. pose shape that needs corrective shape

now apply the #2 mesh as a shape to the neutral pose mesh, set it to weight
of 1

now apply the #3 mesh as a shape to the neutral pose mesh, set it to weight
-1

this effectively removes the posing, and leaves only the corrective shape,
its just a vector subtraction after all.

you now have the corrective shape


d


On Tue, Jun 18, 2013 at 7:45 AM, Sven Constable wrote:

> Just a sidenote: Mr. Smith, your tutorials are the most charming ones
> regarding softimage I saw in the last 15 years. It's just my professional
> opinion. :)  Its pure joy to listen to them. I really like the kind of
> understatement that is always present in your videos. And of course the
> information. The videos about "procedural UVing" or something (with
> particles?) were great. I just wanted to say this in the mailing list
> rather
> than post a comment a a video platform
> Thank you for the effort, Sir!
>
> sven
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Bk
> Sent: Monday, June 17, 2013 23:58
> To: softimage@listproc.autodesk.com
> Subject: Re: Anyone done corrective shapes when SecondaryShapeModeling is
> not an option?
>
> See what you think of this technique
>
> https://vimeo.com/67402407
>
> I find the results are far more natural looking and easier to manage and
> edit. I doubt I'll ever use that shapes-before-bones method again for
> correctives on limbs.
>
>
> On 17 Jun 2013, at 20:27, Alan Fregtman  wrote:
>
> > Hey guys,
> >
> > I'm curious if anyone has already tackled the problem of creating a
> corrective shape (that is, a shape difference in a pose that has been
> readjusted to be relative to the neutral character pose) when
> SecondaryShapeModeling isn't viable?
> >
> > If you use classic envelopes and the ClusterShapeCombiner, you can make
> adjustments in SecondaryShape mode and store a shape that is automatically
> adjusted to the neutral pose for you, and that's cool, but if you have
> anything much fancier, it doesn't do the neutralization right.
> >
> > I'm contemplating perhaps storing the shape vector difference relative to
> the PointReferenceFrame matrices; maybe that'll do it. Any other/better
> ideas?
> >
> > Cheers,
> >
> >-- Alan
> >
>
>

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 pasting our report below. I hope that we can get this fixed.
 Hopefully this will help you guys out as well.


V
_


Alright so here is the testing we have done so far on the "slow keyframing"
issue when trying to set keys on multiple controllers. In this case we are
talking about a characters 206 controllers with multiple attributes. As it
is, trying to do this will take anywhere between 4-6 seconds on all tested
computers here at the studio.

Although we haven't solved the issue I can confirm the following can be
ruled out:

- scene files located on the network with referenced assets have no impact
on the speed. local scenes with local assets on an SSD have been tested.

- Clean Softimage user profiles were tested + freshly created workgroups
were tested so we can rule out our custom tools and pipeline scripts from
having an effect. Gear was also tested on a workgroup install and under
User Add-Ons install. No impact on speed.

- Possible bloatware from HP or "dirty" Windows system with various
background apps can be ruled out. We clean installed a standard workstation
with a vanilla copy of windows 7 and Softimage 2013 SP1 + python + gear. No
impact on speed.

- Process priority, process affinity, CPU energy saving/downclocking,
Windows core parking, hyper threading was verified, edited to max out
settings, and has had no impact on speed.

- Tested our dual CPU systems with only 1 CPU, and according RAM removed.
Also tested if there were any difference between similar Sandy bridge and
Ivy bridge CPU systems, no impact on speed.

-

Keeping in mind the testing that was listed above, I should note that our
definition of "slow" keyframing comes from the fact that we have replicated
the conditions of the test scene on our personal computers/laptops and have
achieved timings pretty much cut down by half. i.e. 2-3 seconds vs 4-6
seconds.

The only thing these personal computers have in common with each other is a
higher core speed than our studio workstations. Although I am hesitant to
jump to conclusions, everything is pointing to the fact that keyframing in
Softimage is purely dependant on the process running on a single thread.

Most of the studio testing was done on a dual CPU workstation with Sandy
bridge Xeon 2Ghz with 6 cores each + 16 Gigs RAM.
I did a test at home last night on my home computer which is a single CPU
i7 930 Quad core nehalem with 6 Gigs RAM (just FYI nehalem is a older micro
architecture than Sandy bridge). As I overclock, my CPU is running at 4Ghz.
I was able to keyframe all the controllers between 1 and 2 secs.

Next, I downclocked my CPU to 2Ghz to match the core speed of our
workstations. Keyframing timings matched the 4 seconds it took at work. I
disabled 3 out of 4 cores on Softimage process and left the frequency at
2Ghz. Keyframe timing remained at 4 secs. A couple things became clear to
me at this point. First of all, it won't matter how many cores you throw at
it, since CPU usage during the keyframing only utilizes 1 CPU thread,
similar to other various Softimage functions like duplicating. Not that I
expect this type of process to be multi-threaded, but I'm just pointing out
that a 12 core workstation vs a dual core laptop will have no significant
impact on the speed of the keyframing instructions.

---

Again all these results are relative for the moment. For all I know, 2 secs
to keyframe 206 controllers on a i7 CPU running over 3Ghz should still be
considered slow? hard to say really... Still a couple things I'd like to
try, like older ver of Python, maybe older version of gear. Wish I could
test the scene on older version of Softimage, sadly scenes aren't backward
compatible.

anyways, will keep playing around with this for a bit when I can.

cheers,
-John


On Thu, May 23, 2013 at 10:46 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> 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 not always done though, and occasionally we pay
> the blood price for it and ask for more fixes.
>
> As for character key sets, the general consensus, and this is across
> several apps, is that they are the festering pit where good animation goes
> to die, so we tend to stay away from them. They require a specificity of
> actions and knowledge, not to mention a maintenance overhead, that means
> they 

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 that said, this rig does not have that many parameters or objects
in it to account for the 6 second delay that I experience on every system
at this company.

With that said. I have found something interesting.

Last night while we chatted, I tried the scene on my laptop at home, and
the issue was largely gone.

This makes no sense to me as I have done heavy testing here with the
workgroup disconnected and a vanilla softimage and gear install. And had
the 6 second delay.

I now think it might have to do with our system configurations here, I am
looking into it.

Thanks for the help, Please don't close this ticket yet. The problem is
larger than just "too many keyable parameters"

-Enrique


On Thu, May 23, 2013 at 6:24 AM, Alan Fregtman wrote:

> 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 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, Eric Thivierge 
>> wrote:
>>
>>>  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 parameter locking until we discovered that it doesn’t
>>> always work for parameters in referenced models.  A number of built-in
>>> Softimage tools don’t function properly with locked parameters either
>>> causing tools to abort prematurely (due to lack of error handling) leaving
>>> our work in a funky state.
>>>
>>>
>>>
>>
>

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 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 does the job for most cases where assets
> are not too complex and relatively lightweight, ie. mesh/rig character type
> assets. What I am saying is it doesn't really take much to get a system
> like this going and benefits can be potentially really big.
> Sorry for being bit off topic.
>
>
> On 22 May 2013 10:00, Enrique Caballero wrote:
>
>> 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 tools that we just don't have. We also don't have enough
>> coordinators to keep track of what shot gets what rig, or the development
>> man power to update our pipeline.
>>
>> Tiny shop in Singapore, very difficult to find talented developers.
>>
>> Until then I've written a bunch of delta cleaning scripts that can solve
>> 90% of our issues, and what was most important for us, was that we are very
>> careful about how we import referenced models so that
>> no unnecessary information gets written to the delta.  So if a rig change
>> does happen, the delta wont freak out and break the rig.
>>
>> Basically via scripting,  I create an empty referenced model, populate
>> the paths for the rig resolutions, add an empty delta, set the proper
>> settings, disabling the evil ones, and then finally setting the active
>> resolution.  I have found this technique to be absolutely essential to
>> making sure our deltas don't store any extra nonsense in them that would
>> eventually clash with a rig change.
>>
>> Otherwise if the animator simply did a vanilla "import referenced model"
>>  this referenced model would have a delta on it thats fully enabled, and it
>> would immediately store a bunch of useless crap under stored
>> expressions/stored positions that would eventually cause the rig to explode
>> when we did the next rig update.
>>
>> Aside from that, when something bad happens, I run one of 3 delta
>> cleaners if necessary, but to be honest it hasnt happened much in a very
>> long time.
>>
>>
>> I am very open minded, but i also know the animators at this company very
>> well. If I gave them a local model pipeline they would bring this studio to
>> its knees and I would be out of a job very quickly
>>
>>
>>
>>
>> On Wed, May 22, 2013 at 4:51 PM, Raffaele Fragapane <
>> raffsxsil...@googlemail.com> wrote:
>>
>>> 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 you, it doesn't ADD
>>> security :)
>>>
>>>
>>> On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland <
>>> sandy.mailli...@gmail.com> wrote:
>>>
>>>> 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 gets auto updated in a reference, THAT has happened to me before,
>>>> largely due to the nature of the overlapping schedules we work with in SA.
>>>>
>>>> S.
>>>>
>>>>
>>>> On 22/05/2013 04:48, Enrique Caballero wrote:
>>>>
>>>>> 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 stuff.  I took all
>>>>> the cloth controls away and seperated it into a different rig, and then
>>>>> aggressively cut down the amount of keyable params.
>>>>>
>>>>> Its at least manageable now.
>>>>>
>>>>> Are you really comfortable letting the animators animate local models?
>>>>>  I don't think I could ever let it happen
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Our users will know fear and cower before our software! Ship it! Ship it
>>> and let them flee like the dogs they are!
>>>
>>
>>
>
>
> --
> --
> Michal
> http://uk.linkedin.com/in/mdoniec
>

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 tools that we just don't have. We also don't have enough
coordinators to keep track of what shot gets what rig, or the development
man power to update our pipeline.

Tiny shop in Singapore, very difficult to find talented developers.

Until then I've written a bunch of delta cleaning scripts that can solve
90% of our issues, and what was most important for us, was that we are very
careful about how we import referenced models so that
no unnecessary information gets written to the delta.  So if a rig change
does happen, the delta wont freak out and break the rig.

Basically via scripting,  I create an empty referenced model, populate the
paths for the rig resolutions, add an empty delta, set the proper settings,
disabling the evil ones, and then finally setting the active resolution.  I
have found this technique to be absolutely essential to making sure our
deltas don't store any extra nonsense in them that would eventually clash
with a rig change.

Otherwise if the animator simply did a vanilla "import referenced model"
 this referenced model would have a delta on it thats fully enabled, and it
would immediately store a bunch of useless crap under stored
expressions/stored positions that would eventually cause the rig to explode
when we did the next rig update.

Aside from that, when something bad happens, I run one of 3 delta cleaners
if necessary, but to be honest it hasnt happened much in a very long time.


I am very open minded, but i also know the animators at this company very
well. If I gave them a local model pipeline they would bring this studio to
its knees and I would be out of a job very quickly




On Wed, May 22, 2013 at 4:51 PM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> 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 you, it doesn't ADD
> security :)
>
>
> On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland <
> sandy.mailli...@gmail.com> wrote:
>
>> 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 gets auto updated in a reference, THAT has happened to me before,
>> largely due to the nature of the overlapping schedules we work with in SA.
>>
>> S.
>>
>>
>> On 22/05/2013 04:48, Enrique Caballero wrote:
>>
>>> 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 stuff.  I took all the
>>> cloth controls away and seperated it into a different rig, and then
>>> aggressively cut down the amount of keyable params.
>>>
>>> Its at least manageable now.
>>>
>>> Are you really comfortable letting the animators animate local models?
>>>  I don't think I could ever let it happen
>>>
>>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 stuff.  I took all the
cloth controls away and seperated it into a different rig, and then
aggressively cut down the amount of keyable params.

Its at least manageable now.

Are you really comfortable letting the animators animate local models?  I
don't think I could ever let it happen


On Wed, May 22, 2013 at 11:26 AM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> 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, asked them which controllers they usually
> scale, and then removed the ability from the rest.
>
> This helped me get some speed back.  Its still slow, but much more useable.
>
> Thanks Matt, it was your suggestions
>
>
> On Wed, May 22, 2013 at 10:54 AM, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> 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 hostility here and in other places was pretty high in the beginning).
>>
>> Given that's always been as much a defining trait of Softimage as the
>> software itself might have been, at least a tip of the hat is probably long
>> overdue :)
>>
>>
>> On Wed, May 22, 2013 at 12:41 PM, Enrique Caballero <
>> enriquecaball...@gmail.com> wrote:
>>
>>> 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 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 impressed me with all the bug fix they did on 2014.
>>>> Seeing very old bug fixed is giving me faith in the new team. Keep up the
>>>> good work, and I'm crossing my fingers to see that one updated in the next
>>>> release ;-)
>>>>
>>>>
>>>> On 21 May 2013 05:52, ivan tay  wrote:
>>>>
>>>>> 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 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 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.
>>>>>>>
>>>>>>>
>>>>>>> I did test in 2014 btw, and it is a bit faster, but its still
>>>>>>> massively slow

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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, asked them which controllers they usually
scale, and then removed the ability from the rest.

This helped me get some speed back.  Its still slow, but much more useable.

Thanks Matt, it was your suggestions


On Wed, May 22, 2013 at 10:54 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> 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 hostility here and in other places was pretty high in the beginning).
>
> Given that's always been as much a defining trait of Softimage as the
> software itself might have been, at least a tip of the hat is probably long
> overdue :)
>
>
> On Wed, May 22, 2013 at 12:41 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> 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 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 impressed me with all the bug fix they did on 2014.
>>> Seeing very old bug fixed is giving me faith in the new team. Keep up the
>>> good work, and I'm crossing my fingers to see that one updated in the next
>>> release ;-)
>>>
>>>
>>> On 21 May 2013 05:52, ivan tay  wrote:
>>>
>>>> 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 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 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.
>>>>>>
>>>>>>
>>>>>> I did test in 2014 btw, and it is a bit faster, but its still
>>>>>> massively slow.
>>>>>>
>>>>>> I've sent the scene to Autodesk, we still have a year on Subscription
>>>>>> so hopefully they can send us a QFE
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 21, 2013 at 11:36 AM, Raffaele Fragapane <
>>>>>> raffsxsil...@googlemail.com> wrote:
>>>>>>
>>>>>>> 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 alive if it took more
>>>>>>> than a second or two to key out a couple thous

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 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 impressed me with all the bug fix they did on 2014.
> Seeing very old bug fixed is giving me faith in the new team. Keep up the
> good work, and I'm crossing my fingers to see that one updated in the next
> release ;-)
>
>
> On 21 May 2013 05:52, ivan tay  wrote:
>
>> 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 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 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.
>>>>
>>>>
>>>> I did test in 2014 btw, and it is a bit faster, but its still massively
>>>> slow.
>>>>
>>>> I've sent the scene to Autodesk, we still have a year on Subscription
>>>> so hopefully they can send us a QFE
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 21, 2013 at 11:36 AM, Raffaele Fragapane <
>>>> raffsxsil...@googlemail.com> wrote:
>>>>
>>>>> 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 alive if it took more
>>>>> than a second or two to key out a couple thousand curves.
>>>>>
>>>>> Consider trying to write your way around it to see how pervasive it
>>>>> is, and if not too far reaching possibly stop them from staring daggers at
>>>>> you.
>>>>>
>>>>> Keying a ref model will always be slower, there's no two ways about it
>>>>> when you have to deal with delta tracking rather than simply adding data
>>>>> somewhere, but shouldn't be in that measure, it should be just a few
>>>>> percentage points at the most.
>>>>>
>>>>>
>>>>> On Tue, May 21, 2013 at 1:32 PM, Enrique Caballero <
>>>>> enriquecaball...@gmail.com> wrote:
>>>>>
>>>>>> 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 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.
>>>>>>>
>&g

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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.


I did test in 2014 btw, and it is a bit faster, but its still massively
slow.

I've sent the scene to Autodesk, we still have a year on Subscription so
hopefully they can send us a QFE




On Tue, May 21, 2013 at 11:36 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> 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 alive if it took more
> than a second or two to key out a couple thousand curves.
>
> Consider trying to write your way around it to see how pervasive it is,
> and if not too far reaching possibly stop them from staring daggers at you.
>
> Keying a ref model will always be slower, there's no two ways about it
> when you have to deal with delta tracking rather than simply adding data
> somewhere, but shouldn't be in that measure, it should be just a few
> percentage points at the most.
>
>
> On Tue, May 21, 2013 at 1:32 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> 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 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 slow whether or not the Fcurve editor is open.  Basically setting
>>> a key on a gear rig referenced model with 180 objects takes 6 seconds, a
>>> local model is instant.
>>>
>>> I've stripped down our workgroup to nothing but gear, same problem.
>>>
>>> Really quite distressing! The animators are giving me dirty looks!
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 21, 2013 at 11:21 AM, Raffaele Fragapane <
>>> raffsxsil...@googlemail.com> wrote:
>>>
>>>> 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 packaged up.
>>>>
>>>>
>>>> On Tue, May 21, 2013 at 1:16 PM, Enrique Caballero <
>>>> enriquecaball...@gmail.com> wrote:
>>>>
>>>>> 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 in 2014 and it is better, by like 30 % but its still
>>>>> massively slower than it would be if the model was in Local Mode.
>>>>>
>>>>> Seeing as how well Softimage's referenced model and Deltas work
>>>>> together, it is a major reason we use Softimage here at this studio, I
>>>>> would expect the speed of keyframing to be very fast on referenced models,
>>>>> it should be just as fast I dare say, otherwise its a massive hit on their
>>>>> usability.
>>>>>
>>>>> I have also tested with other rigs as well,  Gear rigs, the malcolm
>>>>> rig, and rigs of my own making, its a pretty major speed difference when
>>>>> setting and manipulating keys on referenced models vs local models.
>>>>>
>>>>>
>>>>> As far as how many fcurves.  well... A lot, 

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 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 slow whether or not the Fcurve editor is open.  Basically setting a
> key on a gear rig referenced model with 180 objects takes 6 seconds, a
> local model is instant.
>
> I've stripped down our workgroup to nothing but gear, same problem.
>
> Really quite distressing! The animators are giving me dirty looks!
>
>
>
>
>
>
> On Tue, May 21, 2013 at 11:21 AM, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> 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 packaged up.
>>
>>
>> On Tue, May 21, 2013 at 1:16 PM, Enrique Caballero <
>> enriquecaball...@gmail.com> wrote:
>>
>>> 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 in 2014 and it is better, by like 30 % but its still
>>> massively slower than it would be if the model was in Local Mode.
>>>
>>> Seeing as how well Softimage's referenced model and Deltas work
>>> together, it is a major reason we use Softimage here at this studio, I
>>> would expect the speed of keyframing to be very fast on referenced models,
>>> it should be just as fast I dare say, otherwise its a massive hit on their
>>> usability.
>>>
>>> I have also tested with other rigs as well,  Gear rigs, the malcolm rig,
>>> and rigs of my own making, its a pretty major speed difference when setting
>>> and manipulating keys on referenced models vs local models.
>>>
>>>
>>> As far as how many fcurves.  well... A lot, its an entire rig,  its like
>>> 150 objects, and we are keying their entire srt. as the animators are
>>> currently blocking animation, so they key the entire character at once.
>>>
>>>
>>> 2014 is a bit faster, but not massively so. And we don't have the luxury
>>> of moving our pipeline to 2014 right now, our tools are written for 2013 at
>>> the moment and we are going through a major tools development phase
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 21, 2013 at 8:24 AM, Raffaele Fragapane <
>>> raffsxsil...@googlemail.com> wrote:
>>>
>>>> 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 addressed in 2013 already, I believe).
>>>>
>>>>
>>>> On Tue, May 21, 2013 at 9:28 AM, Jeremie Passerin 
>>>> wrote:
>>>>
>>>>> 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 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 wrote:
>>>>>>
>>>>>>> Thanks!
>>>>&g

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 slow whether or not the Fcurve editor is open.  Basically setting a
key on a gear rig referenced model with 180 objects takes 6 seconds, a
local model is instant.

I've stripped down our workgroup to nothing but gear, same problem.

Really quite distressing! The animators are giving me dirty looks!






On Tue, May 21, 2013 at 11:21 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> 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 packaged up.
>
>
> On Tue, May 21, 2013 at 1:16 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> 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 in 2014 and it is better, by like 30 % but its still
>> massively slower than it would be if the model was in Local Mode.
>>
>> Seeing as how well Softimage's referenced model and Deltas work together,
>> it is a major reason we use Softimage here at this studio, I would expect
>> the speed of keyframing to be very fast on referenced models, it should be
>> just as fast I dare say, otherwise its a massive hit on their usability.
>>
>> I have also tested with other rigs as well,  Gear rigs, the malcolm rig,
>> and rigs of my own making, its a pretty major speed difference when setting
>> and manipulating keys on referenced models vs local models.
>>
>>
>> As far as how many fcurves.  well... A lot, its an entire rig,  its like
>> 150 objects, and we are keying their entire srt. as the animators are
>> currently blocking animation, so they key the entire character at once.
>>
>>
>> 2014 is a bit faster, but not massively so. And we don't have the luxury
>> of moving our pipeline to 2014 right now, our tools are written for 2013 at
>> the moment and we are going through a major tools development phase
>>
>>
>>
>>
>>
>> On Tue, May 21, 2013 at 8:24 AM, Raffaele Fragapane <
>> raffsxsil...@googlemail.com> wrote:
>>
>>> 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 addressed in 2013 already, I believe).
>>>
>>>
>>> On Tue, May 21, 2013 at 9:28 AM, Jeremie Passerin 
>>> wrote:
>>>
>>>> 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 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  wrote:
>>>>>
>>>>>> 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, ivan tay wrote:
>>>>>>
>>>>>>> Hi Enrique,
>>>>>>>
>>>&

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 in 2014 and it is better, by like 30 % but its still
massively slower than it would be if the model was in Local Mode.

Seeing as how well Softimage's referenced model and Deltas work together,
it is a major reason we use Softimage here at this studio, I would expect
the speed of keyframing to be very fast on referenced models, it should be
just as fast I dare say, otherwise its a massive hit on their usability.

I have also tested with other rigs as well,  Gear rigs, the malcolm rig,
and rigs of my own making, its a pretty major speed difference when setting
and manipulating keys on referenced models vs local models.


As far as how many fcurves.  well... A lot, its an entire rig,  its like
150 objects, and we are keying their entire srt. as the animators are
currently blocking animation, so they key the entire character at once.


2014 is a bit faster, but not massively so. And we don't have the luxury of
moving our pipeline to 2014 right now, our tools are written for 2013 at
the moment and we are going through a major tools development phase





On Tue, May 21, 2013 at 8:24 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> 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
> addressed in 2013 already, I believe).
>
>
> On Tue, May 21, 2013 at 9:28 AM, Jeremie Passerin wrote:
>
>> 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 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  wrote:
>>>
>>>> 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, ivan tay wrote:
>>>>
>>>>> 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, 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 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 testing and verified that it is quite slow.
>>>>>>>
>>>>>>>
>>>>>>> *I made the referenced model local, and the speed of setting or
>>>>>>> manipulating keys increased quite dramatically.*
>>>>>>>
>>>>>>> We are using GEAR rigs on this project, which I've never had an
>>>>>>> issue with before, and I don't really think its gears fault. Maybe its
>>>>>>> something I layered ontop.
>>>>>>>
>>>>>>> Has anyone run into this problem before?  Our pipeline is heavily
>>>>>>> dependent on referenced models and I have no plans to use local models 
>>>>>>> in
>>>>>>> our pipeline at all.  I'm hoping that its just one little oversight 
>>>>>>> that is
>>>>>>> causing this.
>>>>>>>
>>>>>>> Any insight would be appreciated.
>>>>>>>
>>>>>>> -Enrique
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Our users will know fear and cower before our software! Ship it! Ship it
>>> and let them flee like the dogs they are!
>>>
>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 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, 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 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 testing and verified that it is quite slow.
>>>
>>>
>>> *I made the referenced model local, and the speed of setting or
>>> manipulating keys increased quite dramatically.*
>>>
>>> We are using GEAR rigs on this project, which I've never had an issue
>>> with before, and I don't really think its gears fault. Maybe its something
>>> I layered ontop.
>>>
>>> Has anyone run into this problem before?  Our pipeline is heavily
>>> dependent on referenced models and I have no plans to use local models in
>>> our pipeline at all.  I'm hoping that its just one little oversight that is
>>> causing this.
>>>
>>> Any insight would be appreciated.
>>>
>>> -Enrique
>>>
>>
>>
>

Re: Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 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 testing and verified that it is quite slow.
>
>
> *I made the referenced model local, and the speed of setting or
> manipulating keys increased quite dramatically.*
>
> We are using GEAR rigs on this project, which I've never had an issue with
> before, and I don't really think its gears fault. Maybe its something I
> layered ontop.
>
> Has anyone run into this problem before?  Our pipeline is heavily
> dependent on referenced models and I have no plans to use local models in
> our pipeline at all.  I'm hoping that its just one little oversight that is
> causing this.
>
> Any insight would be appreciated.
>
> -Enrique
>

Setting and Manipulating Keys Very slow in Referenced Model

[Enrique Caballero]

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 testing and verified that it is quite slow.


*I made the referenced model local, and the speed of setting or
manipulating keys increased quite dramatically.*

We are using GEAR rigs on this project, which I've never had an issue with
before, and I don't really think its gears fault. Maybe its something I
layered ontop.

Has anyone run into this problem before?  Our pipeline is heavily dependent
on referenced models and I have no plans to use local models in our
pipeline at all.  I'm hoping that its just one little oversight that is
causing this.

Any insight would be appreciated.

-Enrique

Limiting stretching on a series of surface constraints

[Enrique Caballero]

Hey guys,
  I was hoping someone could help me out with this question.

If i needed to limit the ability of  stretching on a series of nulls that
are surface constrained to a nurbs ribbon how would i go about doing it?

On a nurbs curve i always just divided  the original length of the curve,
by the new length, then multiplied the path cns percentage by that offset,
worked just fine, pretty standard stuff

but is there an easy way for me to find the length of a nurbs surface? I
cant find anything in ICE that does that easily for me or anything in the
SDK. If there was

Any help would be appreciated, I feel a bit silly asking, I bet its pretty
simple.

-Enrique

Re: Test for Inverted UV's

[Enrique Caballero]

Thanks Martin, thats what i suspected as well, but I havent done uvs in
almost 3 years so wasnt sure. I appreciate it. Will pass the info forward


On Sun, May 12, 2013 at 1:29 PM, Martin  wrote:

> Only one UV polyface in an island has been inverted/flipped ?
>
> If that's the case you should be able to detect it in your Tex.Editor.
>
> Softimage doesn't "merge" UV samples that aren't adjacent so their borders
> should appear green/blue in the Text.Editor when you select them because
> they are not "merged".
>
> If the samples are adjacents and have the same coordinates, then they
> shouldn't have green/blue borders.
>
> M.Yara
>
>
>
> On Sun, May 12, 2013 at 12:59 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> sorry guys, wrote that quickly
>>
>> k so apparently these artists have somehow managed to create UVS where
>> some of the polygons in that UV island/shell/hull are facing in the
>> opposite direction.  So that on those polygons the bump and displacement
>> maps are inverted.
>>
>> I'm not sure how they actually did this, they probably cut up the uv's
>> and then tried to put them back together, but somehow messed it up, and now
>> some of the UV's are flipped.
>>
>> They are new starters from a company that used 3dsmax so they are still
>> getting used to the xsi workflow. They have asked us if there's a quick way
>> to tell if a UV is facing in the wrong direction. Apparently in 3dsmax the
>> uv's  would be a different color in the uv editor.
>>
>> anyway i dont think that there is, as I've never ran into this issue
>> before, when I UV i just a combination of projections and uv unwrap. and
>> everything comes out okay
>>
>>
>> On Sun, May 12, 2013 at 8:57 AM, Raffaele Fragapane <
>> raffsxsil...@googlemail.com> wrote:
>>
>>> Was about to ask for the same. For those of us who don't know max
>>> inverted UVs and a stitching where it wouldn't be blatantly obvious don't
>>> make a lot of sense in the same sentence :)
>>>
>>>
>>> On Sun, May 12, 2013 at 10:54 AM, Matt Lind wrote:
>>>
>>>>  define inverted uv
>>>>
>>>>  --
>>>> *From:* softimage-boun...@listproc.autodesk.com [
>>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Enrique
>>>> Caballero [enriquecaball...@gmail.com]
>>>> *Sent:* Saturday, May 11, 2013 6:58 AM
>>>> *To:* softimage@listproc.autodesk.com
>>>> *Subject:* Test for Inverted UV's
>>>>
>>>>   Hey guys,
>>>> I'm passing forward a question from one of our new artists here that
>>>> stumped me.
>>>>
>>>>  Is there a quick way to check for inverted UV's in softimage.  3dsmax
>>>> apparently has one built in.
>>>>
>>>>
>>>>  Basically sometimes the uv's get stitched together inverted and they
>>>> are having a hard time detecting these.
>>>>
>>>>  Thanks,
>>>>
>>>>  -Enrique
>>>>
>>>
>>>
>>>
>>> --
>>> Our users will know fear and cower before our software! Ship it! Ship it
>>> and let them flee like the dogs they are!
>>>
>>
>>
>

Re: Test for Inverted UV's

[Enrique Caballero]

sorry guys, wrote that quickly

k so apparently these artists have somehow managed to create UVS where some
of the polygons in that UV island/shell/hull are facing in the opposite
direction.  So that on those polygons the bump and displacement maps are
inverted.

I'm not sure how they actually did this, they probably cut up the uv's and
then tried to put them back together, but somehow messed it up, and now
some of the UV's are flipped.

They are new starters from a company that used 3dsmax so they are still
getting used to the xsi workflow. They have asked us if there's a quick way
to tell if a UV is facing in the wrong direction. Apparently in 3dsmax the
uv's  would be a different color in the uv editor.

anyway i dont think that there is, as I've never ran into this issue
before, when I UV i just a combination of projections and uv unwrap. and
everything comes out okay


On Sun, May 12, 2013 at 8:57 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> Was about to ask for the same. For those of us who don't know max inverted
> UVs and a stitching where it wouldn't be blatantly obvious don't make a lot
> of sense in the same sentence :)
>
>
> On Sun, May 12, 2013 at 10:54 AM, Matt Lind wrote:
>
>>  define inverted uv
>>
>>  --
>> *From:* softimage-boun...@listproc.autodesk.com [
>> softimage-boun...@listproc.autodesk.com] On Behalf Of Enrique Caballero [
>> enriquecaball...@gmail.com]
>> *Sent:* Saturday, May 11, 2013 6:58 AM
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Test for Inverted UV's
>>
>>   Hey guys,
>> I'm passing forward a question from one of our new artists here that
>> stumped me.
>>
>>  Is there a quick way to check for inverted UV's in softimage.  3dsmax
>> apparently has one built in.
>>
>>
>>  Basically sometimes the uv's get stitched together inverted and they
>> are having a hard time detecting these.
>>
>>  Thanks,
>>
>>  -Enrique
>>
>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Test for Inverted UV's

[Enrique Caballero]

Hey guys,
I'm passing forward a question from one of our new artists here that
stumped me.

Is there a quick way to check for inverted UV's in softimage.  3dsmax
apparently has one built in.


Basically sometimes the uv's get stitched together inverted and they are
having a hard time detecting these.

Thanks,

-Enrique

Re: 2014 in production anyone?

[Enrique Caballero]

Hmm i thought 2012 and 2013 were decent releases.  13 for some reason
really slowed down importing of referenced models that had ICE strands in
them

but 2011 was a very troublesome release, the broken shader issue was painful


On Tue, May 7, 2013 at 11:59 AM, Matt Lind  wrote:

> Let me follow up and say 2014 is probably a safer bet to use in production
> than 2013, 2012 or 2011.
>
> ** **
>
> I would definitely stay away from 2012 as there are some hidden gremlins
> that won’t show up until the data is migrated forward into a newer version.
> 
>
> ** **
>
> ** **
>
> Matt
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Sylvain Lebeau
> *Sent:* Monday, May 06, 2013 8:51 PM
> *To:* softimage@listproc.autodesk.com
> *Cc:* 3...@shedmtl.com
> *Subject:* Re: 2014 in production anyone?
>
> ** **
>
> My god Matt thanks so much for this bible!!! 
>
> ** **
>
> Altought we dont rely on rt shaders, your manifesto is such a good pointer
> man Much appreciated
>
> ** **
>
> Thanks a big bunch! 
>
> ** **
>
> Sly
>
>
> *Sylvain Lebeau // SHED
> *V-P/Visual effects supervisor
> 1410, RUE STANLEY, 11E ÉTAGE MONTRÉAL (QUÉBEC) H3A 1P8
> T 514 849-1555 F 514 849-5025WWW.SHEDMTL.COM 
>
>
> On 2013-05-06, at 22:31, Matt Lind  wrote:
>
> We haven’t switched to 2014 yet, but in testing we’ve encountered a number
> of regressions in important areas to us.  Let me emphasize what is
> important to us might not be important to you.
>
>  
>
> In our case the problem has been the ability to upgrade and migrate old
> data into a current release and have it continue to function as expected –
> e.g. be durable.  For example, we use realtime shaders very heavily in our
> production…in fact every single asset in our production uses them.  But
> there’s always some type of bug/regression in each new release with
> realtime shading preventing an upgrade.  We were stuck on 7.5 for years
> until 2013 SP1 finally resolved the shading issues.  However, upon testing
> everything else we discovered many animation features regressed such as
> ability to import FCurve data efficiently, rotation order not computed
> properly on transforms, scene doesn’t update/refresh properly, cut n’ paste
> FCurve keys fails, envelopes get really cranky/crash when a deformer is not
> found, callbacks/events intermittently fail or don’t execute, scene layers
> misbehave, etc…  It’s been whack-a-mole.  Many bugs we’ve found in 2013 are
> still present in 2014.  Problem is we cannot consistently reproduce some of
> these bugs as the variables leading to their appearance can be complex much
> like needing the stars to align a certain way before the issue is
> revealed.  We just don’t have a complete picture of all the stars involved
> in the problem yet to be able to submit a report for further
> investigation.  It’s a real stressing point in our production.
>
>  
>
> In regards to 2014, the realtime shading architecture migration from RTS 3
> to RTS 4 doesn’t work, or there is no migration path.  Since RTS 3 is
> technically deprecated (but still supported) that is a problem for us.  If
> a shader is not installed, Softimage won’t open the scene/.emdl.  In fact,
> Softimage will crash in spectacular fashion.  If you don’t use realtime
> shaders, then this won’t be an issue for you.
>
>  
>
> If I had to summarize the main issues, it seems like many features in
> recent releases touched on core components and were either inserted in rush
> fashion or sloppily implemented leading to stupid bugs and regressions.
> These largely revolve around system updates and notifications on the
> backend.  For the other stuff where it’s more data centric, the data gets
> into scene files and becomes a problem when the data is migrated forward to
> a newer release and needs to be iterated by an artist.  Problem is the data
> no longer behaves the same.  We’ve had a few models created in 7.5 that
> when brought into current versions don’t react the same way.  Either data
> in the delta is getting interpreted differently, or in some cases, the file
> just won’t load.  Envelopes are a victim of this specific problem.
>
>  
>
> I could go on, but the moral of the story is to test thoroughly before
> upgrading.  Of course, that lesson applies to every product.
>
>  
>
>  
>
> Matt
>
>  
>
>  
>
>  
>
>  
>
>  
>
> *From:* softimage-boun...@listproc.autodesk.com [
> mailto:softimage-boun...@listproc.autodesk.com]
> *On Behalf Of *Sylvain Lebeau
> *Sent:* Monday, May 06, 2013 4:25 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* 2014 in production anyone?
>
>  
>
> Hi everyone…. 
>
>  
>
> After flaming ferosiously at the 2014 release, seeing the bug fixes list
> quite brought me back down to earth. Very extensiv

Re: Aw: RE: Graphics update problem in animation editors

[Enrique Caballero]

we want to switch to linux and have been toying with the idea for a while,
part of the reason we havent is because there currently isnt a PYQT for
Softimage Linux plugin.  If one did come into existence it would help us
finally switch over



On Sat, May 4, 2013 at 8:55 PM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> Why are you even using windows? Unless you mean the production, FOH and
> secretary computers, in that case I think they'll be alright with aero on
> or off :p
>
> More seriously, have a read:
> http://en.wikipedia.org/wiki/Desktop_Window_Manager
>
> http://windows7support247.blogspot.com.au/2011/01/enable-or-disable-desktop-composition.html
>
> It's a GOOD thing :p
>
>
>
> On Sat, May 4, 2013 at 4:04 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> i didnt know this, aero is off on all of our computers at the office.
>>
>>
>> On Sat, May 4, 2013 at 6:20 AM, Raffaele Fragapane <
>> raffsxsil...@googlemail.com> wrote:
>>
>>> People mistook it for THE performance hog in the system when vista first
>>> came out, and agreeably it glitched out quite a few older apps and games.
>>>
>>> Most people though aren't familiar with how desktop management and
>>> overlaying/compositing has changed, and the fact that part of Aero is its
>>> compositing, and that it was about high time MS started doing it and it's a
>>> good thing.
>>>
>>> As Luc said if you think it's a performance hog (and it really isn't,
>>> but people will placebo out on anything), or you dislike the effects, you
>>> can turn those off individually. Modern desktop compositing though you do
>>> want to have.
>>>
>>> I still hear people saying you should turn off your page file for faster
>>> performance (rubbish), complaining "their windows takes all the memory!"
>>> but you can "fix it" by making it cache less aggressively (more rubbish, an
>>> OS that doesn't use every last byte of memory smartly is an OS not worth
>>> using) and so on.
>>>
>>>
>>>
>>> On Sat, May 4, 2013 at 8:13 AM, Sam  wrote:
>>>
>>>> I never understood all the hate for Aero. 
>>>>
>>>> ** **
>>>>
>>>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>>>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Wuijster
>>>> *Sent:* Friday, May 03, 2013 6:29 AM
>>>> *To:* softimage@listproc.autodesk.com
>>>> *Subject:* Re: Aw: RE: Graphics update problem in animation editors
>>>>
>>>> ** **
>>>>
>>>> Most apps rely on the default behavior of Windows itself.
>>>> So by turning off Aero, you may introduce unwanted behavior in an
>>>> app. ;-)
>>>>
>>>> 
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> Rob
>>>>
>>>> \/-\/\/
>>>>
>>>> On 3-5-2013 15:22, Leo Quensel wrote:
>>>>
>>>> I have the same problem all the time. I hate Aero and don't want it.
>>>> Why should we have to switch it on to prevent bugs from happening?
>>>>
>>>>  
>>>>
>>>> Leo
>>>>
>>>>   
>>>>
>>>> *Gesendet:* Freitag, 03. Mai 2013 um 15:03 Uhr
>>>> *Von:* "Sean Donnelly" 
>>>> 
>>>> *An:* "softimage@listproc.autodesk.com"
>>>>  
>>>> *Betreff:* RE: Graphics update problem in animation editors
>>>>
>>>> Do you have Window Aero turned on? It should be.
>>>>
>>>> Sean
>>>>
>>>> From: softimage-boun...@listproc.autodesk.com [
>>>> mailto:softimage-boun...@listproc.autodesk.com]
>>>> On Behalf Of Dan Yargici
>>>> Sent: Friday, May 03, 2013 8:43 AM
>>>> To: Morten Bartholdy; softimage@listproc.autodesk.com
>>>> Subject: Re: Graphics update problem in animation editors
>>>>
>>>> I get it all the time in the Render Tree and ICE Tree, it can be really
>>>> infuriating.
>>>>
>>>> DAN
>>>>
>>>> On Fri, May 3, 2013 at 3:16 PM, Morten Bartholdy >>> <mailto:x...@colorshopvfx.dk> > wrote:
>>>>
>>>> I am experiencing an annoying problem with lacking update in animation
>>>> editors and other curve editors. I can select (tag) a key and it will not
>>>> show the tagged point - I have to move or resize the window to force an
>>>> update. Sometimes only part of the window updates until I move or resize,
>>>> making it difficult to work with any type of curve editor.
>>>>
>>>>
>>>>
>>>> I am on Soft 2013 SP1 Win7 x64, Geforce GTX 570 driver version 311.06.
>>>>
>>>>
>>>>
>>>> I am guessing this is not a bug, merely a driver issue, so I am curious
>>>> to know if others have experienced something similar and if not, which
>>>> version drivers you use?
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Morten
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 2013.0.3272 / Virus Database: 3162/6292 - Release Date:
>>>> 05/02/13
>>>>
>>>> ** **
>>>>
>>>
>>>
>>>
>>> --
>>> Our users will know fear and cower before our software! Ship it! Ship it
>>> and let them flee like the dogs they are!
>>>
>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Aw: RE: Graphics update problem in animation editors

[Enrique Caballero]

i didnt know this, aero is off on all of our computers at the office.


On Sat, May 4, 2013 at 6:20 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> People mistook it for THE performance hog in the system when vista first
> came out, and agreeably it glitched out quite a few older apps and games.
>
> Most people though aren't familiar with how desktop management and
> overlaying/compositing has changed, and the fact that part of Aero is its
> compositing, and that it was about high time MS started doing it and it's a
> good thing.
>
> As Luc said if you think it's a performance hog (and it really isn't, but
> people will placebo out on anything), or you dislike the effects, you can
> turn those off individually. Modern desktop compositing though you do want
> to have.
>
> I still hear people saying you should turn off your page file for faster
> performance (rubbish), complaining "their windows takes all the memory!"
> but you can "fix it" by making it cache less aggressively (more rubbish, an
> OS that doesn't use every last byte of memory smartly is an OS not worth
> using) and so on.
>
>
>
> On Sat, May 4, 2013 at 8:13 AM, Sam  wrote:
>
>> I never understood all the hate for Aero. 
>>
>> ** **
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Wuijster
>> *Sent:* Friday, May 03, 2013 6:29 AM
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: Aw: RE: Graphics update problem in animation editors
>>
>> ** **
>>
>> Most apps rely on the default behavior of Windows itself.
>> So by turning off Aero, you may introduce unwanted behavior in an
>> app. ;-)
>>
>> 
>>
>> ** **
>>
>> ** **
>>
>> Rob
>>
>> \/-\/\/
>>
>> On 3-5-2013 15:22, Leo Quensel wrote:
>>
>> I have the same problem all the time. I hate Aero and don't want it. Why
>> should we have to switch it on to prevent bugs from happening?
>>
>>  
>>
>> Leo
>>
>>   
>>
>> *Gesendet:* Freitag, 03. Mai 2013 um 15:03 Uhr
>> *Von:* "Sean Donnelly" 
>> 
>> *An:* "softimage@listproc.autodesk.com" 
>>  
>> *Betreff:* RE: Graphics update problem in animation editors
>>
>> Do you have Window Aero turned on? It should be.
>>
>> Sean
>>
>> From: softimage-boun...@listproc.autodesk.com [
>> mailto:softimage-boun...@listproc.autodesk.com]
>> On Behalf Of Dan Yargici
>> Sent: Friday, May 03, 2013 8:43 AM
>> To: Morten Bartholdy; softimage@listproc.autodesk.com
>> Subject: Re: Graphics update problem in animation editors
>>
>> I get it all the time in the Render Tree and ICE Tree, it can be really
>> infuriating.
>>
>> DAN
>>
>> On Fri, May 3, 2013 at 3:16 PM, Morten Bartholdy >  > wrote:
>>
>> I am experiencing an annoying problem with lacking update in animation
>> editors and other curve editors. I can select (tag) a key and it will not
>> show the tagged point - I have to move or resize the window to force an
>> update. Sometimes only part of the window updates until I move or resize,
>> making it difficult to work with any type of curve editor.
>>
>>
>>
>> I am on Soft 2013 SP1 Win7 x64, Geforce GTX 570 driver version 311.06.
>>
>>
>>
>> I am guessing this is not a bug, merely a driver issue, so I am curious
>> to know if others have experienced something similar and if not, which
>> version drivers you use?
>>
>>
>>
>> Thanks
>>
>> Morten
>>
>>
>>
>>
>>
>>
>>  
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2013.0.3272 / Virus Database: 3162/6292 - Release Date: 05/02/13
>> 
>>
>> ** **
>>
>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: PyQtForSoftimage: typing in an 'editable' combobox seems to be passed on to Softimage shortcuts?

[Enrique Caballero]

hmm it seems to me that you just have to set the keyboard focus to STRONG
on your QComboBox

I've used Pyqt for Softimage very heavily for 2 years now and have never
run into this issue.


On Fri, May 3, 2013 at 7:41 AM, Steven Caron  wrote:

> yes, but please make sure to use the github issues to get this tracked. i
> am all for continuing the conversation here and everyone sharing their
> experience here. but i will certainly forget if i don't have it logged
> somewhere.
>
> thanks everyone for continuing to push the plugin. it makes jo and me
> happy :)
>
> s
>
>
> On Thu, May 2, 2013 at 4:25 PM, Simon Anderson <
> simonbenandersonl...@gmail.com> wrote:
>
>> Havent had that happen either, will do a test this evening. Im running a
>> custom build at the moment at home(same code just built with a newer
>> version of python and Qt), but will check it out and let you know if im
>> having the same error.
>>
>>
>>
>> On Fri, May 3, 2013 at 3:44 AM, Steven Caron  wrote:
>>
>>> i have not noticed this... could you log and issue on the github page
>>> with some sample code?
>>>
>>> s
>>>
>>>
>>> On Thu, May 2, 2013 at 9:30 AM, philipp.oeser wrote:
>>>
 **
  Hi list,

  I stumbled over this today:
  when you have an "editable" QComboBox and start typing, the
 events/letters seem to be passed on to Softimage.
  This results in keyboard shortcuts being performed in Softimage
 instead of text being written in the QComboBox...
  Not sure if this is the only widget where that happens (it's the first
 that I noticed).

  Is this a known issue? Any workarounds?

  Greetz
  Philipp

  P.S.: still using PyQtForSoftimage_beta5.xsiaddon from 05/02/2013

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

Re: Creation: Horde - new Softimage integration

[Enrique Caballero]

yep amazing.  I love how they actually care about integrating into
Softimage as well.


On Wed, May 1, 2013 at 8:55 PM, olivier jeannel wrote:

>  Wow !
> Super innovative ! Makes me hyper enthousiastic (the hysteric way) each
> time I watch your demos guys :D
>
>
> Le 01/05/2013 03:42, Paul Doyle a écrit :
>
>  Hi guys – I've held off posting any updates on Horde as I knew we had a
> sweet Softimage/ICE integration in the pipe. The nice thing with our
> locomotion system is that it lends itself well to closer shots when you're
> working with a few characters - and combined with ICE that makes for some
> really interesting options. Helge has only scratched the surface with this,
> but already you can see just how awesome the combination is.
>
>
>
> 1)  Reel: https://vimeo.com/61358674
>
> 2)  Maya integration info:
> http://fabricengine.com/creation-modules/inside-maya/ (there's more of a
> breakdown here that we don't duplicate in the Softimage section, so I
> recommend looking here first).
>
> 3)  Softimage integration:
> http://fabricengine.com/creation-modules/inside-softimage/
>
> 4)  Main page: http://fabricengine.com/creation-modules/horde/
>
>
> We're currently in closed alpha/beta - if you're a commercial studio and
> you'd like to help with the testing program, please drop me a line.
>
>  Cheers,
>
>  Paul
>
>
>

Re: scripting: returning value in SIImportMatLib

[Enrique Caballero]

I hated this about Softimage when I first started learning how to script.
 I was both learning Python and the Softimage SDK at the same time.  Little
quirks like this really messed with my head.

Also how very little in the documentation has any Python examples,
everything was in Jscript of Vscript.  Made my life hell.

And ISVT collections to this day still annoy me as I find them ugly and
clunky to work with.

Now after years of getting used to the SDK I still look back on the early
days and shiver.  It really did suck to have to figure all this stuff out
the hard way.

We recently hired a junior TD here and the first thing I did was get her to
watch Rafaele's training videos.  All the stuff I had to figure out from
years of trial and error was in there.

I'm actually a bit jealous

http://tod.cgsociety.org/




On Thu, Apr 25, 2013 at 9:44 PM, Alan Fregtman wrote:

> *ISIVTCollection* collections exist because *Python was not in Softimage
> since the very beginning*, so a few of the SDK command implementations
> used these so-called "output arguments" feature (since a big chunk of the
> core commands are written in VBScript, which supports it.) The special
> collection object was a way of getting them to be accessible automatically
> without having to go back and add new commands.
>
>
>
> >>*  Either way, I don't think the new SDK docs really show what
> arguments are the ones returned
> *
>
> Perhaps not clearly, but they *do* show. For example:
>
> http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/si_cmds/PickElement.html
>
> Note how in the 2nd paragraph they mention output arguments, then in the
> Parameters list, for "*PickedElement*", "*ButtonPressed*" and "*
> ModifierPressed*" the Description of the parameter reads *"Returns the..."
> *. That's how you know it's an *output argument*; because it's trying to
> return something.
>
> The Parameter name for the output argument is the key for the
> ISIVTCollection returned, so in this it might be something like *
> Application.PickElement(...)("PickedElement")* for example.
>
>
> Cheers,
>
>-- Alan
>
>
>
> On Thu, Apr 25, 2013 at 9:10 AM, Eric Thivierge wrote:
>
>>  Yeah certain commands aren't, let's say, specifically compatible with
>> Python or other scripting languages that don't support output arguments.
>> That's an ugly explanation but is pretty much how I think of it. Either
>> way, I don't think the new SDK docs really show what arguments are the ones
>> returned so it may be a bit tough to know but if you take a look at the
>> various code around and maybe some of the older docs you'll see how it
>> works.
>>
>> This may help too in Python:
>>
>> http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/index.html?url=files/ISIVTCollection.htm,topicNumber=d30e53970
>>
>>
>> On 25/04/2013 7:57 AM, David Barosin wrote:
>>
>>  Look at these links - they help explain what ISIVTCollections are and
>> when they are returned.
>>
>> http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/index.html?url=files/outarg_bylang.htm,topicNumber=d30e53710
>>
>> http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/index.html?url=files/ISIVTCollection.htm,topicNumber=d30e53970
>>
>>
>>
>> On Thu, Apr 25, 2013 at 7:36 AM, Martin  wrote:
>>
>>> Hi list,
>>>
>>>  I have a question about SIImportMatLib command.
>>>
>>>  I was trying to get the return value in jscript without success until
>>> I checked Eric's  ET_PassManager code where he is using
>>>
>>>  oMatLib = xsi.SIImportMatLib(strMatLibPath)("Value")
>>>
>>>  and the oMatLib gets the return value.
>>>
>>>  It works (in jscript too) and I'm using it now, but why does it work?
>>>
>>>  I mean, where this ("Value") thing comes from?
>>>
>>> When should I use it?
>>>
>>>  Thanks
>>>
>>>
>>>
>>>  M.Yara
>>>
>>>
>>
>>
>

Re: GEAR question

[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



On Wed, Apr 24, 2013 at 4:45 PM, Peter Agg  wrote:

> 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.
>
>
> On 24 April 2013 09:36, Sebastian Kowalski  wrote:
>
>> 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.mailli...@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
>> >>
>> >>
>> >>
>> >
>> > 
>>
>>
>>
>

Re: GEAR question

[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




On Wed, Apr 24, 2013 at 11:10 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> 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.
>
>
> On Wed, Apr 24, 2013 at 1:05 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> 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
>>
>>
>> On Wed, Apr 24, 2013 at 10:47 AM, Simon Anderson <
>> simonbenandersonl...@gmail.com> wrote:
>>
>>> 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.
>>>
>>>
>>> On Wed, Apr 24, 2013 at 12:11 PM, Enrique Caballero <
>>> enriquecaball...@gmail.com> wrote:
>>>
>>>> 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?
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Apr 24, 2013 at 8:24 AM, Guillaume Laforge <
>>>> guillaume.laforge...@gmail.com> wrote:
>>>>
>>>>> Getting Kinematics Data is not slow. Setting Kinematics Data IS slow
>>>>> :).
>>>>>
>>>>>
>>>>> On Tue, Apr 23, 2013 at 4:50 PM, Alan Fregtman <
>>>>> alan.fregt...@gmail.com> wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 23, 2013 at 4:39 PM, Matt Morris wrote:
>>>>>>
>>>>>>> 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  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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> ---
>>> Simon Ben Anderson
>>> blog: http://vinyldevelopment.wordpress.com/
>>>
>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: GEAR question

[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


On Wed, Apr 24, 2013 at 10:47 AM, Simon Anderson <
simonbenandersonl...@gmail.com> wrote:

> 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.
>
>
> On Wed, Apr 24, 2013 at 12:11 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> 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?
>>
>>
>>
>>
>> On Wed, Apr 24, 2013 at 8:24 AM, Guillaume Laforge <
>> guillaume.laforge...@gmail.com> wrote:
>>
>>> Getting Kinematics Data is not slow. Setting Kinematics Data IS slow :).
>>>
>>>
>>> On Tue, Apr 23, 2013 at 4:50 PM, Alan Fregtman 
>>> wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 23, 2013 at 4:39 PM, Matt Morris  wrote:
>>>>
>>>>> 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  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
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> ---
> Simon Ben Anderson
> blog: http://vinyldevelopment.wordpress.com/
>

Re: GEAR question

[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?




On Wed, Apr 24, 2013 at 8:24 AM, Guillaume Laforge <
guillaume.laforge...@gmail.com> wrote:

> Getting Kinematics Data is not slow. Setting Kinematics Data IS slow :).
>
>
> On Tue, Apr 23, 2013 at 4:50 PM, Alan Fregtman wrote:
>
>> 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.
>>
>>
>>
>>
>> On Tue, Apr 23, 2013 at 4:39 PM, Matt Morris  wrote:
>>
>>> 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  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
>>>
>>
>>
>

Re: PPG Logic - Changing siControlBitmap without Refresh

[Enrique Caballero]

im with Simon. We only use PPG's here on very minor occasions  We have been
using PYQT heavily simply due to how much time it saves. We have very few
TD's here. I hate seeing them spend a week on a PPG that even if done
incredibly well cant hold a candle to something thats made in PYQT in less
then half the time.



On Mon, Apr 22, 2013 at 6:40 PM, Simon Anderson <
simonbenandersonl...@gmail.com> wrote:

> Its been a while since I had to do any PPG editing but ill try rack my
> memory. Have you tried inpecting the parameter after you have reloaded it,
> not sure if that would work, but maybe give it a try
>
> What I would suggest if your making if for your studio is look into pyQt,
> I had to design a similar asset management/tracking tool for about 150
> artists and we utilized pyQt for alot of things, we also used PPG's but in
> the case of plugins that required images we used pyQt, else if you dont
> want to do that, I would suggest C++.
>
> Si.
>
>
> On Mon, Apr 22, 2013 at 6:51 PM, Andreas Böinghoff 
> wrote:
>
>>  Hey Stefan,
>>
>> SI reselects the selection of the Listbox properly, but doesn't reenter
>> the Listbox. If I press the arrow down key SI does the
>> Application.PlaybackStop() command.
>>
>> Andreas
>>
>>
>>
>>
>> On 4/22/2013 10:32 AM, Stefan Kubicek wrote:
>>
>> Most of the PPG widget types need a PPG.Refresh() when changed, e.g. all
>> the enum types (list widget etc), and most likely also the bitmap type.
>> What's strange is that the selection in the listbox changes/disappears when
>> refreshing the PPG. If that widget is related to an actual parameter that
>> holds a value on the PPG it should be properly reselected I think.
>>
>>
>>
>> Hey Everyone,
>>
>> I'm working on a Model/Asset Management system for our Company.  As base
>> for my UI I'm using the PPG logic example of Stephen Blair:
>> Google Group Link
>>
>> 
>> Everything is working fine so far, except one annoying thing: If I click
>> into my Model-Listbox I have to fire a PPG.Refesh() to refresh the
>> preview picture. This leads to an deselection of the Listbox and the
>> user can't click throw the List with the arrow down key to get a fast
>> preview.
>>
>> Is it possible to change the Bitmap of my siControlBitmap UI Item on the
>> fly without firing a PPG.Refresh()?
>>
>> Somthing like that:
>> def ppgLogic_oModelList_OnChanged():
>>  myPPG = PPG.Inspected(0)
>>  myLayout = PPG.PPGLayout
>>  myPreviewPic.SetAttribute(c.siUIFilePath, oPicturePath )
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>  ANDREAS BÖINGHOFF
>>
>> 3D Artist
>>
>>
>>
>>
>>  schönheitsfarm production
>>
>> GmbH & Co. KG
>>
>>
>>schönheitsfarm
>>
>> hamburg
>>
>>   lippmannstrasse 79
>>
>>   22769 hamburg
>>
>>   t   +4940 432 91 200
>>
>>   f   +4940 432 91 222
>>
>>
>>
>>
>>
>> schönheitsfarm
>>
>> düsseldorf
>>
>>   steinstraße 11
>>
>>   40212 düsseldorf
>>
>>   t   +49211 913 701 0
>>
>>   f   +49211 913 701 99
>>
>>
>>
>>
>>
>> schönheitsfarm
>>
>> frankfurt
>>
>>   hanauer landstrasse 151-153
>>
>>   60314 frankfurt
>>
>>   t   +4969 484 484 90
>>
>>
>>
>>
>>
>>
>>
>>
>>w   www.s-farm.de
>>
>>
>>
>>  Geschäftsführung Manfred Brunwey
>>
>> DE 214892548 | Amtsgericht Hamburg HRA 95793
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> ---
> Simon Ben Anderson
> blog: http://vinyldevelopment.wordpress.com/
>

Re: PPG Logic - Changing siControlBitmap without Refresh

[Enrique Caballero]

wish i could help ya, i do everything with Steven Caron and Jo's PyQT
plugin now.  Working with PPG's makes my head hurt


On Mon, Apr 22, 2013 at 4:03 PM, Andreas Böinghoff wrote:

>  Hey Everyone,
>
> I'm working on a Model/Asset Management system for our Company.  As base
> for my UI I'm using the PPG logic example of Stephen Blair:
> Google Group 
> Link
> Everything is working fine so far, except one annoying thing: If I click
> into my Model-Listbox I have to fire a PPG.Refesh() to refresh the preview
> picture. This leads to an deselection of the Listbox and the user can't
> click throw the List with the arrow down key to get a fast preview.
>
> Is it possible to change the Bitmap of my siControlBitmap UI Item on the
> fly without firing a PPG.Refresh()?
>
> Somthing like that:
> def ppgLogic_oModelList_OnChanged():
> myPPG = PPG.Inspected(0)
> myLayout = PPG.PPGLayout
> myPreviewPic.SetAttribute(c.siUIFilePath, oPicturePath )
>
> --
>
>
>
>
>  ANDREAS BÖINGHOFF
>
> 3D Artist
>
>
>
>
>  schönheitsfarm production
>
> GmbH & Co. KG
>
>
>schönheitsfarm
>
> hamburg
>
>   lippmannstrasse 79
>
>   22769 hamburg
>
>   t   +4940 432 91 200
>
>   f   +4940 432 91 222
>
>
>
>
>
> schönheitsfarm
>
> düsseldorf
>
>   steinstraße 11
>
>   40212 düsseldorf
>
>   t   +49211 913 701 0
>
>   f   +49211 913 701 99
>
>
>
>
>
> schönheitsfarm
>
> frankfurt
>
>   hanauer landstrasse 151-153
>
>   60314 frankfurt
>
>   t   +4969 484 484 90
>
>
>
>
>
>
>
>
>w   www.s-farm.de
>
>
>
>  Geschäftsführung Manfred Brunwey
>
> DE 214892548 | Amtsgericht Hamburg HRA 95793
>
>
>
>
>
>
>
>
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

Hey Ahmidou, I will ask the animators for their feedback and forward you
the results.

That sounds pretty awesome already :)



On Fri, Apr 19, 2013 at 7:36 PM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> i just gota say this is pretty heart warming to see, i think I'll buy one
> on principal even if I'm not necessarily an animator these days, i can use
> it to mark stuff out on models :)
>
>
> On 19 April 2013 09:50, Ahmidou Lyazidi  wrote:
>
>> Hi Enrique, good to know :)
>> Do you have any special special expectation on it? currently I'm planning
>> those features:
>>
>> 2D paint and erase
>> screen space
>> onion skin
>> scene persistance
>> ability to move frames on the timeline
>>
>> I'll eventually add those in a second time:
>> multi layers
>> per layer depth distance
>> per layer opacity
>> surface object space strokes (to draw on objects)
>> wacom presure
>>
>>
>> Cheers
>> ---
>> Ahmidou Lyazidi
>> Director | TD | CG artist
>> http://vimeo.com/ahmidou/videos
>>
>>
>> 2013/4/18 Enrique Caballero 
>>
>>> Not to drive the point too strongly, but if you make this tool Ahmidou
>>> and you do a really good job on it, and price it reasonably, I can promise
>>> to buy between 30-40 licenses of it.
>>>
>>> The animators here are driving me absolutely insane about the topic
>>>
>>>
>>>
>>
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

Not to drive the point too strongly, but if you make this tool Ahmidou and
you do a really good job on it, and price it reasonably, I can promise to
buy between 30-40 licenses of it.

The animators here are driving me absolutely insane about the topic


On Tue, Apr 16, 2013 at 10:55 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> They also allow for most countries, whereas KS is only USA and UK (though
> it's not hard to work your way into it from elsewhere if you're a EU
> citizen and know anybody in the UK). Problem with indiegogo is you have 0
> added visibility from the one you provide yourself, they aren't well
> followed or publicized.
>
> When most of your customer base is likely to come from this list and some
> help from friends though, then it's probably not a big deal and the smaller
> cut makes up for it.
>
>
> On Tue, Apr 16, 2013 at 11:16 AM, Leonard Koch 
> wrote:
>
>> Indiegogo. They take a smaller cut too so that is nice.
>> We've used it to fund some webseries and it has worked out well for us.
>>
>>
>> On Tue, Apr 16, 2013 at 3:12 AM, Ahmidou Lyazidi 
>> wrote:
>>
>>> That's a good idea! Kickstarter is for US or UK resident only, what
>>> would be the best worldwide alternative?
>>>
>>> ---
>>> Ahmidou Lyazidi
>>> Director | TD | CG artist
>>> http://vimeo.com/ahmidou/videos
>>>
>>>
>>> 2013/4/16 Raffaele Fragapane 
>>>
>>>> kickstart it for 10 bucks a pop for late delivery, 20 for early beta,
>>>> and 200 for a studio seat and you might pre-pay it, and gauge actual
>>>> interest over lip service :)
>>>>
>>>>
>>>> On Tue, Apr 16, 2013 at 5:08 AM, Prodeep Ghosh 
>>>> wrote:
>>>>
>>>>> Congratulations Ahmidou, pull out that golden egg quick, its
>>>>> pre-sold!:)
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 15, 2013 at 10:24 PM, Enrique Caballero <
>>>>> enriquecaball...@gmail.com> wrote:
>>>>>
>>>>>> seriously, please make it. im sick of hearing them complain about it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 16, 2013 at 12:52 AM, Enrique Caballero <
>>>>>> enriquecaball...@gmail.com> wrote:
>>>>>>
>>>>>>> every animator at our studio has asked for it, if you make it, we
>>>>>>> would happily pay 50 bux a seat for it
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 15, 2013 at 1:26 PM, Ahmidou Lyazidi <
>>>>>>> ahmidou@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks everyone for the links and the ideas!
>>>>>>>> As Steven said, it's going to be a custom tool, the only element in
>>>>>>>> the scene will be a blob and everything will be draw in openGl.
>>>>>>>> It will probably be around 15$.
>>>>>>>> Also I have have a Maya Artisan like paint almost working with undo
>>>>>>>> ( thanks Aloys and Felix for the tips). I'm trying to see how I can 
>>>>>>>> speed
>>>>>>>> up things now.
>>>>>>>> This one will be free :)
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Ahmidou Lyazidi
>>>>>>>> Director | TD | CG artist
>>>>>>>> http://vimeo.com/ahmidou/videos
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/4/14 Steven Caron 
>>>>>>>>
>>>>>>>>> i think the one ahmidou is proposing would use the custom tool
>>>>>>>>> sdk. this means it wouldn't use curves in the scene like thiago's 
>>>>>>>>> does.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Apr 13, 2013 at 4:47 PM, Toonafish wrote:
>>>>>>>>>
>>>>>>>>>> I think Thiago Costa already made one a while ago :
>>>>>>>>>> http://thiagocosta.net/tc-**sketch-v11-grease-pencil-for-**xsi/<http://thiagocosta.net/tc-sketch-v11-grease-pencil-for-xsi/>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Prodeep Ghosh
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Our users will know fear and cower before our software! Ship it! Ship
>>>> it and let them flee like the dogs they are!
>>>>
>>>
>>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Wanted: FFT ICE node

[Enrique Caballero]

please share :)


On Wed, Apr 17, 2013 at 7:20 PM, Jens Lindgren
wrote:

> That sounds great!
> With iFFT do you mean inverse FFT? I think i need just the FFT but maybe
> you can do both?
>
> /Jens
>
>
> On Wed, Apr 17, 2013 at 1:08 PM, Amaan Akram wrote:
>
>> I wrote it to do 2D iFFT's. Never made it into a fully generic ice node.
>> Given time i could write one.
>>
>> If you need the 2d ifft node then i can send that before the weekend
>> On 17 Apr 2013 11:32, "Jens Lindgren" 
>> wrote:
>>
>>> Awesome! Would be nice to have it before the weekend. Is that possible?
>>> When I'm done with the effect I'm doing I will share the compound here.
>>>
>>> /Jens
>>>
>>>
>>> On Wed, Apr 17, 2013 at 11:25 AM, Amaan Akram 
>>> wrote:
>>>
 I have one... somewhere... how soon do you need it?
 On 17 Apr 2013 10:52, "Jens Lindgren" 
 wrote:

> I wonder if someone out there has a raw FFT ICE node?
> I know there was one supplied with the very early versions of aaOcean
> but I don't have any of those old versions laying around.
>  There also seems to be some different sound plugins for Softimage
> that has FFT built in but I haven't found a raw FFT node.
> I'm looking for a node that can do both 1D and 2D FFT.
> It has happend more than once that I find the need for this and I hope
> in the future there could be some FFT toolkit nodes supplied with 
> Softimage.
>
> Crossing my fingers, hoping there is one out there :)
>
> --
> Jens Lindgren
> --
> Lead Technical Director
> Magoo 3D Studios 
>

>>>
>>>
>>> --
>>> Jens Lindgren
>>> --
>>> Lead Technical Director
>>> Magoo 3D Studios 
>>>
>>
>
>
> --
> Jens Lindgren
> --
> Lead Technical Director
> Magoo 3D Studios 
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

seriously, please make it. im sick of hearing them complain about it.


On Tue, Apr 16, 2013 at 12:52 AM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> every animator at our studio has asked for it, if you make it, we would
> happily pay 50 bux a seat for it
>
>
> On Mon, Apr 15, 2013 at 1:26 PM, Ahmidou Lyazidi wrote:
>
>> Thanks everyone for the links and the ideas!
>> As Steven said, it's going to be a custom tool, the only element in the
>> scene will be a blob and everything will be draw in openGl.
>> It will probably be around 15$.
>> Also I have have a Maya Artisan like paint almost working with undo (
>> thanks Aloys and Felix for the tips). I'm trying to see how I can speed up
>> things now.
>> This one will be free :)
>>
>> Cheers
>>
>> ---
>> Ahmidou Lyazidi
>> Director | TD | CG artist
>> http://vimeo.com/ahmidou/videos
>>
>>
>> 2013/4/14 Steven Caron 
>>
>>> i think the one ahmidou is proposing would use the custom tool sdk. this
>>> means it wouldn't use curves in the scene like thiago's does.
>>>
>>>
>>> On Sat, Apr 13, 2013 at 4:47 PM, Toonafish  wrote:
>>>
>>>> I think Thiago Costa already made one a while ago :
>>>> http://thiagocosta.net/tc-**sketch-v11-grease-pencil-for-**xsi/<http://thiagocosta.net/tc-sketch-v11-grease-pencil-for-xsi/>
>>>>
>>>
>>
>

Re: [Pool] Any interest for a grease pencil tool?

[Enrique Caballero]

every animator at our studio has asked for it, if you make it, we would
happily pay 50 bux a seat for it


On Mon, Apr 15, 2013 at 1:26 PM, Ahmidou Lyazidi wrote:

> Thanks everyone for the links and the ideas!
> As Steven said, it's going to be a custom tool, the only element in the
> scene will be a blob and everything will be draw in openGl.
> It will probably be around 15$.
> Also I have have a Maya Artisan like paint almost working with undo (
> thanks Aloys and Felix for the tips). I'm trying to see how I can speed up
> things now.
> This one will be free :)
>
> Cheers
>
> ---
> Ahmidou Lyazidi
> Director | TD | CG artist
> http://vimeo.com/ahmidou/videos
>
>
> 2013/4/14 Steven Caron 
>
>> i think the one ahmidou is proposing would use the custom tool sdk. this
>> means it wouldn't use curves in the scene like thiago's does.
>>
>>
>> On Sat, Apr 13, 2013 at 4:47 PM, Toonafish  wrote:
>>
>>> I think Thiago Costa already made one a while ago :
>>> http://thiagocosta.net/tc-**sketch-v11-grease-pencil-for-**xsi/
>>>
>>
>

Re: Creating a vector between 2 objects in ICE?

[Enrique Caballero]

the majority of the math is usually quite simple and enjoyable to work with.

https://www.khanacademy.org/

this is a great resource


On Mon, Apr 15, 2013 at 2:37 PM, Sam  wrote:

> As it turns out, I wasn’t doing the math part wrong, it was something else
> in my ice tree that was causing the problem. While I was going through my
> ice tree trying to figure out what I did wrong, I accidentally deleted a
> node. After undoing it I got this error:
>
> ** **
>
> # WARNING : 3000 -  Cycle breaking point
> sphere.polymsh.secondaryshapemarker
>
> # WARNING : 3000 - Cycle through null.null.ICETree
>
> # WARNING : 3000 - Cycle through sphere.polymsh.ICETree
>
> # WARNING : 3000 - PROBLEMATIC EVALUATION CYCLES ARE IN THE SPECIFIED GRAPH
> 
>
> ** **
>
> Undoing the delete should have put everything back to how it was, but now
> it wasn’t working at all. So I started going through and deleting all the
> excess nodes I had added in the different trees that were for displaying
> data (set data self.tmp, etc) and all of a sudden it started working as
> expected. I’m thinking that maybe I had more than one reference to
> self.temp or something similar, but none of the nodes turned red, so I
> didn’t realize it. 
>
> ** **
>
> The tip to turn on "use global coordinates for display" did solve a lot
> of my visualization problems. Having what I was doing work for the most
> part but having the vectors appear to be going in the wrong direction was
> definitely confusing.
>
> ** **
>
> Now that it is working I have noticed something else weird. When I move my
> “controller null” the object that is sliding across the sphere will pause
> slightly every time it gets to an edge before rotating slightly and moving
> along the next polygon. Is this a known issue, or should I be using
> something other than Get Closest Location to stick the null on the sphere?
> 
>
> ** **
>
> P.S. I will be watching weeks 6 and 7 shortly =)
>
> ** **
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Raffaele Fragapane
> *Sent:* Sunday, April 14, 2013 8:21 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Creating a vector between 2 objects in ICE?
>
> ** **
>
> get an object's kine.global.pos, and get another object's kine.global.pos
> Subtract one from the other, that's your displacement vector between two
> objects.
>
> Its direction (from A to B or viceversa) is determined by the order of
> subtraction, so if it's the wrong way around just plug the other way around
> in the subtract.
>
> A Vector has no such concept of what object it's under. It will be in the
> space of the object you run the operation from. To display it starting from
> such object, if the display is what you are using to determine it starts
> from the origin, then turn on "use global coordinates for display".
>
> For that vector to operate on an object other than the one you're hosting
> the graph on, you might need to add that object's own position to such
> vector before output.
>
> If you need more than just the position, then you have more work to do as
> you will need to compose a transform from this and additional derivative
> data.
>
> ** **
>
> You're hitting a wall again that has nothing to do with ICE or not using
> the right nodes or operations, and all to do with not quite understanding
> the math fundamentals of the data and operations you're working with :)***
> *
>
> Weeks 6 and 7 ;)
>
> ** **
>
> ** **
>
> On Mon, Apr 15, 2013 at 12:17 PM, Sam  wrote:
>
> As the subject says, I’m trying to create a vector between 2 objects in
> ICE? Essentially what I want to do is point a null (which is attached to
> the closest location on the surface of a mesh) at another object. I’ve
> tried several ways, and I just can’t seem to get it to work. It seems that
> no matter what I do, the vector is always coming from the origin (0,0,0). I
> thought this would be easy, but I’m obviously doing something very wrong.*
> ***
>
>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Creating a vector between 2 objects in ICE?

[Enrique Caballero]

sorry distracted at work and pressed enter too early.  all of your vector
work will be represented from origin until you multiply it by the matrix of
whatever object that you want it to come from

so if you want a vector between two objects

take vector 1, and vector 2, subtract them to get the difference,  this
will be a vector shooting across the space between both of these objects,
but it will be at Origin 000.  Then multiply that vector by the matrix of
the first object, and you will have what you want


On Mon, Apr 15, 2013 at 10:18 AM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> multiply it by the objects matrix
>
>
> On Mon, Apr 15, 2013 at 10:17 AM, Sam  wrote:
>
>> As the subject says, I’m trying to create a vector between 2 objects in
>> ICE? Essentially what I want to do is point a null (which is attached to
>> the closest location on the surface of a mesh) at another object. I’ve
>> tried several ways, and I just can’t seem to get it to work. It seems that
>> no matter what I do, the vector is always coming from the origin (0,0,0). I
>> thought this would be easy, but I’m obviously doing something very wrong.
>> 
>>
>
>

Re: Creating a vector between 2 objects in ICE?

[Enrique Caballero]

multiply it by the objects matrix


On Mon, Apr 15, 2013 at 10:17 AM, Sam  wrote:

> As the subject says, I’m trying to create a vector between 2 objects in
> ICE? Essentially what I want to do is point a null (which is attached to
> the closest location on the surface of a mesh) at another object. I’ve
> tried several ways, and I just can’t seem to get it to work. It seems that
> no matter what I do, the vector is always coming from the origin (0,0,0). I
> thought this would be easy, but I’m obviously doing something very wrong.*
> ***
>

Re: Who Uses Arnold Anyway ? an appeal to fans

[Enrique Caballero]

mirko, just asked our shader guy, he says its the new one, but its slow due
to the fact that they are layering a few shaders together, so my bad, turns
out the SSS is quite fast



On Thu, Mar 21, 2013 at 6:54 PM, Nuno Conceicao  wrote:

> Yes and honestly its just amazing how much more hair it can handle without
> affecting the performance that much,  mental ray on the other hand it was
> always kind of hitting a wall after a certain hair count.
> Using the pixel width optimization helps too.
> When doing the transparent hair setup i also experimented setting the
> Auto-Transparency depth to less than 10, using 5 kind of still gives nice
> results and keeps the render times  considerably lower.
>
> On Tue, Mar 19, 2013 at 11:18 AM, Sebastien Sterling <
> sebastien.sterl...@gmail.com> wrote:
>
>> Did you make thinner hairs and up the fur count ? Nuno ?
>>
>>
>> On 19 March 2013 11:21, Enrique Caballero wrote:
>>
>>> We've used fur ( ice strands) and Arnold  for a few years now and have
>>> had no issues, its fine.  It is deathly slow at SSS though.
>>>
>>>
>>> On Tue, Mar 19, 2013 at 6:15 PM, Nuno Conceicao <
>>> nunoalexconcei...@gmail.com> wrote:
>>>
>>>> I might try to guess some people try to set up the fur using
>>>> transparency. Although it helps making it look softer, i managed to get
>>>> quite nice results on my test without any transparency at all.
>>>>
>>>>
>>>> On Tue, Mar 19, 2013 at 4:10 AM, Raffaele Fragapane <
>>>> raffsxsil...@googlemail.com> wrote:
>>>>
>>>>> At some point, before it even hit SI afaik, it was struggling with
>>>>> some of the old paradigms for fur rendering. It's since earned this back
>>>>> alley talk reputation of struggling with fur, despite the fact nowadays
>>>>> it's probably the single strongest engine of its kind for it out there.
>>>>>
>>>>> It's not unlike the myths that you need an RnD department to do
>>>>> anything with renderman at all, or that you can't do topology work in
>>>>> ZBrush and so on.
>>>>>
>>>>> It should be dismissed, but a rumor will have been around the world
>>>>> before the truth had the time to put its shoes on.
>>>>>
>>>>>
>>>>> On Tue, Mar 19, 2013 at 3:04 PM, Gene Crucean <
>>>>> emailgeneonthel...@gmail.com> wrote:
>>>>>
>>>>>>  Say what?
>>>>>>
>>>>>> How on earth was fur/hair a problem for anyone using Arnold?
>>>>>> Something else must have been very jacked up for this to make a "con" 
>>>>>> list.
>>>>>> For me personally... I could give you a list a mile long about all of the
>>>>>> pro's... and one single con. Interior rendering. Like the Classroom 
>>>>>> scene.
>>>>>> Even then, you can make it look beautiful. It's just the main downside of
>>>>>> it is that it takes a bit longer to render than all the other stuff.
>>>>>>
>>>>>>
>>>>
>>>
>>
>

Re: symmetry template fail

[Enrique Caballero]

This has happened to me before, it usually stems from old geometry that
somehow got corrupted.  I usually export as OBJ and reimport and its fixed.

Some of our geo here was made 3 years ago in older versions of softimage,
have been passed back and forth between users and eventually just got nasty.

Hopefully u can gator your work back onto it just fine




On Wed, Mar 20, 2013 at 10:32 PM, Kris Rivel  wrote:

> Sorry...forgot about this thread!  I'm using Soft 2013 SP1.  Yes..I get
> that error or something similar:  ERROR : Invalid procedure call or
> argument: 'CreateSymmetryMappingTemplate'
>
> It points to a line of code.  Using Gear to rebuild the envelope fixes the
> problem.  But it would be nice to have this fixed in future versions.
>
> Kris
>
>
> On Tue, Mar 19, 2013 at 4:00 AM, ivan tay  wrote:
>
>> Thanks for the explanation.
>>
>> For the Maya to Softimage envelope issue, we have filed this sometime
>> back as SOFT-1717.  But please bring up any issue to us.
>>
>>
>> Thanks again!
>> -Ivan
>> Email : ivan@nospam.autodesk.com (please remove nospam from email
>> address)
>>
>>
>>
>> On Mon, Mar 18, 2013 at 10:37 PM, Martin  wrote:
>>
>>> Hi Ivan,
>>>
>>> I had this problem some time ago. I don't remember exactly which version
>>> I was using but I think it was 2011. I'm not sure what FBX version was used
>>> but the problem was from an outsource that was using Maya and converting it
>>> to SI through FBX before sending it to me. I had a few errors with symmetry
>>> template and discovered that the problem was in the envelope/weights.
>>>
>>> Wrote a few simple scrips to detect <100% weights, and round weights to
>>> fix them and everything went fine.
>>>
>>> M.Yara
>>>
>>>
>

Re: Technical Direction workshop available stand-alone (CGS TODs)

[Enrique Caballero]

I purchased it last night, and have watched the first weeks worth of videos
already.

 Really well paced, and clearly explained.   I also agree with the order in
which Raf is teaching things.

 I think that this is probably the best resource for someone who wants to
become a Softimage TD.  I'm going to convince the owner of our studio to
purchase it as training material for our new TD's.

Great job Raf!


On Wed, Mar 20, 2013 at 6:18 AM, Andre De Angelis  wrote:

> I have to second that Eric said,
>
> Being self taught means one can acquire some bad habbits or a poor
> understanding of basic principals.  It never hurts to go back to the basics
> and it can often shed a much better understanding of what you thought you
> knew or understood.
>
>
> On Wed, Mar 20, 2013 at 12:51 AM, Eric Thivierge wrote:
>
>> Enrique,
>>
>> I have been mostly self taught for python and the workshop was great to
>> get me in to a cleaner code syntax and learn some bits and pieces that have
>> made tool development faster for me. Even though some of the topics in the
>> beginning may seem simple it's worth going through them to pick up things
>> here and there.
>>
>> I think anyone who wants to get a handle on the more technical side of
>> Softimage should get the workshop. Raf goes at a good pace and explains
>> things very well.
>>
>> Thanks for making the workshop available Raf!
>> On Mar 19, 2013 4:02 AM, "Enrique Caballero" 
>> wrote:
>>
>>> Awesome raff,
>>>   I wish that it covered more advanced subjects. But the last 3 weeks or
>>> so seem interesting.
>>>
>>> Seeing as I'm mostly self-taught though, I wouldn't mind seeing how
>>> someone else goes about doing things, and seeing how it compares to what I
>>> discovered myself.
>>>
>>> So I'll be signing up!... Next paycheck :)
>>>
>>> -E
>>>
>>>
>>> On Tue, Mar 19, 2013 at 2:01 PM, Adam Sale  wrote:
>>>
>>>> Nice!!
>>>>
>>>>
>>>> On Mon, Mar 18, 2013 at 10:49 PM, Raffaele Fragapane <
>>>> raffsxsil...@googlemail.com> wrote:
>>>>
>>>>> Some shameless self promotion :)
>>>>>
>>>>> My Technical Direction workshop has finally been made available
>>>>> converted to self-paced training:
>>>>> http://tod.cgsociety.org/index.php/courses
>>>>>
>>>>> It's all the videos, assignments, literature (which is very little)
>>>>> and the most relevant/interesting assignment and tips&tricks threads
>>>>> bundled together and offered with no tutoring for 117/130$ (connect 
>>>>> member,
>>>>> non member).
>>>>>
>>>>> This is most likely the format I will do a next release in before
>>>>> taking on a properly tutored workshop again.
>>>>>
>>>>> Ignore the mention of Maya in the description, it was flagged with CGS
>>>>> but busy with the launch and all they haven't had time to rectify it yet.
>>>>> It's all XSI 7 and python 2.3 or above.
>>>>>
>>>>> Thanks for reading.
>>>>> Cheers,
>>>>> Raff
>>>>>
>>>>
>>>>
>>>
>
>
> --
> Andre De Angelis
>
>

Re: Who Uses Arnold Anyway ? an appeal to fans

[Enrique Caballero]

We've used fur ( ice strands) and Arnold  for a few years now and have had
no issues, its fine.  It is deathly slow at SSS though.


On Tue, Mar 19, 2013 at 6:15 PM, Nuno Conceicao  wrote:

> I might try to guess some people try to set up the fur using transparency.
> Although it helps making it look softer, i managed to get quite nice
> results on my test without any transparency at all.
>
>
> On Tue, Mar 19, 2013 at 4:10 AM, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> At some point, before it even hit SI afaik, it was struggling with some
>> of the old paradigms for fur rendering. It's since earned this back alley
>> talk reputation of struggling with fur, despite the fact nowadays it's
>> probably the single strongest engine of its kind for it out there.
>>
>> It's not unlike the myths that you need an RnD department to do anything
>> with renderman at all, or that you can't do topology work in ZBrush and so
>> on.
>>
>> It should be dismissed, but a rumor will have been around the world
>> before the truth had the time to put its shoes on.
>>
>>
>> On Tue, Mar 19, 2013 at 3:04 PM, Gene Crucean <
>> emailgeneonthel...@gmail.com> wrote:
>>
>>> Say what?
>>>
>>> How on earth was fur/hair a problem for anyone using Arnold? Something
>>> else must have been very jacked up for this to make a "con" list. For me
>>> personally... I could give you a list a mile long about all of the pro's...
>>> and one single con. Interior rendering. Like the Classroom scene. Even
>>> then, you can make it look beautiful. It's just the main downside of it is
>>> that it takes a bit longer to render than all the other stuff.
>>>
>>>
>

Re: Technical Direction workshop available stand-alone (CGS TODs)

[Enrique Caballero]

Awesome raff,
  I wish that it covered more advanced subjects. But the last 3 weeks or so
seem interesting.

Seeing as I'm mostly self-taught though, I wouldn't mind seeing how someone
else goes about doing things, and seeing how it compares to what I
discovered myself.

So I'll be signing up!... Next paycheck :)

-E


On Tue, Mar 19, 2013 at 2:01 PM, Adam Sale  wrote:

> Nice!!
>
>
> On Mon, Mar 18, 2013 at 10:49 PM, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> Some shameless self promotion :)
>>
>> My Technical Direction workshop has finally been made available converted
>> to self-paced training:
>> http://tod.cgsociety.org/index.php/courses
>>
>> It's all the videos, assignments, literature (which is very little) and
>> the most relevant/interesting assignment and tips&tricks threads bundled
>> together and offered with no tutoring for 117/130$ (connect member, non
>> member).
>>
>> This is most likely the format I will do a next release in before taking
>> on a properly tutored workshop again.
>>
>> Ignore the mention of Maya in the description, it was flagged with CGS
>> but busy with the launch and all they haven't had time to rectify it yet.
>> It's all XSI 7 and python 2.3 or above.
>>
>> Thanks for reading.
>> Cheers,
>> Raff
>>
>
>

Re: importing OLD models

[Enrique Caballero]

yep its missing a shader or a DLL

try opening it with your viewports muted, then stripping off all of the
shaders via the explorer. you might be okay after that



On Wed, Mar 6, 2013 at 12:31 AM, Eric Thivierge wrote:

> Usually means it's missing a shader or plug-in. Some known ones:
> http://softimage.wiki.softimage.com/index.php?title=CLSID_Reference
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>
>
> On Tue, Mar 5, 2013 at 11:32 AM, Neil Kidney wrote:
>
>> Hey folks,
>>
>> ** **
>>
>> Trying to import models from 2006 ish (so whatever version that was… v5
>> or v6?) Into 2012, but getting 
>>
>> Missing object to load this model … object missing is [[CLSID\
>>
>> Have tried various other models from 2006 – 2008 that we have and getting
>> the same error so I assume it’s not bug in the model.
>>
>> ** **
>>
>> Anyone know anything about it?
>>
>> ** **
>>
>> Cheers.
>>
>> ** **
>>
>> ** **
>>
>
>

Re: Interest/Opinions on a (possible) rigging workshop

[Enrique Caballero]

id be keen for the ICE and math part


On Fri, Feb 15, 2013 at 10:21 AM, Upinder Dhaliwal wrote:

> Sounds interesting Raff, I'll be keen as well.
>
>
>
> On Thursday, February 14, 2013, Daniel Jahnel wrote:
>
>>  yep, would be interested as well, keep us posted...
>>
>> -D
>>
>> On 13/02/2013 15:57, Ciaran Moloney wrote:
>>
>> Yes, very!
>> I've always looked with deep suspicion upon the dark arts of rigging.
>> Would be nice to   have an insight to that world.
>>
>>
>>
>> On Wed, Feb 13, 2013 at 6:30 AM, Raffaele Fragapane <
>> raffsxsil...@googlemail.com> wrote:
>>
>>> Heya all,
>>>
>>> I'm currently fishing around for interest and feedback on a potential
>>> rigging (for animation) workshop.
>>>
>>> The format and venue would be the same of my technical direction one,
>>> CGSociety, Videos+Literature+Forums Feedback for eight weeks. The costs,
>>> media access, infrastructure etc. are the usual they provide these days.
>>>
>>> I'm basically interested in knowing how many people would be genuinely
>>> interested, and to get a rough idea of what level would be the most popular.
>>>
>>> Currently I have a couple curriculum sketched out, and am inclined to do
>>> something that ranges from basics (familiarity with the software the
>>> pre-req but not aimed to veteran character TDs) to intermediate techniques
>>> for the animation end of things, so deformation, other than the basics, and
>>> layered proceduralism absent, but definitely touch on design, dev,
>>> modularity and maths/tech fundamentals on building user facing rigs.
>>>
>>> If interest seems to be skewed away from that though, I could consider
>>> offsetting towards something of a more advanced level, but I have a hunch
>>> it'd get a lot of lip service but less pull.
>>>
>>> Timeframe would be a start some time between May and August, depending
>>> on several factors.
>>>
>>> Anyway, any expressions of interest, public or private, and feedback
>>> would be sincerely appreciated.
>>>
>>> Cheers,
>>> Raff
>>>
>>
>>
>>
>
> --
> *--
> Upinder Dhaliwal*
> www.upinderdhaliwal.com
>
>
>

Re: ICE Kinematics

[Enrique Caballero]

i agree with ahmidou.

I avoid SCOPS like the plague, usually i can do it with pure ICE.

if for some reason it cant be done with ICE then I insist that people here
use jscript. Otherwise your animators are paying a big price speed wise.

Truthfully though, since ICE came out, i've been able to avoid using SCOPS
100%. I consider it obsolete tech now.







On Thu, Feb 7, 2013 at 8:56 PM, Peter Agg  wrote:

> I see it more as a trade off of speed with quality of life. :)
>
>
> On 7 February 2013 12:39, Ahmidou.xsi  wrote:
>
>> I'd never use python for SCOPs, it's way slower than jscript.
>>
>> Le 7 févr. 2013 à 20:47, Peter Agg  a écrit :
>>
>> I tend to use ICE as a sort of SCOP testbed, especially if the maths is a
>> little complicated it's easier to dev the system there and re-write into
>> Python later. The only exception would be if I needed to make use of
>> locations/geometry queries. But then it's still easier to store a custom
>> attribute then read that into a script.
>>
>>
>>
>> On 7 February 2013 02:02, Raffaele Fragapane > > wrote:
>>
>>> I mean output to an ICE par, not to a CP par, which is akin to hitting
>>> your testicles with a large mallet.
>>>
>>>
>>> On Thu, Feb 7, 2013 at 11:07 AM, joshxsi  wrote:
>>>
 FYI, outputting to a parameter to ICE is around 10x slower than
 outputting to a transform, so I highly recommend that if performance is a
 requirement, never output from ICE into a parameter.

 Cheers,
 -j


 On Thu, Feb 7, 2013 at 10:42 AM, Raffaele Fragapane <
 raffsxsil...@googlemail.com> wrote:

> You might be better off decoupling the length computation, which tends
> to be expensive with any high order surface or curve, and output it to a
> parameter you fetch from graphs further down the stream.
> That way you should save a fair chunk of cycles.
>
> If you need to keep them aligned you could also use some tricks to
> basically reduce the dirtyness to a simpler check, like comparing point
> positions before you start integrating your length function.
>


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

Re: ICE Kinematics

[Enrique Caballero]

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 fine on this end as long as I dont touch the global kinematics
after the ICE tree starts driving it


On Wed, Feb 6, 2013 at 10:17 AM, Alan Fregtman wrote:

> 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 off "Constrain Pose" for your custom
> constraint base. All those compounds do is write the old kine in
> self.__TmpConstraintPose then set self.kine.global. For some reason it's a
> bit more stable that way. Don't know why.
>
>
>
>
> On Tue, Feb 5, 2013 at 9:09 PM, Jeremie Passerin wrote:
>
>> It's been a while since I tried to do stuff on kinematics with ICE and I
>> thought I would give it another shot.
>>
>> Just a quick test, I'm using the UV to Location to recreate a surface
>> constraint and I plug that in the global kinematics of a null.
>> It behaves properly.
>>
>> Then I go check the Global Kinematics of my null, just to see if they are
>> locked or anything. Nope... they don't seem to be locked and I can
>> even manipulate them. It's acting crazy though.
>> And now my simple ICE setup isn't working properly anymore... instead of
>> that I have a null moving all over the place every time I changed a UV
>> value.
>>
>> So first question. Am I doing something wrong ? See attached ice tree
>> and then, who's using ICE kinematics in Rigging ? Was it successful ?
>>
>> Jeremie
>>
>>
>

Re: PyQT for Softimage: problem with QIcons?

[Enrique Caballero]

in retrospect that code is actually a bit convoluted with how it splits the
path up, i think that I just copy and pasted it from a forum. probably dont
need to do that .split :)


On Wed, Feb 6, 2013 at 10:07 AM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> 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( imgpath + 'oneLogo.png' ) )
>
> self.forwardButton.setIcon( QIcon( imgpath +
> "button_forwardOn.png"))
> self.backButton.setIcon( QIcon( imgpath + "button_backOn.png"))
> self.keyButton.setIcon( QIcon( imgpath + "button_okOn.png"))
> self.deleteButton.setIcon( QIcon( imgpath + "button_cancel.png"))
> self.resetButton.setIcon( QIcon( imgpath + "buttons_21.png"))
>
>
> On Wed, Feb 6, 2013 at 8:15 AM, Xavier Lapointe 
> wrote:
>
>> Hey Philipp,
>>
>> you might want to make sure that your path is ok (file exists and so on),
>> and maybe try using 
>> *addFile<http://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 <http://qt-project.org/doc/qt-4.8/qicon.html#QIcon-4>* (
>> const QString & *fileName* )?
>>
>>
>>
>> Cheers
>>
>>
>>
>>
>>
>> On Wed, Feb 6, 2013 at 8:50 AM, Simon Anderson <
>> simonbenandersonl...@gmail.com> wrote:
>>
>>> Currently at work, I can see if I can get an icon showing when im home,
>>> but I do remember us having icons on our buttons.
>>>
>>>
>>>
>>>
>>> On Wed, Feb 6, 2013 at 6:07 AM, philipp.oeser wrote:
>>>
>>>> **
>>>>  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 Nuke (it shows the icons
>>>> with QStandardItems in a QTreeView)
>>>> but the exact same code/ui-file just doesnt show the Icons in
>>>> Softimage...
>>>>
>>>> === something like this ===
>>>> oTasksModel = QtGui.QStandardItemModel()
>>>> oRootItem = oTasksModel.invisibleRootItem()
>>>> self.ui.UI_tv_Tasks.setModel(oTasksModel)
>>>>
>>>> sTask = 'taskname'
>>>> oTaskItem = QtGui.QStandardItem(sTask)
>>>>
>>>> sFullPath = 'validpath'
>>>> oIcon = QtGui.QIcon(sFullPath)
>>>> oTaskItem.setIcon(oIcon)
>>>>
>>>> # it seems to be taken, if you print out oTaskItem.icon(), it will
>>>> print
>>>> # 
>>>>
>>>> oRootItem.appendRow(oTaskItem)
>>>> ==
>>>>
>>>> Has this been done succesfully? Or can someone confirm it is not
>>>> working? Should I dig deeper?
>>>>
>>>> Thanx in advance
>>>> Philipp
>>>>
>>>>  P.S. using PyQt-Py2.6-x64-gpl-4.9.5-1 and PyQtForSoftimage_beta5
>>>>
>>>
>>>
>>>
>>> --
>>> ---
>>> Simon Ben Anderson
>>> blog: http://vinyldevelopment.wordpress.com/
>>>
>>
>>
>>
>> --
>> Xavier
>>
>
>

Re: PyQT for Softimage: problem with QIcons?

[Enrique Caballero]

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( imgpath + 'oneLogo.png' ) )

self.forwardButton.setIcon( QIcon( imgpath +
"button_forwardOn.png"))
self.backButton.setIcon( QIcon( imgpath + "button_backOn.png"))
self.keyButton.setIcon( QIcon( imgpath + "button_okOn.png"))
self.deleteButton.setIcon( QIcon( imgpath + "button_cancel.png"))
self.resetButton.setIcon( QIcon( imgpath + "buttons_21.png"))


On Wed, Feb 6, 2013 at 8:15 AM, Xavier Lapointe wrote:

> Hey Philipp,
>
> you might want to make sure that your path is ok (file exists and so on),
> and maybe try using 
> *addFile
>  *on your QIcon object ...
>
> I doubt that might be the case, bus maybe you need to cast your path to a
> QString *QIcon * (
> const QString & *fileName* )?
>
>
>
> Cheers
>
>
>
>
>
> On Wed, Feb 6, 2013 at 8:50 AM, Simon Anderson <
> simonbenandersonl...@gmail.com> wrote:
>
>> Currently at work, I can see if I can get an icon showing when im home,
>> but I do remember us having icons on our buttons.
>>
>>
>>
>>
>> On Wed, Feb 6, 2013 at 6:07 AM, philipp.oeser wrote:
>>
>>> **
>>>  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 Nuke (it shows the icons
>>> with QStandardItems in a QTreeView)
>>> but the exact same code/ui-file just doesnt show the Icons in
>>> Softimage...
>>>
>>> === something like this ===
>>> oTasksModel = QtGui.QStandardItemModel()
>>> oRootItem = oTasksModel.invisibleRootItem()
>>> self.ui.UI_tv_Tasks.setModel(oTasksModel)
>>>
>>> sTask = 'taskname'
>>> oTaskItem = QtGui.QStandardItem(sTask)
>>>
>>> sFullPath = 'validpath'
>>> oIcon = QtGui.QIcon(sFullPath)
>>> oTaskItem.setIcon(oIcon)
>>>
>>> # it seems to be taken, if you print out oTaskItem.icon(), it will print
>>> # 
>>>
>>> oRootItem.appendRow(oTaskItem)
>>> ==
>>>
>>> Has this been done succesfully? Or can someone confirm it is not
>>> working? Should I dig deeper?
>>>
>>> Thanx in advance
>>> Philipp
>>>
>>>  P.S. using PyQt-Py2.6-x64-gpl-4.9.5-1 and PyQtForSoftimage_beta5
>>>
>>
>>
>>
>> --
>> ---
>> Simon Ben Anderson
>> blog: http://vinyldevelopment.wordpress.com/
>>
>
>
>
> --
> Xavier
>