JOB: Modeler Required - TeamUp

[Jason Brynford-Jones]

Hi everyone,

TeamUp getteamup.com is looking to hire a modeler ASAP.  This is a short
gig, for about a month or so.

Mainly hard surface models
Residing in Montreal preferable
Ideally the candidate would have their own software, but it is not a hard
requirement.

Please let others know, if you recommend them.

Please send all questions/links/showreels to my TeamUp address

ja...@getteamup.com

Thanks

Jason/Chinny

RE: ICE in Maya is an engineer's worst nightmare

[Matt Lind]

Performance could improve by trimming transforms, but I don’t think scalability 
would be affected too much as the amount of data saved is tiny in comparison 
the ceiling we’re talking about.  Scalability on this level is fundamental of 
working with crowds of data – it needs to be a primary focus of the design to 
do it well.  Softimage opted for better performance of fewer complex objects.

Matt




From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Greg Punchatz
Sent: Thursday, September 06, 2012 5:40 PM
To: softimage@listproc.autodesk.com
Subject: Re: ICE in Maya is an engineer's worst nightmare

Both...we were on 64 bit CPUs before we had ICE. It (ice) and Arnold have let 
us build light scenes that can generate incredible detail that has not been 
achievable for us.  64 bits made it feasible ... Ice and Arnold made it a 
reality.

Now XSI could use a boost in scalability for sure... It fails in large number 
of objects. I always wondered if  a optional simplified transform with out all 
the pivots, centers and offsets would give XSI a speed boost.

G

Sent from my iPhone

On Sep 6, 2012, at 7:18 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Is that due to ICE or because you’re now on 64 bit systems with extra hardware 
resources at your disposal?


Matt




From: 
softimage-boun...@listproc.autodesk.com
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Greg Punchatz
Sent: Thursday, September 06, 2012 5:17 PM
To: softimage@listproc.autodesk.com
Cc: softimage@listproc.autodesk.com
Subject: Re: ICE in Maya is an engineer's worst nightmare

What said Raf +1

What's ironic about this part of this thread is that ICE and Arnold has let us 
reach a level of scale in our little boutique that I could not have even 
imagined before they showed up... Even on our outdated render farm, we can 
render enormous fully path traced , motion blured scenes in one pass that only 
a few years ago even the big boys would would of had to break into many passes 


Sent from my iPhone

Re: ICE in Maya is an engineer's worst nightmare

[Steven Caron]

indeed, pursuit of performance increases should NEVER stop. SolidAngle does
this with Arnold and its boring but it keeps everyone happy when nearly
every release you see a performance improvement.

On Thu, Sep 6, 2012 at 5:40 PM, Greg Punchatz  wrote:

>
> Now XSI could use a boost in scalability for sure...
>
>

Re: ICE in Maya is an engineer's worst nightmare

[Greg Punchatz]

Both...we were on 64 bit CPUs before we had ICE. It (ice) and Arnold have let 
us build light scenes that can generate incredible detail that has not been 
achievable for us.  64 bits made it feasible ... Ice and Arnold made it a 
reality. 

Now XSI could use a boost in scalability for sure... It fails in large number 
of objects. I always wondered if  a optional simplified transform with out all 
the pivots, centers and offsets would give XSI a speed boost.

G

Sent from my iPhone

On Sep 6, 2012, at 7:18 PM, Matt Lind  wrote:

> Is that due to ICE or because you’re now on 64 bit systems with extra 
> hardware resources at your disposal?
>  
>  
> Matt
>  
>  
>  
>  
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Greg Punchatz
> Sent: Thursday, September 06, 2012 5:17 PM
> To: softimage@listproc.autodesk.com
> Cc: softimage@listproc.autodesk.com
> Subject: Re: ICE in Maya is an engineer's worst nightmare
>  
> What said Raf +1
>  
> What's ironic about this part of this thread is that ICE and Arnold has let 
> us reach a level of scale in our little boutique that I could not have even 
> imagined before they showed up... Even on our outdated render farm, we can 
> render enormous fully path traced , motion blured scenes in one pass that 
> only a few years ago even the big boys would would of had to break into many 
> passes 
> 
> Sent from my iPhone
>  

Re: ICE in Maya is an engineer's worst nightmare

[Tim Leydecker]

Hi Luc-Eric, Hi Graham,


can you guys talk with the Maya UI group about a better way to incorporate
Duncan Brinsmead´s parameter options?

I know, the alternative Houdini way of having to pipe together everything
over and over yourself and ideally mentally debugging the graph even before
placing any node at all isn´t ideal either but just poking around the ICE
node editor without knowing all the nodes is so rewarding because of the
feedback it gives you while learning your way around the nodes and compounds.

Compared to that, simply rotating Maya particles nice still needs the same pre 
y2k script...

###

Comparing Softimage and Maya features of the last couple of years, I find
the following (unsorted) list shows some of the steps that led to gaining 
functionality:

*Gator (Softimage Attribute Transfer)
*Motor (Softimage prior/competitor to Motionbuilder)
*Rendermapping (Maya/Softimage, mR functionality)
*paint fx (Maya)
*reworked Maya dynamics - the nucleus solver framework
*Maya fluids, shading particles as fluids and actually rendering fluids
*Softimage ICE, still lacking a fluid (smoke) solver and render options
*Softimage FaceRobot
*Renderlayers, Passes, Partitions, Groups, overrides (Softimage/Maya)
*Trax (Maya)
*Animation Mixer (Softimage)
*The RenderRegion (Softimage)
*ICE´s CrowdFx (Softimage)

Last but not least:


"The Send to ..." button

(Overly) simplifying the above, it´s all plug-ins to extend an existing tool.

Personally, I like the Softimage way for Modeling, Lighting, Shading and 
Rendering better
but wonder why Rendering and Lighting doesn´t evolve much anymore?

There´s lot´s of buzz about viewport 2.0, I´d prefer to just render A+++ or 
wysiwyg. exactly.
Not almost or nice as well. exactly. Maybe a bit less fine AA. But not 
something completely different...

###

In terms of scalability, I can´t say how much I am feed up with Polygons, 
Triangles and pulling vertices.

I wonder why nobody looks into getting rid of that crappy approximation of a 
surface and looks into
describing things better than by a flat tri a normal and a voodoo uhuhu 
smoothing angle?

Class A surfaces. Gazillions of them, smoothly animated and playing back on 
screen.
Going from close-up to total shot without a burp.

Voxels. NicNacs. Whatever. As long as there is a Send to button to and from 
ZBrush/3D coat.

That would be something. You can pack it into Alembic if you like. As long as I 
can read it in 10 years, that´s fine with me.



Cheers,


tim
.

Re: SDK : connecting an object to a matrix port on a shader

[Steven Caron]

it works, thanks. alternatively i could probably use a port group and use
the 'Index' property of the class.

s

On Thu, Sep 6, 2012 at 2:35 PM, Steven Caron  wrote:

> thanks, i haven't tried it yet but what you suggest make sense.
>
>
> On Thu, Sep 6, 2012 at 11:13 AM, Matt Lind wrote:
>
>> ** **
>>
>> In essence the _update callback becomes a loop where each invocation is
>> dedicated to a specific output port of the operator.  You merely have to
>> put some logic at the top to branch into the different paths based on which
>> output port is being processed in the current call.
>>
>

RE: ICE in Maya is an engineer's worst nightmare

[Matt Lind]

Is that due to ICE or because you’re now on 64 bit systems with extra hardware 
resources at your disposal?


Matt




From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Greg Punchatz
Sent: Thursday, September 06, 2012 5:17 PM
To: softimage@listproc.autodesk.com
Cc: softimage@listproc.autodesk.com
Subject: Re: ICE in Maya is an engineer's worst nightmare

What said Raf +1

What's ironic about this part of this thread is that ICE and Arnold has let us 
reach a level of scale in our little boutique that I could not have even 
imagined before they showed up... Even on our outdated render farm, we can 
render enormous fully path traced , motion blured scenes in one pass that only 
a few years ago even the big boys would would of had to break into many passes 


Sent from my iPhone

Re: ICE in Maya is an engineer's worst nightmare

[Greg Punchatz]

What said Raf +1

What's ironic about this part of this thread is that ICE and Arnold has let us 
reach a level of scale in our little boutique that I could not have even 
imagined before they showed up... Even on our outdated render farm, we can 
render enormous fully path traced , motion blured scenes in one pass that only 
a few years ago even the big boys would would of had to break into many passes 


Sent from my iPhone
> 

Re: Small Annoying Things

[Greg Punchatz]

This little guy is really annoying 

http://images1.wikia.nocookie.net/__cb20080330011925/starwars/images/a/a9/Crumb_btm.jpg

Re: ICE in Maya is an engineer's worst nightmare

[Raffaele Fragapane]

It's great to hear all this talk of rendering and FX, and scalability, two
things that have seen paradigm shifts and multiple evolutions several times
in the last few years, so that large firms can be catered to, when we
already have our own solutions, or Houdini, we use for those that are very
unlikely to be matched (because even if they are, we won't own the source).

In the meantime, animation, interaction, the general feeling of an app,
ease of use, clarity, the whole animation field and everything related,
languish and are stuck in the realm of models, tools, procedures and
concepts that last saw a generational hop with SOFTIMAGE|3D 3.0, and
haven't seen one since.

This leaves the large shops with a feature set we were already forced to
develop quite a few years ago, and that needs to be close to the rendering
engine (which is NOT going to be MRay, the one currently bundled with all
products), and is absolutely useless unless you have that (rendertime
injection and all), and doesn't even nudge all the static things that we
actually DO use Soft or Maya for, rigging and animation.

At the same time, the small boutique will still not be able to do the major
scale stuff, because even with all the tools, frameworks and scalability in
the world they won't have the infrastructure and deadlines to crack LA in
two and sink it, and their bread&butter tools languish, and their staff
still places keyframes on the same six bloody function curves they did
fiften years ago, on animation rigs that feature, as their most complex
technology provided by the app, IK that is the same that was made available
to the first Jurassic Park.

Of course I'm biased, I've always worked on a broad spectrum of things, but
always around characters/creatures, so this might be a pointless and
blindsided rant.

But more likely, in the endless chase for bigger numbers and better
headlines in reviews, the major software providers forget that as a large
studio we can get ourselves a better fluid simulator for a movie in less
than a year with three people than maya was able to provide in seven with a
team of six.
What IS phenomenally expensive to create (the user facing and enormously
complex scene graph and data management side and the UI and GUI around it)
is what both us and the smaller shops REALLY use day to day. And when the
small shops need a multibillion particle sim they'll have three days to do,
and will therefore pick up the first 400$ plugin that does it for them over
an API built over a framework that scales like a Caterpillar mining truck,
but can't be used without three engineers full time on it.

As for ICE being the now and this massively scalable thing being the next,
two years on Walking with Dinosaurs with a shitload of deformation and
pipeline work relying on ICE beg to differ that large datasets are the
next, and would like to raise their hand and affirm that some of us don't
blow shit up all day for a living, and kinda relish a solid data model and
a good UI :p

Re: ICE in Maya is an engineer's worst nightmare

[Rob Chapman]

On 6 September 2012 23:00, Bradley Gabe  wrote:

> I'm starting to think a better analogy would have been cars pulling
> trailers.


nice, so in the case the studios are trailers of different sizes and maya
and softimage are the cars and trucks ?  So Softimage can be the fiat panda
pulling our mobile fruit & veg stall?  :D

Re: ICE in Maya is an engineer's worst nightmare

[Bradley Gabe]

I'm starting to think a better analogy would have been cars pulling
trailers.


On Thu, Sep 6, 2012 at 5:57 PM, Rob Chapman  wrote:

>
>
> *On 6 September 2012 17:34, Bradley Gabe  wrote:
> *
>>
>> * The real threat is their fear of ADSK, and the potential that they
>> re-wire their trucks without dependence on any DCC app.*
>>
>
> and this is what Guy is talking about in another thread , no?  in which
> case its already starting to happen :)  and by your analogy of comparing
> the large film production studios as big trucks driven by Maya, then myself
> and Fabrice agreed that our little studio where we work is definitely a
> Fiat Panda driven by Softimage.
>
> :D
>
>
>

Re: ICE in Maya is an engineer's worst nightmare

[Rob Chapman]

*On 6 September 2012 17:34, Bradley Gabe  wrote:
*
>
> * The real threat is their fear of ADSK, and the potential that they
> re-wire their trucks without dependence on any DCC app.*
>

and this is what Guy is talking about in another thread , no?  in which
case its already starting to happen :)  and by your analogy of comparing
the large film production studios as big trucks driven by Maya, then myself
and Fabrice agreed that our little studio where we work is definitely a
Fiat Panda driven by Softimage.

:D

Re: SDK : connecting an object to a matrix port on a shader

[Steven Caron]

thanks, i haven't tried it yet but what you suggest make sense.

On Thu, Sep 6, 2012 at 11:13 AM, Matt Lind  wrote:

> ** **
>
> In essence the _update callback becomes a loop where each invocation is
> dedicated to a specific output port of the operator.  You merely have to
> put some logic at the top to branch into the different paths based on which
> output port is being processed in the current call.
>

Re: ICE in Maya is an engineer's worst nightmare

[olivier jeannel]

/"Meanwhile, for the rest of us who don't have our own RnD departments, 
XSI is great because something like ICE does empower non-programmers to 
do things we couldn't do otherwise. So at least we have a fighting 
chance. Compare the workability of a custom tool made by someone who 
only writes code all day, versus a custom tool developed by the user in 
the context of the usage. There is still a huge value to that, and 
should (hopefully) continue to be a market for that."/


Amen.




Le 06/09/2012 18:34, Bradley Gabe a écrit :
Think of Maya more like a standard than an application. It's a front 
end that people are already used to looking at, even though they might 
be using it to drive a different "truck" on the back end. If you don't 
like working within the Maya or Max environment, imagine what it was 
like working in a completely proprietary environment developed by your 
RnD department who was more interested in making cool effects possible 
than smoothing out the GUI and user experience!


With a DCC application, you *have* to invest in the user experience 
because you need to sell as many seats as possible. With a custom RnD 
effort inside your studio, you don't care as much about user 
experience because you have a captive "market" who is facing the 
choice of "do it my way" if you even want to have a remote chance of 
doing it at all.


It doesn't matter if the XSI experience is nicer for some of us. It 
doesn't matter if XSI's core is more mature or potentially easier to 
develop for functionality like ICE. At the end of the day, the larger 
market base has built their own "trucks" and is using Maya to drive 
them, and they might be starting to champ at the bit a little as their 
"trucks" are needing more modern controls. XSI is not an option to 
them, it's not even on the radar. The real threat is their fear of 
ADSK, and the potential that they re-wire their trucks without 
dependence on any DCC app.


Meanwhile, for the rest of us who don't have our own RnD departments, 
XSI is great because something like ICE does empower non-programmers 
to do things we couldn't do otherwise. So at least we have a fighting 
chance. Compare the workability of a custom tool made by someone who 
only writes code all day, versus a custom tool developed by the user 
in the context of the usage. There is still a huge value to that, and 
should (hopefully) continue to be a market for that.


