PDA

View Full Version : Soliciting suggestions for MEL Scripting for Maya Animators, Volume 2


mark_wilkins
07-31-2003, 10:10 PM
I'm currently working on

MEL Scripting for Maya Animators, Volume 2: Advanced User Interfaces and Character Rigging

and I'm curious what techniques or topics the community here would like to see included.

For reference, the outline of the original MEL Scripting for Maya Animators ("volume 1," although that's not part of its title) is at

http://www.melscripting.com/

Note that this is NOT a second edition of MEL Scripting for Maya Animators but is instead an entirely new book that builds on the first.

Comments? Questions? Rants? Raves? Phone lines are open, Alan Greenspan is standing by to take your call.

(Just kidding on that last one...)

-- Mark

twidup
07-31-2003, 10:27 PM
hmmm, I think one of the things I would like to see is something that David Gould kinda did, but not really.

I would like to some stuff on taking a script from a melscript to a plugin.

Also, maybe more about using Mel with system commands and other languages like Python and Perl (small section maybe)

-Todd

mark_wilkins
07-31-2003, 10:33 PM
I'm pretty sure David is working on more plug-in related stuff, and since we're both with the same publisher it wouldn't do to edge in on his territory :D

However, interfacing with external scripting languages might be a good thing to cover... I've written a TON of Perl scripts that fire off MEL scripts and vice versa in my work.

The only thing is that it's hard to come up with good examples of where this would be really useful in a Maya-only environment... mostly I do it when trying to make Maya play well with other software, which may be outside the scope of the book, and maybe not.

Thanks for the idea!

-- Mark

loked
07-31-2003, 11:18 PM
Hey Mark,

I'd really like to see a lot more advanced topics covered. Eg, ways to make skinning easier, either by using muscle systems or by procedurally automating it. Advanced GUI building for characters, like where you have a viewPane pop up isolating a tongue for example, so you can animate the tongue without having a head in the way. Scripts for importing and exporting animation of characters (I dont remember if you covered this in your first book).

Basically just production type things, that are advanced and arent really available anywhere else. One of my major problems with books now days is that you buy it and most of the info that you get out the book, you can either find somewhere on the net for free or in the Maya documentation. I'm not referring to your first book, I'm just speaking generaly:) So try and add things that are completely new and mind blowing!

I really look forward to this book. Thanks!!:thumbsup:

later:wavey:
loked

twidup
07-31-2003, 11:23 PM
no worries, I will have to mention the mel to plugin stuff to David then when he gets back from Siggraph and see what he says.

Cool though, I would buy the next book if it covered interacting with outside software for sure thru perl.

I personally wouldnt mind seeing a really in depth UI creation, something really deep covering a lot of tools for UIs.

-Todd

mark_wilkins
07-31-2003, 11:55 PM
loked: Much of what you're suggesting is the kind of thing I'm hoping to do with this book, and each of your specific ideas are great, but this one comment is worth discussing a bit (and the emphasis is mine):

Basically just production type things, that are advanced and arent really available anywhere else.

When you find a script in the archives at Highend3D.com, for example, it's usually just a mass of code, maybe well-commented, maybe not. Sometimes the documentation is great and sometimes it isn't. In any case, you have to read the script to figure out what it does and how to modify it to be useful to you.

What the MEL Scripting for Maya Animators books are fundamentally about, unlike those scripts at Highend3D, is describing, in detail, how useful scripts actually work, and talking about how to build them. They're meant to teach the skills that are necessary for script development, and code examples are included, with commentary, to serve that goal.

When people talk about "advanced" scripts, they usually either mean innovative scripts or complex scripts. I'm hoping to try to put together the most innovative examples possible, because these are likely to be both educational for the beginner and interesting to an advanced reader.

Complex example scripts, though, can be problematic because providing good, thorough commentary on a complex example is very difficult and the extra complexity tends to make the substance of the example less generally applicable.

That's a lot of the reason that, for example, when we discussed implementing crowd behavior in the first book, it was presented as only the beginning of a useful system, or perhaps a proof-of-concept for the flocking portion of a crowd system, rather than a complete engine.

By keeping the complexity low compared to what it would look like in production, we were able to provide sufficiently thorough commentary that someone new to the underlying ideas could keep up, yet we tried to have some interesting approaches implemented in it. A more advanced reader would immediately start thinking about how to build on what were there, but in no event would someone just install the script and use it as a turnkey solution to the problem because it wouldn't have served the educational goals to take it that far.

