BTW, just for my personal reference, why does this work:
EditPolyMod.GetNumEdges $.modifiers[1]
and this doesn’t…
EditPolyMod.getEdgeFace 2 1 $.modifiers[1]
Is that a bug?
- Neil
Nope, a user error.
From the Reference:
[left]Two Ways of Accessing the Interface
[/left]
[left]There are two ways to access the interface – as a standalone interface and as an interface on a particular object. If you access the interface directly, you need to pass to it the object to work on.
[/left]
[left]EXAMPLE
[/left]
[left]
[/left]
[left]m = Bitmaptexture fileName:[color=maroon]“L:\mypath\scenes\2500hicon.JPG” [/color]
bitmapTex.viewImage m [color=green]– direct interface access, need to pass object
[/color]m.viewImage() [color=green]– accessing interface on object, object internally passed as arg 1. [/color]
[/left]
[left]
[/left]
[left]
[/left]
As you can see, the object the interface method operates on is ALWAYS the first one, either explicitly or implicitly.
So when you say
$.modifiers[1].EditPolyMod.getEdgeFace 2 1
MAXScript will take $.modifiers[1] and pass it as first parameter, so 2 and 1 become second and third parameter internally.
If you say
EditPolyMod.getEdgeFace $.modifiers[1] 2 1
you HAVE TO pass the modifier as first argument – nameless arguments always have to be passed in a specific order. Only named keyword arguments followed by colon: can be passed in random order because the name defines what they are.
(The above code works, btw)
Ah ok, I see what I was doing. The help file said…
<index>GetEdgeFace <index>edgeID <index>side node:<node>
So I assumed that you passed it the node as the last parameter. Maybe changing the position of the node mention in the helpfile would make it clearer, although having the examples you just added will probably be plenty to let people know how to use this. Thanks for the explanation.
- Neil
Ah, no. node: IS an OPTIONAL named keyword parameter. Not the Modifier you have to pass (which is implicit in the definition, because it assumes you are calling it the other way, without passing the modifier as argument), but the NODE the modifier is applied to. Remember, an Edit_Poly can be instanced across any number of different nodes, so if you want to tell MAXScript which of them to take into account when working with the Edit_Poly, you can optionally pass the node:$Box01 keyword.
The position of the node: keyword cannot change much, it comes right after the position-bound parameters.
Ah, ok. So the real issue is that <index>GetEdgeFace should either be replaced by
$.modifiers[1].GetEdgeFace
or
EditPolyMod.GetEdgeFace $.modifiers[1]
I was getting confused by there being basically 2 nodes in the statment, and not realizing they meant 2 different things…
- Neil
One final question, since this is the last bit of code I need to finish my script. Any idea why this code doesn’t work (max9, SP1). It produces a result of true in the script editor, however, it doesn’t actually select the 3 edges you’d think it would select in the viewport.
$.modifiers[1].SetSelection #Edge #{1,2,3}
- Neil
I see what you mean – there is definitely some black magic at work. If the bitarray contains the last SO element in the object, it appears to work. For example, on a box with 602 vertices, passing #{1…602}, #{100…602} etc. works, but #{1…601} or #{100…601} does not. There is either a bug or some flags are being used that are not obvious.
Try using the .Select method instead – it appears to work as expected.
Looks like we got a bug goin’ on.
Cool. 2 notes:
-
the max9 helpfile doesn’t mention this method. Hope it makes it into the 10 documentation.
-
For the method to work, you need to be in subobject mode already using $.modifiers[1].SetEPolySelLevel #edge. May be worth making a note of.
Thanks for all the help bobo.
- Neil
- I can see it in the Max 9 help file, right after SetSelection. In Max 2008, the formatting and ordering is much better, but the content is about the same.
[left]
[/left]
2. Good idea!
[left]
[/left]
[left]
[/left]
[left]
[/left]
Yup, there it is. I am officially blind I guess
- Neil