-Bradley

On Thu, Sep 6, 2012 at 12:04 PM, Stefan Kubicek > wrote:


Fair enough and agreed on, but why would Maya be a better
candidate to be developed in that direction than any other app?

Re: Small Annoying Things

[Eugen Sares]

- In perspective/user view, Isopoint selection is jumpy and almost 
unusable, because the selection tolerance is zero. You have to hover 
exactly over the curve to place the Isopoint.

In ortho views, it works conveniently.

Also, after task switching, snapping seems to somehow hang - although it 
is off, Isopoints snap to Knots.
Repro: create a Curve, go to Isopoint component, switch to another task, 
click on SI's title bar, and try to select an Isopoint exactly on the Curve.

After click-deselecting in the vp, it works again.

Re: Forcing Order of firing of events in soft

[Alok]

  
  
Very nice !!
  
  Thank you so much Stephen, that is very helpful, and special
  thanks for being available on the list !!
  

  On 06/09/2012 2:54 PM, Stephen Blair wrote:

I did a quick test with some OnBeginCommand events
  (2013 SP1 only)
  
  The events were triggered in the order they were registered.
  So, the order depended on
  - order of RegisterEvent calls (alpha order of event names did not
  matter, I tested that)
  - location of plugin (User plugins loaded before Workgroup)
  - order of workgroups (they should be loaded in the order they are
  listed...I didn't test with multiple workgroups)
  - name of plugins in a given location ( "A_Event.py" was loaded
  before "X_Event.py")
  
  I wouldn't necessarily call this conclusive, but it was
  suggestive...
  
  
  
  On Thu, Sep 6, 2012 at 1:58 PM, Alok 
wrote:

  
Nothing is stopping me but the events are all scattered
  in various plugins, libraries. As our in house python
  libraries are humongous (thousands of lines of code) it
  will create huge maintenance issues to put everything into
  one event. I have used the awesome SetGlobal() and
  GetGlobal() for other purposes before and it works
  beautifully but for this case it is a bit of an overkill.
  Never mind, it is not absolutely needed now, I can think
  of something later. Anyways thanks for your insights Alan
  !
  

  On 06/09/2012 1:33 PM, Alan Fregtman wrote:

The only workaround I can think of
  is keeping track of which events have run with global
  temporary variables (SetGlobal(), GetGlobal()) and if an
  event fires and it shouldn't, registering a TimerEvent to
  re-fire that procedure soon thereafter, thus allowing
  other events to fire, until they have all fired in the
  right order.
   
  
  Ugly, but better than nothing.

What's stopping you from doing all the events in one?


On Thu, Sep 6, 2012 at 1:19 PM,
  Alok 
  wrote:
  
 Hi List,
  
  Is there a way we can force the order of running
  events in soft ?. For example I have two events
  for open scene event1 and event2. Is there a way I
  can force the events to fire in a predetermined
  order so that event1 is always fired before
  event2.
  
  Apparently I know the answer to this one is no but
  I am still asking if anyone has some insights.
  -- 


 
   
 
  
  
  No virus found in this
message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5252 -
Release Date: 09/06/12


  

  
  
  No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5252 - Release Date:
09/06/12


  

Re: ICE in Maya is an engineer's worst nightmare

[Luc-Eric Rousseau]

On Thu, Sep 6, 2012 at 12:30 PM, Williams, Wayne
 wrote:
> What I'd like to know is how the devs feel about the core of Maya in 
> comparison to Soft now that they have access to the code (I'm guessing this 
> is the case, please let me know if wrong).  Are there any things you devs see 
> that were done extremely well in Maya and Soft could have taken a cue from in 
> that regard or vice versa? I realize that you can't go into specifics but 
> figured I'd put the general question out there.
> -wayne

We haven't been very deep into Maya yet, but the depth of the SDK is
impressive (we were influenced by the way it works when designing the
Softimage C++ SDK) and the extent to which the scripting is used in
the UI is also surprising.  Maya is all about the API.

On the Softimage side, the SDK/Platform stuff was originally (1998)
left to the magic Microsoft COM fairies. We added scripting about a
year or two after the development had started in a reaction to Maya.
We added a Windows-only COM SDK to XSI 1.5.  The C++ SDK came up only
at version 3.0, in late 2002. So four years after Maya 1.0 was
released we came up with our first cross platform SDK. It's a lot more
time and work to add this years after the app is already written and
shipped, so there's still a lot that isn't there.  On the other hand,
we could evolve the architecture without being held back by API
compatibility concerns :)

Re: Forcing Order of firing of events in soft

[Stephen Blair]

I did a quick test with some OnBeginCommand events (2013 SP1 only)

The events were triggered in the order they were registered.
So, the order depended on
- order of RegisterEvent calls (alpha order of event names did not matter,
I tested that)
- location of plugin (User plugins loaded before Workgroup)
- order of workgroups (they should be loaded in the order they are
listed...I didn't test with multiple workgroups)
- name of plugins in a given location ( "A_Event.py" was loaded before
"X_Event.py")

I wouldn't necessarily call this conclusive, but it was suggestive...



On Thu, Sep 6, 2012 at 1:58 PM, Alok  wrote:

>  Nothing is stopping me but the events are all scattered in various
> plugins, libraries. As our in house python libraries are humongous
> (thousands of lines of code) it will create huge maintenance issues to put
> everything into one event. I have used the awesome SetGlobal() and
> GetGlobal() for other purposes before and it works beautifully but for this
> case it is a bit of an overkill. Never mind, it is not absolutely needed
> now, I can think of something later. Anyways thanks for your insights Alan !
>
>  On 06/09/2012 1:33 PM, Alan Fregtman wrote:
>
> The only workaround I can think of is keeping track of which events have
> run with global temporary variables (SetGlobal(), GetGlobal()) and if an
> event fires and it shouldn't, registering a TimerEvent to re-fire that
> procedure soon thereafter, thus allowing other events to fire, until they
> have all fired in the right order.
>
>  Ugly, but better than nothing.
>
> What's stopping you from doing all the events in one?
>
>
> On Thu, Sep 6, 2012 at 1:19 PM, Alok  wrote:
>
>>  Hi List,
>>
>> Is there a way we can force the order of running events in soft ?. For
>> example I have two events for open scene event1 and event2. Is there a way
>> I can force the events to fire in a predetermined order so that event1 is
>> always fired before event2.
>>
>> Apparently I know the answer to this one is no but I am still asking if
>> anyone has some insights.
>> --
>>
>
>  No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2197 / Virus Database: 2437/5252 - Release Date: 09/06/12
>
>
>
<><>

RE: SDK : connecting an object to a matrix port on a shader

[Matt Lind]

I've done multiple output ports.

In essence the _update callback becomes a loop where each invocation is 
dedicated to a specific output port of the operator.  You merely have to put 
some logic at the top to branch into the different paths based on which output 
port is being processed in the current call.

For example;

Let's say your SCOP has 3 output ports: Position, Rotation, Scale

Each time the input ports are dirtied, the SCOP will be called to evaluate.  
Each time it's called, it's called in a package of three calls to _update().  
Your code needs to check the OperatorContext object to determine which output 
port Softimage is focusing on during the current callback, do the computations, 
then assign the result to the current output port.

If ( oOperatorContext.OutputPort.Name == "Position" ) {
//
oOutputPort.Value = 
} else if (oOperatorContext.OutputPort.Name == "Rotation" ) {
//
oOutputPort.Value = 
} else if ( oOperatorContext.OutputPort.Name == "Scale" ) {
//
oOutputPort.Value = 
}



Basically an operator is a command encapsulated inside a framework where the 
inputs and outputs are always known.

Matt







From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron
Sent: Thursday, September 06, 2012 10:20 AM
To: softimage@listproc.autodesk.com
Subject: Re: SDK : connecting an object to a matrix port on a shader

anyone?

how about multiple output ports on SCOPs, anyone do that before?

s
On Wed, Sep 5, 2012 at 1:38 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
does anyone have any examples on how to connect an object matrix to a port on a 
shader using a scop? its been soo long since i have used scops and i am not 
getting much traction.

s

Re: Forcing Order of firing of events in soft

[Alok]

  
  
Nothing is stopping me but the events
  are all scattered in various plugins, libraries. As our in house
  python libraries are humongous (thousands of lines of code) it
  will create huge maintenance issues to put everything into one
  event. I have used the awesome SetGlobal() and GetGlobal() for
  other purposes before and it works beautifully but for this case
  it is a bit of an overkill. Never mind, it is not absolutely
  needed now, I can think of something later. Anyways thanks for
  your insights Alan !
  

  On 06/09/2012 1:33 PM, Alan Fregtman wrote:

The only workaround I can think of is keeping track of
  which events have run with global temporary variables
  (SetGlobal(), GetGlobal()) and if an event fires and it shouldn't,
  registering a TimerEvent to re-fire that procedure soon
  thereafter, thus allowing other events to fire, until they have
  all fired in the right order.
  

  
  Ugly, but better than nothing.

What's stopping you from doing all the events in one?


On Thu, Sep 6, 2012 at 1:19 PM, Alok 
  wrote:
  
 Hi List,
  
  Is there a way we can force the order of running events in
  soft ?. For example I have two events for open scene
  event1 and event2. Is there a way I can force the events
  to fire in a predetermined order so that event1 is always
  fired before event2.
  
  Apparently I know the answer to this one is no but I am
  still asking if anyone has some insights.
  -- 


  


  
  No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5252 - Release Date:
09/06/12


  

Re: ICE in Maya is an engineer's worst nightmare

[Andy Jones]

I really think the fact that Sony built Katana to manage their large
scene complexity rather than somehow pipelining Maya speaks to a
fundamental lack of scalability inherent in the organization of the
scene graph.  Look at a render layer in the hypergraph.  There are
nodes, but the nodes that exist have little regard for streamlining
execution.

I think for scalability beyond what ICE and lots of RAM offers, you
have to be thinking in terms of cloud computing, cluster computing,
and similar distributed models.  GPU computing essentially follows a
similar need for a mapReduce scheme as well, as you need to be able to
manage the large data sets in a massively parallel way in order for
them to be useful.  Honestly, though, I think building scalability on
this magnitude is far more feasible for specialized tools designed to
solve a particular problem (like a massive fluid sim) than as a
modified framework for a general application.  The reason is that
unless you're talking about a specific tool (city generator, fluid
sim, etc) actual scene content is human-bound, and therefore already
mapReduced by the production workflow.  Beyond that, the scene graph's
purpose is to be a top-down interface to the entire scene graph.  By
it's nature it either fits everything at once, or has to load pieces
on demand and/or use a proxy representation system in order to be
useful as a complete view of your scene.

Personally, I think for any of the big 3 apps, the scalability answer
actually has more to do with offloading than changing the
architecture.  And the irony there is that offloading is actually a
relatively simple problem to solve, compared to modifying node-based
workflows.  Exocortex will probably streamline it between the three
apps long before Autodesk does.  I mean, they're already well on their
way with their Alembic plugin products.

Once scenes are offloading efficiently, you simply design your
specialty software to talk to the same offloading protocol, or act as
a plug-in in software that already speaks that protocol.

The bleeding edge for scene scalability is found in render software,
not DCC apps.  And it's pretty much always been that way.

- Andy

On Thu, Sep 6, 2012 at 9:30 AM, Williams, Wayne
 wrote:
> What I'd like to know is how the devs feel about the core of Maya in 
> comparison to Soft now that they have access to the code (I'm guessing this 
> is the case, please let me know if wrong).  Are there any things you devs see 
> that were done extremely well in Maya and Soft could have taken a cue from in 
> that regard or vice versa? I realize that you can't go into specifics but 
> figured I'd put the general question out there.
> -wayne
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Kubicek
> Sent: Thursday, September 06, 2012 12:05 PM
> To: softimage@listproc.autodesk.com
> Subject: Re: ICE in Maya is an engineer's worst nightmare
>
> Fair enough and agreed on, but why would Maya be a better candidate to be 
> developed in that direction than any other app?
>
>
>> On Thu, Sep 6, 2012 at 11:22 AM, Stefan Kubicek  
>> wrote:
>>> Scalability is a good buzzword, but what does it actually mean?
>>
>> In the specific context of FX, scalability means very large number of
>> objects, billions of particles, huge fluid grids, etc. Stuff that may
>> not even fit in RAM at once.  Juhani's mention of Katana is a good
>> one; it doesn't just everything in RAM at once and process it the way
>> traditional apps do, it creates a receipe that will run in the
>> renderer as needed.  For very large data sets, different tools and
>> approach are required other than just adding more RAM to a single PC
>> and doing things the old way.  It's also difficult to reference,
>> track, change  all those assets if the system isn't thought for that.
>> Again, truck vs family car.
>>
>>> Does it mean you can "process" more "data" in the same amount of time
>>> compared to another app? And what kind of data? Procedural geometry?
>>> Rendered Images? Does it mean you can load more assets into the same
>>> amount of available RAM on a machine compared to another app?
>>>
>>> How would the automation of such processes need to look like to scale well?
>>> Scripted? C++? Node-based like ICE?
>>> Multithreading across the board? Or is it a question of architecture
>>> rather than which programming language was used to implement it (scripted 
>>> vs C++)?
>>> What does Maya offer in this regard, or where does it differ, to
>>> scale well/better than Soft or app X in your opinion?
>>>
>>> In my experience Softimage offers pretty much the same mechanisms to
>>> automate processes and handle scene complexity as Maya does, + ICE on
>>> top, and I found it can load a good chunk more data simultaneously
>>> than Maya can fit into the same amount of memory, especially when it
>>> comes to working with textures and realtime shaders. That was

Re: ICE in Maya is an engineer's worst nightmare

[Daniel H]

Re: ...Luc-Eric's point that just bringing Maya up to Soft's level isn't
exactly pushing the envelope" - Well you have to first prove you can handle
the 50 lb. bicep curl before you can move up to the 60's.

While it's true a lot of shops are running Maya, they certainly aren't
doing it without a lot of added cost from workarounds, custom survival
tools, dedicated programmers, and overall hair-pulling. I worked for over a
year with a fully loaded shop of Mayans and every day was a day of
frustration, cussing, and chaos. That experience (I was there as a
programmer) gave me plenty of time to contemplate a better 3D package. Maya
is nothing but cobbled and hacked crap. Maya was initially popular over SI
starting in 1998 only because it was much cheaper (1/10 of the SI price at
the time) not because it was superior.

Is Maya's target SI or Houdini? That's irrelevant to its present task...
can it catch up to, or will it ever surpass either one? Not sure anymore if
Softimage is an ever increasing target, but Houdini definitely is. Will AD
pour thousands of hours and invest serious money into Maya to make all that
happen? It's very clear AD is unpredictable. This is what happens when you
try to convince everyone it's all ok and we're maintaining three products
because we love you and we want you to have freedom of choice. Well fluffy
marketing aside, AD can't effectively maintain three products that
basically do the same thing. It was all poor strategy from the beginning.