I hope that clears up a little bit what we've tried to do with the first book and what I'm hoping the second can look like in broad strokes.

mark_wilkins
07-31-2003, 11:59 PM
BTW twidup, you can just stick the MEL script in a string and call

MGlobal::executeCommand

but I guess that wouldn't be much of an optimization. Never mind...

:D:D

-- Mark

dstripinis
08-01-2003, 04:54 AM
Just as a note:

I spent two full chapters on UI building in my book, and by far it is the section people have been most vocal about liking.

The problem with any "advanced" scripts is always that people think "Ok, that's great, but what if I want to animate just the eyeballs. This only works on tongues."

It happens. I spent a 60 some odd pages on building a procedural grass generator in The MEL Companion. I recently got an email from someone who wanted to know if something like that would also work for asteroids.

And Mark, all I'll say is you're a brave man for taking on a second book already.

mark_wilkins
08-01-2003, 06:14 AM
Hi David!

MEL Scripting for Maya Animators has been done for about a year now, and I didn't bear the full brunt of it because of all the work Chris did, so it's easy to contemplate jumping back in.

We'll probably have some overlap in the UI stuff, because I'd like to make sure the basics are covered between the two MEL Scripting for Maya Animators books, but I'm planning on spending maybe half the book (250 pages or so) on UI development, so hopefully it'll add a good deal to the picture. I've only skimmed those chapters in your book (and I'm eager to avoid doing more until I have some of the work done on this one so that I'm more likely to produce something that takes a different approach) but they look really good and are a great place to go for someone who's looking for some user interface material in the meantime.

I believe that, when all is said and done, the two MSMA volumes, David's book and any follow-on project he undertakes, and The MEL Companion will all be able to coexist on the same shelf without the reader thinking "I didn't really get anything new from <book>."

-- Mark

dwalden74
08-01-2003, 08:52 AM
Hi mark, et al...

but I'm planning on spending maybe half the book (250 pages or so) on UI development

What kind of info are you planning on discussing here? To me this seems like a huge waste of space, unless of course you do something rather innovative(but what?). UI stuff is rather straight-forward and certainly nothing special. That kind of stuff anyone can learn just by dissecting other peopleīs scripts, right? Perhaps a discussion on the scripted panel might be nice, but then again, how often do we use that? Pretty much never.


A few things Iīd like to see in a MEL book:
-thorough `selectionConnection` discussion.
-exporting/importing animation data (already said).
-useful workflow tools at PDI/DW ;)
-useful workflow tools at Pixar ;) ;)
-"internal MEL"...whatīs Maya doing secretly under the hood?
-How to make tank treads??? (sorry, couldnīt resist that one)
-tools to facilitate multiple constraint-blending on characters (for example, character picks up glass, character rests elbows, character grabs another characterīs arm and shakes violently, all in the same shot).
-How about explaining the `match` command a little better than last time? (Iīm an idiot, I know.)

In general I would avoid a "general workflow tutorial" approach, and focus only on the technical aspects of MEL.

If I think of others Iīll post īem later.

Later-
David

dwalden74
08-01-2003, 09:00 AM
...oh yeah, Iīd also like to know if you know of any techniques for automating/transferring facial setups among different characters.

-d

mark_wilkins
08-01-2003, 09:07 AM
Well, if it's a waste of space, I won't take it that far.

However, if I follow the pattern of the original book and have half the length be about the underlying concepts and half be example chapters, 250 pages is not that much, particularly because UI chapters are figure-heavy.

I think the tutorials will have a different feel to them that addresses what you're getting at. Part of this is my style vs. Chris's, part of this is that this book will definitely be aimed at someone who already knows some MEL, and part of it is that these topics don't particularly require too much discussion of extraneous workflow (though I don't want to leave steps out of, say, a rigging example, because that drives people nuts who are trying to work through it!)

Also, please be aware that I do not plan to discuss DreamWorks tools or processes, nor those of any other companies, as anything I know about is either covered by various nondisclosure agreements or could get people in trouble for having talked.


-- Mark

P.S. I've seen AMAZING things done with Maya's user interface, things I would not have imagined possible. I'm hoping that I can put together at least one example for this book that's a pale reflection of that.

mark_wilkins
08-01-2003, 09:51 AM
How about explaining the `match` command a little better than last time? (Iīm an idiot, I know.)


