Heavy scenes with the GTX 970

2015-05-28 Thread Leoung O'Young
We have switched some of our workstation using the GTX 970's, they 
preforms quite well rendering in Redshift.
A good bang for the buck. But we find the it is very sluggish 
manipulating heavy geometry scenes inside Softimage 2915.

What is a better option?

Thanks,
Leoung


Re: Jordskott tv series visual effects, Softimage+Redshift

2015-05-28 Thread Arvid Björn
Thanks guys! Indeed, Soft is such a powerhouse, I only had to go outside it
for volumetric smoke effects, but even emFluid is pretty cool, even though
I prefer Houdini. On the 3D side of things it was me and Per Bergstén, an
ex-Stopp'er which I like to work with and I also got some help from Robin
Erneström who's fulltime at Stopp. Niklas Lundgren (freelancer in Göteborg)
did most of the raven animations and also the rig for it in Soft. We also
had Victor Sanchez on compositing, he's now an employee as well. Great team
and great tools =)





On Wed, May 27, 2015 at 4:20 PM, Morten Bartholdy x...@colorshopvfx.dk
wrote:

   Really well done Arvid! And I too love the Softimage+Redshift combo - I
 just wish they would support ICE/emFluid volumetrics soon. It is still
 amazing how much work a small team can do with Softimage.



 Who were the other guys - staff at Stopp or freelancers? I am asking as it
 is hard to find (good) XSI freelancers here in Copenhagen.



 Morten




 Den 22. maj 2015 kl. 22:37 skrev Arvid Björn arvidbj...@gmail.com:

   Hi guys, just wanted to show a couple of shots we did for the Swedish
 tv series Jordskott. We did all the 342 vfx shots for all 10 episodes,
 all cg in Softimage, rendered in Redshift, Houdini for smoke sim and Nuke
 for comp.

 Here's some of the more interesting ones I think (excuse the compression):

 Full cg env and destruction. Redshift+ICE instance scattering achieved the
 level of detail, comped using deep data to combine Redshift and Mantra
 smoke renders. RS frame time was about 20 minutes on this, which is the
 highest I've ever reached with Redshift I think.
  https://app.frame.io/f/9839ef2c-0a25-4c41-8308-548078b613b1

 Here's a bunch of cg ravens rigged and animated in Softimage, rendered in
 Redshift.
  https://app.frame.io/f/17a5c43d-0b29-4928-a0ae-35779930a492

 This is a face wound-type thing in a dream sequence, Soft+Redshift
  https://app.frame.io/f/e7740833-7faa-4e13-a92e-b0be2f75f3b0

 All the underwater environments in this sequence is full cg combined with
 some green screen uw-plates of the actress. The entity is made with a bit
 of ICE strand magic. Soft+Redshift, RS really has awesome volumetrics btw.
  https://app.frame.io/f/680ec84a-573d-4e9f-b0e3-9d68a0c3ad3a (with sound,
 without grade)

 And about 300 other shots.. =)

 We worked for ~8 months with a core team of 3 artists including myself,
 and a few more for shorter periods. I also supervised the vfx on the show,
 which was a true pleasure! Can't imagine a better tool for the job than
 Soft and RS, it's quite remarkable how well they work together, it's all
 rendered on cheap GTX780's as well.

 So Softimage is alive and well over here at least! The Maya licenses
 doesn't even work as a door stop, not sure why we keep them around really.

  We'll do a proper reel for the whole season soonish, hope you like it!

 Cheers








Re: Heavy scenes with the GTX 970

2015-05-28 Thread Leoung O'Young

No, thanks for the suggestion.

On 28/05/2015 7:46 PM, Sven Constable wrote:

Manipulating heavy geo was a problem with ATI cards, nvidia usually performes 
well. Did you add the xsi.exe in the nvidia control panel?

sven

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung O'Young
Sent: Friday, May 29, 2015 1:20 AM
To: xsi
Subject: Heavy scenes with the GTX 970

We have switched some of our workstation using the GTX 970's, they preforms 
quite well rendering in Redshift.
A good bang for the buck. But we find the it is very sluggish manipulating 
heavy geometry scenes inside Softimage 2915.
What is a better option?

Thanks,
Leoung







RE: Heavy scenes with the GTX 970

2015-05-28 Thread Sven Constable
Manipulating heavy geo was a problem with ATI cards, nvidia usually performes 
well. Did you add the xsi.exe in the nvidia control panel?

sven

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung O'Young
Sent: Friday, May 29, 2015 1:20 AM
To: xsi
Subject: Heavy scenes with the GTX 970

We have switched some of our workstation using the GTX 970's, they preforms 
quite well rendering in Redshift.
A good bang for the buck. But we find the it is very sluggish manipulating 
heavy geometry scenes inside Softimage 2915.
What is a better option?

Thanks,
Leoung




Re: Heavy scenes with the GTX 970

2015-05-28 Thread Raffaele Fragapane
If your heavy scene is truly heavy, past the 3.5GB mark, you might be
bumping into a known design limitation of the 970 that basically craps
itself if memory usage exceeds the 3.5 mark (even if you have 4 on board).

On Fri, May 29, 2015 at 11:37 AM, Leoung O'Young digim...@digimata.com
wrote:

 No, thanks for the suggestion.


 On 28/05/2015 7:46 PM, Sven Constable wrote:

 Manipulating heavy geo was a problem with ATI cards, nvidia usually
 performes well. Did you add the xsi.exe in the nvidia control panel?

 sven

 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung O'Young
 Sent: Friday, May 29, 2015 1:20 AM
 To: xsi
 Subject: Heavy scenes with the GTX 970

 We have switched some of our workstation using the GTX 970's, they
 preforms quite well rendering in Redshift.
 A good bang for the buck. But we find the it is very sluggish
 manipulating heavy geometry scenes inside Softimage 2915.
 What is a better option?

 Thanks,
 Leoung







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


Re: Heavy scenes with the GTX 970

2015-05-28 Thread Greg Punchatz
inside Softimage 2915

Apparently softimage rises from the ashes, but in a far distant future ;)

On Thu, May 28, 2015 at 6:20 PM, Leoung O'Young digim...@digimata.com
wrote:

 We have switched some of our workstation using the GTX 970's, they
 preforms quite well rendering in Redshift.
 A good bang for the buck. But we find the it is very sluggish manipulating
 heavy geometry scenes inside Softimage 2915.
 What is a better option?

 Thanks,
 Leoung



Re: Heavy scenes with the GTX 970

2015-05-28 Thread Leoung O'Young

Sorry, typo, need new glasses.

On 28/05/2015 7:31 PM, Greg Punchatz wrote:

inside Softimage 2915

Apparently softimage rises from the ashes, but in a far distant future ;)

On Thu, May 28, 2015 at 6:20 PM, Leoung O'Young digim...@digimata.com 
mailto:digim...@digimata.com wrote:


We have switched some of our workstation using the GTX 970's, they
preforms quite well rendering in Redshift.
A good bang for the buck. But we find the it is very sluggish
manipulating heavy geometry scenes inside Softimage 2915.
What is a better option?

Thanks,
Leoung






Re: Heavy scenes with the GTX 970

2015-05-28 Thread Leoung O'Young

Hi Sven,

Where do you add xsi.exe in the nvidia control panel?

Thanks,
Leoung

On 28/05/2015 7:46 PM, Sven Constable wrote:

Manipulating heavy geo was a problem with ATI cards, nvidia usually performes 
well. Did you add the xsi.exe in the nvidia control panel?

sven

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung O'Young
Sent: Friday, May 29, 2015 1:20 AM
To: xsi
Subject: Heavy scenes with the GTX 970

We have switched some of our workstation using the GTX 970's, they preforms 
quite well rendering in Redshift.
A good bang for the buck. But we find the it is very sluggish manipulating 
heavy geometry scenes inside Softimage 2915.
What is a better option?

Thanks,
Leoung