Daniel
VFXM

Re: ICE in Maya is an engineer's worst nightmare

[Bradley Gabe]

Think of Maya more like a standard than an application. It's a front end
that people are already used to looking at, even though they might be using
it to drive a different "truck" on the back end. If you don't like working
within the Maya or Max environment, imagine what it was like working in a
completely proprietary environment developed by your RnD department who was
more interested in making cool effects possible than smoothing out the GUI
and user experience!

With a DCC application, you *have* to invest in the user experience because
you need to sell as many seats as possible. With a custom RnD effort inside
your studio, you don't care as much about user experience because you have
a captive "market" who is facing the choice of "do it my way" if you even
want to have a remote chance of doing it at all.

It doesn't matter if the XSI experience is nicer for some of us. It doesn't
matter if XSI's core is more mature or potentially easier to develop for
functionality like ICE. At the end of the day, the larger market base has
built their own "trucks" and is using Maya to drive them, and they might be
starting to champ at the bit a little as their "trucks" are needing more
modern controls. XSI is not an option to them, it's not even on the radar.
The real threat is their fear of ADSK, and the potential that they re-wire
their trucks without dependence on any DCC app.

Meanwhile, for the rest of us who don't have our own RnD departments, XSI
is great because something like ICE does empower non-programmers to do
things we couldn't do otherwise. So at least we have a fighting chance.
Compare the workability of a custom tool made by someone who only writes
code all day, versus a custom tool developed by the user in the context of
the usage. There is still a huge value to that, and should (hopefully)
continue to be a market for that.

-Bradley

On Thu, Sep 6, 2012 at 12:04 PM, Stefan Kubicek wrote:

> Fair enough and agreed on, but why would Maya be a better candidate to be
> developed in that direction than any other app?
>
>
>

Re: Forcing Order of firing of events in soft

[Alan Fregtman]

The only workaround I can think of is keeping track of which events have
run with global temporary variables (SetGlobal(), GetGlobal()) and if an
event fires and it shouldn't, registering a TimerEvent to re-fire that
procedure soon thereafter, thus allowing other events to fire, until they
have all fired in the right order.

Ugly, but better than nothing.

What's stopping you from doing all the events in one?


On Thu, Sep 6, 2012 at 1:19 PM, Alok  wrote:

>  Hi List,
>
> Is there a way we can force the order of running events in soft ?. For
> example I have two events for open scene event1 and event2. Is there a way
> I can force the events to fire in a predetermined order so that event1 is
> always fired before event2.
>
> Apparently I know the answer to this one is no but I am still asking if
> anyone has some insights.
> --
>
<>

Forcing Order of firing of events in soft

[Alok]

  
  
Hi List,

Is there a way we can force the order of running events in soft ?.
For example I have two events for open scene event1 and event2. Is
there a way I can force the events to fire in a predetermined order
so that event1 is always fired before event2.

Apparently I know the answer to this one is no but I am still asking
if anyone has some insights.
-- 
  
  

Re: SDK : connecting an object to a matrix port on a shader

[Steven Caron]

anyone?

how about multiple output ports on SCOPs, anyone do that before?

s

On Wed, Sep 5, 2012 at 1:38 PM, Steven Caron  wrote:

> does anyone have any examples on how to connect an object matrix to a port
> on a shader using a scop? its been soo long since i have used scops and i
> am not getting much traction.
>
> s
>

RE: ICE in Maya is an engineer's worst nightmare

[Williams, Wayne]

What I'd like to know is how the devs feel about the core of Maya in comparison 
to Soft now that they have access to the code (I'm guessing this is the case, 
please let me know if wrong).  Are there any things you devs see that were done 
extremely well in Maya and Soft could have taken a cue from in that regard or 
vice versa? I realize that you can't go into specifics but figured I'd put the 
general question out there. 
-wayne


-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Kubicek
Sent: Thursday, September 06, 2012 12:05 PM
To: softimage@listproc.autodesk.com
Subject: Re: ICE in Maya is an engineer's worst nightmare

Fair enough and agreed on, but why would Maya be a better candidate to be 
developed in that direction than any other app?


> On Thu, Sep 6, 2012 at 11:22 AM, Stefan Kubicek  
> wrote:
>> Scalability is a good buzzword, but what does it actually mean?
>
> In the specific context of FX, scalability means very large number of 
> objects, billions of particles, huge fluid grids, etc. Stuff that may 
> not even fit in RAM at once.  Juhani's mention of Katana is a good 
> one; it doesn't just everything in RAM at once and process it the way 
> traditional apps do, it creates a receipe that will run in the 
> renderer as needed.  For very large data sets, different tools and 
> approach are required other than just adding more RAM to a single PC 
> and doing things the old way.  It's also difficult to reference, 
> track, change  all those assets if the system isn't thought for that.
> Again, truck vs family car.
>
>> Does it mean you can "process" more "data" in the same amount of time 
>> compared to another app? And what kind of data? Procedural geometry? 
>> Rendered Images? Does it mean you can load more assets into the same 
>> amount of available RAM on a machine compared to another app?
>>
>> How would the automation of such processes need to look like to scale well?
>> Scripted? C++? Node-based like ICE?
>> Multithreading across the board? Or is it a question of architecture 
>> rather than which programming language was used to implement it (scripted vs 
>> C++)?
>> What does Maya offer in this regard, or where does it differ, to 
>> scale well/better than Soft or app X in your opinion?
>>
>> In my experience Softimage offers pretty much the same mechanisms to 
>> automate processes and handle scene complexity as Maya does, + ICE on 
>> top, and I found it can load a good chunk more data simultaneously 
>> than Maya can fit into the same amount of memory, especially when it 
>> comes to working with textures and realtime shaders. That was up 
>> until two versions ago, maybe that has changed?
>>
>> If all that doesn't mean it scales well, what exactly does it mean then?
>>
>> Note: I'm not a Softimage fanboy or Maya hater (ok, just a little, 
>> but not enough to not use it if it offers something that helps me to 
>> do my work), I just try to understand what scalability means by your 
>> (or anyones) standards compared to how I understand it.
>


--
---
Stefan Kubicek   Co-founder
---
   keyvis digital imagery
  Wehrgasse 9 - Grüner Hof
   1050 Vienna  Austria
 Phone:+43/699/12614231
--- www.keyvis.at  ste...@keyvis.at ---
--  This email and its attachments are
--confidential and for the recipient only--

Re: Pyton 2.7 and Softimage?

[Francois Lord]

Thanks Stephen.
I knew it was quicker to ask here than search the archives. :)

On 06/09/2012 12:10, Stephen Blair wrote:

Hi Francois

The bug (some sort of memory leak with named objects like XSIMath 
being added into the scripting engine) was related to the version of 
pywin. That's why we--oops--they, settled on 2.5 and 212.


https://groups.google.com/d/topic/xsi_list/hnOTjF3JBsU/discussion

I've used 2.7, but that was only for day-to-day support work.


On Thu, Sep 6, 2012 at 12:04 PM, Francois Lord > wrote:


Hi,

Is anyone using python 2.7 with Softimage on Windows?
Any problems?
I remember there was a bug a while back, but can't remember what
it was. It is fixed?

Thanks.

Re: Pyton 2.7 and Softimage?

[Stephen Blair]

Hi Francois

The bug (some sort of memory leak with named objects like XSIMath being
added into the scripting engine) was related to the version of pywin.
That's why we--oops--they, settled on 2.5 and 212.

https://groups.google.com/d/topic/xsi_list/hnOTjF3JBsU/discussion

I've used 2.7, but that was only for day-to-day support work.


On Thu, Sep 6, 2012 at 12:04 PM, Francois Lord  wrote:

> Hi,
>
> Is anyone using python 2.7 with Softimage on Windows?
> Any problems?
> I remember there was a bug a while back, but can't remember what it was.
> It is fixed?
>
> Thanks.
>

Re: subscribing and unsubscribing from the Softimage mailing list

[Bradley Gabe]

And then he threw us out of his life. He thought we were creeps. He thought
we were geeks, and he probably wasn't the first...

On Thu, Sep 6, 2012 at 11:26 AM, Chris Chia  wrote:

> Ok Oral, removing u now...
> This is probably the last email for u.
>
> Chris
>
> On 6 Sep, 2012, at 11:13 PM, "Luc-Eric Rousseau" 
> wrote:
>
> > Wait, I thought you had failed to bring presents.  you meant failed to
> > unsubscribe..
> >
> > On Thu, Sep 6, 2012 at 11:05 AM, Oral Samli 
> wrote:
> >> Please do so, I wanted to give it a try again but nothing have changed,
> I
> >> dislike mailing lists:)
> >>
> >>
> >> On Thu, 06 Sep 2012 17:53:48 +0300, Chris Chia  >
> >> wrote:
> >>
> >>> Hey Oral, I would unsubscribe for you if u could confirm here.
> >>>
> >>> Chris
> >>>
> >>> On 6 Sep, 2012, at 9:37 PM, "Oral Samli"
> >>> mailto:greatclo...@live.com>> wrote:
> >>>
> >>> I tried but failed:)
> >>>
> >>> On Thu, 06 Sep 2012 16:22:02 +0300, Alan Fregtman
> >>> mailto:alan.fregt...@gmail.com>> wrote:
> >>>
> >>> You brought presents?! :D
> >>>
> >>> On Thu, Sep 6, 2012 at 12:04 AM, Rares Halmagean
> >>> mailto:ra...@rarebrush.com>> wrote:
> >>> Present!  :}
> >>>
> >>>
> >>> On 9/5/2012 10:19 AM, Bradley Gabe wrote:
> >>> Everyone who is currently unsubscribed from this list, please respond.
> >>>
> >>>
> >>> On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia
> >>> mailto:chris.c...@autodesk.com>> wrote:
> >>> Ha, people are addicted to this list, who would bother to know how to
> >>> unsubscribe... J
> >>>
> >>>
> >>> On 5 Sep, 2012, at 10:54 PM, "Luc-Eric Rousseau"
> >>> mailto:luceri...@gmail.com>> wrote:
> >>>
>  "You are so much to me list.. I wish I knew how to quit you!"
> 
>  To subscribe:
> 
>  Send an email to
> 
>  softimage-requ...@listproc.autodesk.com softimage-requ...@listproc.autodesk.com>
>  with the subject
>    subscribe
>  Then reply to the confirmation email that is sent back to you.
> 
>  To unsubscribe:
>  Send an email to
> 
>  softimage-requ...@listproc.autodesk.com softimage-requ...@listproc.autodesk.com>
>  with the subject
>    unsubscribe
>  Then reply to the confirmation email that is sent back to you.
> 
> 
>  Can't get it to work? You can ask me to do it for you
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Using Opera's revolutionary email client: http://www.opera.com/mail/
> >>
> >>
> >>
> >> --
> >> Using Opera's revolutionary email client: http://www.opera.com/mail/
>

Re: ICE in Maya is an engineer's worst nightmare

[Stefan Kubicek]

Fair enough and agreed on, but why would Maya be a better candidate to be 
developed in that direction than any other app?



On Thu, Sep 6, 2012 at 11:22 AM, Stefan Kubicek  wrote:

Scalability is a good buzzword, but what does it actually mean?


In the specific context of FX, scalability means very large number of
objects, billions of particles, huge fluid grids, etc. Stuff that may
not even fit in RAM at once.  Juhani's mention of Katana is a good
one; it doesn't just everything in RAM at once and process it the way
traditional apps do, it creates a receipe that will run in the
renderer as needed.  For very large data sets, different tools and
approach are required other than just adding more RAM to a single PC
and doing things the old way.  It's also difficult to reference,
track, change  all those assets if the system isn't thought for that.
Again, truck vs family car.


Does it mean you can "process" more "data" in the same amount of time
compared to another app? And
what kind of data? Procedural geometry? Rendered Images? Does it mean you
can load more assets into the same amount of available RAM on a machine
compared to another app?

How would the automation of such processes need to look like to scale well?
Scripted? C++? Node-based like ICE?
Multithreading across the board? Or is it a question of architecture rather
than which programming language was used to implement it (scripted vs C++)?
What does Maya offer in this regard, or where does it differ, to scale
well/better than Soft or app X in your opinion?

In my experience Softimage offers pretty much the same mechanisms to
automate processes and handle scene complexity as Maya does, + ICE on top,
and I found it can load a good chunk more data simultaneously than Maya can
fit into the same amount of memory, especially when it comes to working with
textures and realtime shaders. That was up until two versions ago, maybe
that has changed?

If all that doesn't mean it scales well, what exactly does it mean then?

Note: I'm not a Softimage fanboy or Maya hater (ok, just a little, but not
enough to not use it if it offers something that helps me to do my work), I
just try to understand what scalability means by your (or anyones) standards
compared to how I understand it.





--
---
Stefan Kubicek   Co-founder
---
  keyvis digital imagery
 Wehrgasse 9 - Grüner Hof
   1050 Vienna  Austria
Phone:+43/699/12614231
--- www.keyvis.at  ste...@keyvis.at ---
--  This email and its attachments are
--confidential and for the recipient only--

Re: ICE in Maya is an engineer's worst nightmare

[Peter Agg]

*"Agreed that Maya has not caught up to the "Now" that is Softimage and
ICE."*

Surely the target for 'Now' isn't Soft, it's Houdini? As great as ICE is it
doesn't exactly match Houdini in terms of 'pure' procedural workflows. I
can certainly take Luc-Eric's point that just bringing Maya up to Soft's
level isn't exactly pushing the envelope.

I mean, personally, I think Maya has just too much baggage to ever really
push boundaries again but if that's what AD is pushing towards then they
have to look beyond what Soft is doing at the moment.



On 6 September 2012 16:30, Sandy Sutherland <
sandy.sutherl...@triggerfish.co.za> wrote:

> Wondering myself - as we have used ICE extensively to huge set dressing
> and creation of bushes etc.. for Khumba - worked like a charm - and using
> that 'other' renderer proved to be the cherry on the top - we certainly did
> not hit any walls.
>
> S.
> _
> Sandy Sutherland
> Technical Supervisor
> sandy.sutherl...@triggerfish.co.za
> _
>
>
>
>
>
> 
> From: softimage-boun...@listproc.autodesk.com [
> softimage-boun...@listproc.autodesk.com] on behalf of Stefan Kubicek [
> s...@tidbit-images.com]
> Sent: 06 September 2012 17:22
> To: softimage@listproc.autodesk.com
> Subject: Re: ICE in Maya is an engineer's worst nightmare
>
> Scalability is a good buzzword, but what does it actually mean?
>
> Does it mean you can "process" more "data" in the same amount of time
> compared to another app? And
> what kind of data? Procedural geometry? Rendered Images? Does it mean you
> can load more assets into the same amount of available RAM on a machine
> compared to another app?
>
> How would the automation of such processes need to look like to scale
> well? Scripted? C++? Node-based like ICE?
> Multithreading across the board? Or is it a question of architecture
> rather than which programming language was used to implement it (scripted
> vs C++)? What does Maya offer in this regard, or where does it differ, to
> scale well/better than Soft or app X in your opinion?
>
> In my experience Softimage offers pretty much the same mechanisms to
> automate processes and handle scene complexity as Maya does, + ICE on top,
> and I found it can load a good chunk more data simultaneously than Maya can
> fit into the same amount of memory, especially when it comes to working
> with textures and realtime shaders. That was up until two versions ago,
> maybe that has changed?
>
> If all that doesn't mean it scales well, what exactly does it mean then?
>
> Note: I'm not a Softimage fanboy or Maya hater (ok, just a little, but not
> enough to not use it if it offers something that helps me to do my work), I
> just try to understand what scalability means by your (or anyones)
> standards compared to how I understand it.
>
>
>
>
>
> > There is not as much enthusiasm in having ICE in Maya internally as
> > you'd think, and I think that mail from Chris means to infer that to
> > the community to cause some reactions, and to look beyond ICE.
> >
> > One reason is that unlike XSI 6.0, Maya has always been node-based, so
> > it would not be as much as game changer in Maya as it is in XSI which
> > had nothing. The confusing hypergraph UI and some legacy stuff (like
> > older nodes having too many inputs) obscures the use of Maya existing
> > node system, but the Maya team is working on that already with the new
> > Node Editor, no need to introduce a duplicate system.
> >
> > Another reason is much more interesting, though I suspect the message
> > boards will incinerate me for suggesting it.  Basically, there is a
> > train of thought that ICE is great, but it's just the Now, not the
> > Next; it's not scalable to the extremely large scale procedural work
> > that the Maya film clients are _already_ doing in custom apps and a
> > series of odd tools. This is work that they wouldn't be able to
> > undertake in ICE today, because it doesn't scale well to extremely
> > large data sets.  Since any kind of development takes several years,
> > Autodesk wants to focus on finding the Next, rather than just trying
> > to catch up to the Now.   The creators of Naiad, who worked on PhysBAM
> > and Zero at ILM and have multiple film credits are cooking up that
> > vision.
> >
> > Since Maya is targeted at the large studios and not the one-man
> > boutique,  Autodesk doesn't want to work on any tech that works just
> > fine for general data sets, but falls flat on its face on extremely
> > large one.  Large data set scalability is a requirement for anything
> > new we add to Maya.  That might mean something comes up that's
> > comparatively less elegant to use than ICE in XSI, but more scalable.
> > Maya is more like a construction truck than a family car, it needs to
> > move large stuff around, and that stuff keeps getting larger.
> >
> > On Thu, Sep 6, 2012 at 8:26 AM, Rob Chapman 
> wrote:
> >> OK, thanks all. so what confir

Pyton 2.7 and Softimage?

[Francois Lord]

Hi,

Is anyone using python 2.7 with Softimage on Windows?
Any problems?
I remember there was a bug a while back, but can't remember what it was. 
It is fixed?


Thanks.

Re: ICE in Maya is an engineer's worst nightmare

[Luc-Eric Rousseau]

On Thu, Sep 6, 2012 at 11:22 AM, Stefan Kubicek  wrote:
> Scalability is a good buzzword, but what does it actually mean?

In the specific context of FX, scalability means very large number of
objects, billions of particles, huge fluid grids, etc. Stuff that may
not even fit in RAM at once.  Juhani's mention of Katana is a good
one; it doesn't just everything in RAM at once and process it the way
traditional apps do, it creates a receipe that will run in the
renderer as needed.  For very large data sets, different tools and
approach are required other than just adding more RAM to a single PC
and doing things the old way.  It's also difficult to reference,
track, change  all those assets if the system isn't thought for that.
Again, truck vs family car.

> Does it mean you can "process" more "data" in the same amount of time
> compared to another app? And
> what kind of data? Procedural geometry? Rendered Images? Does it mean you
> can load more assets into the same amount of available RAM on a machine
> compared to another app?
>
> How would the automation of such processes need to look like to scale well?
> Scripted? C++? Node-based like ICE?
> Multithreading across the board? Or is it a question of architecture rather
> than which programming language was used to implement it (scripted vs C++)?
> What does Maya offer in this regard, or where does it differ, to scale
> well/better than Soft or app X in your opinion?
>
> In my experience Softimage offers pretty much the same mechanisms to
> automate processes and handle scene complexity as Maya does, + ICE on top,
> and I found it can load a good chunk more data simultaneously than Maya can
> fit into the same amount of memory, especially when it comes to working with
> textures and realtime shaders. That was up until two versions ago, maybe
> that has changed?
>
> If all that doesn't mean it scales well, what exactly does it mean then?
>
> Note: I'm not a Softimage fanboy or Maya hater (ok, just a little, but not
> enough to not use it if it offers something that helps me to do my work), I
> just try to understand what scalability means by your (or anyones) standards
> compared to how I understand it.

RE: ICE in Maya is an engineer's worst nightmare

[Sandy Sutherland]

Wondering myself - as we have used ICE extensively to huge set dressing and 
creation of bushes etc.. for Khumba - worked like a charm - and using that 
'other' renderer proved to be the cherry on the top - we certainly did not hit 
any walls.

S.
_
Sandy Sutherland
Technical Supervisor
sandy.sutherl...@triggerfish.co.za
_






From: softimage-boun...@listproc.autodesk.com 
[softimage-boun...@listproc.autodesk.com] on behalf of Stefan Kubicek 
[s...@tidbit-images.com]
Sent: 06 September 2012 17:22
To: softimage@listproc.autodesk.com
Subject: Re: ICE in Maya is an engineer's worst nightmare

Scalability is a good buzzword, but what does it actually mean?

Does it mean you can "process" more "data" in the same amount of time compared 
to another app? And
what kind of data? Procedural geometry? Rendered Images? Does it mean you can 
load more assets into the same amount of available RAM on a machine compared to 
another app?

How would the automation of such processes need to look like to scale well? 
Scripted? C++? Node-based like ICE?
Multithreading across the board? Or is it a question of architecture rather 
than which programming language was used to implement it (scripted vs C++)? 
What does Maya offer in this regard, or where does it differ, to scale 
well/better than Soft or app X in your opinion?

In my experience Softimage offers pretty much the same mechanisms to automate 
processes and handle scene complexity as Maya does, + ICE on top, and I found 
it can load a good chunk more data simultaneously than Maya can fit into the 
same amount of memory, especially when it comes to working with textures and 
realtime shaders. That was up until two versions ago, maybe that has changed?

If all that doesn't mean it scales well, what exactly does it mean then?

Note: I'm not a Softimage fanboy or Maya hater (ok, just a little, but not 
enough to not use it if it offers something that helps me to do my work), I 
just try to understand what scalability means by your (or anyones) standards 
compared to how I understand it.





> There is not as much enthusiasm in having ICE in Maya internally as
> you'd think, and I think that mail from Chris means to infer that to
> the community to cause some reactions, and to look beyond ICE.
>
> One reason is that unlike XSI 6.0, Maya has always been node-based, so
> it would not be as much as game changer in Maya as it is in XSI which
> had nothing. The confusing hypergraph UI and some legacy stuff (like
> older nodes having too many inputs) obscures the use of Maya existing
> node system, but the Maya team is working on that already with the new
> Node Editor, no need to introduce a duplicate system.
>
> Another reason is much more interesting, though I suspect the message
> boards will incinerate me for suggesting it.  Basically, there is a
> train of thought that ICE is great, but it's just the Now, not the
> Next; it's not scalable to the extremely large scale procedural work
> that the Maya film clients are _already_ doing in custom apps and a
> series of odd tools. This is work that they wouldn't be able to
> undertake in ICE today, because it doesn't scale well to extremely
> large data sets.  Since any kind of development takes several years,
> Autodesk wants to focus on finding the Next, rather than just trying
> to catch up to the Now.   The creators of Naiad, who worked on PhysBAM
> and Zero at ILM and have multiple film credits are cooking up that
> vision.
>
> Since Maya is targeted at the large studios and not the one-man
> boutique,  Autodesk doesn't want to work on any tech that works just
> fine for general data sets, but falls flat on its face on extremely
> large one.  Large data set scalability is a requirement for anything
> new we add to Maya.  That might mean something comes up that's
> comparatively less elegant to use than ICE in XSI, but more scalable.
> Maya is more like a construction truck than a family car, it needs to
> move large stuff around, and that stuff keeps getting larger.
>
> On Thu, Sep 6, 2012 at 8:26 AM, Rob Chapman  wrote:
>> OK, thanks all. so what confirmations, if any, do we actually have or
>> 'allowed' to talk about?
>>
>> 1. its not going to be ICE but will have same workflow / functionality
>>
>> - I really dont appreciate the difference? so each node will be called a
>> mayacompound and not xsicompound ?  will there be any interop with Softimage
>> / Maya planned in this regards?
>>
>> 2. Its going to take a few years
>>
>> 3. Its not a separate App, but part of the main Maya
>>
>>
>> I am good to assume these as actual facts then? :)
>>
>> And certainly dont want or need yet another tirade / rant / sky is falling
>> thread, am trying to tread carefully, be less emotional and just ask
>> rational questions based upon facts, which would be much more rewarding for
>> those that feel are being kept in the dark.  but as a Softi

Re: ICE in Maya is an engineer's worst nightmare

[Daniel H]

Re: "...rather than just trying  to catch up to the Now" - Agreed that Maya
has not caught up to the "Now" that is Softimage and ICE. Hurry Maya, the
train of innovation is leaving the station. If you run, you might catch up.

Re: "...Autodesk wants to focus on finding the Next, rather than just
trying  to catch up to the Now" - Well, I guess we will see if AD is going
to remain dedicated to spending the time and the money to leapfrog Maya
into those high bars. Dang it Maya, you idiot... you need buy a ticket
before you can get on the train of innovation.

When AD lets go of a loyal and dedicated worker like Stephen Blair, no
rooster is safe, and a coyote can enter the hen house and change the fates
of all instantly.

Daniel
VFXM

Re: subscribing and unsubscribing from the Softimage mailing list

[Chris Chia]

Ok Oral, removing u now... 
This is probably the last email for u.

Chris 

On 6 Sep, 2012, at 11:13 PM, "Luc-Eric Rousseau"  wrote:

> Wait, I thought you had failed to bring presents.  you meant failed to
> unsubscribe..
> 
> On Thu, Sep 6, 2012 at 11:05 AM, Oral Samli  wrote:
>> Please do so, I wanted to give it a try again but nothing have changed, I
>> dislike mailing lists:)
>> 
>> 
>> On Thu, 06 Sep 2012 17:53:48 +0300, Chris Chia 
>> wrote:
>> 
>>> Hey Oral, I would unsubscribe for you if u could confirm here.
>>> 
>>> Chris
>>> 
>>> On 6 Sep, 2012, at 9:37 PM, "Oral Samli"
>>> mailto:greatclo...@live.com>> wrote:
>>> 
>>> I tried but failed:)
>>> 
>>> On Thu, 06 Sep 2012 16:22:02 +0300, Alan Fregtman
>>> mailto:alan.fregt...@gmail.com>> wrote:
>>> 
>>> You brought presents?! :D
>>> 
>>> On Thu, Sep 6, 2012 at 12:04 AM, Rares Halmagean
>>> mailto:ra...@rarebrush.com>> wrote:
>>> Present!  :}
>>> 
>>> 
>>> On 9/5/2012 10:19 AM, Bradley Gabe wrote:
>>> Everyone who is currently unsubscribed from this list, please respond.
>>> 
>>> 
>>> On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia
>>> mailto:chris.c...@autodesk.com>> wrote:
>>> Ha, people are addicted to this list, who would bother to know how to
>>> unsubscribe... J
>>> 
>>> 
>>> On 5 Sep, 2012, at 10:54 PM, "Luc-Eric Rousseau"
>>> mailto:luceri...@gmail.com>> wrote:
>>> 
 "You are so much to me list.. I wish I knew how to quit you!"
 
 To subscribe:
 
 Send an email to
 
 softimage-requ...@listproc.autodesk.com
 with the subject
   subscribe
 Then reply to the confirmation email that is sent back to you.
 
 To unsubscribe:
 Send an email to
 
 softimage-requ...@listproc.autodesk.com
 with the subject
   unsubscribe
 Then reply to the confirmation email that is sent back to you.
 
 
 Can't get it to work? You can ask me to do it for you
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>> 
>> 
>> 
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
<>

Re: ICE in Maya is an engineer's worst nightmare

[Rob Chapman]

thanks Eric,

ok let me rephrase as I'm already painfully aware that as a Softimage
customer I currently have zero influence with Autodesk in the future
development of my app of choice - because the other apps have higher
priority. I understand your points and I really don't care what the other
AD apps get or have , I'm not using them on a daily basis.

what Im eager to know is, and this btw does fundamentally affect my
decision for further use and which direction to head next - is if it is
still going to be developed (more in the style it was prior to the purchase
rather than of lately) after its only unique selling point (in the eyes of
AD marketing) is assimilated into Maya. Its already been said elsewhere and
demonstrated as fact that AD wont develop in areas that crossover to the
other apps areas of interest.  - in fear of reprisal from the other larger
user bases and economic reasons,  If it continues the way it has then
really there is no point to using a product that is being held in
'maintenance' mode is there?  Its a slow death that the likes of Mr
Rabiller predicted years ago and I would rather make the course change
sooner rather than later.

Maya is to be the new platform of choice, has this new FX dev with lots of
investment in viewports etc, Max, it seems, they are admitting are limiting
to Design / Archviz only so no new *SIGNIFICANT *games / animation or
effects dev in the future for them but they do have an ongoing XBR dev
project.

Where is Softimage in all of this scheming?  is there a roadmap for the
next 5 years that the users would appreciate and are we to expect any new
features in the future of Softimage?









On 6 September 2012 14:45, Eric Thivierge  wrote:

> 1. Compare ICE to Houdini's node editor workflow. Similar but not the
> same. The Node editor is the UI. My guess is that Maya will have a prettier
> UI to work with what it already has.
> 2. Who knows...
> 3. Yes seems that they are beefing up the interaction model in Maya for
> working with its FX tools that are already there. Less similar to ICE since
> ICE redefined pretty much the entirety of particles in Softimage.
>
> Nothing that I've said is official fact but educated assumptions based on
> the facts and comments repeatedly given in the threads.
>
> In the end if you got your solid answers of what exactly they were doing
> with Maya, what does it matter? They'll do it if they want especially if
> their Maya users want it. You're not going to stop it. Are you going to
> stop using Softimage because of it? Even if its still alive and kicking?
> Think of it in a wider perspective. How does it affect you if you're
> happily using Softimage with all the awesome ICE stuff and flexible
> workflow, while the Maya dudes just get some lipstick slapped on their pig?
> Keep in mind they stated they weren't stopping dev on Softimage (fact).
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>
>
> On Thu, Sep 6, 2012 at 10:26 PM, Rob Chapman  wrote:
>
>> OK, thanks all. so what confirmations, if any, do we actually have or
>> 'allowed' to talk about?
>>
>> 1. its not going to be ICE but will have same workflow / functionality
>>
>> - I really dont appreciate the difference? so each node will be called a
>> mayacompound and not xsicompound ?  will there be any interop with
>> Softimage / Maya planned in this regards?
>>
>> 2. Its going to take a few years
>>
>> 3. Its not a separate App, but part of the main Maya
>>
>>
>> I am good to assume these as actual facts then? :)
>>
>> And certainly dont want or need yet another tirade / rant / sky is
>> falling  thread, am trying to tread carefully, be less emotional and just
>> ask rational questions based upon facts, which would be much more rewarding
>> for those that feel are being kept in the dark.  but as a Softimage
>> customer using ICE everyday since the last 6 years , (in the ultimate niche
>> of niches - Softimage FX)  I feel I have a right to know what the  is
>> going on that will affect my favourite apps future?  is the only option
>> available is to wait until 2014?
>>
>> cheers
>>
>> Rob
>>
>>
>>
>> On 6 September 2012 12:01, Luc-Eric Rousseau  wrote:
>>
>>> there is no such thing as "MayaFX".  A couple people wrote on linkedin
>>> being in the "Maya FX" team. That's like saying you work in the "Maya
>>> UI" or "Maya Rendering" team. It's not a product, it's the name of the
>>> team in the org chart. We have since learned to be more careful about
>>> those things, since it is meaningless. For example, the guys working
>>> on the Node Editor are the UI team although that might end up being
>>> useful in "FX" or "Rendering". Who is reports to is meaningless.
>>>
>>> On Thu, Sep 6, 2012 at 6:28 AM, Rob Chapman 
>>> wrote:
>>> > So its just a confirmation then of what Luceric has already hinted as
>>> to why
>>> > the ex devs from Softimage  are working on MayaFX - to port something
>>> like a
>>> > new ICE \ Naiad over to M

Re: ICE in Maya is an engineer's worst nightmare

[Stefan Kubicek]

Scalability is a good buzzword, but what does it actually mean?

Does it mean you can "process" more "data" in the same amount of time compared 
to another app? And
what kind of data? Procedural geometry? Rendered Images? Does it mean you can 
load more assets into the same amount of available RAM on a machine compared to 
another app?

How would the automation of such processes need to look like to scale well? 
Scripted? C++? Node-based like ICE?
Multithreading across the board? Or is it a question of architecture rather 
than which programming language was used to implement it (scripted vs C++)? 
What does Maya offer in this regard, or where does it differ, to scale 
well/better than Soft or app X in your opinion?

In my experience Softimage offers pretty much the same mechanisms to automate 
processes and handle scene complexity as Maya does, + ICE on top, and I found 
it can load a good chunk more data simultaneously than Maya can fit into the 
same amount of memory, especially when it comes to working with textures and 
realtime shaders. That was up until two versions ago, maybe that has changed?

If all that doesn't mean it scales well, what exactly does it mean then?

Note: I'm not a Softimage fanboy or Maya hater (ok, just a little, but not 
enough to not use it if it offers something that helps me to do my work), I 
just try to understand what scalability means by your (or anyones) standards 
compared to how I understand it.






There is not as much enthusiasm in having ICE in Maya internally as
you'd think, and I think that mail from Chris means to infer that to
the community to cause some reactions, and to look beyond ICE.

One reason is that unlike XSI 6.0, Maya has always been node-based, so
it would not be as much as game changer in Maya as it is in XSI which
had nothing. The confusing hypergraph UI and some legacy stuff (like
older nodes having too many inputs) obscures the use of Maya existing
node system, but the Maya team is working on that already with the new
Node Editor, no need to introduce a duplicate system.

Another reason is much more interesting, though I suspect the message
boards will incinerate me for suggesting it.  Basically, there is a
train of thought that ICE is great, but it's just the Now, not the
Next; it's not scalable to the extremely large scale procedural work
that the Maya film clients are _already_ doing in custom apps and a
series of odd tools. This is work that they wouldn't be able to
undertake in ICE today, because it doesn't scale well to extremely
large data sets.  Since any kind of development takes several years,
Autodesk wants to focus on finding the Next, rather than just trying
to catch up to the Now.   The creators of Naiad, who worked on PhysBAM
and Zero at ILM and have multiple film credits are cooking up that
vision.

Since Maya is targeted at the large studios and not the one-man
boutique,  Autodesk doesn't want to work on any tech that works just
fine for general data sets, but falls flat on its face on extremely
large one.  Large data set scalability is a requirement for anything
new we add to Maya.  That might mean something comes up that's
comparatively less elegant to use than ICE in XSI, but more scalable.
Maya is more like a construction truck than a family car, it needs to
move large stuff around, and that stuff keeps getting larger.

On Thu, Sep 6, 2012 at 8:26 AM, Rob Chapman  wrote:

OK, thanks all. so what confirmations, if any, do we actually have or
'allowed' to talk about?

1. its not going to be ICE but will have same workflow / functionality

- I really dont appreciate the difference? so each node will be called a
mayacompound and not xsicompound ?  will there be any interop with Softimage
/ Maya planned in this regards?

2. Its going to take a few years

3. Its not a separate App, but part of the main Maya


I am good to assume these as actual facts then? :)

And certainly dont want or need yet another tirade / rant / sky is falling
thread, am trying to tread carefully, be less emotional and just ask
rational questions based upon facts, which would be much more rewarding for
those that feel are being kept in the dark.  but as a Softimage customer
using ICE everyday since the last 6 years , (in the ultimate niche of niches
- Softimage FX)  I feel I have a right to know what the  is going on
that will affect my favourite apps future?  is the only option available is
to wait until 2014?

cheers

Rob





--
---
Stefan Kubicek   Co-founder
---
  keyvis digital imagery
 Wehrgasse 9 - Grüner Hof
   1050 Vienna  Austria
Phone:+43/699/12614231
--- www.keyvis.at  ste...@keyvis.at ---
--  This email and its attachments are
--confidential and for the recipient only--

Re: subscribing and unsubscribing from the Softimage mailing list

[Luc-Eric Rousseau]

Wait, I thought you had failed to bring presents.  you meant failed to
unsubscribe..

On Thu, Sep 6, 2012 at 11:05 AM, Oral Samli  wrote:
> Please do so, I wanted to give it a try again but nothing have changed, I
> dislike mailing lists:)
>
>
> On Thu, 06 Sep 2012 17:53:48 +0300, Chris Chia 
> wrote:
>
>> Hey Oral, I would unsubscribe for you if u could confirm here.
>>
>> Chris
>>
>> On 6 Sep, 2012, at 9:37 PM, "Oral Samli"
>> mailto:greatclo...@live.com>> wrote:
>>
>> I tried but failed:)
>>
>> On Thu, 06 Sep 2012 16:22:02 +0300, Alan Fregtman
>> mailto:alan.fregt...@gmail.com>> wrote:
>>
>> You brought presents?! :D
>>
>> On Thu, Sep 6, 2012 at 12:04 AM, Rares Halmagean
>> mailto:ra...@rarebrush.com>> wrote:
>> Present!  :}
>>
>>
>> On 9/5/2012 10:19 AM, Bradley Gabe wrote:
>> Everyone who is currently unsubscribed from this list, please respond.
>>
>>
>> On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia
>> mailto:chris.c...@autodesk.com>> wrote:
>> Ha, people are addicted to this list, who would bother to know how to
>> unsubscribe... J
>>
>>
>> On 5 Sep, 2012, at 10:54 PM, "Luc-Eric Rousseau"
>> mailto:luceri...@gmail.com>> wrote:
>>
>>> "You are so much to me list.. I wish I knew how to quit you!"
>>>
>>> To subscribe:
>>>
>>> Send an email to
>>>
>>> softimage-requ...@listproc.autodesk.com
>>> with the subject
>>>subscribe
>>> Then reply to the confirmation email that is sent back to you.
>>>
>>> To unsubscribe:
>>> Send an email to
>>>
>>> softimage-requ...@listproc.autodesk.com
>>> with the subject
>>>unsubscribe
>>> Then reply to the confirmation email that is sent back to you.
>>>
>>>
>>> Can't get it to work? You can ask me to do it for you
>>
>>
>>
>>
>>
>>
>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: ICE in Maya is an engineer's worst nightmare

[Juhani Karlsson]

Imo, I think Katana is the answer for the all the time growing datasets.
(Naturally its not Autodeks product, tho)
Maya should focus on making proper content, hehe! ; )

On 6 September 2012 17:59, Luc-Eric Rousseau  wrote:

> There is not as much enthusiasm in having ICE in Maya internally as
> you'd think, and I think that mail from Chris means to infer that to
> the community to cause some reactions, and to look beyond ICE.
>
> One reason is that unlike XSI 6.0, Maya has always been node-based, so
> it would not be as much as game changer in Maya as it is in XSI which
> had nothing. The confusing hypergraph UI and some legacy stuff (like
> older nodes having too many inputs) obscures the use of Maya existing
> node system, but the Maya team is working on that already with the new
> Node Editor, no need to introduce a duplicate system.
>
> Another reason is much more interesting, though I suspect the message
> boards will incinerate me for suggesting it.  Basically, there is a
> train of thought that ICE is great, but it's just the Now, not the
> Next; it's not scalable to the extremely large scale procedural work
> that the Maya film clients are _already_ doing in custom apps and a
> series of odd tools. This is work that they wouldn't be able to
> undertake in ICE today, because it doesn't scale well to extremely
> large data sets.  Since any kind of development takes several years,
> Autodesk wants to focus on finding the Next, rather than just trying
> to catch up to the Now.   The creators of Naiad, who worked on PhysBAM
> and Zero at ILM and have multiple film credits are cooking up that
> vision.
>
> Since Maya is targeted at the large studios and not the one-man
> boutique,  Autodesk doesn't want to work on any tech that works just
> fine for general data sets, but falls flat on its face on extremely
> large one.  Large data set scalability is a requirement for anything
> new we add to Maya.  That might mean something comes up that's
> comparatively less elegant to use than ICE in XSI, but more scalable.
> Maya is more like a construction truck than a family car, it needs to
> move large stuff around, and that stuff keeps getting larger.
>
> On Thu, Sep 6, 2012 at 8:26 AM, Rob Chapman  wrote:
> > OK, thanks all. so what confirmations, if any, do we actually have or
> > 'allowed' to talk about?
> >
> > 1. its not going to be ICE but will have same workflow / functionality
> >
> > - I really dont appreciate the difference? so each node will be called a
> > mayacompound and not xsicompound ?  will there be any interop with
> Softimage
> > / Maya planned in this regards?
> >
> > 2. Its going to take a few years
> >
> > 3. Its not a separate App, but part of the main Maya
> >
> >
> > I am good to assume these as actual facts then? :)
> >
> > And certainly dont want or need yet another tirade / rant / sky is
> falling
> > thread, am trying to tread carefully, be less emotional and just ask
> > rational questions based upon facts, which would be much more rewarding
> for
> > those that feel are being kept in the dark.  but as a Softimage customer
> > using ICE everyday since the last 6 years , (in the ultimate niche of
> niches
> > - Softimage FX)  I feel I have a right to know what the  is going on
> > that will affect my favourite apps future?  is the only option available
> is
> > to wait until 2014?
> >
> > cheers
> >
> > Rob
>



-- 
-- 
Juhani Karlsson
3D Artist/TD

Talvi Digital Oy
Pursimiehenkatu 29-31 b 2krs.
00150 Helsinki
+358 443443088
juhani.karls...@talvi.fi
www.vimeo.com/talvi

Re: subscribing and unsubscribing from the Softimage mailing list

[Oral Samli]

Please do so, I wanted to give it a try again but nothing have changed, I  
dislike mailing lists:)


On Thu, 06 Sep 2012 17:53:48 +0300, Chris Chia   
wrote:



Hey Oral, I would unsubscribe for you if u could confirm here.

Chris

On 6 Sep, 2012, at 9:37 PM, "Oral Samli"  
mailto:greatclo...@live.com>> wrote:


I tried but failed:)

On Thu, 06 Sep 2012 16:22:02 +0300, Alan Fregtman  
mailto:alan.fregt...@gmail.com>> wrote:


You brought presents?! :D

On Thu, Sep 6, 2012 at 12:04 AM, Rares Halmagean  
mailto:ra...@rarebrush.com>> wrote:

Present!  :}


On 9/5/2012 10:19 AM, Bradley Gabe wrote:
Everyone who is currently unsubscribed from this list, please respond.


On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia  
mailto:chris.c...@autodesk.com>> wrote:
Ha, people are addicted to this list, who would bother to know how to  
unsubscribe... J



On 5 Sep, 2012, at 10:54 PM, "Luc-Eric Rousseau"  
mailto:luceri...@gmail.com>> wrote:



"You are so much to me list.. I wish I knew how to quit you!"

To subscribe:

Send an email to
   
softimage-requ...@listproc.autodesk.com
with the subject
   subscribe
Then reply to the confirmation email that is sent back to you.

To unsubscribe:
Send an email to
   
softimage-requ...@listproc.autodesk.com
with the subject
   unsubscribe
Then reply to the confirmation email that is sent back to you.


Can't get it to work? You can ask me to do it for you







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



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

Re: ICE in Maya is an engineer's worst nightmare

[Luc-Eric Rousseau]

There is not as much enthusiasm in having ICE in Maya internally as
you'd think, and I think that mail from Chris means to infer that to
the community to cause some reactions, and to look beyond ICE.

One reason is that unlike XSI 6.0, Maya has always been node-based, so
it would not be as much as game changer in Maya as it is in XSI which
had nothing. The confusing hypergraph UI and some legacy stuff (like
older nodes having too many inputs) obscures the use of Maya existing
node system, but the Maya team is working on that already with the new
Node Editor, no need to introduce a duplicate system.

Another reason is much more interesting, though I suspect the message
boards will incinerate me for suggesting it.  Basically, there is a
train of thought that ICE is great, but it's just the Now, not the
Next; it's not scalable to the extremely large scale procedural work
that the Maya film clients are _already_ doing in custom apps and a
series of odd tools. This is work that they wouldn't be able to
undertake in ICE today, because it doesn't scale well to extremely
large data sets.  Since any kind of development takes several years,
Autodesk wants to focus on finding the Next, rather than just trying
to catch up to the Now.   The creators of Naiad, who worked on PhysBAM
and Zero at ILM and have multiple film credits are cooking up that
vision.

Since Maya is targeted at the large studios and not the one-man
boutique,  Autodesk doesn't want to work on any tech that works just
fine for general data sets, but falls flat on its face on extremely
large one.  Large data set scalability is a requirement for anything
new we add to Maya.  That might mean something comes up that's
comparatively less elegant to use than ICE in XSI, but more scalable.
Maya is more like a construction truck than a family car, it needs to
move large stuff around, and that stuff keeps getting larger.