That discussion in the book wasn't meant to be a complete explanation of regular expressions, but a much more complete explanation might fit pretty well into a discussion of user interfaces because of how useful it is in input processing...

hmmmmmmmmmmm the only problem is that regular expressions are ALWAYS confusing, there's no way around it.

-- Mark

loked
08-01-2003, 01:39 PM
Hey Mark,

In terms of what dwalden74 was saying about Pixar and PDI stuff, it's understandable that there is disclosure agreements and I dont know if dwalden74 wanted u to take exact things from there or do things that are of a similar level. I personally would want maybe at the end of the book an advanced section, that shows how to setup something that is of Pixar level and not necessarily something you did for them or other's alike.

In terms of what you were saying about complex scripts and wanting to explain things bit by bit. I completely agree and I think you did a really good job of that in the first book. A huge script is really just a series of smaller and basic techniques combined. With that said, I think you pulled it off in the first book and anybody that needs that type of beginner stuff, can purchase the first book. For us that one more advanced stuff, I'd much prefer the second book to basically be less explanation and more technique. Maybe now take the crowd system and take it to another level, where you show how to develop crowd simulations that are more advanced and have more features.

I agree on the whole thing of UI's, there is only so much you can learn and then it's just about applying it and being creative in your layouts. I wouldnt want too much more on that.

Basically to be entirely honest, you are the expert and I'm sure you know what is advanced and what isn't. I would really just prefer a more advanced book with more content and less explanation. Not to say that, that was a problem in the first, cause it definitely served its purpose.

Thanks again!

later:wavey:
loked

loked
08-01-2003, 01:42 PM
Oh yeah one other thing and this applies to you and David. Whats with the funny covers you guys used. I almost thought I was buying a book on the history of Egypt. This time please put something with 0's and 1's :beer:

later:wavey:
loked

dwalden74
08-01-2003, 02:11 PM
I've seen AMAZING things done with Maya's user interface

OK, something amazing I might be interested in seeing... I just wouldnīt want to see space being wasted on setting up form layouts, or whatever...things that people can easily learn via Internet resources and other scripts... Most UI stuff is straight-forward like this and doesnīt require much explanation.

please be aware that I do not plan to discuss DreamWorks tools or processes

No...really?? ;)


this book will definitely be aimed at someone who already knows some MEL

Yeah, thatīs a good approach. Actually, you should assume that the reader has already read-and-digested your first book, and has since gone on to create his own scripts in the meanwhile. Therefore, assuming your reader has a solid knowledge of MEL is a great start.

I'd much prefer the second book to basically be less explanation and more technique

Here, here! Thatīs where I thought the first book lacked. You often seemed to be walking the reader through a Maya tutorial, and not specifically a MEL tutorial. By assuming your reader is a professional Maya user with a solid understanding of MEL, your second book could be much better. Not that your first book sucked or anything, actually it was quite good!

:beer:
David

dwalden74
08-01-2003, 05:38 PM
Another thing which would be cool to discuss, mark, is how Maya actually writes an Ascii file. How is data collected and described in the "*.ma" format? I ask this because I may need to write information to a file using the .ma syntax (but NOT a Maya .ma file), although Iīm not quite sure how to do this right now....

-david

mark_wilkins
08-01-2003, 05:39 PM
Hehe the Mayans were South American, but yeah. :D

Seriously, though, I hear just what you guys are getting at and will be paying your comments a lot of attention when trying to find the right balance for this project. Thanks for the comments!

BTW, here's a question that came up in a different forum: if the book cost an extra $10 when discounted through Amazon or Barnes and Noble, would it be worth it to get the examples and scene files on a CD rather than by download? (assuming that the correct URL were printed on the book, which should be corrected by the second printing of MSMA by the way :D)

As for the .ma file format... I'd love to go into that, but since it's considered highly undocumented by Alias I'd be concerned about providing more than pointers about how to read .ma files or something like that.

-- Mark

jschleifer
08-01-2003, 09:53 PM
Ahh.. a mel book made for people who know mel.. awesome!

Okay, as someone who's been writing mel for a reeeeeely long time, something which would make me buy this book:


A discussion on how to make your OWN maya interface for animation/rendering/etc.

Not just make windows and buttons and stuff like that.. but how to completely change what maya starts up with. Basically, discuss the best techniques/etc... how do you remove maya's calls for the interface w/out farkin everything up. :)