Re: Heavy scenes with the GTX 970

2015-05-28 Thread Tim Leydecker
Another thing worth a shot is going to microsoft.com and finding the 
latest directX installer,
trying to install it won´t hurt if something newer is already installed 
but directx was something

i found was missing in machines giving sluggish performance in the past.

it sounds far fetched but it makes sense, kind of.

cheers,

tim

Am 29.05.2015 um 07:19 schrieb Sven Constable:


The standard (global) settings are different from the softimage 
settings provided by nvidia. I had selection problems on nvidia based 
workstations and after I changed to the softimage settings, problems 
are gone.  Even it not applies to that heavy geo problem, it doesn't hurt.


*From:*softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of 
*Raffaele Fragapane

*Sent:* Friday, May 29, 2015 6:33 AM
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Heavy scenes with the GTX 970

Unless you need to have separate configurations for different apps why 
would you do that?


On Fri, May 29, 2015 at 9:46 AM, Sven Constable 
sixsi_l...@imagefront.de mailto:sixsi_l...@imagefront.de wrote:


Manipulating heavy geo was a problem with ATI cards, nvidia usually 
performes well. Did you add the xsi.exe in the nvidia control panel?


sven


-Original Message-
From: softimage-boun...@listproc.autodesk.com 
mailto:softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com 
mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung 
O'Young

Sent: Friday, May 29, 2015 1:20 AM
To: xsi
Subject: Heavy scenes with the GTX 970

We have switched some of our workstation using the GTX 970's, they 
preforms quite well rendering in Redshift.
A good bang for the buck. But we find the it is very sluggish 
manipulating heavy geometry scenes inside Softimage 2915.

What is a better option?

Thanks,
Leoung



--

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






Re: Heavy scenes with the GTX 970

2015-05-28 Thread Raffaele Fragapane
Unless you need to have separate configurations for different apps why
would you do that?

On Fri, May 29, 2015 at 9:46 AM, Sven Constable sixsi_l...@imagefront.de
wrote:

 Manipulating heavy geo was a problem with ATI cards, nvidia usually
 performes well. Did you add the xsi.exe in the nvidia control panel?

 sven

 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung O'Young
 Sent: Friday, May 29, 2015 1:20 AM
 To: xsi
 Subject: Heavy scenes with the GTX 970

 We have switched some of our workstation using the GTX 970's, they
 preforms quite well rendering in Redshift.
 A good bang for the buck. But we find the it is very sluggish manipulating
 heavy geometry scenes inside Softimage 2915.
 What is a better option?

 Thanks,
 Leoung





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


RE: Heavy scenes with the GTX 970

2015-05-28 Thread Sven Constable
Open up Nvidia control panel. Under 3D Settings-Manage 3d settings-Program 
settings.
CLick add.Choose the xsi.exe  (C:\Program Files\Autodesk\Softimage 2015 
SP1\Application\bin\)

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung O'Young
Sent: Friday, May 29, 2015 6:24 AM
To: softimage@listproc.autodesk.com
Subject: Re: Heavy scenes with the GTX 970

Hi Sven,

Where do you add xsi.exe in the nvidia control panel?

Thanks,
Leoung

On 28/05/2015 7:46 PM, Sven Constable wrote:
 Manipulating heavy geo was a problem with ATI cards, nvidia usually performes 
 well. Did you add the xsi.exe in the nvidia control panel?

 sven

 -Original Message-
 From: softimage-boun...@listproc.autodesk.com 
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Leoung O'Young
 Sent: Friday, May 29, 2015 1:20 AM
 To: xsi
 Subject: Heavy scenes with the GTX 970

 We have switched some of our workstation using the GTX 970's, they preforms 
 quite well rendering in Redshift.
 A good bang for the buck. But we find the it is very sluggish manipulating 
 heavy geometry scenes inside Softimage 2915.
 What is a better option?

 Thanks,
 Leoung







Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Raffaele Fragapane
GATOR might use that for the sampling, but I don't think those rely on
GATOR itself, or even if they did it'd be more of a logistical thing than
anything to do with what makes GATOR as good as it is (maybe there's an
acceleration structure or some sampling methods that under the hood were
implemented as part of GATOR and then used to service other parts of the
SDK).

Soft has a vastly superior, to ANYTHING out there, notion and handling of
properties on meshes in general, even if, algorithmically speaking, Maya
was to get all the maths across tomorrow, it still wouldn't be a fraction
as powerful as the app in general, right now, is utterly lacking in
abstractions and representations of mesh data and using them for
deformation.

On Thu, May 28, 2015 at 4:09 PM, Steven Caron car...@gmail.com wrote:

 All the GetClosest* functions on the geometry class? I would consider that
 part of the GATOR sdk

 *written with my thumbs
 On May 27, 2015 6:11 PM, Luc-Eric Rousseau luceri...@gmail.com wrote:

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures
 vs rigging things, reflecting on their architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not in
  2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
 less use
  out-of-the-box as the very things that made it nice for exchanging data
  between XSI and Maya, for example, were the very same features that
 tripped
  up game artists trying to do simpler things quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
 artists
  needed more micro-management of meshes and transfers.  Artists used it
 to
  transfer UV's, normals, vertex colors, envelope weights, and many other
  features.  I also extended, as well as exposed, many features from the
 SDK
  GATOR did not expose directly such as transferring attributes in local
  space, by raycasting, distance limits, transferring only selected
  subcomponents, correcting numerical flaws found in UV transfer, and so
 on.
  However, my use of the GATOR SDK was not limited to replicating the
 tool as
  a command.  I also used it heavily for other tasks which weren't
 strictly
  related to attribute transfer tasks such as animation remapping, pose
  transfer, mesh fitting, and interactive editing of normals and
 symmetrical
  envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
 and age
  is surprising considering it's so universally useful and isn't rocket
  science to develop.  If you know anything about tree data structures and
  linear algebra, you can write your own (even if it's not as efficient as
  GATOR).  What makes the GATOR SDK nice is the algorithm is very fast,
  accurate, and relatively easy to use.  Reverse lookups of subcomponents
 is a
  pain as GATOR worked on triangles, not polygons, but that's minor
 compared
  to all the benefits it provides.




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


Re: Softimage Digest, Vol 78, Issue 106

2015-05-28 Thread Matt Lind
 for exchanging data
 between XSI and Maya, for example, were the very same features that
tripped
 up game artists trying to do simpler things quickly in heavy 
 repetition.


 I wrote a command based version of the tool using the GATOR SDK as
artists
 needed more micro-management of meshes and transfers.  Artists used it
to
 transfer UV's, normals, vertex colors, envelope weights, and many other
 features.  I also extended, as well as exposed, many features from the
SDK
 GATOR did not expose directly such as transferring attributes in local
 space, by raycasting, distance limits, transferring only selected
 subcomponents, correcting numerical flaws found in UV transfer, and so
on.
 However, my use of the GATOR SDK was not limited to replicating the
tool as
 a command.  I also used it heavily for other tasks which weren't
strictly
 related to attribute transfer tasks such as animation remapping, pose
 transfer, mesh fitting, and interactive editing of normals and
symmetrical
 envelope weighting of asymmetrical characters.

 To hear other applications don't have a GATOR equivalent in this day
and age
 is surprising considering it's so universally useful and isn't rocket
 science to develop.  If you know anything about tree data structures 
 and
 linear algebra, you can write your own (even if it's not as efficient 
 as

 GATOR).  What makes the GATOR SDK nice is the algorithm is very fast,
 accurate, and relatively easy to use.  Reverse lookups of subcomponents
is a
 pain as GATOR worked on triangles, not polygons, but that's minor
compared
 to all the benefits it provides.






--
Our users will know fear and cower before our software! Ship it! Ship it
and let them flee like the dogs they are!
-- next part --
An HTML attachment was scrubbed...
URL: 
http://listproc.autodesk.com/pipermail/softimage/attachments/20150528/ba23d260/attachment.html