On Thu, Sep 6, 2012 at 8:26 AM, Rob Chapman  wrote:
> OK, thanks all. so what confirmations, if any, do we actually have or
> 'allowed' to talk about?
>
> 1. its not going to be ICE but will have same workflow / functionality
>
> - I really dont appreciate the difference? so each node will be called a
> mayacompound and not xsicompound ?  will there be any interop with Softimage
> / Maya planned in this regards?
>
> 2. Its going to take a few years
>
> 3. Its not a separate App, but part of the main Maya
>
>
> I am good to assume these as actual facts then? :)
>
> And certainly dont want or need yet another tirade / rant / sky is falling
> thread, am trying to tread carefully, be less emotional and just ask
> rational questions based upon facts, which would be much more rewarding for
> those that feel are being kept in the dark.  but as a Softimage customer
> using ICE everyday since the last 6 years , (in the ultimate niche of niches
> - Softimage FX)  I feel I have a right to know what the  is going on
> that will affect my favourite apps future?  is the only option available is
> to wait until 2014?
>
> cheers
>
> Rob

Re: subscribing and unsubscribing from the Softimage mailing list

[Chris Chia]

Hey Oral, I would unsubscribe for you if u could confirm here.

Chris

On 6 Sep, 2012, at 9:37 PM, "Oral Samli" 
mailto:greatclo...@live.com>> wrote:

I tried but failed:)

On Thu, 06 Sep 2012 16:22:02 +0300, Alan Fregtman 
mailto:alan.fregt...@gmail.com>> wrote:

You brought presents?! :D

On Thu, Sep 6, 2012 at 12:04 AM, Rares Halmagean 
mailto:ra...@rarebrush.com>> wrote:
Present!  :}


On 9/5/2012 10:19 AM, Bradley Gabe wrote:
Everyone who is currently unsubscribed from this list, please respond.


On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia 
mailto:chris.c...@autodesk.com>> wrote:
Ha, people are addicted to this list, who would bother to know how to 
unsubscribe... J


On 5 Sep, 2012, at 10:54 PM, "Luc-Eric Rousseau" 
mailto:luceri...@gmail.com>> wrote:

> "You are so much to me list.. I wish I knew how to quit you!"
>
> To subscribe:
>
> Send an email to
>
> softimage-requ...@listproc.autodesk.com
> with the subject
>subscribe
> Then reply to the confirmation email that is sent back to you.
>
> To unsubscribe:
> Send an email to
>
> softimage-requ...@listproc.autodesk.com
> with the subject
>unsubscribe
> Then reply to the confirmation email that is sent back to you.
>
>
> Can't get it to work? You can ask me to do it for you






--
Using Opera's revolutionary email client: http://www.opera.com/mail/
<>

Re: subscribing and unsubscribing from the Softimage mailing list

[Oral Samli]

I tried but failed:)On Thu, 06 Sep 2012 16:22:02 +0300, Alan Fregtman  wrote:You brought presents?! :DOn Thu, Sep 6, 2012 at 12:04 AM, Rares Halmagean  wrote:


  

  
  
Present!  :}

On 9/5/2012 10:19 AM, Bradley Gabe
  wrote:

Everyone who is currently unsubscribed from this list,
  please respond.
  

On Wed, Sep 5, 2012 at 11:09 AM, Chris
  Chia 
  wrote:
  Ha, people
are addicted to this list, who would bother to know how to
unsubscribe... J

  

On 5 Sep, 2012, at 10:54 PM, "Luc-Eric Rousseau" 
wrote:

> "You are so much to me list.. I wish I knew how to
quit you!"
>
> To subscribe:
>
> Send an email to
>    softimage-requ...@listproc.autodesk.com
> with the subject
>    subscribe
> Then reply to the confirmation email that is sent
back to you.
>
> To unsubscribe:
> Send an email to
>    softimage-requ...@listproc.autodesk.com
> with the subject
>    unsubscribe
> Then reply to the confirmation email that is sent
back to you.
>
>
> Can't get it to work? You can ask me to do it for
you
  

  


  


  


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

Re: ICE in Maya is an engineer's worst nightmare

[Eric Thivierge]

1. Compare ICE to Houdini's node editor workflow. Similar but not the same.
The Node editor is the UI. My guess is that Maya will have a prettier UI to
work with what it already has.
2. Who knows...
3. Yes seems that they are beefing up the interaction model in Maya for
working with its FX tools that are already there. Less similar to ICE since
ICE redefined pretty much the entirety of particles in Softimage.

Nothing that I've said is official fact but educated assumptions based on
the facts and comments repeatedly given in the threads.

In the end if you got your solid answers of what exactly they were doing
with Maya, what does it matter? They'll do it if they want especially if
their Maya users want it. You're not going to stop it. Are you going to
stop using Softimage because of it? Even if its still alive and kicking?
Think of it in a wider perspective. How does it affect you if you're
happily using Softimage with all the awesome ICE stuff and flexible
workflow, while the Maya dudes just get some lipstick slapped on their pig?
Keep in mind they stated they weren't stopping dev on Softimage (fact).


Eric Thivierge
http://www.ethivierge.com


On Thu, Sep 6, 2012 at 10:26 PM, Rob Chapman  wrote:

> OK, thanks all. so what confirmations, if any, do we actually have or
> 'allowed' to talk about?
>
> 1. its not going to be ICE but will have same workflow / functionality
>
> - I really dont appreciate the difference? so each node will be called a
> mayacompound and not xsicompound ?  will there be any interop with
> Softimage / Maya planned in this regards?
>
> 2. Its going to take a few years
>
> 3. Its not a separate App, but part of the main Maya
>
>
> I am good to assume these as actual facts then? :)
>
> And certainly dont want or need yet another tirade / rant / sky is falling
>  thread, am trying to tread carefully, be less emotional and just ask
> rational questions based upon facts, which would be much more rewarding for
> those that feel are being kept in the dark.  but as a Softimage customer
> using ICE everyday since the last 6 years , (in the ultimate niche of
> niches - Softimage FX)  I feel I have a right to know what the  is
> going on that will affect my favourite apps future?  is the only option
> available is to wait until 2014?
>
> cheers
>
> Rob
>
>
>
> On 6 September 2012 12:01, Luc-Eric Rousseau  wrote:
>
>> there is no such thing as "MayaFX".  A couple people wrote on linkedin
>> being in the "Maya FX" team. That's like saying you work in the "Maya
>> UI" or "Maya Rendering" team. It's not a product, it's the name of the
>> team in the org chart. We have since learned to be more careful about
>> those things, since it is meaningless. For example, the guys working
>> on the Node Editor are the UI team although that might end up being
>> useful in "FX" or "Rendering". Who is reports to is meaningless.
>>
>> On Thu, Sep 6, 2012 at 6:28 AM, Rob Chapman  wrote:
>> > So its just a confirmation then of what Luceric has already hinted as
>> to why
>> > the ex devs from Softimage  are working on MayaFX - to port something
>> like a
>> > new ICE \ Naiad over to Maya. A bit more open about it than in the past
>> > which is better than usual.
>>
>
>

Re: Asset viewer / manager

[Michal Doniec]

I understand. Seems like quite involved project (probably needs a
human to keep it tidy :) ) - maybe sending the data/recent version of
assets from production asset system to archive as you go would work,
just an idea, I've never done anything like this before. I'd think
that archiving in version control system wouldn't be good.

Most projects I work on have exactly the same issue as you mentioned,
when they are done, they are usually gone (archived, but rather hard
to restore), I tend to keep my own backups of small subset of assets,
but it's not really practical.

On Thu, Sep 6, 2012 at 1:18 PM, Marc-Andre Carbonneau
 wrote:
> Right. It sounds interesting. We have something similar in place. We already 
> have a pipeline which is addressing what you're mentioning below. What I was 
> looking for was more of a separate archive or library where some things from 
> a project can be shelved and identified correctly for future use. The reason 
> is the way we are set up, once we are done and delivered a project, the 
> sandboxes get deleted and only what has been checked in with the pipeline 
> tools is backed up. That way we only have the relevant scenes, assets etc... 
> Once the backup is done, it can take up to 3 weeks to get a project back. We 
> don't always have that kind of time so we want to use a tool similar to 
> ResourceSpace to create a growing library of the kind of assets that gets 
> regularly used.
> For example we model lots of characters and we're asked to do more and more 
> crowds so having secondary or low characters already available will improve 
> previz quality and turnaround time instead of having to remodel everything or 
> having ugly unibody proxies. ;) And since we're a game company and that we do 
> quite a few shooters we also have tons of different guns at different 
> resolutions. We need to index this properly.
> We'll be having discussion about all this soon internally. The way I see it 
> right now is probably to go with something like ResourceSpace and include the 
> power of Fabric Engine. Might be overkill, thumbnails might do. We'll see how 
> excited I can get the developers over this. ;)
>
> Thanks Michal and all
> MAC
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Michal Doniec
> Sent: Thursday, September 06, 2012 7:13 AM
> To: softimage@listproc.autodesk.com
> Subject: Re: Asset viewer / manager
>
> I developed one which uses Python/PyQT/SQL and perforce (was used sucessfully 
> on our last project which is about to be shipped), but it's just for 
> lighweight assets (.emdls). Basically all tracking is done using SQL, storage 
> and version control is left to perforce, with only very lightweight wrapper 
> library (I wrote it to simplify perforce interactions only) to interface with 
> asset manager.
> It works on a higher level than just .emdl, deifning an asset as an abstract 
> database record/entity, so you can have an asset which contains rigs, meshes 
> etc. components. Component is defined as an abstract class with only 
> save/load methods (which come from packagae specific custom module, so in 
> theory should be easy to port to other 3d app) and a couple of properties 
> like version and perforce path, so it's easily extendable to any component 
> type (obj, textures, fbx files I even had some reference pictures etc.. as 
> components within an asset). It makes it easy to add custom properties like 
> root node and bone count for the rigs etc. All these components can be freely 
> instanced between multple assets, so you can have a rig shared between 
> multiple creatures, for example.
>
> It is a push system, so when someone modfies and saves an asset, everyone 
> gets it automatically (there is a warning and choice to cancel tho). We used 
> it mainly for characters.
>
> I am not sure about performance (load/save/sync speed) when attempting this 
> approach with caches/obj and other heavy data, but I'd think it's mainly 
> dependend on the speed of your network/servers during sync/submit. For 
> lightweight models it was very fast.
>
> I generate thumbnails on save and they are stored as plain files in perforce, 
> also store connections between components in SQL records (link withs coming 
> from rig .emdl to mesh .emdl, envelopes, etc), they are recreated on load, so 
> there is no issue having connections between different components or mutiple 
> instances of the same assets in the scene (evelopes and other stuff will 
> connect correctly). QT takes care of the infterface, it's all displayed in a 
> tree like browser with thumbnails.
>
> It's really nothing fancy, just simple database tracking with an interface, 
> doing all perforce work for the user in the background.
> Having everything tracked in SQL database allowed easy comminuctations with 
> our animation production database and export/importscene building tools.
>
> I am sure it can be done 

Re: subscribing and unsubscribing from the Softimage mailing list

[Alan Fregtman]

You brought presents?! :D

On Thu, Sep 6, 2012 at 12:04 AM, Rares Halmagean wrote:

>  Present!  :}
>
>
> On 9/5/2012 10:19 AM, Bradley Gabe wrote:
>
> Everyone who is currently unsubscribed from this list, please respond.
>
>
> On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia wrote:
>
>> Ha, people are addicted to this list, who would bother to know how to
>> unsubscribe... J
>>
>>
>> On 5 Sep, 2012, at 10:54 PM, "Luc-Eric Rousseau" 
>> wrote:
>>
>> > "You are so much to me list.. I wish I knew how to quit you!"
>> >
>> > To subscribe:
>> >
>> > Send an email to
>> >softimage-requ...@listproc.autodesk.com
>> > with the subject
>> >subscribe
>> > Then reply to the confirmation email that is sent back to you.
>> >
>> > To unsubscribe:
>> > Send an email to
>> >softimage-requ...@listproc.autodesk.com
>> > with the subject
>> >unsubscribe
>> > Then reply to the confirmation email that is sent back to you.
>> >
>> >
>> > Can't get it to work? You can ask me to do it for you
>>
>
>
>

RE: Asset viewer / manager

[Marc-Andre Carbonneau]

Right. It sounds interesting. We have something similar in place. We already 
have a pipeline which is addressing what you're mentioning below. What I was 
looking for was more of a separate archive or library where some things from a 
project can be shelved and identified correctly for future use. The reason is 
the way we are set up, once we are done and delivered a project, the sandboxes 
get deleted and only what has been checked in with the pipeline tools is backed 
up. That way we only have the relevant scenes, assets etc... Once the backup is 
done, it can take up to 3 weeks to get a project back. We don't always have 
that kind of time so we want to use a tool similar to ResourceSpace to create a 
growing library of the kind of assets that gets regularly used.
For example we model lots of characters and we're asked to do more and more 
crowds so having secondary or low characters already available will improve 
previz quality and turnaround time instead of having to remodel everything or 
having ugly unibody proxies. ;) And since we're a game company and that we do 
quite a few shooters we also have tons of different guns at different 
resolutions. We need to index this properly.
We'll be having discussion about all this soon internally. The way I see it 
right now is probably to go with something like ResourceSpace and include the 
power of Fabric Engine. Might be overkill, thumbnails might do. We'll see how 
excited I can get the developers over this. ;)

Thanks Michal and all
MAC


-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Michal Doniec
Sent: Thursday, September 06, 2012 7:13 AM
To: softimage@listproc.autodesk.com
Subject: Re: Asset viewer / manager

I developed one which uses Python/PyQT/SQL and perforce (was used sucessfully 
on our last project which is about to be shipped), but it's just for lighweight 
assets (.emdls). Basically all tracking is done using SQL, storage and version 
control is left to perforce, with only very lightweight wrapper library (I 
wrote it to simplify perforce interactions only) to interface with asset 
manager.
It works on a higher level than just .emdl, deifning an asset as an abstract 
database record/entity, so you can have an asset which contains rigs, meshes 
etc. components. Component is defined as an abstract class with only save/load 
methods (which come from packagae specific custom module, so in theory should 
be easy to port to other 3d app) and a couple of properties like version and 
perforce path, so it's easily extendable to any component type (obj, textures, 
fbx files I even had some reference pictures etc.. as components within an 
asset). It makes it easy to add custom properties like root node and bone count 
for the rigs etc. All these components can be freely instanced between multple 
assets, so you can have a rig shared between multiple creatures, for example.

It is a push system, so when someone modfies and saves an asset, everyone gets 
it automatically (there is a warning and choice to cancel tho). We used it 
mainly for characters.

I am not sure about performance (load/save/sync speed) when attempting this 
approach with caches/obj and other heavy data, but I'd think it's mainly 
dependend on the speed of your network/servers during sync/submit. For 
lightweight models it was very fast.

