Maya Mash a Mograph for Maya

[Bullit]

http://marquee.by/mash/

http://forums.cgsociety.org/showthread.php?f=59&t=1076310


See how clear language and clear propose helps a nodal system?

[luceric]

See how clear language and clear propose helps a nodal system?

can you clarify with a bit more info, what conversation is this part of?

[oktawu]

Been using it for a couple of days and i really like what they've done...
Maya was sorely missing a friendly way of creating these effects (even in the year of the lord 2012 one has to still write expressions for controlling particle goals),
so this was much needed. We also have had SOUP for some time now, which to me should have been done by alias/autodesk long ago (apparently autodesk has been in touch
with Peter for some time). Coupling all this with a theoretical port of ice and you have yourself a winning combination for the maya userbase.
But everything mash does can currently be done with ice. Maybe not as elegantly or artist friendly, but possible.

Cheers

[EricTRocks]

Been using it for a couple of days and i really like what they've done...
Maybe not as elegantly or artist friendly, but possible.

Why not? It can be done as long as the workflow and tools are built in that way.

[Butachan]

I think pretty much everything i saw in the examples can be done with ICE out of the box. And rather simply. Except maybe for the spring animation system, that is something it has eluded me for quite sometime.

[Bullit]

can you clarify with a bit more info, what conversation is this part of?

It is my long grip with ICE. In that mash webpage there are simple language concepts that have a propose that is clear. That language advantage makes the system more accessible to common users and easier to learn.

Of course only if the application is reliable with predictable results and the interface is well thought, i don't know if it is the case but from oktawu words it seems so.

But everything mash does can currently be done with ice. Maybe not as elegantly or artist friendly, but possible.

I would be surprised if ICE couldn't do much more than mash even restricting to the mash subject.

[luceric]

it's nice to have few well defined nodes, but then you have to use them with the rest of the nodes in the Maya DG. Nodes with sometimes dozen connections, loops, hidden connections, etc. So it's no better than having made ICE compound in ICE. But you can't make compounds in the Maya DG, you need to code them in C++. As soon as you get nodes in general, imho, the artist friendliness is relative...

[Letterbox]

can you clarify with a bit more info, what conversation is this part of?

It is my long grip with ICE...
I would be surprised if ICE couldn't do much more than mash even restricting to the mash subject.

The first implies, and I agree ICE is more for TD's, even thought in 2011 they did try to make it more friendly, i think all those simulation roots made it more complex.

But the solution is nearly there for artists, take the emit from surface, that's a great example of how a non ice person can use ICE, the only issue that i can see missing, is that to connect a curve you have to go into the ice tree, it should have been a text field with a pick button in the ppg itself. Then ice connections, like curves, nulls, geo, anyone not interested in ICE would not have to even look at an ice tree if the compound developer had that specific capability. (maybe they put it in? If they haven't I like to hope AD can see the benefit.)

Absolutely on point two, as well I have no doubt it could be way more than mash, and you have to give credit to those people who spent their time and money developing it, and then decided to share it. Well done to them.



As for Springs, from Hooke's law F=-kx. Where K is how stiff the spring is, and F is the force. X is the distance moved (which is what you want to solve for) A force has both magnitude and direction (ie vector). Wikipedia for Hooke's law.

So you could take the point position globally, eg on a specific frame, or on an emit, then subtract the current point position, that would give you a length, a distance, , so one could connect that length into the drag (what is what a spring does) node, and you would have a simplistic Spring node. Similarly you could use the Mass of the particle from the initial emit and it's size to get other necessary info.