-jason

mark_wilkins
08-01-2003, 10:01 PM
Hehe Jason, I hope this doesn't turn out to be like Stephen Wolfram's book that he took seventeen years to write...

:D

-- Mark

jschleifer
08-01-2003, 10:04 PM
:)

yeah, cuz by then we'll all be using xsi.. :D

loked
08-01-2003, 11:33 PM
Jason, nice suggestion! Although, it would probably hold more value if you were actually somebody that knew something about mel:)

Mark, I'm sure you'll come up with great stuff to add to the book, so I'll put my trust in you:thumbsup: Oh yeah, also the $10 extra definitely would'nt suit me. I order from South Africa, so that $10 dollars works out to a lot in our currency and downloading stuff off the net really isnt a big deal. At least not for me.

Keep up the good work.

later:wavey:
loked

mark_wilkins
08-01-2003, 11:54 PM
Originally posted by dwalden74
Here, here! Thatīs where I thought the first book lacked. You often seemed to be walking the reader through a Maya tutorial, and not specifically a MEL tutorial.

There were a couple of reasons for this, but the biggest one is that the easiest way for someone who doesn't know scripting to get into it is to make the step-by-step connection from what they do know about how to work in Maya.

When someone works through a tutorial like some of our example chapters and says at each point "OK, I see where this step comes from" and then sees a discussion of how that action they took in the interface corresponds to a small chunk of MEL, it helps reinforce the connection (obvious to those of us with experience, but not to those who are new to it) that a MEL script is just a series of actions that in many cases could as well be done in the interface.

I anticipate that some of the character rigging material may have that quality as well, but probably not to the same extent as in the first book. The UI stuff probably won't, as there's no way to build user interfaces interactively in Maya.

-- Mark

Zappa
08-02-2003, 12:08 AM
[B]Hehe the Mayans were South American, but yeah. :D

HeY!Mark,
I thought Maya actually meant" Illusion" in Sanskrit and/or also used as the name for the godess of Illusion.

btw i got the first book and thought it was great, i still have much to go thru from the first book, so i wont even start about what i want from a second:D .
Cheers
zappa

mark_wilkins
08-02-2003, 12:21 AM
well, if anything the covers on those books were meant as a visual pun, not a serious commentary.

Hope you're enjoying the book!!

-- Mark

loked
08-02-2003, 12:29 AM
I was really just kidding about the covers, I didnt mean for it to become an actual topic:)

They say dont judge a book by it's cover and lets be honest now, if people really did, then you probably wouldn't have made any sales Mark :beer: Just kidding!!


Take it easy

later:wavey:
loked

mark_wilkins
08-02-2003, 12:49 AM
Well.... let's just say the cover was the least offensive of two alternatives we were offered. :D

I dunno, I think it's a nice picture. The book doesn't really stand out on the shelf at Barnes and Noble though... :D

-- Mark

mental
08-02-2003, 04:50 AM
heya Mark!

if you don't mind me asking: about when should the book be coming out?

i've got cash in one hand and i'm typing this post with the other! i'm ready to buy this book :)

i'm going through the first book at the moment and it is really helping me out. the prospect of a follow up book that covers user interfaces would be very welcome. infact your new book will prove to be indespensible for my first real mel project:

the maya calculator (http://www.cgtalk.com/showthread.php?s=&postid=745014)

-mental :surprised

mark_wilkins
08-02-2003, 04:54 AM
Hi Mental:

Put your cash away, at least for now. It will be a while. :D

-- Mark

dwalden74
08-05-2003, 04:02 PM
mark-

One last thing concering UI: you said that youīve seen some pretty amazing things done with the Maya UI. I donīt doubt that. Someone told me once that he had seen the Maya software even turned into an interactive TETRIS game. While that might be "cool", itīs not very practical. I wouldnīt recommend putting things in your book about UI that people wouldnīt actually use on a (normal) project. Showing just "amazing" things in this case would not be very beneficial to the reader, IMHO.

:beer:
David

mark_wilkins
08-05-2003, 04:57 PM
Well, look, I work in production every day, and I know what's likely to be useful, so please don't assume that I'm talking about a Maya UI Tetris game.

I have no idea how much of the really interesting stuff can be demonstrated in a reasonable book on the topic... covering the basics is very important too. I'm hoping to get a few good advanced examples in.

-- Mark

loked
08-05-2003, 05:34 PM
Mark: covering the basics is very important too. I'm hoping to get a few good advanced examples in.


Hey Mark, I dont really agree with this so much. I think you did a really good job of that in the first book. I understand that a basic explanation of what you are doing is required, but not to the point that it repeats any of the things you went over in the first book. Basically what I'm really getting at, is that it would be really dissapointing to have to read the same things again.

Like I said before, I'll put my trust in you:)

later:wavey:
loked

dwalden74
08-05-2003, 05:41 PM
please don't assume that I'm talking about a Maya UI Tetris game

Yeah, thatīs what I figured. Sounds good.


it would be really dissapointing to have to read the same things again

I donīt think heīs stupid enough to do that. :p


covering the basics is very important too. I'm hoping to get a few good advanced examples in.


Too bad, because I think many people out there are looking for more "advanced" and less "basics". If a person is smart enough to learn MEL on his own (or with the help of a book, for that matter), then heīs certainly smart enough to learn the basics on his own as well. I feel that this isnīt an area that requires much explanation, but thatīs just my own opinion.

:beer:
David

loked
08-05-2003, 05:47 PM
Originally posted by dwalden74



I donīt think heīs stupid enough to do that. :p




I dont think he's stupid enough to make Maya into a tetris game and charge you for that either :p

later:wavey:
loked

mark_wilkins
08-05-2003, 06:59 PM
Sorry, but I simply have to disagree that it's satisfactory to simply point the beginning MEL scripter at the documentation and say "have at it." All the information is in there, definitely, but it's spectactularly badly organized for the beginner. (Also, from what I hear, though I haven't had the chance to look myself, big chunks of it have been removed for Version 5, probably to be repurposed as a Learning Maya book.)

There are two audiences for Volume 2. One is the audience of beginners who are just coming off working through Volume 1 and want to do something more sophisticated, and one is the audience of more experienced MEL scripters for whom much of Volume 1 was a bit basic.

Whatever ends up going into Volume 2, it's going to try to give each of those audiences something, but I have to tell you, neither are going to have the book to themselves. The good news is that the advanced audience will probably be happier with the result.

A friend, who worked in technical publications at a technology company I won't mention, said once that their rule to maximize sales is to put basic material in the book and slap "advanced" on the cover. That seems a lot more crass to me than genuinely trying to offer something for both audiences, which is what I'm after.

-- Mark

P.S. I'm not stupid, period. :cool:

loked
08-05-2003, 07:08 PM
Hey Mark,

I think you've really hit the nail on the head. I think what you have just described is pretty much the ideal way to go about it.

I know it's still a while till this book comes out, but I really look forward to it.

Maybe it's not a bad idea, while writing the book to come on here and just ask for an opinion on some of the topics. That way you can get feedback as you work and it might help in constructing something more suited for the pro's themselves. It also leaves you having to make less assumptions. Just a suggestion :)

Take it easy

later:wavey:
loked

chips__
08-05-2003, 09:48 PM
Heya Mark

can't wait :D yepiiieeee

first of all, downloads are much cooler than cd's in my opinion!!!

some description of interfacing with perl and renderman would be more than averagely awesome!
also, like jason said, setting up your own interface... very nice idea.
another thing could be shading, and workflow (saving out animation files in your own format to use on a special rig etc.)
i don't know if this is suitable for a mel book, but i feel there's a need to explain some math stuff!! i always read all these sigraph pdf papers etc.. and most of it makes no sense at all, untill i spend hours in the library reading up on it etc.

daniloxl
08-07-2003, 04:09 PM
First thing and one of the most important I think are typing errors...I think you should pay big attention to avoid that problem as much as you can...Maybe that also depends on the publisher but in a book like this it's essencial...
I think your first book was exellent because it showed very good thinking workflow and explained some basic stuf very clearly...
One of my suggestions is a chapter where you could show some examples on how to simulate real world dynamics with .mel.Inspiration for this suggestion came from an interesting thread posted here where someone asks how to simulate rotor and stator behaviour in el.motor...It can always be interesting to read some math functions implemented in formulas that define laws of nature...for example how to write a script that will simulate gravity or magnetic fields between two objects depending on certain parametars...
Those are just some suggestions which can awake some ideas...
Good luck...

mark_wilkins
08-07-2003, 05:09 PM
First thing and one of the most important I think are typing errors...I think you should pay big attention to avoid that problem as much as you can...Maybe that also depends on the publisher but in a book like this it's essencial...

Yes, I hate them too. Let me give you an idea of what the process is like:

I produce a first draft, which contains all the text, rough figures, and code examples. This draft is distributed by e-mail to a number of technical reviewers who review the text for accuracy and submit suggestions.

Usually, these suggestions come back quickly enough for me to be able to incorporate them into the final draft, which I also prepare. Sometimes they come back after I've submitted a final draft.

Then, the publisher has the book copy edited. Copy editing consists of an editor reading the text and suggesting changes for clarity, fixing grammatical errors or typos, and enforcing consistency in the use of specialized terminology. Copy editing is done BY HAND, in pen, on a printed duplicate of the final draft.

Once the copy editing is finished, the actual hand-marked pages get sent to me to ensure that copy editing has not introduced errors. This is my last opportunity to make substantive changes to the text, and in some cases they may be extensive if I've gotten important but late feedback from technical reviewers. These changes, again, are generally made by hand, pen on paper, although I can insert additional typewritten pages if absolutely necessary.

Then, once that's returned, the editor looks over any changes I've made and then the book is laid out. The laid-out pages are then proofread, again marked up by hand by the proofreader, and I get the actual hand-marked pages for one last review before publication.

Note that all of these steps from the submission of the final draft to preparation of the final laid-out pages are by hand, not electronic, and rely on one person being able to read and understand another person's markings on the page. This presents lots of opportunities for error.

Also, many of the errors in our book were introduced in the process of laying the book out, because code had to be changed to fit within the book's page width given the font and design. In at least one instance we lost a line of code entirely at the bottom of a page. We generally had a day or two, maximum, to turn around our review of laid-out pages, so it was very difficult to go through everything as thoroughly as we would have liked.

Unfortunately, these kinds of things are virtually inevitable in this kind of book -- I've heard from reliable sources that MEL Scripting for Maya Animators is remarkably error-free for a first edition. (For some real horror stories on textual errors, told by someone who found them infuriating, check out the comments that J.R.R. Tolkien added to the second edition of The Lord of the Rings.)

As far as MEL Scripting for Maya Animators, our first line of defense has been to keep an up-to-date list of errata at http://www.melscripting.com/. Also, all of the errors that we were able to catch up until about mid-June are going to be corrected in the second printing. (Note that the second printing, now underway, is not the same as any future second edition, which will add new material, or Volume 2, which will be an entirely separate book.)

As far as MEL Scripting for Maya Animators, Volume 2 goes, I think that having been through that process once, I have some ideas about how to make it go more smoothly. Locking down code examples earlier would help quite a bit, and insisting on typing out changed code examples rather than hand-writing changes would probably make things easier too.

This book probably won't include much additional material on effects animation, but should the topic of a second edition of MEL Scripting for Maya Animators come up, I'll certainly think about how we can incorporate some of what you're suggesting.

-- Mark

trevlb
08-07-2003, 09:30 PM
i agree with jason, and loked about discussing low level UI customizing.

i'd love to be able to have versions of the UI optimized for specific areas of production.

gga
08-08-2003, 11:57 PM
I'd like to second that notion.

Having a book that goes deep into covering the structure of maya internal scripts for GUI customization would be a boon.

Albeit maya's scripts do change from version to version, so it could be a moving target.

Documentation on maya's GUI internals is absolutely atrocious (no list of global variables, no list of common functions, no list of conventions -if I see a function calling function X(), where do I know to find function X-, covering the use of TAGS to do the above, no suggestions on coding conventions, covering what are the limits on user customization --how much, say, the hypergraph can be changed, etc).

Somehow I think something like that would even be benefitial to Alias.

mark_wilkins
08-11-2003, 04:10 PM
OK so here's another question:

How much do you think it would upset people to have some or all of the screen shots be made with the OS X version of Maya?

Maybe this isn't such a great idea for the UI section of the book, but it's the version of Maya I'm using the most these days...

Perhaps trading off screen shots between Mac, Windows, and Linux would be cool too. :D

(Yeah, yeah, I know you guys are all running Windows, but I'm just askin')

-- Mark

loked
08-11-2003, 04:17 PM
How much of an extreme is there in the look??

I cant see it being so different to the point that you cant translate it to your OS. I would however definitely recommend going with one OS and sticking with it. If you see one thing on Linux and the next page its on Mac, it might get a bit confusing. Why dont you post some pics of all of them and let people decide that way :thumbsup:

later:wavey:
loked

chips__
08-11-2003, 04:19 PM
i think most people don't care to much which version of maya it is? isn't it just a question of round or square buttons? and colors? :D :wip:
Is there any difference i don't know about?

oh, and mark, how is osX and maya working? is it as fast as on a pc?

mark_wilkins
08-11-2003, 05:11 PM
oh, and mark, how is osX and maya working? is it as fast as on a pc?

Not on my 800 MHz Powerbook, but my dual 2 GHz G5 is coming at the end of the month and I'm looking forward to doing some real testing then!

Anyway, on my laptop it's not as fast as on a high-end PC (or even my 1.4 GHz Athlon) but it's very usable and since my workspace is much more set up around the Mac than the PC I like using it on that system more.

-- Mark

chips__
08-11-2003, 05:16 PM
i look forward to seeing some comparisons!!! i really want a G5 ... just have to justify it somehow :scream:

trevlb
08-11-2003, 08:59 PM
in all the screenshots i've seen, the actual maya interface doesn't look that different from os to os. if that is the case, i say use whatever.

has anyone seen anything different?

jschleifer
08-11-2003, 09:49 PM
I did my first dvd on pc, & the second on mac.. I found using the mac MUCH easier to do screenshots on.. and they looked so much better. :) there's this great auto-drop-shadow tool you can use which will just capture things in such a nice way..