--

___
Softimage mailing list
Softimage@listproc.autodesk.com
http://listproc.autodesk.com/mailman/listinfo/softimage


End of Softimage Digest, Vol 78, Issue 106
** 



Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Steven Caron
All the GetClosest* functions on the geometry class? I would consider that
part of the GATOR sdk

*written with my thumbs
On May 27, 2015 6:11 PM, Luc-Eric Rousseau luceri...@gmail.com wrote:

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures
 vs rigging things, reflecting on their architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not in
  2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has less
 use
  out-of-the-box as the very things that made it nice for exchanging data
  between XSI and Maya, for example, were the very same features that
 tripped
  up game artists trying to do simpler things quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
 artists
  needed more micro-management of meshes and transfers.  Artists used it to
  transfer UV's, normals, vertex colors, envelope weights, and many other
  features.  I also extended, as well as exposed, many features from the
 SDK
  GATOR did not expose directly such as transferring attributes in local
  space, by raycasting, distance limits, transferring only selected
  subcomponents, correcting numerical flaws found in UV transfer, and so
 on.
  However, my use of the GATOR SDK was not limited to replicating the tool
 as
  a command.  I also used it heavily for other tasks which weren't strictly
  related to attribute transfer tasks such as animation remapping, pose
  transfer, mesh fitting, and interactive editing of normals and
 symmetrical
  envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day and
 age
  is surprising considering it's so universally useful and isn't rocket
  science to develop.  If you know anything about tree data structures and
  linear algebra, you can write your own (even if it's not as efficient as
  GATOR).  What makes the GATOR SDK nice is the algorithm is very fast,
  accurate, and relatively easy to use.  Reverse lookups of subcomponents
 is a
  pain as GATOR worked on triangles, not polygons, but that's minor
 compared
  to all the benefits it provides.



Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Graham Bell
Many moons ago, I was demoing XSI to a certain very large Maya based games
company (who shall remain nameless), there were a couple of guys in the
room who were convinced that despite looking 'ok', GATOR wasn't anything
that special. And that Maya could already do pretty much the same thing
with an existing feature or a custom/modified tool.

They promptly spent the rest of the day (and evening) trying and failing to
match the demo workflow.

GATOR was always one of those features that would always grab an audiences
attention. At an event last year, after the main agenga for sh*ts 
giggles, I booted up Soft and did some demos. GATOR had people in shock. lol

The only thing I found that had a similar 'wow' factor, was the transfer
maps feature in Mudbox, that's actually very good.




On Thu, May 28, 2015 at 7:48 AM Raffaele Fragapane 
raffsxsil...@googlemail.com wrote:

 GATOR might use that for the sampling, but I don't think those rely on
 GATOR itself, or even if they did it'd be more of a logistical thing than
 anything to do with what makes GATOR as good as it is (maybe there's an
 acceleration structure or some sampling methods that under the hood were
 implemented as part of GATOR and then used to service other parts of the
 SDK).

 Soft has a vastly superior, to ANYTHING out there, notion and handling of
 properties on meshes in general, even if, algorithmically speaking, Maya
 was to get all the maths across tomorrow, it still wouldn't be a fraction
 as powerful as the app in general, right now, is utterly lacking in
 abstractions and representations of mesh data and using them for
 deformation.

 On Thu, May 28, 2015 at 4:09 PM, Steven Caron car...@gmail.com wrote:

 All the GetClosest* functions on the geometry class? I would consider
 that part of the GATOR sdk

 *written with my thumbs
 On May 27, 2015 6:11 PM, Luc-Eric Rousseau luceri...@gmail.com wrote:

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures
 vs rigging things, reflecting on their architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not in
  2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
 less use
  out-of-the-box as the very things that made it nice for exchanging data
  between XSI and Maya, for example, were the very same features that
 tripped
  up game artists trying to do simpler things quickly in heavy
 repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
 artists
  needed more micro-management of meshes and transfers.  Artists used it
 to
  transfer UV's, normals, vertex colors, envelope weights, and many other
  features.  I also extended, as well as exposed, many features from the
 SDK
  GATOR did not expose directly such as transferring attributes in local
  space, by raycasting, distance limits, transferring only selected
  subcomponents, correcting numerical flaws found in UV transfer, and so
 on.
  However, my use of the GATOR SDK was not limited to replicating the
 tool as
  a command.  I also used it heavily for other tasks which weren't
 strictly
  related to attribute transfer tasks such as animation remapping, pose
  transfer, mesh fitting, and interactive editing of normals and
 symmetrical
  envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
 and age
  is surprising considering it's so universally useful and isn't rocket
  science to develop.  If you know anything about tree data structures
 and
  linear algebra, you can write your own (even if it's not as efficient
 as
  GATOR).  What makes the GATOR SDK nice is the algorithm is very fast,
  accurate, and relatively easy to use.  Reverse lookups of
 subcomponents is a
  pain as GATOR worked on triangles, not polygons, but that's minor
 compared
  to all the benefits it provides.




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



Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Gerbrand Nel
Houdini attribute transfer does some bloody fantastic things if you use 
it right.
The more I work in houdini, the more I can come to terms with the death 
of softimage.

G
On 28/05/2015 12:40, Nicolas Esposito wrote:
Tom that's exactly what I was thinking...Gator has been around for A 
LOT, but not Autodesk nor anyone else ( as far as I know ) come up 
with something like that, and it's shocking...
Maya is well known for being You can't do that out-of-the-box, code 
it yourself, and no one attempted even?


For the game rigs I'm developing Gator is essential, especially for 
facial rigs is a time saver...


I seriously hope that with Fabric Engine a Gator-like tool could be 
developedhowever its shocking that something so usefull still 
isn't within the major DCCs around ( except Blender from what I've read )


2015-05-28 12:28 GMT+02:00 Tom Kleinenberg zagan...@gmail.com 
mailto:zagan...@gmail.com:


Is there a reason that it's not included in Maya? I mean, beyond
what Raff's saying about Softimage's handling of properties on
meshes. Is there a weird 3rd party licensing thing?

Would it be possible to replicate GATOR style behaviour using
Fabric or Houdini engine to prevent having to move out of Maya
with all the weirdness that could occur?

On 28 May 2015 at 12:01, Graham Bell bell...@gmail.com
mailto:bell...@gmail.com wrote:

Many moons ago, I was demoing XSI to a certain very large Maya
based games company (who shall remain nameless), there were a
couple of guys in the room who were convinced that despite
looking 'ok', GATOR wasn't anything that special. And that
Maya could already do pretty much the same thing with an
existing feature or a custom/modified tool.

They promptly spent the rest of the day (and evening) trying
and failing to match the demo workflow.

GATOR was always one of those features that would always grab
an audiences attention. At an event last year, after the main
agenga for sh*ts  giggles, I booted up Soft and did some
demos. GATOR had people in shock. lol

The only thing I found that had a similar 'wow' factor, was
the transfer maps feature in Mudbox, that's actually very good.




On Thu, May 28, 2015 at 7:48 AM Raffaele Fragapane
raffsxsil...@googlemail.com
mailto:raffsxsil...@googlemail.com wrote:

GATOR might use that for the sampling, but I don't think
those rely on GATOR itself, or even if they did it'd be
more of a logistical thing than anything to do with what
makes GATOR as good as it is (maybe there's an
acceleration structure or some sampling methods that under
the hood were implemented as part of GATOR and then used
to service other parts of the SDK).

Soft has a vastly superior, to ANYTHING out there, notion
and handling of properties on meshes in general, even if,
algorithmically speaking, Maya was to get all the maths
across tomorrow, it still wouldn't be a fraction as
powerful as the app in general, right now, is utterly
lacking in abstractions and representations of mesh data
and using them for deformation.

On Thu, May 28, 2015 at 4:09 PM, Steven Caron
car...@gmail.com mailto:car...@gmail.com wrote:

All the GetClosest* functions on the geometry class? I
would consider that part of the GATOR sdk

*written with my thumbs

On May 27, 2015 6:11 PM, Luc-Eric Rousseau
luceri...@gmail.com mailto:luceri...@gmail.com wrote:

GATOR was developed for/with one of our main game
customers, Square I think.
I'm not aware of a Gator sdk, what is that?
There are attribute transfers in other apps, but
it's generally
separate tools for textures
vs rigging things, reflecting on their
architecture vs XSI

On 27 May 2015 at 19:27, Matt Lind
speye...@hotmail.com
mailto:speye...@hotmail.com wrote:
 For the record, GATOR was introduced in late
2005 with XSI v5.0, not in
 2008.

 GATOR was largely tailored for those switching
applications and doing
 rigging in a film/video pipeline. For games
development, GATOR has less use
 out-of-the-box as the very things that made it
nice for exchanging data
 between XSI and Maya, for example, were the very
same features that tripped
 up game 

Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Mirko Jankovic
Well it is more matter of if you don;t know what is it and how useful it
is then you wont miss it.
That is case with a lot of things in Maya that people accepted as truth
nuder the sun, and not knowing that it can be better they don't miss it.

In one occasion in studio of couple maya guys no one managed to transfer UV
map from identical topology model from one to another. After digging in
google I managed to find a way, which is some nasty go into hyper-schematic
or something dig into hidden notes, cut copy move... manged but man what is
1min job with GATOR turned out to be over hour nightmare in Maya.

