PDA

View Full Version : Collisions influencing an input attract of 1 on nCloth


rulling
01-12-2012, 02:58 AM
so I have an nCloth shirt wrapped to a body (which is a passive collider), I flooded the shirt with an input attract of 1 which I thought should disable all dynamics on the nCloth allowing the wrap to work.

but I still see vertices still moving and the cloth deforming in certain areas, why is this? and how can I localize the dynamics and yet still have them not influence such tight regions as the armpit (where both collisions and self-collisions apply to the whole cloth animation).

Thank you!

john_homer
01-12-2012, 08:35 AM
increase it to 1.5 (its not a 0-1 range value)

and paint collideStrength to 0 in areas you dont want to collide

although i would never actually use inputMeshAttract for a shirt, if you want it to just be wrapped, save yourself time and wrap it :)

inputMeshAttract is more useful for non-cloth type stuff and special (ie partially animated/manipulated) shots

.j

rulling
01-12-2012, 09:40 AM
increase it to 1.5 (its not a 0-1 range value)

and paint collideStrength to 0 in areas you dont want to collide

although i would never actually use inputMeshAttract for a shirt, if you want it to just be wrapped, save yourself time and wrap it :)

inputMeshAttract is more useful for non-cloth type stuff and special (ie partially animated/manipulated) shots

.j

thank you, input attract values around 2-3 worked best for my cloth. Is there a value that would be considered excessive? and I can enter it in the attribute editor, but it's not possible to paint this value (3.0) on is it?

small sections of the shirt are dynamic, the animator also wanted nCloth and I thought it good practice ;)

I presume that with the nCloth mostly wrapped, I have to use Geometry Cache? (nCache didn't appear to do anything)

much obliged! :thumbsup:

john_homer
01-12-2012, 05:07 PM
thank you, input attract values around 2-3 worked best for my cloth. Is there a value that would be considered excessive? and I can enter it in the attribute editor, but it's not possible to paint this value (3.0) on is it?

small sections of the shirt are dynamic, the animator also wanted nCloth and I thought it good practice ;)

I presume that with the nCloth mostly wrapped, I have to use Geometry Cache? (nCache didn't appear to do anything)

much obliged! :thumbsup:

values above 1.5 shouldnt change much... unless maybe you have low substeps so your sole is n't doing what it should.
I would never use substeps less than 20

you should never paint maps out of the 0-1 range.
paint map in the 0-1 range and set the inputMeshAttract to 1.5 (or 3 if you like)

I dont really understand your cache question. but you will want to cache the cloth with nCache when you sim it. then geoCache the hero geo if you like...

.j

Duncan
01-12-2012, 07:34 PM
John knows what he's talking about. With input attract the number of iterations is proportional to inputAttract ^ 5 (the fifth power). The amount of computation is fixed for values less than 1.0, but when you make it 2 it will do 2*2*2*2*2 more calculations than for 1.0. Generally 1.5 should be enough to lock the motion if you have enough substeps. Values like 20 will just be needlessly slow.

rulling
01-13-2012, 03:58 AM
values above 1.5 shouldnt change much... unless maybe you have low substeps so your sole is n't doing what it should.
I would never use substeps less than 20

you should never paint maps out of the 0-1 range.
paint map in the 0-1 range and set the inputMeshAttract to 1.5 (or 3 if you like)

I dont really understand your cache question. but you will want to cache the cloth with nCache when you sim it. then geoCache the hero geo if you like...

.j


You are both sages ;) , thank you for elaborating further on this...

