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 developed....however 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 <[email protected]>: > 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 <[email protected]> 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 < >> [email protected]> 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 <[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! >>> >> >
