Maya Wish List

[novakog]

That's true, compositing apps were made for this - but still. It's always nice to do something in as few steps and software as possible - I don't want to dish out the time and money for a new piece of software, I have other things I need to pay for (don't we all?).

Yes, I never expected the blurred reflections to be post-production, but hey, we can always WANT it to be, can't we?

Alright, I'll say that pretty much anything can be done in Maya with its API and MEL, but if you ask me, I think MEL and API are supposed to be something for a single person/corporation's customization/use, not for a feature that a lot of people are asking for (and a LOT of people are asking for hypershade folders).

Fine, I'm lazy, but being lazy is what technology is for - isn't it?

[joojaa]

I can understan that but... i think alias has made some cler moves away from doing more comp on it

In reply to:
feature that a lot of people are asking for (and a LOT of people are asking for hypershade folders).

well thats just i theve actualy incorporated folders on this request (its just that what windows remeber form time to time is a bit obscure since most users just go around destroying the windows instead of hiding them like they are supposed to). The point is that alias shouldnt need to bother about things that can be done in mel (yes aw would do it in mel almost for sure....)

[jboddy]

Folks,
Thanks for all this great feedback. Please be assured that we are listening. However, since like all software companies we have a finite set of resources and we can't possibly do everything, the most useful thing that you can do is help us to focus in and prioritize the most important features for the largest number of people.

The best way to do this is to use the Maya features voting website that has been set up at: www.maya.digication.com.

Thanks and best regards,

Jill Ramsay
Senior Product Manager, Maya

[1000101-]

hrmm
haha too bad you can't post a rebuttal there; or at least how we've managed to work around whatever.

since A|W has given their blessings I'll go vote..
I see number one on my list is number one on their list.

Hopefully 5.5 addresses this issue; or at least starts to.. if not we'll know they ain't listenin haha

[novakog]

Alright, in that case, I have two more feature requests.

1. In the main viewport, you can tap the spacebar to make one of the views full screen - this should be doable with any open window (Hypershade, Render View, etc.)

2. I'm pretty sure they don't already have this, but I could be wrong. I want to be able to save HDR images (like floating-point TIFF, .hdr, etc.). Can Mental Ray do this?

[stanislav]

Here are some complaints/suggestions about the Vector renderer:

1. The docs say that ' When Curve Tolerance is 0, object outlines are represented by a series of straight line segments (one segment for each polygon edge).' This does not work for me. The way the 2d object edges are produced seems to be dependent on fill type but the 2D object edges never coincide with 3D edges in Maya. They are usually weirdly subdivided. This produces dirty and unusable files.

2. The lines and 2D areas are grouped in random fashion in generated files. This is again extremely difficult to control and work with. Ideally, it would be good to have controls over the way the areas/lines are grouped with the following options: one line per edge, one area per surface, the same color together, areas/lines of one object together (!!!), perhaps retaining the name, etc.

3. Variable line thicknesses per object. Savable styles that can be applied to objects and edited with objects automatically updated, maybe presented as a material.

4. Extensive controls where and what lines are drawn: outlines, folds, intersections, regions, borders, etc. Have a look at Illustrate! plugin for MAX, it is not without faults but is much better featured.

5. Different styles for the lines: hash, rough, dots, etc. Opacity for lines and areas.

6. Min. Edge Angle: it should be possible to set this to anything up to 180 degrees.

7. We need to be able to control edge visibility explicitly.

[stanislav]

Make DWG importer/exporter work properly. Currently it is buggy, underfeatured and half of 3D geometry in ACAD is not supported.

S.

[stanislav]

Make dual monitor setup function properly. Currently, all the pop-up window on the secondary monitor on all pro cards are appearing in the wrong monitor. Redesign UI to make the elements movable.

S.

[1000101-]

hrmm
I'd rather enhancements to the core package more than UI features you can easily work around.

"yay I can move my shelf but I still must deal with these bizaar joint rotations..."

[stanislav]

Yeah? I have to zoom in and out more and drag the cursor to the primary monitor to choose an item in my right-click menus (if they ever appear that is). This slows me down on every operation. Is that professional software or what? None of the competitors let themselves do it. UI programming is trivial and has to be done properly.

S.

[stanislav]

Why don

[1000101-]

thats not alias's fault.
thats your video card vendors fault.
I'm currently using nvidia's span mode for dual head displays and the hot box as well as all of my marking menus appear just fine on whatever display I have my cursor over. Everything behaves as expected.

On a side not you'll hit similiar issues with any app that uses openGL to display a majority of the UI.

So at any rate; I'd rather alias fix something to benifit a large portion of the userbase more than a UI enhancement to satisfy someones wishes that something like the shelf be movable. (especially considering its not terribly difficult to code up a floating shelf in MEL)

[stanislav]

In MEL? Nice. Or in C++? Or should we better draw our frames by hand? Well, we can do it all. That is not the point, however. Professional software is supposed to be flexible, efficient and reliable, built to be fast.