so I set my nCloth `Input Mesh Attract` to 1.5, flooded the mesh with an `Input Attract' value of 1.0, configured my nucleus to a substep/maxCollisionIterations of 30 and 45 respectively; as a test to see if I could follow the wrap precisely. But I still see movement in the armpits (and crumpling elsewhere), I presume collisions are a separate input calculated after the wrap? and the only way to remove this dynamics is to paint it away? and how do I keyframe both values ('Input Attract' and 'Collision Strength'), the 'Input Attract Map' and 'Collide Strength Map' are greyed out once I start painting and keying the "per-vertex" doesn't appear to work?


concerning the nCache, when I go to create a new nCache by selecting the mesh it shows a "Calculating..." message in the status line with no feed back shown on the timeline (...peculiar?). I went for a coffee to give it some time, when I returned it completed with a cache node enabled and both an *.mc and *.xml file present in the data folder. Scrubbing through the scene tho still results in a "Warning: Nucleus evaluation skipped, frame change too large" and it doesn't appear as anything was cached, what could be the reason?

btw, I'm using a ratio of 1:1.5 for 'Substep' to 'Max Collision Iterations'...is this proper? and what would a proportional 'Max Self Collide Iteration' value be?

my apologies for all the questions, but you have my gratitude.

djx
01-13-2012, 11:02 AM
rulling, just in case you have not already read it, here's my favourite nucleus link (http://images.autodesk.com/adsk/files/autodeskmaya_nucleus_whitepaper.pdf).

John, you suggest not painting outside the 0-1 range. I value you opinion so I wanted to understand your reasoning. It is possible to paint any value range and I've been doing this for collision thickness where I found it easier to set the base attribute to 1 and then paint exact values. Is this going to cause problems do you think?

thanks
David

john_homer
01-13-2012, 01:08 PM
... But I still see movement in the armpits (and crumpling elsewhere), I presume collisions are a separate input calculated after the wrap?
well, there is no "wrap" function, you entire mesh is cloth. so you need to manage it
with a high inPutMesh attract, you will need to set the "collideLastThreshold" to 1 so it does the collisions afterwards to get correct collisions. this is new in maya2012 (I think)


and the only way to remove this dynamics is to paint it away?

no, there is no way to remove dynamics, you can only "paint away" attributes on the cloth, so it doesnt try and move

and how do I keyframe both values ('Input Attract' and 'Collision Strength'), the 'Input Attract Map' and 'Collide Strength Map' are greyed out once I start painting and keying the "per-vertex" doesn't appear to work?

key the value, not the map
I believe there are plugins (soup) to use animated per Vertex maps. I have never had the need


concerning the nCache, when I go to create a new nCache by selecting the mesh it shows a "Calculating..." message in the status line with no feed back shown on the timeline (...peculiar?). I went for a coffee to give it some time, when I returned it completed with a cache node enabled and both an *.mc and *.xml file present in the data folder. Scrubbing through the scene tho still results in a "Warning: Nucleus evaluation skipped, frame change too large" and it doesn't appear as anything was cached, what could be the reason?

hmm, hard to say...
try removing all caches by selecting all the cloth, and from one of the nCloth menues, deleteCache.
then run this to be sure
delete `ls -type cacheFile`;
then select cloth and cache again, making sure your timeline and nucleus startFrame are correct


btw, I'm using a ratio of 1:1.5 for 'Substep' to 'Max Collision Iterations'...is this proper? and what would a proportional 'Max Self Collide Iteration' value be?
.
it depends, for 24 fps solves I prefer them the same 30 or 40
but for 48 fps, halving the substeps to 20 solves the same as 40 @ 24fps(as its the same substeps per timeStep) but you need to increase MaxCollisionIters if you have lots of layered cloth.. so I like 20/40
It depends on what you are solving etc


John, you suggest not painting outside the 0-1 range. I value you opinion so I wanted to understand your reasoning. It is possible to paint any value range and I've been doing this for collision thickness where I found it easier to set the base attribute to 1 and then paint exact values. Is this going to cause problems do you think?

yes, duncan will correct me if this has changed since we spoke about it a while ago...
but last I checked..
you will actually get different results with:
value of 1, flood paint 10
vs
value of 10, flood paint 1

I know this sounds wrong, but its kind of right because the value (in most cases) are the number of iterations, the painted value is the "weight"
so, for example, if you have a stretchResistance of 100 and flood to 0.1, it does 100 iterations with a weighting of 0.1
hopefully that makes sense
I would especially avoid it with thickness, as there is currently 1 bug related to painted thickness which you could hit, and I've seen this decrease sim times by 10X (I think, I'm out of the country so dont have access to maya)

djx
01-13-2012, 01:17 PM
I know this sounds wrong, but its kind of right because the value (in most cases) are the number of iterations, the painted value is the "weight"
so, for example, if you have a stretchResistance of 100 and flood to 0.1, it does 100 iterations with a weighting of 0.1
hopefully that makes sense
I would especially avoid it with thickness, as there is currently 1 bug related to painted thickness which you could hit, and I've seen this decrease sim times by 10X
This whole thread has been very informative, but the above advice in particular will help a great deal with my current project. I appreciate you taking the time to explain it.

David

john_homer
01-13-2012, 03:14 PM
Generally 1.5 should be enough to lock the motion if you have enough substeps. Values like 20 will just be needlessly slow.

another thing to note here is that if you want to paint off the effect, it will be difficult/annoying with unnecessarily high inPutMeshAttract values, for example, with a value of 20, what would you paint the map Value for a "half" effect?
0.5 would give you a resulting inPutMeshAttract of 10 (20*0.5), so would still fully follow.
if you use 1.5 and paint 0.5 you would get 0.75 which would result in some dynamic motion.


... and what would a proportional 'Max Self Collide Iteration' value be?


just noticed I missed this part of the question.
its a little more difficult to answer as its dependent on your motion/substeps and cloth settings...
generally you wont need to change them, because, even though they are very low by default, like the solver maxCollisionItterations, they are at least that of the substeps, that is to say...
there will always be one per substep
If you have 40 substeps, you have 40 maxCollisionItters, unless you set it higher
If you have 40 substeps, you have 40 selfMaxCollisionItters, unless you set it higher

if your substeps are sufficient, the only time you will need to increase MaxSelfCollisionItters is if you have high stretch/compression resistance.
yeah, that sounds odd.. but again makes sense when you consider the iterations you are asking maya to calculate at.
maya uses an interleaved solve, you can read about this by googling the nucleus whitePaper (http://bit.ly/wastVT)
here is my description.. ;)

with low stretch/compression values... maya solves like this (very simplified)...
stretch/compression/collision/stretch/compression/collision/stretch/compression/collision/

thats a sweet solve, every time it sims stretch and compression it checks collisions!!

with high stretch/compression values... maya solves like this (very simplified)...
stretch/compression/stretch/compression/stretch/compression/collision/

that cloth could be anywhere before it had a chance to check collisions!!

Duncan
01-13-2012, 11:01 PM
Just to add to what John said... the substeps are relatively more expensive than doing a stretch iterations as they involve computing the bounding trees for objects( among other things). Every element will iterate at LEAST at the substep level, thus if the substeps are high enough everything will compute one iteration each substep. However this is slow and generally not practical. For stretch it helps if the substeps are no less than about 1/10th of the stretch resistance value( assuming the scaling relation is set to "link" ).

As a rule of thumb.... the faster the dynamics motion the higher the required value for substeps (and stretch/compression/bend resistance, as well as constraint strength). To make things more efficient you can animate substeps to be greater when things move quickly. We break time into discreet slices for computer graphics. If you go faster through time you will need more slices, thus increasing speed means more iterations. The behavior of matter at a small scale is much like at a large scale, only faster, thus it is like a fast forward version and needs more substeps. It is a bit counter intuitive in that a large scale object like a giant sail would need fewer substeps than a tiny one because the relative motion is much slower at the large scale. We tend to think that bigger things need more resources.

rulling
01-16-2012, 09:58 AM
amazing replies, John and Duncan your input has been highly appreciated :beer: . I read through the whitepaper today (thanks djx!), will let it digest and run some tests and reply back with the results of my new found knowledge :)

CGTalk Moderation
01-16-2012, 09:58 AM
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.