PDA

View Full Version : classOf() at a precise point in the stack?


Caprier
12-15-2010, 10:41 AM
I am working on a tool that is run from one of the menus of the Edit UVWs dialog of an Unwrap UVW modifier.
Currently the tool works only on trimesh structures. So I test for classOf myObject == editable_mesh in the on isEnabled event of the macro.

If I have an editable mesh plus an unwrap and an edit poly modifier on top, the tool is disabled though it shouldn't be. Or worse, an editable poly plus an unwrap plus and edit mesh mod: the tool can then be run but will crash most of the time.
Similarly, testing for classOf myObject.baseObject == editable_mesh doesn't work since there can be other modifiers below the unwrap.

A workaround would be to temporarily turn off all the modifiers above the unwrap before testing but I was wondering if there was a way to evaluate directly the class of an object at a precise point in the stack.

stigatle
12-15-2010, 12:12 PM
is it possible that you can post some actual script?

If you can provide a loop that checks selected object, then we can use that to help you.

Caprier
12-15-2010, 12:35 PM
Hu? What loop? What code?


I was wondering if there was a way to evaluate directly the class of an object at a precise point in the stack.

The code in which I want to do that is irrelevant (or I'm completely missing something).

stigatle
12-15-2010, 12:52 PM
What if you do this? :

classOf $.modifiers[#Unwrap_UVW]

$box1.modifiers -- get modifier array

$box1.modifiers[3] -- get the 3rd down the list

$box1.modifiers[#twist] -- get the one named "twist"

$box1.modifiers["ffd 4x4x4"] -- get the FFD

Caprier
12-15-2010, 12:57 PM
stigatle, I really appreciate that you're trying to help but my question is about evaluating the class of the object, not of its modifiers.

stigatle
12-15-2010, 01:13 PM
But the base object is the same class regardless of stack.
you don't change it's class by adding modifiers.
only way to change it is by collapsing to another object type.

so you have to check the "base" object at the beginning of stack.

Caprier
12-15-2010, 01:33 PM
Please read my first post carefully.

denisT
12-15-2010, 04:07 PM
I am working on a tool that is run from one of the menus of the Edit UVWs dialog of an Unwrap UVW modifier.
Currently the tool works only on trimesh structures. So I test for classOf myObject == editable_mesh in the on isEnabled event of the macro.

If I have an editable mesh plus an unwrap and an edit poly modifier on top, the tool is disabled though it shouldn't be. Or worse, an editable poly plus an unwrap plus and edit mesh mod: the tool can then be run but will crash most of the time.
Similarly, testing for classOf myObject.baseObject == editable_mesh doesn't work since there can be other modifiers below the unwrap.

A workaround would be to temporarily turn off all the modifiers above the unwrap before testing but I was wondering if there was a way to evaluate directly the class of an object at a precise point in the stack.

some modifiers applied to an object can change its class. For example the Edit_Poly applied to Editable_Mesh changes its class to PolyMeshObject.
But a modifier can't change the supperclass of an object. All trimesh based objects have GeometryClass superclass. So you can check if iskindof obj GeometryClass ...
If you need to know a class of an object on some step in modifiers stack you have to disable all modifiers above and check the class.

Caprier
12-15-2010, 04:43 PM
Hi Denis.

Unfortunately testing the superclass won't do. An editable poly's superclass is GeometryClass too but the tool I'm developing works only on triangular faces. As far as I know there is no simple way of accessing the underlying trimesh of an editable poly through the unwrap interface (like using myEPoly.mesh for a scene object).

The workaround I'm using works fine:
local obj = selection[1]
local mod = modPanel.getCurrentObject()
local ind = modPanel.getModifierIndex obj mod
local isClassOk

if ind > 1 then
(
local oldStates = #()
for j = 1 to ind - 1 do
(
append oldStates obj.modifiers.enabled
obj.modifiers.enabled = false
)
isClassOk = classOf obj == editable_mesh
for j = 1 to ind - 1 do
obj.modifiers.enabled = oldStates[j]
)
else isClassOk = classOf obj == editable_mesh

I'm just wondering if there was something in the maxscript language that would allow accessing an object state anywhere in the stack.
classOf myObject evaluates at the top,
classOf myObject.baseObject evaluates at the bottom,
but nothing in between (?).

Something like classOf myObject.stackLevel[n] would turn these thirteen lines of code into one.

denisT
12-15-2010, 05:09 PM
you can jump at any level of modifiers stack, temporally set showEndResult to OFF, and check the class...

what are you doing with the object? why can you not use the object's triMesh directly?

Caprier
12-15-2010, 05:36 PM
YES! You've nailed it.
I knew there had to be something simple I overlooked. Thanks a ton, Denis.

The macro moves texture vertices around and is run from within the Edit UVWs dialog (it's a mapping tool).
Quite a few unexpected problems, I must say. Like dead texture vertices, vertToFaceSelect() that doesn't behave like meshop.getMapFacesUsingMapVert(), etc...
Implementing it for editable polys is not going to be a breeze.

denisT
12-15-2010, 06:03 PM
The macro moves texture vertices around and is run from within the Edit UVWs dialog (it's a mapping tool).
Quite a few unexpected problems, I must say. Like dead texture vertices, vertToFaceSelect() that doesn't behave like meshop.getMapFacesUsingMapVert(), etc...
Implementing it for editable polys is not going to be a breeze.

are you trying to move texture vertices using meshop or uvw_unwrap methods?

Caprier
12-15-2010, 08:28 PM
I use the unwrap methods.
I started first by using the meshop methods for testing the topology, retrieving the coordinates, etc, and only the setVertexPosition() unwrap method for the last step. But that was a mistake.
I know a lot more now about scripted mapping than a week ago.

denisT
12-15-2010, 09:13 PM
I use the unwrap methods.

So you don't need do check the object(s) class to make your tool work. Mostly the uvw_unwrap methods don't work if a UVW_Unwrap modifier in not current object of Modifiers panel and UVW Editor is not open. You have to check if modpanel.getCurrentObject() is the UVW_Unwrap modifier.

Caprier
12-15-2010, 10:01 PM
That's not a problem. Since the macro is run from the mapping menu in the Edit UVWs dialog, the current modifier cannot not be an unwrap uvw modifier.
What I do need to test is the kind of mesh structure that is fed to the modifier. And I need it to be a trimesh because the tool works on a tri-only topology (so far). If the stack below the unwrap evaluates as a primitive, an editable mesh or even a NURBS object, the unwrap sees a triangulated topology and evaluating at its level returns an editable mesh.
If I give it an editable poly, the unwrap sees a polymesh structure and the macro will make a mess of it (it has to walk from face to face to check the pattern of the selected faces before moving things around).

I started making that tool for my own use. So I didn't care much about stack problems and crashes. I just made sure the unwrap gets a trimesh. But I've shown it to several people who seemed to find it useful and now I'm trying to make a foolproof (enough) version.
I'll post it on scriptspot in a couple of days and add the link here if you're interested.

CGTalk Moderation
12-15-2010, 10:01 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.