ahh..

not that it's hard to do screen captures on pc, but when you're doing 800 billion of 'em.. saving one mouse click is brilliant. :)

-jason

chips__
08-11-2003, 10:03 PM
@Jason, is there any other reasons for using a mac? besides the fact that they are much cooler to look at?
ok, sorry, no more mac talk in Marks thread :D

jschleifer
08-11-2003, 10:06 PM
oh yeah, lots of reasons.

well there's...

and then there's..


well I like it 'cuz...



hmm.

nah, just emotional love. :)

mark_wilkins
08-11-2003, 10:31 PM
Because the Power Mac G5 is the fastest personal computer (http://www.apple.com/powermac/) and the first 64-bit personal computer (http://www.apple.com/powermac/)!!!

:D (Just kidding, but it IS fast and it IS 64-bit, and mine's coming!!!) :D

-- Mark

dstripinis
08-12-2003, 05:43 AM
Wanna know what's really, really amusing?

I'm a Mac person too. ( my G5 is on the way too! ).

So Jay, Mark and I are all Mac people.

hmm.

Wonder what that says about the people who think the Mac aint for real artists.

If you're looking for killer mac capturing:

http://www.ambrosiasw.com/utilities/snapzprox/

Azrael
09-05-2003, 05:47 PM
I might be alone in this request, but how about a selection of toolsets for different tasks?
By this I mean say if you were working on say something like environments. Instead of writing a tool that did everything, not that I'm suggesting that anyone would, if you took an overview of the tasks that you were going to do, then create different scripts that complemented eachother really well, simplifying the processes yet keeping a lot of flexibility.
For environments you might make a script that did mountain geometry, then a script that took the geometry data from that to generate displacement maps, bump maps and colour maps etc based on that. Then for things that are closer you might need more detail and different types of objects but you'd still want to marry the two so they blend in well with background so with a good structure the scripts could talk to eachother. Other things like a random rock generator should take into account the level of ground, not wind up inside trees, grass should fold around rocks etc.

Now this may be a bit over the top and unpractical, but my point is basically an exercise in creating well organised working environments that are as flexible and interchangable as possible. I think with a good structure that you use throughout your scripts you can gain a lot by sharing data etc.

Is this all just meaningless rambling?

SaucyJack
09-05-2003, 09:10 PM
Hey Mark

Just a few suggestions from a MEL newbie. One thing which i think would be really useful would be an apendix which covers some basic and advanced mathematics that is applicable to scripting(expressions and particle stuff). When working through your book and Davids i kept finding snippets of mathematical knowledge here and there rather than in one place which i could refer back to. (The vector stuff for example).

Putting this stuff in an appendix would be an enormous help as the fear of mathematics puts a lot of people off. I know all of this information is available in countless other books but they never include where this is applicable. This is also one of my main gripes with Math teachers at school. They gave you loads of info to remember but no practical use for it. Just cold useless facts.

One more thing, stick with the Mayan theme for the covers. Perhaps something a bit more green and jungly this time. Not enough jungly green covers for CG books IMHO.

Lata

:thumbsup:

wilson81
10-01-2003, 06:02 PM
wow, this really dropped back. on the last page

anywho

i would like to suggest a section on useing mel and/or expressions along with shaders. maybe even just an example section.

just my 2 cents

btw, reading your first book now, you rock
:buttrock:

:)

dunkel3d
10-02-2003, 06:39 AM
How about a section on mel scripts written by animators who bought the first volume.

S

wilson81
10-02-2003, 08:37 AM
yeah, that could be cool, like a contributed section....:beer:

zachgrachan
10-02-2003, 08:25 PM
I'd send some of mine in...the first book is really helping me out. I got david's first, but it just didn't work for me too well. Plus, I'm not ready to work with the api just yet...

I agree that covering some of the math would be awesome. I have math books, I have programming books, I have maya books, but it sure would be nice to have one book that has the relevant peices of all of 'em.

MikeRhone
10-02-2003, 08:48 PM
Im glad to see that there will be a second book in the series! I have the first one open on my desk as I type. I've only given it a good look over the last 3 or 4 days, but I have my first script done. I know its probably messy and there are a million ways to make it faster and better, but it works!

I'll be buying the second one as soon as its released. Im glad to see there will be a stronger focus on rigging and UI building, as that is the area I am most interested in. The first book has a lot lot on particle expressions, which isn't an area I'm particularly interested in.

Um... no suggestions for the book so far though.... except maybe explain that a ` isnt the same as a '. That was killing me for the longest time...

Mike R

Edit: For those of you that wanted to see a script from people who bought the first book, check out my thread here. (http://www.cgtalk.com/showthread.php?s=&threadid=92170)

verbal007
09-15-2005, 07:59 PM
MEL's flavor of regular expressions really needs to be covered in detail. It's too powerful to just be ignored or labeled "outside the scope of this book". Maybe discuss the differences between PERL's regEx from MEL's. Or... are there just no details to cover? Is it just me, or does MEL's regEx just... well... blow?

- Jeremy

P.S. Mastering Regular Expressions is a GREAT book on RegEx.

EigenPuff
09-16-2005, 01:12 AM
I might not count, since I am a programmer and not an animator ...

I would like to see some good UI stuff as well (all the programmer books cover MEL UI in less than a chapter - not enough depth to do all the crazy programmer stuff that the artists here demand *grumble*). I'll have to look into the first book for specific ideas of what to include (or exclude) from the second, but regardless of that, what I would really, really love if _anybody_ anywhere were to do is to pay some lip service to how things can go wrong and why and what to do to fix them. Most of the time that I am sticking my nose into a tutorial/reference/handbook is I am trying to find subtle clues as to why my thing doesn't work the way it should.

I am not suggesting that you have an errata chapter at the end or anything, but say, when introducing a topic, "and this how we use this amazing function, which incidently can go horribly wrong if used in combination with this widget" or "and that's all I have to say about control X, except to say that flags y & z are mutually exclusive and if you try to use them together on control X, then they will conspire together to kill your first born child in holy vengeance". Kudos if you can work in _why_ things don't work the way they should.

I realize that it might not be entirely practical to sell a book, but I can dream ...

bdeda
10-01-2005, 09:56 PM
Hey Mark, can you give us an update on the status of Volume 2? this thread has aged quite a bit, so I'm not sure if suggestions are still appropriate, but anyway...

I would like to see more about integrating a mel environment with an external program/script. How about being able to get the number of maya files with a reference to a certain character file from a mel interface, using a perl script to parse .ma's, for example, or tie in with an SQL database, or a spreadsheet... Or maybe just the execution of an exe from a mel UI button... How about launching Photoshop to edit an image? I really want to see more that would tie the maya environment with external programs.

Also, since specific examples of scripts companies like PDI or Pixar use in their workflow, how about just an overview of some of the ways mel scripting has been advantagous in expanding the commercial product to accommodate a more personalized production environment would be useful. I'd be interested in the corporate expectations of the duties of a professional mel scripter as well.

By the way, I loved both your and David Gould's books, and I look forward to reading any future books the two of you will write. It's good to see that the two of you are communicating about potential content as well.

CGTalk Moderation
10-01-2005, 09:56 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.