I generate thumbnails on save and they are stored as plain files in perforce, 
also store connections between components in SQL records (link withs coming 
from rig .emdl to mesh .emdl, envelopes, etc), they are recreated on load, so 
there is no issue having connections between different components or mutiple 
instances of the same assets in the scene (evelopes and other stuff will 
connect correctly). QT takes care of the infterface, it's all displayed in a 
tree like browser with thumbnails.

It's really nothing fancy, just simple database tracking with an interface, 
doing all perforce work for the user in the background.
Having everything tracked in SQL database allowed easy comminuctations with our 
animation production database and export/importscene building tools.

I am sure it can be done quicker and better with help of tools like Fabric 
Engine.

On Tue, Sep 4, 2012 at 6:45 PM, Marc-Andre Carbonneau 
 wrote:
> Hi,
>
> We’re looking into archiving and building a library of assets we have.
>
>
>
> By assets I mean:
>
> 3D assets(.obj, .FBX, .abc, .emdl…) and
>
> 2D assets(reference images, textures, concept art…)
>
>
>
> How are you guys organizing all this in your studio?
>
> Do you use a system that’s both a viewer and a repository or you’re 
> using regular windows folders along with a viewer?
>
>
>
> Thanks for any advice, info you can give me.
>
> MAC
>
>



--
--
Michal
http://uk.linkedin.com/in/mdoniec

Re: ICE in Maya is an engineer's worst nightmare

[piotrek marczak]

last nail to softimage coffin?
anyway I agree, maya is the worst nightmare :p

From: Eric Thivierge
Sent: Thursday, September 06, 2012 5:04 AM
To: softimage@listproc.autodesk.com
Subject: ICE in Maya is an engineer's worst nightmare

This was posted on the 3dPro list from Chris Vienneau of AD:

"Hi everyone,

Amino has been showing up in a technology preview we have called Skyline
which is a games animation authoring system. You can find plenty of videos
online. We are still working on the technology preview with a small number
of customers. Nothing ready for prime time yet. Games animation is hard
for the record. ICE in Maya is an engineer's worst nightmare as ICE was
years of work and hooking into Softimage was a big chunk of that work.
What I can say is that anyone interested in FX in Maya and what is
happening with Naiad (anyone? :) ) should contact me or Kamal Mistry and
we can discuss.""

At least on the surface they admit it isn't as easy to just port ICE to Maya 
and years of work as well. Anything regarding MayaFX in my eyes is just a 
continuation / extension of dev on their FX tools.



Eric Thivierge
http://www.ethivierge.com 

Re: Custom Parameters names changing when creating Marking Sets

[Enrique Caballero]

Interesting, thanks man

On Thu, Sep 6, 2012 at 8:54 PM, Eric Thivierge  wrote:

> >From what I remember from Support its a bug and was addressed in 2013.
> Haven't tested lately though.
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>
>
>
> On Thu, Sep 6, 2012 at 10:49 PM, Enrique Caballero <
> enriquecaball...@gmail.com> wrote:
>
>> Eric I just ran into this thread while doing a search of the list.
>>
>> Is this really a 2011 thing?  I was under the impression that this was
>> related to Proxy Parameters. When you connect something to a proxy
>> parameter the name of that parameter will change.  So by creating a marking
>> set, or a character key set, or a displayInfo you are creating proxy's of
>> the original proxy parameter.
>>
>> I also found that if you do "Edit Definition" of a proxy parameter, and
>> rename it, as soon as you connect something to that parameter the name will
>> change back to what it was named before the renaming happened.
>>
>> In order to avoid this we have implemented rules on how we create our
>> parameters, and in what order we create them in. ( eventually we will unify
>> this with a tool to automate it for us but we are too busy at the moment)
>>
>>
>>
>>
>> On Wed, Feb 1, 2012 at 8:41 PM, Eric Thivierge wrote:
>>
>>> Scratch that. It's a change from 2010 to 2011. How annoying.
>>>
>>> 
>>> Eric Thivierge
>>> Currently: Digital Artist, Rigging at Animal Logic
>>> http://www.ethivierge.com
>>>
>>>
>>> On Wed, Feb 1, 2012 at 10:39 PM, Eric Thivierge wrote:
>>>
 Also note that hitting undo doesn't change them back.

 
 Eric Thivierge
 Currently: Digital Artist, Rigging at Animal Logic
 http://www.ethivierge.com


 On Wed, Feb 1, 2012 at 10:38 PM, Eric Thivierge 
 wrote:

> If I select all the parameters in the keying panel including some
> custom parameters on a DisplayInfo custom property and Create a marking
> set. The custom parameters get renamed to include the object it is created
> on and the custom property name for example:
>
> DisplayInfo_Arm_Settings
> - Bicep
> - Forearm
>
> when selecting those parameters and creating a marking set they get
> renamed in the custom property to:
>
> DisplayInfo_Arm_Settings
> - Arm_L_RT_arm_settings_bicep
> - Arm_L_RT_arm_settings_forearm
>
> Is this normal or a bug? I've tested from 2010 > and the same thing
> happens throughout.
>
> 
> Eric Thivierge
> Currently: Digital Artist, Rigging at Animal Logic
> http://www.ethivierge.com
>


>>>
>>
>

Re: Custom Parameters names changing when creating Marking Sets

[Eric Thivierge]

>From what I remember from Support its a bug and was addressed in 2013.
Haven't tested lately though.


Eric Thivierge
http://www.ethivierge.com


On Thu, Sep 6, 2012 at 10:49 PM, Enrique Caballero <
enriquecaball...@gmail.com> wrote:

> Eric I just ran into this thread while doing a search of the list.
>
> Is this really a 2011 thing?  I was under the impression that this was
> related to Proxy Parameters. When you connect something to a proxy
> parameter the name of that parameter will change.  So by creating a marking
> set, or a character key set, or a displayInfo you are creating proxy's of
> the original proxy parameter.
>
> I also found that if you do "Edit Definition" of a proxy parameter, and
> rename it, as soon as you connect something to that parameter the name will
> change back to what it was named before the renaming happened.
>
> In order to avoid this we have implemented rules on how we create our
> parameters, and in what order we create them in. ( eventually we will unify
> this with a tool to automate it for us but we are too busy at the moment)
>
>
>
>
> On Wed, Feb 1, 2012 at 8:41 PM, Eric Thivierge wrote:
>
>> Scratch that. It's a change from 2010 to 2011. How annoying.
>>
>> 
>> Eric Thivierge
>> Currently: Digital Artist, Rigging at Animal Logic
>> http://www.ethivierge.com
>>
>>
>> On Wed, Feb 1, 2012 at 10:39 PM, Eric Thivierge wrote:
>>
>>> Also note that hitting undo doesn't change them back.
>>>
>>> 
>>> Eric Thivierge
>>> Currently: Digital Artist, Rigging at Animal Logic
>>> http://www.ethivierge.com
>>>
>>>
>>> On Wed, Feb 1, 2012 at 10:38 PM, Eric Thivierge wrote:
>>>
 If I select all the parameters in the keying panel including some
 custom parameters on a DisplayInfo custom property and Create a marking
 set. The custom parameters get renamed to include the object it is created
 on and the custom property name for example:

 DisplayInfo_Arm_Settings
 - Bicep
 - Forearm

 when selecting those parameters and creating a marking set they get
 renamed in the custom property to:

 DisplayInfo_Arm_Settings
 - Arm_L_RT_arm_settings_bicep
 - Arm_L_RT_arm_settings_forearm

 Is this normal or a bug? I've tested from 2010 > and the same thing
 happens throughout.

 
 Eric Thivierge
 Currently: Digital Artist, Rigging at Animal Logic
 http://www.ethivierge.com

>>>
>>>
>>
>

Re: Custom Parameters names changing when creating Marking Sets

[Enrique Caballero]

Eric I just ran into this thread while doing a search of the list.

Is this really a 2011 thing?  I was under the impression that this was
related to Proxy Parameters. When you connect something to a proxy
parameter the name of that parameter will change.  So by creating a marking
set, or a character key set, or a displayInfo you are creating proxy's of
the original proxy parameter.

I also found that if you do "Edit Definition" of a proxy parameter, and
rename it, as soon as you connect something to that parameter the name will
change back to what it was named before the renaming happened.

In order to avoid this we have implemented rules on how we create our
parameters, and in what order we create them in. ( eventually we will unify
this with a tool to automate it for us but we are too busy at the moment)




On Wed, Feb 1, 2012 at 8:41 PM, Eric Thivierge  wrote:

> Scratch that. It's a change from 2010 to 2011. How annoying.
>
> 
> Eric Thivierge
> Currently: Digital Artist, Rigging at Animal Logic
> http://www.ethivierge.com
>
>
> On Wed, Feb 1, 2012 at 10:39 PM, Eric Thivierge wrote:
>
>> Also note that hitting undo doesn't change them back.
>>
>> 
>> Eric Thivierge
>> Currently: Digital Artist, Rigging at Animal Logic
>> http://www.ethivierge.com
>>
>>
>> On Wed, Feb 1, 2012 at 10:38 PM, Eric Thivierge wrote:
>>
>>> If I select all the parameters in the keying panel including some custom
>>> parameters on a DisplayInfo custom property and Create a marking set. The
>>> custom parameters get renamed to include the object it is created on and
>>> the custom property name for example:
>>>
>>> DisplayInfo_Arm_Settings
>>> - Bicep
>>> - Forearm
>>>
>>> when selecting those parameters and creating a marking set they get
>>> renamed in the custom property to:
>>>
>>> DisplayInfo_Arm_Settings
>>> - Arm_L_RT_arm_settings_bicep
>>> - Arm_L_RT_arm_settings_forearm
>>>
>>> Is this normal or a bug? I've tested from 2010 > and the same thing
>>> happens throughout.
>>>
>>> 
>>> Eric Thivierge
>>> Currently: Digital Artist, Rigging at Animal Logic
>>> http://www.ethivierge.com
>>>
>>
>>
>

Re: ICE in Maya is an engineer's worst nightmare

[Rob Chapman]

OK, thanks all. so what confirmations, if any, do we actually have or
'allowed' to talk about?

1. its not going to be ICE but will have same workflow / functionality

- I really dont appreciate the difference? so each node will be called a
mayacompound and not xsicompound ?  will there be any interop with
Softimage / Maya planned in this regards?

2. Its going to take a few years

3. Its not a separate App, but part of the main Maya


I am good to assume these as actual facts then? :)

And certainly dont want or need yet another tirade / rant / sky is falling
 thread, am trying to tread carefully, be less emotional and just ask
rational questions based upon facts, which would be much more rewarding for
those that feel are being kept in the dark.  but as a Softimage customer
using ICE everyday since the last 6 years , (in the ultimate niche of
niches - Softimage FX)  I feel I have a right to know what the  is
going on that will affect my favourite apps future?  is the only option
available is to wait until 2014?

cheers

Rob



On 6 September 2012 12:01, Luc-Eric Rousseau  wrote:

> there is no such thing as "MayaFX".  A couple people wrote on linkedin
> being in the "Maya FX" team. That's like saying you work in the "Maya
> UI" or "Maya Rendering" team. It's not a product, it's the name of the
> team in the org chart. We have since learned to be more careful about
> those things, since it is meaningless. For example, the guys working
> on the Node Editor are the UI team although that might end up being
> useful in "FX" or "Rendering". Who is reports to is meaningless.
>
> On Thu, Sep 6, 2012 at 6:28 AM, Rob Chapman  wrote:
> > So its just a confirmation then of what Luceric has already hinted as to
> why
> > the ex devs from Softimage  are working on MayaFX - to port something
> like a
> > new ICE \ Naiad over to Maya. A bit more open about it than in the past
> > which is better than usual.
>

Re: Small Annoying Things

[David Barosin]

Thanks Stephen.  I cleared my user preferences and it seems to have come
back.  I had my prefs on so many machines it seemed like the norm :P

Cheers,
 -Dave



On Thu, Sep 6, 2012 at 6:28 AM, Stephen Blair wrote:

> CTRL+Y did work when I tried. But maybe it's like CTRL+C and CTRL+V, which
> work, except when they don't.
>
> I think maybe using the right-click menu will sometimes kickstart the
> keyboard shortcuts back into working...I'll try to remember and check next
> time it happens
>
>
> On Wed, Sep 5, 2012 at 12:38 PM, David Barosin  wrote:
>
>> Without reading the long list. Did anyone mentioned ctrl+Y working for
>> redo in the script editor?
>>
>>
>

Re: Asset viewer / manager

[Michal Doniec]

I developed one which uses Python/PyQT/SQL and perforce (was used
sucessfully on our last project which is about to be shipped), but
it's just for lighweight assets (.emdls). Basically all tracking is
done using SQL, storage and version control is left to perforce, with
only very lightweight wrapper library (I wrote it to simplify perforce
interactions only) to interface with asset manager.
It works on a higher level than just .emdl, deifning an asset as an
abstract database record/entity, so you can have an asset which
contains rigs, meshes etc. components. Component is defined as an
abstract class with only save/load methods (which come from packagae
specific custom module, so in theory should be easy to port to other
3d app) and a couple of properties like version and perforce path, so
it's easily extendable to any component type (obj, textures, fbx files
I even had some reference pictures etc.. as components within an
asset). It makes it easy to add custom properties like root node and
bone count for the rigs etc. All these components can be freely
instanced between multple assets, so you can have a rig shared between
multiple creatures, for example.

It is a push system, so when someone modfies and saves an asset,
everyone gets it automatically (there is a warning and choice to
cancel tho). We used it mainly for characters.

I am not sure about performance (load/save/sync speed) when attempting
this approach with caches/obj and other heavy data, but I'd think it's
mainly dependend on the speed of your network/servers during
sync/submit. For lightweight models it was very fast.

I generate thumbnails on save and they are stored as plain files in
perforce, also store connections between components in SQL records
(link withs coming from rig .emdl to mesh .emdl, envelopes, etc), they
are recreated on load, so there is no issue having connections between
different components or mutiple instances of the same assets in the
scene (evelopes and other stuff will connect correctly). QT takes care
of the infterface, it's all displayed in a tree like browser with
thumbnails.

It's really nothing fancy, just simple database tracking with an
interface, doing all perforce work for the user in the background.
Having everything tracked in SQL database allowed easy comminuctations
with our animation production database and export/importscene building
tools.

I am sure it can be done quicker and better with help of tools like
Fabric Engine.

On Tue, Sep 4, 2012 at 6:45 PM, Marc-Andre Carbonneau
 wrote:
> Hi,
>
> We’re looking into archiving and building a library of assets we have.
>
>
>
> By assets I mean:
>
> 3D assets(.obj, .FBX, .abc, .emdl…) and
>
> 2D assets(reference images, textures, concept art…)
>
>
>
> How are you guys organizing all this in your studio?
>
> Do you use a system that’s both a viewer and a repository or you’re using
> regular windows folders along with a viewer?
>
>
>
> Thanks for any advice, info you can give me.
>
> MAC
>
>



-- 
--
Michal
http://uk.linkedin.com/in/mdoniec

