I'm going to go out on a limb and say that MScriptUtil is the not
greatest thing in history of Maya.
here is an example in 2011
select -r nurbsSphere1.cv[4][0] ;
import maya.OpenMaya as openMaya
sel=openMaya.MSelectionList()
openMaya.MGlobal().getActiveSelectionList(sel)
path=openMaya.MDagPath()
obj=openMaya.MObject()
sel.getDagPath(0, path, obj)
compItr = openMaya.MItSurfaceCV(path, obj)
while not compItr.isDone():
u = openMaya.MScriptUtil()
v = openMaya.MScriptUtil()
compItr.getIndex(u.asIntPtr(), v.asIntPtr())
print openMaya.MScriptUtil().getInt(u.asIntPtr())
print openMaya.MScriptUtil().getInt(v.asIntPtr())
compItr.next()
123221088
123112400
I'm really liking these values it kicks back out.
Maybe some weird maya bug?
On May 13, 4:55 pm, Adam Mechtley <[email protected]> wrote:
> To clarify: the change is only in the docs, not in the behavior. As far as I
> know it is how they've always worked.
>
> The example works for me in both 8.5 and 2011 on OSX, so I assume it also
> works for everything in between. Because this is not the recommended usage,
> however, this may be one of those cases where it's not guaranteed to work
> unless you first initialize with the proper type of value and then create a
> separate pointer object.
>
> On Thu, May 13, 2010 at 4:50 PM, Brandon Harris <[email protected]>wrote:
>
> > Is this change mainly for 2011? Because if I run the example that I
> > put up in 2009-x64 on linux, here is what I get.
>
> > select -r nurbsSphere1.cv[4][7] ;
> > import maya.OpenMaya as openMaya
> > sel=openMaya.MSelectionList()
> > openMaya.MGlobal().getActiveSelectionList(sel)
> > path=openMaya.MDagPath()
> > obj=openMaya.MObject()
> > sel.getDagPath(0, path, obj)
> > compItr = openMaya.MItSurfaceCV(path, obj)
> > while not compItr.isDone():
> > u = openMaya.MScriptUtil()
> > v = openMaya.MScriptUtil()
> > compItr.getIndex(u.asIntPtr(), v.asIntPtr())
> > print openMaya.MScriptUtil().getInt(u.asIntPtr())
> > print openMaya.MScriptUtil().getInt(v.asIntPtr())
> > compItr.next()
>
> > 0
> > 0
>
> > what I'm going for is for this tool to function across all versions of
> > maya. I can account for depreciations and such without any issue, but
> > if they changed MScriptUtil and then didn't document it (as in made it
> > more strict, or whatever in 2011) Kind of a crappy move.
>
> > On May 13, 4:42 pm, Adam Mechtley <[email protected]> wrote:
> > > Your first example works perfectly fine for me. Here's an example of my
> > > script editor history:
>
> > > cmds.sphere()
>
> > > # Result: [u'nurbsSphere1', u'makeNurbSphere1'] #
>
> > > select -r nurbsSphere1.cv[3][7] ;
>
> > > import maya.OpenMaya as openMaya
>
> > > sel=openMaya.MSelectionList()
>
> > > openMaya.MGlobal().getActiveSelectionList(sel)
>
> > > path=openMaya.MDagPath()
>
> > > obj=openMaya.MObject()
>
> > > sel.getDagPath(0, path, obj)
>
> > > compItr = openMaya.MItSurfaceCV(path, obj)
>
> > > while not compItr.isDone():
>
> > > u = openMaya.MScriptUtil()
>
> > > v = openMaya.MScriptUtil()
>
> > > compItr.getIndex(u.asIntPtr(), v.asIntPtr())
>
> > > uVal = openMaya.MScriptUtil.getInt(u.asIntPtr()) # note: getInt is a
> > static
> > > function, you don't need an instance
>
> > > vVal = openMaya.MScriptUtil.getInt(v.asIntPtr())
>
> > > print '(%i, %i)'%(uVal, vVal)
>
> > > compItr.next()
>
> > > (3, 7)
>
> > > The reason why your second example doesn't work is because of the
> > > distinction between initial and working values on MScriptUtil objects.
> > > Calling createFromInt sets an initial value, while passing u.asIntPtr()
> > to
> > > your function only operates on a working value. Changing working values
> > will
> > > not change initial values. In the first example, you had no initial
> > value,
> > > so it was returning the first working value it found, while in the second
> > > example it returned the initial value (50).
>
> > > A lot of this was clarified (or muddied maybe) in the 2011 docs:
> >http://download.autodesk.com/us/maya/2011help/API/class_m_script_util...
>
> > > On Thu, May 13, 2010 at 3:01 PM, Brandon Harris <[email protected]
> > >wrote:
>
> > > > ok, so here's a test to show what's going wrong.
>
> > > > grab some components on a nurb surface and run this.
>
> > > > import maya.OpenMaya as openMaya
> > > > sel=openMaya.MSelectionList()
> > > > openMaya.MGlobal().getActiveSelectionList(sel)
> > > > path=openMaya.MDagPath()
> > > > obj=openMaya.MObject()
> > > > sel.getDagPath(0, path, obj)
> > > > compItr = openMaya.MItSurfaceCV(path, obj)
> > > > while not compItr.isDone():
> > > > u = openMaya.MScriptUtil()
> > > > v = openMaya.MScriptUtil()
> > > > compItr.getIndex(u.asIntPtr(), v.asIntPtr())
> > > > print openMaya.MScriptUtil().getInt(u.asIntPtr())
> > > > print openMaya.MScriptUtil().getInt(v.asIntPtr())
> > > > compItr.next()
>
> > > > Now the issue I have is that it doesn't print the correct values.
>
> > > > import maya.OpenMaya as openMaya
> > > > sel=openMaya.MSelectionList()
> > > > openMaya.MGlobal().getActiveSelectionList(sel)
> > > > path=openMaya.MDagPath()
> > > > obj=openMaya.MObject()
> > > > sel.getDagPath(0, path, obj)
> > > > compItr = openMaya.MItSurfaceCV(path, obj)
> > > > while not compItr.isDone():
> > > > u = openMaya.MScriptUtil()
> > > > v = openMaya.MScriptUtil()
> > > > u.createFromInt(50)
> > > > v.createFromInt(50)
> > > > compItr.getIndex(u.asIntPtr(), v.asIntPtr())
> > > > print openMaya.MScriptUtil().getInt(u.asIntPtr())
> > > > print openMaya.MScriptUtil().getInt(v.asIntPtr())
> > > > compItr.next()
>
> > > > This will just print 50. So how am I plugging this into
> > > > compItr.getIndex wrong?
>
> > > > Brandon L. Harris
>
> > > > On May 13, 2:55 pm, Adam Mechtley <[email protected]> wrote:
> > > > > An MScriptUtil object shouldn't care, since it is a Python object.
> > What
> > > > > matters is what you tell SWIG it is, not how you construct it in
> > Python.
> > > > If
> > > > > the API wants a reference to a double, but you pass a float ptr, it
> > won't
> > > > > like it. You'll notice, for instance, that there's only
> > createFromInt():
> > > > > there is no createFromShort(), createFromLong(), createFromUInt(),
> > etc.
> > > > > because they're all the same as far as Python is concerned. Likewise,
> > > > > MScriptUtil.getInt(), MScriptUtil.getShort(), MScriptUtil.getBool(),
> > etc.
> > > > > all return an int, because Python doesn't discriminate. It really
> > doesn't
> > > > > even bother Python if you create from a decimal and request it as an
> > > > int—it
> > > > > will handle the conversion. For instance:
>
> > > > > u = om.MScriptUtil()
> > > > > u.createFromInt(5)
> > > > > om.MScriptUtil.getInt(u.asIntPtr()) # this will return 5
> > > > > om.MScriptUtil.getDouble(u.asDoublePtr()) # this will return 5.0
> > > > > om.MScriptUtil.getDouble(u.asIntPtr()) # this will not work, since
> > > > > MScriptUtil.getDouble requires an argument of type double &, while
> > > > > u.asIntPtr() is of type int &
>
> > > > > On Thu, May 13, 2010 at 1:49 PM, Brandon Harris <
> > [email protected]
> > > > >wrote:
>
> > > > > > But that also brings me back to the initial scripts.
>
> > > > > > u=om.MScriptUtil()
> > > > > > u.createFromInt(0)#correct usage?
> > > > > > v=om.MScriptUtil()
> > > > > > v.createFromInt(0)#correct usage?
> > > > > > compItr.getIndex(u.asIntPtr(),v.asIntPtr())
> > > > > > om.MScriptUtil.getInt(u.asIntPtr())
>
> > > > > > OK so if I use createFromInt and just feed it an arbitrary value to
> > > > > > allocate the space, is that correct? what do I have to consider
> > when
> > > > > > doing that? if the number may have a value like 20 instead of 2, do
> > I
> > > > > > need to do createFromInt(100) or something to give it adequate
> > space?
>
> > > > > > Brandon L. Harris
>
> > > > > > On May 13, 1:36 pm, Brandon Harris <[email protected]> wrote:
> > > > > > > OK so when I do this
>
> > > > > > > u=om.MScriptUtil()
> > > > > > > u.createFromInt(0)
>
> > > > > > > the u.asInt is equal to 0.
>
> > > > > > > so when I do that I need to do
>
> > > > > > > u.createFromInt(Value That Will Be Used)
>
> > > > > > > On May 13, 1:28 pm, Adam Mechtley <[email protected]>
> > wrote:
>
> > > > > > > > Basically:
>
> > > > > > > > Imagined through the lens of a language like C++, Python always
> > > > passes
> > > > > > > > simple types (integer, decimal, etc.) by value—you are passing
> > > > actual
> > > > > > > > numeric data. Some places in the API, however, require that
> > simple
> > > > > > types be
> > > > > > > > passed by reference (that is, passing an address to some
> > numeric
> > > > data
> > > > > > rather
> > > > > > > > than passing the numeric data itself). In such cases, there is
> > no
> > > > > > automatic
> > > > > > > > way for the SWIG layer to translate a simple type into a
> > > > *reference* to
> > > > > > a
> > > > > > > > simple type. An MScriptUtil object is thus basically a way of
> > > > wrapping
> > > > > > a
> > > > > > > > simple numeric value (like an integer or decimal) in a complex
> > > > object
> > > > > > so it
> > > > > > > > can be passed by reference.
>
> > > > > > > > In your example, u is an object containing a simple integer
> > value
> > > > (0 or
> > > > > > 20
> > > > > > > > or whatever you give it when you construct it). The sole
> > function
> > > > of u
> > > > > > is
> > > > > > > > thus to pass its contents by reference (u.asIntPtr()) or to
> > obtain
> > > > the
> > > > > > value
> > > > > > > > when something else has changed it (u.asInt()).
>
> > > > > > > > On Thu, May 13, 2010 at 1:11 PM, Brandon Harris <
> > > > [email protected]
> > > > > > >wrote:
>
> > > > > > > > > OK, I believe that by changing some of this I have actually
> > > > crippled
> > > > > > > > > some functionality. So is there more information on exactly
> > what
> > > > > > > > > u=om.MScriptUtil()
> > > > > > > > > u.createFromInt(0)
> > > > > > > > > actually does and if I use 20 instead of 0 what happens?
> > > > > > > > > Forgive my ignorance. Just an odd class that I'm not sure on
> > what
> > > > > > it's
> > > > > > > > > doing so not 100% on how I'm to use it properly
>
> > > > > > > > > On May 11, 12:20 pm, Brandon Harris <[email protected]>
> > > > wrote:
> > > > > > > > > > Alright. That did seem to be the issue. big thanks for the
> > > > help!
>
> > > > > > > > > > Brandon L. Harris
>
> > > > > > > > > > On May 11, 10:21 am, Paul Molodowitch <[email protected]>
> > > > wrote:
>
> > > > > > > > > > > Yup... the only thing I would add is that you need to
> > > > allocate
> > > > > > space
> > > > > > > > > for
> > > > > > > > > > > whatever you're going to be storing - the default
> > constructor
> > > > > > allocates
> > > > > > > > > NO
>
> ...
>
> read more »
--
http://groups.google.com/group/python_inside_maya
