[Closed] classOf() at a precise point in the stack?
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.
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.
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).
What if you do this? :
[b]classOf $.modifiers[#Unwrap_UVW]
[/b][left]$box1.modifiers [color=green]-- get modifier array[/color]
[/left]
[left]$box1.modifiers[3] [color=green]-- get the 3[/color][color=green]rd[/color][color=green] down the list[/color]
[/left]
[left]$box1.modifiers[#twist] [color=green]-- get the one named "twist"[/color]
[/left]
[left]$box1.modifiers[[color=maroon]"ffd 4x4x4"[/color]] [color=green]-- get the FFD[/color]
[/left]
[left]
[/left]
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.
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.
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.
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?
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.