Re: Softimage Digest, Vol 78, Issue 106

[Matt Lind]

t, 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!
-- 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

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

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

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

> 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  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  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" 
 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  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.
> >
> > 

Re: GATOR - A feature in Softimage since 2008

[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 :
>
>> 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  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  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" 
> 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  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, 

Re: GATOR - A feature in Softimage since 2008

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


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 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
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
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"
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
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 artists trying to do simpler things
quickly in heavy repetition.
>
>

RE: GATOR - A feature in Softimage since 2008

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

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

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

[Christopher Crouzet]

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  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  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  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* 

Re: GATOR - A feature in Softimage since 2008

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


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

Re: GATOR - A feature in Softimage since 2008

[Andy Goehler]

> On 28.05.2015, at 13:50, Gerbrand Nel  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

[Paul Doyle]

You need to work on some new material :)

On 28 May 2015 at 09:17, Christopher Crouzet 
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  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  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  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* 
>>
>>
>
>
> --
> Christopher Crouzet
> *http://christophercrouzet.com* 
>
>

Re: GATOR - A feature in Softimage since 2008

[Tom Kleinenberg]

A simple GATOR replacement would probably refresh the material ...

On 28 May 2015 at 15:36, Paul Doyle  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  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  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  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* 
>>>
>>>
>>
>>
>> --
>> Christopher Crouzet
>> *http://christophercrouzet.com* 

Softimage going to sleep on Windows 8

[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: Softimage going to sleep on Windows 8

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

[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: GATOR - A feature in Softimage since 2008

[Ed Manning]

On Thu, May 28, 2015 at 11:42 AM, Luc-Eric Rousseau 
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

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

[Eric Turman]

+1 well stated

On Thu, May 28, 2015 at 10:45 AM, Ed Manning  wrote:

> On Thu, May 28, 2015 at 11:42 AM, Luc-Eric Rousseau 
> 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

[Luc-Eric Rousseau]

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

[Nicolas Esposito]

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 :

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

[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 :
>>
>> 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  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
>> > 
>> > 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: "Jordskott" tv series visual effects, Softimage+Redshift

[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 
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" :
>
>   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
>
>
>
>
>
>

Heavy scenes with the GTX 970

[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: Heavy scenes with the GTX 970

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

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

[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

[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

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

[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

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

[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: Heavy scenes with the GTX 970

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

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

[Raffaele Fragapane]

That's usually the quadro cards, I don't know of the gtx driver branch
offering the AD apps as one you can pick. Maybe it changed and I didn't
notice though.

Adding the exe though simply changes the (subset of per app) settings for
that app, changing them globally sorts the same effect.

On Fri, May 29, 2015 at 3:19 PM, Sven Constable 
wrote:

> 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 
> 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!
>



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