(tip. Always look at the units, Force = Newtons (also Kg m/s^2) from Newtons equation f=mass*acceleration. (acceleration m/s^2 is the rate of change of velocity m/s = emit speed?)

Hope that helps you.
( this explains the relationship with time, distance, velocity and acceleration quite nicely, as here doesn't let me input math symbols) http://www.quora.com/Mathematics/Whats- ... ent/961854

[Bullit]

My problem is not nodes.
It is the language and also how much a node can do.

For example there are the emit node and the emit blast node.... both of them have options that are helpful but are present in one and missing in the other. Why is that? It should be:

Option A: only one node to emit particles and make the blast, an emit Übernode.
Option B: or a node called blast to add to the emit particles node and all options will be available with both nodes because they could be put in same ice tree.

This both options are the logical way for a nodal system to work. If the emit Übernode is too heavy or complex then should be choose the option B.
As is it now it is the worse way to be.

[Butachan]

Thanks for the idea for a spring system. But my point was that pretty much everything in the examples can be done with ICE out of the box without any TD knowledge. As for the nomenclature, or language as it was mentioned here, the reality is that ICE not only is great but set a new standard for this kinds of tools. You can use the specific compounds or dig into the basic nodes. You can achieve as much as your skills allows or stay in the simple tasks. A language that is "easy to understand" is far more subjective that you may realize. The nomenclature in ICE is as it should be, a vector is a vector, velocity is velocity and position is position, and if you don't know what is a matrix, you should probably not be using it because that node was probably not meant for you. But the beauty of ICE is that if you want you can learn more, dig more, and do more.
Said that, I do think that there should be an appropiate channel to distribute compounds that will safe time.

[bottleofram]

My problem is not nodes.
It is the language and also how much a node can do.

For example there are the emit node and the emit blast node.... both of them have options that are helpful but are present in one and missing in the other. Why is that? It should be:

Option A: only one node to emit particles and make the blast, an emit Übernode.
Option B: or a node called blast to add to the emit particles node and all options will be available with both nodes because they could be put in same ice tree.

This both options are the logical way for a nodal system to work. If the emit Übernode is too heavy or complex then should be choose the option B.
As is it now it is the worse way to be.

Well, your gripe seems to be with compounds, not ICE itself. Although, you could argue compounds are part of ICE, i think it would be useful to differentiate between basic building blocks and compounded structures. The nice thing is, nothing stops you from rebuilding/rearranging those compounds the way you like. In-depth knowledge of ICE programing language is required, but at least it's completely nodal.

From what i see, Mash is very similar to Gustavo's Motion Tools. It streamlines procedures for building otherwise complex and/or time-demanding tasks. Clear language comes from the specialized use. The more abstract it gets, the harder to please everybody.

Speaking of third party efforts, i really like what Eric Mootz is doing with emTopolizer and the whole operator-stack-on-the-main-compound paradigm. It simplifies the way you add effects and the way you need to think about the whole setup, but it doesn't sacrifice the nodal goodness of ICE. I believe this is much better approach than putting everything into buttons and menus and such unintuitive one-click solutions...

[Bullit]

i think it would be useful to differentiate between basic building blocks and compounded structures.

Precisely. Two languages. One operative to achieve effects another with all granularity, this could be presented with 2 tabs in ICE explorer.
Of course there might be some building blocks that need to be in both place since they can be effective enough for use as they are.

The nice thing is, nothing stops you from rebuilding/rearranging those compounds the way you like.

Correct, but the way it is prevents ICE widespread acceptance.

[nuverian]

Mash look certainly good.
By the way. I am afraid that even showing a 3D model in this forum will result in replies like "nice, but this can be done with ICE".
And while it is true that a 3D model can be done with ICE..will you do it?
You get my point.

[gustavoeb]

Lol... you have a point neuverian, but the alternative to doing something like Mash without ICE would be C++.

[CiaranM]

And while it is true that a 3D model can be done with ICE..will you do it?

Sure. Will you pay me?

[nuverian]

And while it is true that a 3D model can be done with ICE..will you do it?

Sure. Will you pay me?

Frankly, no. Cause I can pay another much less than you would ask to do it in ICE and he will do it faster (since Im in a hurry you see), with more dedicated modeling tools that exist for the specific task. Thanks for the offer though.

--edit: while sarcastic dont take it offensively