On Thu, May 28, 2015 at 12:40 PM, Nicolas Esposito 3dv...@gmail.com wrote:

 Tom that's exactly what I was thinking...Gator has been around for A LOT,
 but not Autodesk nor anyone else ( as far as I know ) come up with
 something like that, and it's shocking...
 Maya is well known for being You can't do that out-of-the-box, code it
 yourself, and no one attempted even?

 For the game rigs I'm developing Gator is essential, especially for facial
 rigs is a time saver...

 I seriously hope that with Fabric Engine a Gator-like tool could be
 developedhowever its shocking that something so usefull still isn't
 within the major DCCs around ( except Blender from what I've read )

 2015-05-28 12:28 GMT+02:00 Tom Kleinenberg zagan...@gmail.com:

 Is there a reason that it's not included in Maya? I mean, beyond what
 Raff's saying about Softimage's handling of properties on meshes. Is there
 a weird 3rd party licensing thing?

 Would it be possible to replicate GATOR style behaviour using Fabric or
 Houdini engine to prevent having to move out of Maya with all the weirdness
 that could occur?

 On 28 May 2015 at 12:01, Graham Bell bell...@gmail.com wrote:

 Many moons ago, I was demoing XSI to a certain very large Maya based
 games company (who shall remain nameless), there were a couple of guys in
 the room who were convinced that despite looking 'ok', GATOR wasn't
 anything that special. And that Maya could already do pretty much the same
 thing with an existing feature or a custom/modified tool.

 They promptly spent the rest of the day (and evening) trying and failing
 to match the demo workflow.

 GATOR was always one of those features that would always grab an
 audiences attention. At an event last year, after the main agenga for sh*ts
  giggles, I booted up Soft and did some demos. GATOR had people in shock.
 lol

 The only thing I found that had a similar 'wow' factor, was the transfer
 maps feature in Mudbox, that's actually very good.




 On Thu, May 28, 2015 at 7:48 AM Raffaele Fragapane 
 raffsxsil...@googlemail.com wrote:

 GATOR might use that for the sampling, but I don't think those rely on
 GATOR itself, or even if they did it'd be more of a logistical thing than
 anything to do with what makes GATOR as good as it is (maybe there's an
 acceleration structure or some sampling methods that under the hood were
 implemented as part of GATOR and then used to service other parts of the
 SDK).

 Soft has a vastly superior, to ANYTHING out there, notion and handling
 of properties on meshes in general, even if, algorithmically speaking, Maya
 was to get all the maths across tomorrow, it still wouldn't be a fraction
 as powerful as the app in general, right now, is utterly lacking in
 abstractions and representations of mesh data and using them for
 deformation.

 On Thu, May 28, 2015 at 4:09 PM, Steven Caron car...@gmail.com wrote:

 All the GetClosest* functions on the geometry class? I would consider
 that part of the GATOR sdk

 *written with my thumbs
 On May 27, 2015 6:11 PM, Luc-Eric Rousseau luceri...@gmail.com
 wrote:

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures
 vs rigging things, reflecting on their architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0,
 not in
  2008.
 
  GATOR was largely tailored for those switching applications and
 doing
  rigging in a film/video pipeline.  For games development, GATOR has
 less use
  out-of-the-box as the very things that made it nice for exchanging
 data
  between XSI and Maya, for example, were the very same features that
 tripped
  up game artists trying to do simpler things quickly in heavy
 repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
 artists
  needed more micro-management of meshes and transfers.  Artists used
 it to
  transfer UV's, normals, vertex colors, envelope weights, and many
 other
  features.  I also extended, as well as exposed, many features from
 the SDK
  GATOR did not expose directly such as transferring attributes in
 local
  space, by raycasting, distance limits, transferring only selected
  subcomponents, correcting 

Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Tom Kleinenberg
Is there a reason that it's not included in Maya? I mean, beyond what
Raff's saying about Softimage's handling of properties on meshes. Is there
a weird 3rd party licensing thing?

Would it be possible to replicate GATOR style behaviour using Fabric or
Houdini engine to prevent having to move out of Maya with all the weirdness
that could occur?

On 28 May 2015 at 12:01, Graham Bell bell...@gmail.com wrote:

 Many moons ago, I was demoing XSI to a certain very large Maya based games
 company (who shall remain nameless), there were a couple of guys in the
 room who were convinced that despite looking 'ok', GATOR wasn't anything
 that special. And that Maya could already do pretty much the same thing
 with an existing feature or a custom/modified tool.

 They promptly spent the rest of the day (and evening) trying and failing
 to match the demo workflow.

 GATOR was always one of those features that would always grab an audiences
 attention. At an event last year, after the main agenga for sh*ts 
 giggles, I booted up Soft and did some demos. GATOR had people in shock. lol

 The only thing I found that had a similar 'wow' factor, was the transfer
 maps feature in Mudbox, that's actually very good.




 On Thu, May 28, 2015 at 7:48 AM Raffaele Fragapane 
 raffsxsil...@googlemail.com wrote:

 GATOR might use that for the sampling, but I don't think those rely on
 GATOR itself, or even if they did it'd be more of a logistical thing than
 anything to do with what makes GATOR as good as it is (maybe there's an
 acceleration structure or some sampling methods that under the hood were
 implemented as part of GATOR and then used to service other parts of the
 SDK).

 Soft has a vastly superior, to ANYTHING out there, notion and handling of
 properties on meshes in general, even if, algorithmically speaking, Maya
 was to get all the maths across tomorrow, it still wouldn't be a fraction
 as powerful as the app in general, right now, is utterly lacking in
 abstractions and representations of mesh data and using them for
 deformation.

 On Thu, May 28, 2015 at 4:09 PM, Steven Caron car...@gmail.com wrote:

 All the GetClosest* functions on the geometry class? I would consider
 that part of the GATOR sdk

 *written with my thumbs
 On May 27, 2015 6:11 PM, Luc-Eric Rousseau luceri...@gmail.com
 wrote:

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures
 vs rigging things, reflecting on their architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
 in
  2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
 less use
  out-of-the-box as the very things that made it nice for exchanging
 data
  between XSI and Maya, for example, were the very same features that
 tripped
  up game artists trying to do simpler things quickly in heavy
 repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
 artists
  needed more micro-management of meshes and transfers.  Artists used
 it to
  transfer UV's, normals, vertex colors, envelope weights, and many
 other
  features.  I also extended, as well as exposed, many features from
 the SDK
  GATOR did not expose directly such as transferring attributes in local
  space, by raycasting, distance limits, transferring only selected
  subcomponents, correcting numerical flaws found in UV transfer, and
 so on.
  However, my use of the GATOR SDK was not limited to replicating the
 tool as
  a command.  I also used it heavily for other tasks which weren't
 strictly
  related to attribute transfer tasks such as animation remapping, pose
  transfer, mesh fitting, and interactive editing of normals and
 symmetrical
  envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
 and age
  is surprising considering it's so universally useful and isn't rocket
  science to develop.  If you know anything about tree data structures
 and
  linear algebra, you can write your own (even if it's not as efficient
 as
  GATOR).  What makes the GATOR SDK nice is the algorithm is very fast,
  accurate, and relatively easy to use.  Reverse lookups of
 subcomponents is a
  pain as GATOR worked on triangles, not polygons, but that's minor
 compared
  to all the benefits it provides.




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




Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Nicolas Esposito
Tom that's exactly what I was thinking...Gator has been around for A LOT,
but not Autodesk nor anyone else ( as far as I know ) come up with
something like that, and it's shocking...
Maya is well known for being You can't do that out-of-the-box, code it
yourself, and no one attempted even?

For the game rigs I'm developing Gator is essential, especially for facial
rigs is a time saver...

I seriously hope that with Fabric Engine a Gator-like tool could be
developedhowever its shocking that something so usefull still isn't
within the major DCCs around ( except Blender from what I've read )

2015-05-28 12:28 GMT+02:00 Tom Kleinenberg zagan...@gmail.com:

 Is there a reason that it's not included in Maya? I mean, beyond what
 Raff's saying about Softimage's handling of properties on meshes. Is there
 a weird 3rd party licensing thing?

 Would it be possible to replicate GATOR style behaviour using Fabric or
 Houdini engine to prevent having to move out of Maya with all the weirdness
 that could occur?

 On 28 May 2015 at 12:01, Graham Bell bell...@gmail.com wrote:

 Many moons ago, I was demoing XSI to a certain very large Maya based
 games company (who shall remain nameless), there were a couple of guys in
 the room who were convinced that despite looking 'ok', GATOR wasn't
 anything that special. And that Maya could already do pretty much the same
 thing with an existing feature or a custom/modified tool.

 They promptly spent the rest of the day (and evening) trying and failing
 to match the demo workflow.

 GATOR was always one of those features that would always grab an
 audiences attention. At an event last year, after the main agenga for sh*ts
  giggles, I booted up Soft and did some demos. GATOR had people in shock.
 lol

 The only thing I found that had a similar 'wow' factor, was the transfer
 maps feature in Mudbox, that's actually very good.




 On Thu, May 28, 2015 at 7:48 AM Raffaele Fragapane 
 raffsxsil...@googlemail.com wrote:

 GATOR might use that for the sampling, but I don't think those rely on
 GATOR itself, or even if they did it'd be more of a logistical thing than
 anything to do with what makes GATOR as good as it is (maybe there's an
 acceleration structure or some sampling methods that under the hood were
 implemented as part of GATOR and then used to service other parts of the
 SDK).

 Soft has a vastly superior, to ANYTHING out there, notion and handling
 of properties on meshes in general, even if, algorithmically speaking, Maya
 was to get all the maths across tomorrow, it still wouldn't be a fraction
 as powerful as the app in general, right now, is utterly lacking in
 abstractions and representations of mesh data and using them for
 deformation.

 On Thu, May 28, 2015 at 4:09 PM, Steven Caron car...@gmail.com wrote:

 All the GetClosest* functions on the geometry class? I would consider
 that part of the GATOR sdk

 *written with my thumbs
 On May 27, 2015 6:11 PM, Luc-Eric Rousseau luceri...@gmail.com
 wrote:

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures
 vs rigging things, reflecting on their architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
 in
  2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
 less use
  out-of-the-box as the very things that made it nice for exchanging
 data
  between XSI and Maya, for example, were the very same features that
 tripped
  up game artists trying to do simpler things quickly in heavy
 repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
 artists
  needed more micro-management of meshes and transfers.  Artists used
 it to
  transfer UV's, normals, vertex colors, envelope weights, and many
 other
  features.  I also extended, as well as exposed, many features from
 the SDK
  GATOR did not expose directly such as transferring attributes in
 local
  space, by raycasting, distance limits, transferring only selected
  subcomponents, correcting numerical flaws found in UV transfer, and
 so on.
  However, my use of the GATOR SDK was not limited to replicating the
 tool as
  a command.  I also used it heavily for other tasks which weren't
 strictly
  related to attribute transfer tasks such as animation remapping, pose
  transfer, mesh fitting, and interactive editing of normals and
 symmetrical
  envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
 and age
  is surprising considering it's so universally useful and isn't rocket
  science to develop.  If you know anything about tree data structures
 and
  linear algebra, you can write your own (even if it's not as
 efficient 

Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Christopher Crouzet
I've just noticed that the exact same thread happened on the Fabric
mailing-list—someone asked for GATOR and I quoted that foot roll thingy in
my reply. I'm so predictable :)


On 28 May 2015 at 20:11, Christopher Crouzet christopher.crou...@gmail.com
wrote:

 Beware also to not implement any foot roll in your rigs.

 http://www.google.com/patents/US7545378


 On 28 May 2015 at 19:50, Paul Doyle technove...@gmail.com wrote:

 Most likely covered by this one:
 Transfer of attributes between geometric surfaces of arbitrary
 topologies with distortion reduction and discontinuity preservation
 United States 7760201Issued July 20, 2010

 This describes how to transfer surface attributes (such as color, UVs,
 skinning) between two 3D geometries of different topologies and potentially
 different type (polygon mesh, NURBS, curve...). In particular, it describes
 methods to preserve surface discontinuitues (such as UV island seams) and
 reduce attribute distortion on the target surface.

 On 28 May 2015 at 08:42, Paul Doyle technove...@gmail.com wrote:

 Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing
 it in Fabric but I think he'd stab me if I gave him any more work to do. I
 don't know if there are patents around the work and that's why other people
 haven't replicated it.

 On 28 May 2015 at 08:21, Marc-Andre Carbonneau 
 marc-andre.carbonn...@ubisoft.com wrote:

 Good morning Lucer,

 Do you remember who designed and coded GATOR?
 I'm just curious.
 Thanks!
 MAC


 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
 Sent: May-27-15 9:11 PM
 To: softimage@listproc.autodesk.com
 Subject: Re: GATOR - A feature in Softimage since 2008

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures vs rigging things, reflecting on their
 architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
  in 2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
  less use out-of-the-box as the very things that made it nice for
  exchanging data between XSI and Maya, for example, were the very same
  features that tripped up game artists trying to do simpler things
 quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
  artists needed more micro-management of meshes and transfers.  Artists
  used it to transfer UV's, normals, vertex colors, envelope weights,
  and many other features.  I also extended, as well as exposed, many
  features from the SDK GATOR did not expose directly such as
  transferring attributes in local space, by raycasting, distance
  limits, transferring only selected subcomponents, correcting
 numerical flaws found in UV transfer, and so on.
  However, my use of the GATOR SDK was not limited to replicating the
  tool as a command.  I also used it heavily for other tasks which
  weren't strictly related to attribute transfer tasks such as animation
  remapping, pose transfer, mesh fitting, and interactive editing of
  normals and symmetrical envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
  and age is surprising considering it's so universally useful and isn't
  rocket science to develop.  If you know anything about tree data
  structures and linear algebra, you can write your own (even if it's
  not as efficient as GATOR).  What makes the GATOR SDK nice is the
  algorithm is very fast, accurate, and relatively easy to use.  Reverse
  lookups of subcomponents is a pain as GATOR worked on triangles, not
  polygons, but that's minor compared to all the benefits it provides.






 --
 Christopher Crouzet
 *http://christophercrouzet.com* http://christophercrouzet.com




-- 
Christopher Crouzet
*http://christophercrouzet.com* http://christophercrouzet.com


Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Paul Doyle
Most likely covered by this one:
Transfer of attributes between geometric surfaces of arbitrary topologies
with distortion reduction and discontinuity preservation
United States 7760201Issued July 20, 2010

This describes how to transfer surface attributes (such as color, UVs,
skinning) between two 3D geometries of different topologies and potentially
different type (polygon mesh, NURBS, curve...). In particular, it describes
methods to preserve surface discontinuitues (such as UV island seams) and
reduce attribute distortion on the target surface.

On 28 May 2015 at 08:42, Paul Doyle technove...@gmail.com wrote:

 Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing it
 in Fabric but I think he'd stab me if I gave him any more work to do. I
 don't know if there are patents around the work and that's why other people
 haven't replicated it.

 On 28 May 2015 at 08:21, Marc-Andre Carbonneau 
 marc-andre.carbonn...@ubisoft.com wrote:

 Good morning Lucer,

 Do you remember who designed and coded GATOR?
 I'm just curious.
 Thanks!
 MAC


 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
 Sent: May-27-15 9:11 PM
 To: softimage@listproc.autodesk.com
 Subject: Re: GATOR - A feature in Softimage since 2008

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally separate
 tools for textures vs rigging things, reflecting on their architecture vs
 XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
  in 2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
  less use out-of-the-box as the very things that made it nice for
  exchanging data between XSI and Maya, for example, were the very same
  features that tripped up game artists trying to do simpler things
 quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
  artists needed more micro-management of meshes and transfers.  Artists
  used it to transfer UV's, normals, vertex colors, envelope weights,
  and many other features.  I also extended, as well as exposed, many
  features from the SDK GATOR did not expose directly such as
  transferring attributes in local space, by raycasting, distance
  limits, transferring only selected subcomponents, correcting numerical
 flaws found in UV transfer, and so on.
  However, my use of the GATOR SDK was not limited to replicating the
  tool as a command.  I also used it heavily for other tasks which
  weren't strictly related to attribute transfer tasks such as animation
  remapping, pose transfer, mesh fitting, and interactive editing of
  normals and symmetrical envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
  and age is surprising considering it's so universally useful and isn't
  rocket science to develop.  If you know anything about tree data
  structures and linear algebra, you can write your own (even if it's
  not as efficient as GATOR).  What makes the GATOR SDK nice is the
  algorithm is very fast, accurate, and relatively easy to use.  Reverse
  lookups of subcomponents is a pain as GATOR worked on triangles, not
  polygons, but that's minor compared to all the benefits it provides.





Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Paul Doyle
Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing it
in Fabric but I think he'd stab me if I gave him any more work to do. I
don't know if there are patents around the work and that's why other people
haven't replicated it.

On 28 May 2015 at 08:21, Marc-Andre Carbonneau 
marc-andre.carbonn...@ubisoft.com wrote:

 Good morning Lucer,

 Do you remember who designed and coded GATOR?
 I'm just curious.
 Thanks!
 MAC


 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
 Sent: May-27-15 9:11 PM
 To: softimage@listproc.autodesk.com
 Subject: Re: GATOR - A feature in Softimage since 2008

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally separate
 tools for textures vs rigging things, reflecting on their architecture vs
 XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
  in 2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
  less use out-of-the-box as the very things that made it nice for
  exchanging data between XSI and Maya, for example, were the very same
  features that tripped up game artists trying to do simpler things
 quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
  artists needed more micro-management of meshes and transfers.  Artists
  used it to transfer UV's, normals, vertex colors, envelope weights,
  and many other features.  I also extended, as well as exposed, many
  features from the SDK GATOR did not expose directly such as
  transferring attributes in local space, by raycasting, distance
  limits, transferring only selected subcomponents, correcting numerical
 flaws found in UV transfer, and so on.
  However, my use of the GATOR SDK was not limited to replicating the
  tool as a command.  I also used it heavily for other tasks which
  weren't strictly related to attribute transfer tasks such as animation
  remapping, pose transfer, mesh fitting, and interactive editing of
  normals and symmetrical envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
  and age is surprising considering it's so universally useful and isn't
  rocket science to develop.  If you know anything about tree data
  structures and linear algebra, you can write your own (even if it's
  not as efficient as GATOR).  What makes the GATOR SDK nice is the
  algorithm is very fast, accurate, and relatively easy to use.  Reverse
  lookups of subcomponents is a pain as GATOR worked on triangles, not
  polygons, but that's minor compared to all the benefits it provides.




Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Andy Goehler

 On 28.05.2015, at 13:50, Gerbrand Nel nagv...@gmail.com wrote:
 
 Houdini attribute transfer does some bloody fantastic things if you use it 
 right.
 The more I work in houdini, the more I can come to terms with the death of 
 softimage.

Finally, a mention of Houdini’s Attribute Transfer.




Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Paul Doyle
You need to work on some new material :)

On 28 May 2015 at 09:17, Christopher Crouzet christopher.crou...@gmail.com
wrote:

 I've just noticed that the exact same thread happened on the Fabric
 mailing-list—someone asked for GATOR and I quoted that foot roll thingy in
 my reply. I'm so predictable :)


 On 28 May 2015 at 20:11, Christopher Crouzet 
 christopher.crou...@gmail.com wrote:

 Beware also to not implement any foot roll in your rigs.

 http://www.google.com/patents/US7545378


 On 28 May 2015 at 19:50, Paul Doyle technove...@gmail.com wrote:

 Most likely covered by this one:
 Transfer of attributes between geometric surfaces of arbitrary
 topologies with distortion reduction and discontinuity preservation
 United States 7760201Issued July 20, 2010

 This describes how to transfer surface attributes (such as color, UVs,
 skinning) between two 3D geometries of different topologies and potentially
 different type (polygon mesh, NURBS, curve...). In particular, it describes
 methods to preserve surface discontinuitues (such as UV island seams) and
 reduce attribute distortion on the target surface.

 On 28 May 2015 at 08:42, Paul Doyle technove...@gmail.com wrote:

 Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing
 it in Fabric but I think he'd stab me if I gave him any more work to do. I
 don't know if there are patents around the work and that's why other people
 haven't replicated it.

 On 28 May 2015 at 08:21, Marc-Andre Carbonneau 
 marc-andre.carbonn...@ubisoft.com wrote:

 Good morning Lucer,

 Do you remember who designed and coded GATOR?
 I'm just curious.
 Thanks!
 MAC


 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric
 Rousseau
 Sent: May-27-15 9:11 PM
 To: softimage@listproc.autodesk.com
 Subject: Re: GATOR - A feature in Softimage since 2008

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures vs rigging things, reflecting on their
 architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
  in 2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
  less use out-of-the-box as the very things that made it nice for
  exchanging data between XSI and Maya, for example, were the very same
  features that tripped up game artists trying to do simpler things
 quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
  artists needed more micro-management of meshes and transfers.
 Artists
  used it to transfer UV's, normals, vertex colors, envelope weights,
  and many other features.  I also extended, as well as exposed, many
  features from the SDK GATOR did not expose directly such as
  transferring attributes in local space, by raycasting, distance
  limits, transferring only selected subcomponents, correcting
 numerical flaws found in UV transfer, and so on.
  However, my use of the GATOR SDK was not limited to replicating the
  tool as a command.  I also used it heavily for other tasks which
  weren't strictly related to attribute transfer tasks such as
 animation
  remapping, pose transfer, mesh fitting, and interactive editing of
  normals and symmetrical envelope weighting of asymmetrical
 characters.
 
  To hear other applications don't have a GATOR equivalent in this day
  and age is surprising considering it's so universally useful and
 isn't
  rocket science to develop.  If you know anything about tree data
  structures and linear algebra, you can write your own (even if it's
  not as efficient as GATOR).  What makes the GATOR SDK nice is the
  algorithm is very fast, accurate, and relatively easy to use.
 Reverse
  lookups of subcomponents is a pain as GATOR worked on triangles, not
  polygons, but that's minor compared to all the benefits it provides.






 --
 Christopher Crouzet
 *http://christophercrouzet.com* http://christophercrouzet.com




 --
 Christopher Crouzet
 *http://christophercrouzet.com* http://christophercrouzet.com




Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Tom Kleinenberg
A simple GATOR replacement would probably refresh the material ...

On 28 May 2015 at 15:36, Paul Doyle technove...@gmail.com wrote:

 You need to work on some new material :)

 On 28 May 2015 at 09:17, Christopher Crouzet 
 christopher.crou...@gmail.com wrote:

 I've just noticed that the exact same thread happened on the Fabric
 mailing-list—someone asked for GATOR and I quoted that foot roll thingy in
 my reply. I'm so predictable :)


 On 28 May 2015 at 20:11, Christopher Crouzet 
 christopher.crou...@gmail.com wrote:

 Beware also to not implement any foot roll in your rigs.

 http://www.google.com/patents/US7545378


 On 28 May 2015 at 19:50, Paul Doyle technove...@gmail.com wrote:

 Most likely covered by this one:
 Transfer of attributes between geometric surfaces of arbitrary
 topologies with distortion reduction and discontinuity preservation
 United States 7760201Issued July 20, 2010

 This describes how to transfer surface attributes (such as color, UVs,
 skinning) between two 3D geometries of different topologies and potentially
 different type (polygon mesh, NURBS, curve...). In particular, it describes
 methods to preserve surface discontinuitues (such as UV island seams) and
 reduce attribute distortion on the target surface.

 On 28 May 2015 at 08:42, Paul Doyle technove...@gmail.com wrote:

 Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing
 it in Fabric but I think he'd stab me if I gave him any more work to do. I
 don't know if there are patents around the work and that's why other 
 people
 haven't replicated it.

 On 28 May 2015 at 08:21, Marc-Andre Carbonneau 
 marc-andre.carbonn...@ubisoft.com wrote:

 Good morning Lucer,

 Do you remember who designed and coded GATOR?
 I'm just curious.
 Thanks!
 MAC


 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric
 Rousseau
 Sent: May-27-15 9:11 PM
 To: softimage@listproc.autodesk.com
 Subject: Re: GATOR - A feature in Softimage since 2008

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally
 separate tools for textures vs rigging things, reflecting on their
 architecture vs XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
  in 2008.
 
  GATOR was largely tailored for those switching applications and
 doing
  rigging in a film/video pipeline.  For games development, GATOR has
  less use out-of-the-box as the very things that made it nice for
  exchanging data between XSI and Maya, for example, were the very
 same
  features that tripped up game artists trying to do simpler things
 quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
  artists needed more micro-management of meshes and transfers.
 Artists
  used it to transfer UV's, normals, vertex colors, envelope weights,
  and many other features.  I also extended, as well as exposed, many
  features from the SDK GATOR did not expose directly such as
  transferring attributes in local space, by raycasting, distance
  limits, transferring only selected subcomponents, correcting
 numerical flaws found in UV transfer, and so on.
  However, my use of the GATOR SDK was not limited to replicating the
  tool as a command.  I also used it heavily for other tasks which
  weren't strictly related to attribute transfer tasks such as
 animation
  remapping, pose transfer, mesh fitting, and interactive editing of
  normals and symmetrical envelope weighting of asymmetrical
 characters.
 
  To hear other applications don't have a GATOR equivalent in this day
  and age is surprising considering it's so universally useful and
 isn't
  rocket science to develop.  If you know anything about tree data
  structures and linear algebra, you can write your own (even if it's
  not as efficient as GATOR).  What makes the GATOR SDK nice is the
  algorithm is very fast, accurate, and relatively easy to use.
 Reverse
  lookups of subcomponents is a pain as GATOR worked on triangles, not
  polygons, but that's minor compared to all the benefits it provides.






 --
 Christopher Crouzet
 *http://christophercrouzet.com* http://christophercrouzet.com




 --
 Christopher Crouzet
 *http://christophercrouzet.com* http://christophercrouzet.com





Softimage going to sleep on Windows 8

2015-05-28 Thread Leonard Koch
Hey list,

since updating to Windows 8 I've had the issue that if I leave softimage
alone for a few minutes, it takes about 10 seconds for it to become
responsive again after tabbing/clicking back into it.

I have a fast SSD, plenty of RAM and not much else going on.
Has anyone else encountered this issue?

Cheers.
-Leo


Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Luc-Eric Rousseau
I was replying about who was the design partner, not who used it after
the it was released.

On 28 May 2015 at 12:03, Nicolas Esposito 3dv...@gmail.com wrote:
 Ehm...

 MGS4 meets Assassin's Creed

 As far sa I remember:
 Konami
 Sega
 Square Enix
 Crytek
 Namco
 Capcom
 Others probably...

 2015-05-28 17:57 GMT+02:00 Luc-Eric Rousseau luceri...@gmail.com:

 Or it might have been Sega or Capcomp.. it was definitely one of these
 three big japan Softimage client.
 This was all about transferring uv and weighting between game
 characters and same and different resolutions.

 On 27 May 2015 at 21:13, Martin Contel martin3d...@gmail.com wrote:
  Really, for Square?! :)
 
  There are still lots of XSI seats here, all of them on the game
  development
  teams. At Visual Works (the CG cinematics division) everything is Maya
  and a
  tinny bit of Houdini.
 
  Cheers,
 
  --
  Martin Contel
  CG Supervisor
  Square Enix (Visual Works Division)
 
  On Thu, May 28, 2015 at 10:10 AM, Luc-Eric Rousseau
  luceri...@gmail.com
  wrote:
 
  GATOR was developed for/with one of our main game customers, Square I
  think.
  I'm not aware of a Gator sdk, what is that?
  There are attribute transfers in other apps, but it's generally
  separate tools for textures
  vs rigging things, reflecting on their architecture vs XSI




