API wishlist surveys for Autodesk M&E products API

Tools
#1

just saw this over on cgtalk

It’s that time of year again. The following “Summer 2010” API wishlist surveys are now ready:

* [Autodesk® Maya®](http://www.zoomerang.com/Survey/WEB22APSHGBUNG)
* [Autodesk® 3ds Max®](http://www.zoomerang.com/Survey/WEB22APSJ2BUZG)

Please do take the time to fill out the surveys for the products you customize or develop applications for.

Our Engineering teams use the feedback you provide to prioritize our API development efforts: this is a great chance for you to have a direct impact on the direction we take in exposing APIs from our products. And if you (optionally) provide your email address in the survey, I’ll send you a copy of the results once they’ve been compiled.

The surveys will remain open until July 1st, 2010. Thanks in advance for your feedback!

The Autodesk Developer Network

#2

And Everybody make sure you check .NET support on question 8!:laugh:

#3

As well as “Provide an API for Artisan-like brush tools”.
I’m tired of having to reverse engineer the brush manipulator…

#4

I was actually curious about this item, since it was quite vague (e.g. are we talking about doing it via Mono (to be accessible cross-platform)? would it just be more API bindings or would it provide fundamentally new functionality? etc.).

What do you feel like .NET support would add to the product? I feel like I can do pretty much everything I need to do now with Python, which I find to be much faster to work with for most problems. I could see it potentially providing a performance advantage over Python for some plug-ins, but I feel like it’s currently pretty painless to convert Python API code into C++ API code if I really need a boost.

#5

[QUOTE=adam;6541]
What do you feel like .NET support would add to the product?[/QUOTE]

I called out two specific things in the survey, one is scripting level support similar to what Python .NET provides and the other is a Managed version of the API, similar to what Digital Anvil was doing back in early 2000s.

It’s not so much additional functionality or anything like that, i mean sure, the Python standard library and the base .NET framework have similar facilities. I will say having worked with both that certain things on the .NET side make a bit more sense than Python (System.XML vs xml.dom.minidom, for instance, at least in my opinion). The major point is that C# is a fairly ubiquitous standard in games (2/3 of the companies i’ve worked at, for example), so it’s nice to be able to take that existing functionality and pull it into Maya. Maybe at smaller studios not so much, but all the larger studios i’ve worked at use C#. So really it’s just being able to have a common ground between framework/engine tools and maya tools, that sort of thing.

#6

Makes sense. I suppose that where you might see benefits depends greatly on what you do a lot of at work. I’d certainly agree I prefer to work with XML in .NET, but I also prefer regular expressions, string manipulation, and directory browsing in Python, which I generally spend much more time with when I’m still in Maya.

The point about having a common framework makes sense, too. I suppose the big difference for me is that in most of my work there’s generally the “out of DCC app and into engine/editor as quickly as possible” philosophy. Thus, I haven’t been in many situations where the Maya tools could benefit much from sharing with the engine/editor tools. I generally don’t need a lot of super complicated things on the Maya side, so I just want something that’s fast to develop with so I can leave. If it’s more complicated than File -> Save, then it can probably be simplified :slight_smile:

I guess .NET support is the sort of thing that could be interesting and potentially open some new possibilities, but if it were a question of limited resources, then I’d personally prefer that some of the existing API features be improved or expanded before support for (essentially just) another interface were added.

#7

For us those two ideas are inclusive. Before anything can get through the game data pipe, we have to create external data like our sidecar files and things like that. Ordinarily that’s governed by an external tool, but since our artists don’t want to leave Maya (and shouldn’t have to), having the .NET support allows to have the one click from maya to engine pipeline. At the end of the day, sure, it depends your studio and pipeline’s individual needs, but at the very least it’s something Adsk needs to consider very carefully, rather than just taking the stance they’ve taken for the last few yrs and hiding behind the “it’s not multi-platform friendly”, which isn’t really true anyway.

#8

Our studio’s standalone tools are 90% C#, we have our own Game Editor and that is all C#, when we want to export any assets to our engine or editor the code is already written for us, so we use python.net to access these functions and we don’t need to dupe any code. Beside having access to all the libraries that the editor has (Game Introspection, Math, File IO), it’s a dam site easier to use C# to create UI, true it locks us down to windows machines (we are not using Mono, and wont), but we are a windows house.

Python.net gives us code that is really easy to work with, the most complex thing is making sure you have your tool running in a thread and is parented to Maya. It’s just nice when you can get standard Office and windows components and just slot them in.

Yeah it would be nice to have C# directly in Maya; like Max, and the latest version of C# has taken a couple of tricks from python, but don’t get me wrong I am a huge fan or python and I am quite happy with a python.net style interface, then you have python and .net in any app.

~B)

oh yes, I was meant to get some code to you too Seth. It’s on it’s way.

#9

Thanks, guys. Sorry if my questions come across as making anyone stand trial for their pipeline; I’m just actually really interested in what people would do with .NET in Maya if they had it, as it’s not totally obvious to me.

Sidecar generation seems sensible enough as an XML example, but I’m not sure I totally follow all of Robert’s examples. When I look at how I actually use Maya in the pipeline, I’m not sure what I would do inside Maya itself where game introspection, for instance, would help me (or, indeed, where the Maya API’s math or Python’s file I/O wouldn’t suit me just fine or possibly be a little less troublesome to work with). I’m in a similar situation where all of my game code and editor tools are entirely C#, but I’m just not sure how having access to any of that from within Maya itself would do much for me. Maybe I’m missing something obvious here.

As for hiding behind the “it’s-not-multi-platform-friendly” curtain, it’s a totally understandable concern for them at the higher level, whether or not it’s true in this particular case. They don’t seem to do many big features each release, so I suppose they have to be fairly careful about what they commit to. I wonder what percentage of their M&E customers (or even Maya customers more specifically) are actually game developers. If the majority of the customers are people in film or design/visualization, then I could see why single-platform features or items otherwise limited in scope might be lower on the priority list. As someone who actually does all his development in OSX, I do appreciate that they at least don’t totally forget about us.

#10

Not at all Adam, I didn’t take it that way. :wink:

Without going into to much detail about our pipeline, introspection in Maya allows us to connect to the game and the editor enabling some debugging and live updating of content, very handy with cinematics. Although introspection is a vital part of our pipe, file IO is the most used component within our pipeline as you can image. In relation to Math libraries, yes, math can certainly be done with the python libraries and we do that, but what it gives us is code that may be optimized within the game that is not standard or requires to be 100% accurate. We don’t often use this game math within Maya but there are a couple of times it has been required.

Hehehe, games are the small percentage of users for Maya and i don’t expect that Autodesk are going to bend over backwards just for us especially those of us using Windows. It doesn’t make sense from a business plan, even more so at this point in time to create a smaller market then the have, more bang for buck if they can keep a platform independent app. Who knows what the 3dsMax market would have been like if it was out on Windows & Mac or Linux.

~B)

#11

Hybrid Cheap Clubs Help With Your ShotExperiment with different club lengths in a Hybrid cheap golf clubs to see exactly which length will help you with your shots. Ishiner Typically, you should also realize that a hybrid will get about 5 to 8 yards more distance than their comparable iron. So can get a bit more length in your shot and with a higher trajectory. You won’t get as much roll because of that increased shot height but you will find you will have much more control on where the ball ends up on the course.