Strange things happen in extrude surface...?!?

[rentallmay]

hi all,

please try this:
in top view or side view create a square path curve with the curve tool. Curve settings set to degree1.

Don

[joojaa]

What you are encoumtering is a slight limitation of eulerian math so what happens is the curve

[rentallmay]

hi,
thanks for the quick answer.
when you say this is a limitation of eulerian maths, do you mean that is a problem that occurs in other 3d apps too or is this something that Maya can

[joojaa]

Yes its a limitation to how nurbs work on a mathematical levell! not maya spesific issue. Beziers will have similliar problems but different apps behave a bit differently for example some apps automaticay adjust the xyz cordinates on the fly... theres a drawback to this however wich is that debugging this becomes a pain.

but as I said theres 3 mothods for coping with the problem. Just in maya you will have to do it automaticaly. wich is good for the levell of contoll i usually need. because then i know whats going on!

[campbell]

In reply to: but you can avoid this by using a curve on suface bcause its norma li defined.

just been looking at this, and i dont get how crvs on surface can help out here? i can see how they are handy for inflectional flipping on motion paths, but this isnt the problem here? why does the profile distort like it does, rather than just some bung orientation? i just cant see whats really going on, would you be kind enough to explain this phenomenon in a little more detail?

[joojaa]

Ok then it might be a interpolation issue. It related to how the surface are built. It works like lofting multiple shapes along the path. So that each span is exactly like the curve. But now in the corner the shape is at 45 angle now if you draw a straight curve from each point in the shape (wich is how this nurbs object is now built bacsuse you told maya do do it like this) you get a slanted shape. So you need to set a fev extra steps at strategic locations.

Also bulge in middle is because the curve starts at a 0 degree angle wich isnt slanted like the corner shape is!

[campbell]

i dont think thats it ...im just noticing now that it appears to be depedent on the first two CVs of the path, and whether they're coplanar in world XZ and not XY (not sharing XZ presents as half the result of a shared XY.). the extent to which this distortion behaviour is a problem changes across situations. i dont know whether to consider this a bug or not? it sure doesnt give you what you expect when constructing certain things (OPoster's eg for 1). sure, easy to fix, but it takes the user time to sit back and WTF the situation and tease out what the issue is, and a remedy.... is this yet another piece of bad dev? i still dont know whats going on here...

[joojaa]

No i think its more in line with how the tool works as opposed to the way poeple expect it to work!

send me a detailed picture!

alos theres on slight thing here too if you extrude periodic then the result isnt periodc wich means it would get a few axtra ponts at the start place.

PS aslo im noticing that theyve in fact might have done some changes in maya 5... gotta investigate.

[campbell]

i think mulder's example is perfectly illustrative ...
draw a linear square, centred on world, starting in - Z, and ending there, extrude a circle around it. its naf. grab the second cv, budge it a tad in Z. its clean. budge same cv a tad in Y. its naf, but only 'half as much' (one dimension). ZY is involved too - they're all in on it i tells ya! certain combinations are required to see the effects of a certain plane, eg scew on ZX&XY but planar on ZY is naf (a hlaf state) .... but if ZX is planar, ZY has no effect.

interesting if this sorted in 5.0 ... its a pitty we cant see the bug list, whats slated to be fixed, and a comprehensive bug fix list (What's Fixed in Maya x, surely isnt the lot!).

[joojaa]

I still claim this is no bug but rather a unfortunate side effect of the way aextrude tool is supposed to work versus how people suppose it to work! Send me a file and i can se the problem more clearly.

[campbell]

you may well be right (tho i wonder where the description of a tool starts and ends), but its unfortunate that the engineers didnt see this unfortunateness as something to point out to their users.... no mention anywhere of this issue. if it is indeed an unredeemable quirk of the such a tool's implementation, i can handle that, but in such a case this needs to be documented in the tool's description.

ok, so a scene of the above example... grab the annotated handle to shift the second CV around and get feed back on which World planes they share. there is animation on that handle, so step through the keyframes to see some of the examples i've mentioned, but just play to see the results for yourself.

extrudeQuirk.ma

[joojaa]

Well yes i just wanted the file from you because i wanted to get the exact same behaivour as you do.

But the honest underlying fact is that the computer cant account for things you think should happen. And the eingeneer cant either. The reason for this is that while peple often asume one thing in a certain situation they asume another in another situation (and from the computers standpoint there can only be one explicit way to do things rest is up to you). A tool offcourse has no way of knowing wich contigency is at hand at given moments. And neither can the eingeneer.

For example if you choose a spanning that will cause problems the tool will do it for you with seemingly incorrect results. Ok now if the eingeneers would take this into account then what happens wen you want to controll this yourself? Or are you at the mercy of how its done? more switches? big questions.

Ill look into this. As soon as i can.

[campbell]

i totally understand what youre saying, and couldnt agree more it!. im all for leaving things as open, core and bare boned as possible - w/o any frilly bits that supposedly make tasks easier (which can end up running counter-productive, like you mentioned firstly). im _not_ saying they should write tools that magically handle the infinitudes of obscure situations we dream up for their use, acting just as we dreamnt they should.

im just questioning the basic dev pipeline, and how they test their tools before they ship. im talking about developing a tool on a suite of _generic examples_ that it is most likely to encounter (not every human contingency!, but foreseeables such as this one), and ensuring the tool acts consistently, as expected (not by somebody just sitting down and going "work!", but by a user who has spent enough time with tool to have reasonable expectations of its behaviour). i think this is basal criteria for a good tool. in the event your developing tool diverges from this, you either rethink a more robust implementation, or if the implementation is sound but for a few quirks (nothing wrong with that, special cases are in the nature of maths), thats fine, _but you point it out to the user_ (you dont even have to explain why, but at least note it!!).

playing w soft and max, they appear to go for the 'animated sweep' approach - so they get that bulging the way you thought maya would. im having no problem w periodicity being preserved here (4.5).

im glad you ask for the file, its good to make sure we're talking about the same thing (or at least head closer to!). interested to hear what you figure out, as always! be nice to sort out whats really going on. anybody else got some ideas?

cheers.