RE: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Marc-Andre Carbonneau
Good morning Lucer,

Do you remember who designed and coded GATOR? 
I'm just curious.
Thanks!
MAC


-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: May-27-15 9:11 PM
To: softimage@listproc.autodesk.com
Subject: Re: GATOR - A feature in Softimage since 2008

GATOR was developed for/with one of our main game customers, Square I think.
I'm not aware of a Gator sdk, what is that?
There are attribute transfers in other apps, but it's generally separate tools 
for textures vs rigging things, reflecting on their architecture vs XSI

On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
 For the record, GATOR was introduced in late 2005 with XSI v5.0, not 
 in 2008.

 GATOR was largely tailored for those switching applications and doing 
 rigging in a film/video pipeline.  For games development, GATOR has 
 less use out-of-the-box as the very things that made it nice for 
 exchanging data between XSI and Maya, for example, were the very same 
 features that tripped up game artists trying to do simpler things quickly in 
 heavy repetition.

 I wrote a command based version of the tool using the GATOR SDK as 
 artists needed more micro-management of meshes and transfers.  Artists 
 used it to transfer UV's, normals, vertex colors, envelope weights, 
 and many other features.  I also extended, as well as exposed, many 
 features from the SDK GATOR did not expose directly such as 
 transferring attributes in local space, by raycasting, distance 
 limits, transferring only selected subcomponents, correcting numerical flaws 
 found in UV transfer, and so on.
 However, my use of the GATOR SDK was not limited to replicating the 
 tool as a command.  I also used it heavily for other tasks which 
 weren't strictly related to attribute transfer tasks such as animation 
 remapping, pose transfer, mesh fitting, and interactive editing of 
 normals and symmetrical envelope weighting of asymmetrical characters.

 To hear other applications don't have a GATOR equivalent in this day 
 and age is surprising considering it's so universally useful and isn't 
 rocket science to develop.  If you know anything about tree data 
 structures and linear algebra, you can write your own (even if it's 
 not as efficient as GATOR).  What makes the GATOR SDK nice is the 
 algorithm is very fast, accurate, and relatively easy to use.  Reverse 
 lookups of subcomponents is a pain as GATOR worked on triangles, not 
 polygons, but that's minor compared to all the benefits it provides.



Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Eric Turman
+1 well stated