Re: subscribing and unsubscribing from the Softimage mailing list

[Chris Marshall]

That was it, Monkeys and cheese.



On 6 September 2012 11:57, Rob Wuijster  wrote:

>  That's Ed fault. And monkeys too ;-)
>
> Rob
>
> \/-\/\/
>
> On 6-9-2012 12:52, Chris Marshall wrote:
>
> What was that Cheese thing that ran and ran on this list?
>
>
>
> On 6 September 2012 05:28, Raffaele Fragapane  > wrote:
>
>> Oh, and Autodesk probably doesn't care about kittens or bunnies anyway,
>> so it's not an effective threat anymore. I'd send you some for the sake of
>> old times though.
>>
>>
>> On Thu, Sep 6, 2012 at 2:27 PM, Raffaele Fragapane <
>> raffsxsil...@googlemail.com> wrote:
>>
>>> Then start listing your address again and stop moving houses!
>>>
>>>
>>>  On Thu, Sep 6, 2012 at 2:22 PM, Bradley Gabe wrote:
>>>
 I liked the old days more when you just sent me dead kittens in the
 mail.

 On Thu, Sep 6, 2012 at 12:10 AM, Raffaele Fragapane <
 raffsxsil...@googlemail.com> wrote:

> I've just sent your e-mail address to many unrelated newsgroups to
> facilitate the process. You might get a new wife and some cheap 
> medications
> in the process too.
>
>
> On Thu, Sep 6, 2012 at 1:19 AM, Bradley Gabe wrote:
>
>> Everyone who is currently unsubscribed from this list, please
>> respond.
>>
>>
>> On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia 
>> wrote:
>>
>>> Ha, people are addicted to this list, who would bother to know how
>>> to unsubscribe... J
>>>
>>>

>>>

Re: ICE in Maya is an engineer's worst nightmare

[Luc-Eric Rousseau]

there is no such thing as "MayaFX".  A couple people wrote on linkedin
being in the "Maya FX" team. That's like saying you work in the "Maya
UI" or "Maya Rendering" team. It's not a product, it's the name of the
team in the org chart. We have since learned to be more careful about
those things, since it is meaningless. For example, the guys working
on the Node Editor are the UI team although that might end up being
useful in "FX" or "Rendering". Who is reports to is meaningless.

On Thu, Sep 6, 2012 at 6:28 AM, Rob Chapman  wrote:
> So its just a confirmation then of what Luceric has already hinted as to why
> the ex devs from Softimage  are working on MayaFX - to port something like a
> new ICE \ Naiad over to Maya. A bit more open about it than in the past
> which is better than usual.

Re: ICE in Maya is an engineer's worst nightmare

[Eric Thivierge]

You don't talk about oh right... hmm. You get invited by someone on the
list willing to vouch for you.

Well its going to be something ICE-like it seems. Honestly though think
about it. Any new technology that is being developed these days is going to
be procedural or node based. Look at Coral and Nanode and probably Fabric.
Even Max has some node editors now. Its just the way things are going. If
they DIDN'T put a node editor into Maya that would be surprising. Also the
best flatery is imitation. Just proves that it works and work well.
Softimage is inspiring Maya!

The Softimage is a red headed step child of Maya and Max is a long drawn
out beaten to death topic that we're going to have to agree to disagree on.
Try taking an outside look without any loyalty to any of the 3 apps and
with no history of the 3d apps. You would see that Maya has a crap ton more
seats in VFX studios. To get more of those studios who are already
established and having pipelines based around Maya to use more of your
apps, you bundle them and improve interop. That gets you more sales and
makes studio to studio asset sharing easier. Thus you market a Maya suite
to the majority since they are using it. Same with Max. Lets not kid
ourselves, we all know we're in the minority, we're probably never going to
be the majority. Good for us, we get to use cool stuff and have a more
flexible app out of the box. Lastly on this thought, keep in mind they have
to build their node editor on their already aging core. As the statement I
posted above states, its years of hard work and lots of things had to
change (and break) because of it.

Softimage users are specialists in awesome and at the core, we're all still
3D artists. I've been finding myself more and more lately realizing that
while I love this one software, it'd be silly not to embrace the overall
area of expertise (for me rigging and tool dev). I wouldn't ever want to be
someone who only knew how to do 3D in 1 application. If that 1 application
tanks I'll be hard pressed to continue in the field easily and I don't ever
want to have to relearn the lion's share of my chosen profession. Plus it
makes me more valuable (at least I think so).

Softimage isn't going anywhere. It's been stated numerous times by numerous
people, Softimage is huge in Asia and provides a crap ton of income for AD
and that market isn't going to just up and switch to Maya just as the
majority of VFX houses aren't going to do the reverse. AD is a business
that needs money to survive. Regardless of whether you have overlap and
redundant features in apps, you don't get rid of something that is making
you money.

He did state that he's open to questions and I'll email and ask if he would
mind if I posted his email here.

* My personal opinion and outlook. 2014 is going to be an interesting
release with the new devs in the drivers seat. Hoping for great things.


Eric Thivierge
http://www.ethivierge.com

RE: ICE in Maya is an engineer's worst nightmare

[Graham Bell]

I don’t think it ‘actually’ confirms anything that ICE is going into Maya, more 
what Luc-Eric/Chinny and myself have said before - it took x-amount to get ICE 
ready for XSI 7 and then x-amount to get it where it is now. So, getting all 
that literally into Maya, wouldn’t be a short project.

Just about every Maya person I speak too mentions the words “ICE into Maya”, 
but this doesn’t mean they literally want ICE in Maya, they want a ICE/Houdini 
style workflow and level of interaction. Maya’s nucleus framework and 
nParticles/Cloth/Hair isn’t that bad, it’s just people (including myself) just 
fine it clumsy to work with and they want something more Node based. Plus 
there’s still lots to do in continuing to improve Maya’s Node Editor so it gets 
anywhere near Softs Rendertree/ICEtree.

G


From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman
Sent: 06 September 2012 11:28
To: softimage@listproc.autodesk.com
Subject: Re: ICE in Maya is an engineer's worst nightmare

hey thanks for this Eric,  how does one get an invite to this secret 3Dpro list 
?

So its just a confirmation then of what Luceric has already hinted as to why 
the ex devs from Softimage  are working on MayaFX - to port something like a 
new ICE \ Naiad over to Maya. A bit more open about it than in the past which 
is better than usual.

what I still don't get from this post or from any actions like this from 
Autodesk, where does this leave Softimage once this work is complete?.  If our 
dear old 'marge is worthy of pillaging yet is still only sold as a companion to 
Maya because of ICE, once Maya has its own ICE what is the point of Softimage 
in the M & E scheme?  Facerobot...??  we (Softimage users) are already 2nd 
class citizens on the AD ship, one this is finished how will we not be demoted 
to third class alongside Toxic and Matchmover :(

would it be possible for mr Vienneau to answer this?  or he only speaks to 
market share above a certain percentage?

cheers

Rob


On 6 September 2012 04:04, Eric Thivierge 
mailto:ethivie...@gmail.com>> wrote:
This was posted on the 3dPro list from Chris Vienneau of AD:

"Hi everyone,

Amino has been showing up in a technology preview we have called Skyline
which is a games animation authoring system. You can find plenty of videos
online. We are still working on the technology preview with a small number
of customers. Nothing ready for prime time yet. Games animation is hard
for the record. ICE in Maya is an engineer's worst nightmare as ICE was
years of work and hooking into Softimage was a big chunk of that work.
What I can say is that anyone interested in FX in Maya and what is
happening with Naiad (anyone? :) ) should contact me or Kamal Mistry and
we can discuss.""

At least on the surface they admit it isn't as easy to just port ICE to Maya 
and years of work as well. Anything regarding MayaFX in my eyes is just a 
continuation / extension of dev on their FX tools.


Eric Thivierge
http://www.ethivierge.com

<>

Re: subscribing and unsubscribing from the Softimage mailing list

[Rob Wuijster]

That's Ed fault. And monkeys too ;-)


Rob

\/-\/\/

On 6-9-2012 12:52, Chris Marshall wrote:

What was that Cheese thing that ran and ran on this list?



On 6 September 2012 05:28, Raffaele Fragapane 
mailto:raffsxsil...@googlemail.com>> wrote:


Oh, and Autodesk probably doesn't care about kittens or bunnies
anyway, so it's not an effective threat anymore. I'd send you some
for the sake of old times though.


On Thu, Sep 6, 2012 at 2:27 PM, Raffaele Fragapane
mailto:raffsxsil...@googlemail.com>>
wrote:

Then start listing your address again and stop moving houses!


On Thu, Sep 6, 2012 at 2:22 PM, Bradley Gabe
mailto:witha...@gmail.com>> wrote:

I liked the old days more when you just sent me dead
kittens in the mail.

On Thu, Sep 6, 2012 at 12:10 AM, Raffaele Fragapane
mailto:raffsxsil...@googlemail.com>> wrote:

I've just sent your e-mail address to many unrelated
newsgroups to facilitate the process. You might get a
new wife and some cheap medications in the process too.


On Thu, Sep 6, 2012 at 1:19 AM, Bradley Gabe
mailto:witha...@gmail.com>> wrote:

Everyone who is currently unsubscribed from this
list, please respond.


On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia
mailto:chris.c...@autodesk.com>> wrote:

Ha, people are addicted to this list, who
would bother to know how to unsubscribe... J





-- 


No virus found in this message.
Checked by AVG - www.avg.com 
Version: 2012.0.2197 / Virus Database: 2437/5251 - Release Date: 09/05/12

Re: subscribing and unsubscribing from the Softimage mailing list

[Chris Marshall]

What was that Cheese thing that ran and ran on this list?



On 6 September 2012 05:28, Raffaele Fragapane
wrote:

> Oh, and Autodesk probably doesn't care about kittens or bunnies anyway, so
> it's not an effective threat anymore. I'd send you some for the sake of old
> times though.
>
>
> On Thu, Sep 6, 2012 at 2:27 PM, Raffaele Fragapane <
> raffsxsil...@googlemail.com> wrote:
>
>> Then start listing your address again and stop moving houses!
>>
>>
>> On Thu, Sep 6, 2012 at 2:22 PM, Bradley Gabe  wrote:
>>
>>> I liked the old days more when you just sent me dead kittens in the
>>> mail.
>>>
>>> On Thu, Sep 6, 2012 at 12:10 AM, Raffaele Fragapane <
>>> raffsxsil...@googlemail.com> wrote:
>>>
 I've just sent your e-mail address to many unrelated newsgroups to
 facilitate the process. You might get a new wife and some cheap medications
 in the process too.


 On Thu, Sep 6, 2012 at 1:19 AM, Bradley Gabe wrote:

> Everyone who is currently unsubscribed from this list, please respond.
>
>
> On Wed, Sep 5, 2012 at 11:09 AM, Chris Chia 
> wrote:
>
>> Ha, people are addicted to this list, who would bother to know how to
>> unsubscribe... J
>>
>>
>>>
>>
>>
>> --
>
>

Re: ICE in Maya is an engineer's worst nightmare

[Daniel H]

Ya know, since ICE is already IN and working great IN Softimage, AD could
save itself a lot of money, time, and pain by just migrating the primitive
Mayans to a complete system that already works great... like Softimage. :)

Daniel
VFXM

Re: To post

[Oral Samli]

On Thu, 06 Sep 2012 13:26:42 +0300, Oral Samli   
wrote:



greatclo...@live.com



That was just a test, ignore it
--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Small Annoying Things

[Stephen Blair]

CTRL+Y did work when I tried. But maybe it's like CTRL+C and CTRL+V, which
work, except when they don't.

I think maybe using the right-click menu will sometimes kickstart the
keyboard shortcuts back into working...I'll try to remember and check next
time it happens

On Wed, Sep 5, 2012 at 12:38 PM, David Barosin  wrote:

> Without reading the long list. Did anyone mentioned ctrl+Y working for
> redo in the script editor?
>
>

Re: ICE in Maya is an engineer's worst nightmare

[Rob Chapman]

hey thanks for this Eric,  how does one get an invite to this secret 3Dpro
list ?

So its just a confirmation then of what Luceric has already hinted as to
why the ex devs from Softimage  are working on MayaFX - to port something
like a new ICE \ Naiad over to Maya. A bit more open about it than in the
past which is better than usual.

what I still don't get from this post or from any actions like this from
Autodesk, where does this leave Softimage once this work is complete?.  If
our dear old 'marge is worthy of pillaging yet is still only sold as a
companion to Maya because of ICE, once Maya has its own ICE what is the
point of Softimage in the M & E scheme?  Facerobot...??  we (Softimage
users) are already 2nd class citizens on the AD ship, one this is finished
how will we not be demoted to third class alongside Toxic and Matchmover :(

would it be possible for mr Vienneau to answer this?  or he only speaks to
market share above a certain percentage?

cheers

Rob



On 6 September 2012 04:04, Eric Thivierge  wrote:

> This was posted on the 3dPro list from Chris Vienneau of AD:
>
> "Hi everyone,
>
> Amino has been showing up in a technology preview we have called Skyline
> which is a games animation authoring system. You can find plenty of videos
> online. We are still working on the technology preview with a small number
> of customers. Nothing ready for prime time yet. Games animation is hard
> for the record. ICE in Maya is an engineer's worst nightmare as ICE was
> years of work and hooking into Softimage was a big chunk of that work.
> What I can say is that anyone interested in FX in Maya and what is
> happening with Naiad (anyone? :) ) should contact me or Kamal Mistry and
> we can discuss.""
>
> At least on the surface they admit it isn't as easy to just port ICE to
> Maya and years of work as well. Anything regarding MayaFX in my eyes is
> just a continuation / extension of dev on their FX tools.
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>

To post

[Oral Samli]

greatclo...@live.com

Re: Small Annoying Things

[Peter Agg]

If you have your scripting preferences set to 'use spaces instead of tabs',
it would be really handy if the SDK Wizard made templates which also used
spaces instead of tabs!

On 5 September 2012 18:43, Sandy Sutherland <
sandy.sutherl...@triggerfish.co.za> wrote:

>  LOL I used to get caught by that one too - now I pretty much use the
> parent button all the time!
>
> S.
>
> _
> Sandy Sutherland
> Technical Supervisor
> sandy.sutherl...@triggerfish.co.za
> _
>
>
>
>
>   --
> *From:* softimage-boun...@listproc.autodesk.com [
> softimage-boun...@listproc.autodesk.com] on behalf of Alan Fregtman [
> alan.fregt...@gmail.com]
> *Sent:* 05 September 2012 18:57
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Small Annoying Things
>
>  One more thing, irrelevant to the PyQt discussion but relevant to the
> thread:
>
>  - dragging a long list of objects to another (to reparent) in the
> Explorer results in individual CopyPaste() commands for each object which
> is crazy slow compared to a single ParentObj() command if I were to use the
> Parent button.
>
>  Sometimes I forget and have to wait a while for a thousand commands to
> trigger. It should be smarter than that. :/
>
>
>