About the dual monitor bugs. They are officially recognized by A|W (#156690). GeForce cards are not certified by A|W while our FireGL's and WildCat's are. They are expensive and if recommended, should work properly with Maya. E.g. Studio uses OpenGL interface with far less severe problems in both monitors.

S.

[joojaa]

In reply to:
In MEL? Nice. Or in C++? Or should we better draw our frames by hand? Well, we can do it all. That is not the point, however. Professional software is supposed to be flexible, efficient and reliable, built to be fast.

maya is fast and flexible... using maya without knowing mel is like buying a porche for grocery shopping trips in town with blind people!

[stanislav]

Interface level tools are there for speed. Speed gives accessibility. If you compare the amount of user-written scripts for, say, MAX (object-oriented, visual programming, debugging) and Maya you will see the difference. I can program, the point of buying software is that I should not have to for trivial problems.

S.

[joojaa]

well id have to disagree on this ive seen plenty of max users who have never done a sirpt but ive yet to se a maya user that hasnt cripted atleast a few tools for pretty wierd workflow enhancements...

[1000101-]

In reply to:
In MEL? Nice. Or in C++? Or should we better draw our frames by hand? Well, we can do it all. That is not the point, however. Professional software is supposed to be flexible, efficient and reliable, built to be fast.

I'm sorry you can't be bothered to take 10 minutes out of your time to make a floating shelf for you; I'm even more sorry you don't want to take the 5 minutes out of your time to look on HE3d and see a floating shelf script that allready exists.
I hate to say it but maya gets its flexibility from being built from the ground up via MEL and opening it all up to the user via MEL. The API just further extends that.
It sounds like because the user interface doesn't meet your exact needs that the program is not flexible enough for you. Its not even that you want a drastic change; you want trivial changes.

In reply to:About the dual monitor bugs. They are officially recognized by A|W (#156690). GeForce cards are not certified by A|W while our FireGL's and WildCat's are. They are expensive and if recommended, should work properly with Maya. E.g. Studio uses OpenGL interface with far less severe problems in both monitors.

Hrmmm; it does not occur on any of the following cards of which I have tested:

Geforce2 MX; Geforce4 MX 220 and 440; Geforce4 Ti4200, Ti4600; Quadro2MXR; Quadro4 750XGL; Quadro4 900XGL.

I believe someone with a fireGL X1 has told me also that he has fixed this issue with a driver setting. I also believe radeon users have this very same setting available to them.

If you are treating each output as a seperate display on an nvidia board; it will render marking menus on the wrong display. If you are using dual view it will render marking menus on the wrong display.
If you are using span mode everything renders correctly as your desktop acts as one massive 2560x1024 display as opposed to 1280x1024 displays.

In reply to:
Interface level tools are there for speed. Speed gives accessibility. If you compare the amount of user-written scripts for, say, MAX (object-oriented, visual programming, debugging) and Maya you will see the difference. I can program, the
point of buying software is that I should not have to for trivial problems.

Should I compare by volume? by functionality? by how many users are making them?
Why is it noone else has problems writing UI scripts for maya? I have no programming background; and I hate scripting; yet I'm not going to demand A|W build custom UI's to my liking in the core package. Its there to be changed; if you don't like it; fix it.

I hate seeing developers waste time on features like "Oh it would be better if the button were over here instead; and maybe we can add some more pieces of flare"

To me UI improvements are like people who market products as better without actually improving them.

[wjflywheel]

|User Interface|

my wishes:

get all the damn windows to use the same interface. i.e.: shift-select vs. control-select, left/middle zoom vs. right zoom, etc. - that stuff is massively annoying and slows learning of new users to a crawl

get rid of the bizzarre method of making connections in the particle instancer (particularly the orientation stuff). why can't it have channel boxes and expressions like the rest of the interface? why does it have to be so obscurely difficult to assign 20 different static models to 1700 particles? particularly in random fashion. the whole interface could be brought in line with the other particle functionality. or better, with the way everything except particles works. while you're at it, why not make the particle attributes work the way other attributes do? consistency is sorely lacking in the maya interface in general.

when the attribute editor rolls up a section near the bottom, if it hits the bottom of the current pane, it pulls the whole vertical scroll down. then when you open the next section, it opens down past the bottom of the attribute editor, and you have to scroll down again (and without a mouse wheel...). rinse, repeat (ad nauseum).

my faves from the list:

• Do simple arithmetic (3.14/1.5+2.6*7.3) in any intField or floatField such as in channelBox, Attribute Editor etc.

• Middle Mouse button scrolling !!

[yeepeee]

Hi, here my wish list:

For MR:
Better integration (all particle type rendering)
A sky light wizard (sun+sky type)
A real doc (really detailed, with ex, how to and tutos)
An IES import plug

Anim:
-Quaternion for motion path or something to fix esealy the probs of flipping
-Rotation of the scale pivot
-Possibility to constraint an object on a cluster and not only the cluster on an object, to make what does the "rivet" mel (cf softimage)

FX:
A better paticle instancer, possibility to use an animated object rather than a break down its anim. And the hability to make easily control and a random off the birth state, to make an asynchronous flock

UI:
The wheel, please !!
A better Trax interface, the possibility to scale or retime (right click choice) directly in the time line, more editing possibilities in the time line

Its possible that some things listed above already exist in Maya, even i used for a long time now (but mostly for rendering), in this case the updates should be made in the docs, cause concerning flipping on motion path and asynch flocks, i had to make heavy tweaking and brainstorming before to find a somehow solution

[geoffcrowther]

my 2 pesos: have 64bit maya ready for 64 bit linux on amd cpu's when the time comes.