On Thu, May 28, 2015 at 10:45 AM, Ed Manning etmth...@gmail.com wrote:

 On Thu, May 28, 2015 at 11:42 AM, Luc-Eric Rousseau luceri...@gmail.com
 wrote:


 Somebody could totally write yet another attribute transfer tool, but
 I think what people love IMHO is how XSI's data is structured which
 allows such a tool to be implemented.

 Correct!  It's not the fact that GATOR exists; it's the usability and
 artist-friendliness of the workflow that make the difference.




-- 




-=T=-


Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Nicolas Esposito
Ehm...

MGS4 meets Assassin's Creed https://youtu.be/U-DrkSQLHsk?t=1m45s

As far sa I remember:
Konami
Sega
Square Enix
Crytek
Namco
Capcom
Others probably...

2015-05-28 17:57 GMT+02:00 Luc-Eric Rousseau luceri...@gmail.com:

 Or it might have been Sega or Capcomp.. it was definitely one of these
 three big japan Softimage client.
 This was all about transferring uv and weighting between game
 characters and same and different resolutions.

 On 27 May 2015 at 21:13, Martin Contel martin3d...@gmail.com wrote:
  Really, for Square?! :)
 
  There are still lots of XSI seats here, all of them on the game
 development
  teams. At Visual Works (the CG cinematics division) everything is Maya
 and a
  tinny bit of Houdini.
 
  Cheers,
 
  --
  Martin Contel
  CG Supervisor
  Square Enix (Visual Works Division)
 
  On Thu, May 28, 2015 at 10:10 AM, Luc-Eric Rousseau luceri...@gmail.com
 
  wrote:
 
  GATOR was developed for/with one of our main game customers, Square I
  think.
  I'm not aware of a Gator sdk, what is that?
  There are attribute transfers in other apps, but it's generally
  separate tools for textures
  vs rigging things, reflecting on their architecture vs XSI



