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!
