Yes.
GetClosestLocations(), GetClosestLocationWithinRadius(), the PointLocator
class, GetTriangleWeights(), etc... I call it the GATOR SDK because those
methods and classes define what GATOR does and became available with the
introduction of GATOR.
Matt
Date: Wed, 27 May 2015 23:09:12 -0700
From: Steven Caron <[email protected]>
Subject: Re: GATOR - A feature in Softimage since 2008
To: [email protected]
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" <[email protected]> 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 <[email protected]> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://listproc.autodesk.com/pipermail/softimage/attachments/20150527/d1289516/attachment.html
------------------------------
Message: 5
Date: Thu, 28 May 2015 16:48:18 +1000
From: Raffaele Fragapane <[email protected]>
Subject: Re: GATOR - A feature in Softimage since 2008
To: [email protected]
Message-ID:
<cajgptr+cn_cfak2jgcommdvp3baao_gghetvz5dd6w_6qwa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://listproc.autodesk.com/pipermail/softimage/attachments/20150528/ba23d260/attachment.html
------------------------------
_______________________________________________
Softimage mailing list
[email protected]
http://listproc.autodesk.com/mailman/listinfo/softimage
End of Softimage Digest, Vol 78, Issue 106
******************************************