Re: Softimage going to sleep on Windows 8

2015-05-28 Thread Eric Thivierge
Did you turn off the Reload Externally Modified Clips On Focus in the 
Prefs  Rendering  Images Tab?


On Thursday, May 28, 2015 10:43:22 AM, Leonard Koch wrote:

Hey list,

since updating to Windows 8 I've had the issue that if I leave
softimage alone for a few minutes, it takes about 10 seconds for it to
become responsive again after tabbing/clicking back into it.

I have a fast SSD, plenty of RAM and not much else going on.
Has anyone else encountered this issue?

Cheers.
-Leo




Re: Softimage going to sleep on Windows 8

2015-05-28 Thread Tom Kleinenberg
We're not using Windows 8 but if there are files in External Files that
can't be found I think XSI tries to refresh when alt-tabbing. I'm not sure
what the fix would be, barring fixing the path(s) - I think referenced
objects with Animation Mixer nodes may be particularly susceptible to the
problem (they seem to return a lot of \\none paths).

On 28 May 2015 at 16:43, Leonard Koch leonardkoch...@gmail.com wrote:

 Hey list,

 since updating to Windows 8 I've had the issue that if I leave softimage
 alone for a few minutes, it takes about 10 seconds for it to become
 responsive again after tabbing/clicking back into it.

 I have a fast SSD, plenty of RAM and not much else going on.
 Has anyone else encountered this issue?

 Cheers.
 -Leo



Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Ed Manning
On Thu, May 28, 2015 at 11:42 AM, Luc-Eric Rousseau luceri...@gmail.com
wrote:


 Somebody could totally write yet another attribute transfer tool, but
 I think what people love IMHO is how XSI's data is structured which
 allows such a tool to be implemented.

 Correct!  It's not the fact that GATOR exists; it's the usability and
artist-friendliness of the workflow that make the difference.


Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Luc-Eric Rousseau
I think it doesn't matter that there is a patent around some
implementation detail of attribute transfer in XSI, or even who wrote
it.  I think what people see in a GATOR is a menu item in XSI that
will transfer property maps, uv, skinning between objects reliably and
without having to understand the details.  Why that works is because
of decisions in XSI'd design and architecture, because you have to
have something that's property-based in the first place and all that
cluster updating thing beneath to use it as a live operator.
Somebody could totally write yet another attribute transfer tool, but
I think what people love IMHO is how XSI's data is structured which
allows such a tool to be implemented.


On 28 May 2015 at 08:50, Paul Doyle technove...@gmail.com wrote:
 Most likely covered by this one:
 Transfer of attributes between geometric surfaces of arbitrary topologies
 with distortion reduction and discontinuity preservation

 United States 7760201

 Issued July 20, 2010

 This describes how to transfer surface attributes (such as color, UVs,
 skinning) between two 3D geometries of different topologies and potentially
 different type (polygon mesh, NURBS, curve...). In particular, it describes
 methods to preserve surface discontinuitues (such as UV island seams) and
 reduce attribute distortion on the target surface.


 On 28 May 2015 at 08:42, Paul Doyle technove...@gmail.com wrote:

 Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing it
 in Fabric but I think he'd stab me if I gave him any more work to do. I
 don't know if there are patents around the work and that's why other people
 haven't replicated it.

 On 28 May 2015 at 08:21, Marc-Andre Carbonneau
 marc-andre.carbonn...@ubisoft.com wrote:

 Good morning Lucer,

 Do you remember who designed and coded GATOR?
 I'm just curious.
 Thanks!
 MAC


 -Original Message-
 From: softimage-boun...@listproc.autodesk.com
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric
 Rousseau
 Sent: May-27-15 9:11 PM
 To: softimage@listproc.autodesk.com
 Subject: Re: GATOR - A feature in Softimage since 2008

 GATOR was developed for/with one of our main game customers, Square I
 think.
 I'm not aware of a Gator sdk, what is that?
 There are attribute transfers in other apps, but it's generally separate
 tools for textures vs rigging things, reflecting on their architecture vs
 XSI

 On 27 May 2015 at 19:27, Matt Lind speye...@hotmail.com wrote:
  For the record, GATOR was introduced in late 2005 with XSI v5.0, not
  in 2008.
 
  GATOR was largely tailored for those switching applications and doing
  rigging in a film/video pipeline.  For games development, GATOR has
  less use out-of-the-box as the very things that made it nice for
  exchanging data between XSI and Maya, for example, were the very same
  features that tripped up game artists trying to do simpler things
  quickly in heavy repetition.
 
  I wrote a command based version of the tool using the GATOR SDK as
  artists needed more micro-management of meshes and transfers.  Artists
  used it to transfer UV's, normals, vertex colors, envelope weights,
  and many other features.  I also extended, as well as exposed, many
  features from the SDK GATOR did not expose directly such as
  transferring attributes in local space, by raycasting, distance
  limits, transferring only selected subcomponents, correcting numerical
  flaws found in UV transfer, and so on.
  However, my use of the GATOR SDK was not limited to replicating the
  tool as a command.  I also used it heavily for other tasks which
  weren't strictly related to attribute transfer tasks such as animation
  remapping, pose transfer, mesh fitting, and interactive editing of
  normals and symmetrical envelope weighting of asymmetrical characters.
 
  To hear other applications don't have a GATOR equivalent in this day
  and age is surprising considering it's so universally useful and isn't
  rocket science to develop.  If you know anything about tree data
  structures and linear algebra, you can write your own (even if it's
  not as efficient as GATOR).  What makes the GATOR SDK nice is the
  algorithm is very fast, accurate, and relatively easy to use.  Reverse
  lookups of subcomponents is a pain as GATOR worked on triangles, not
  polygons, but that's minor compared to all the benefits it provides.