I am writing a script where a piece of my code could possibly be written inside one function as oppose to 2 functions. However, prior to my for loop, I am converting the current selection to faces, which I then loose the original subobjectlevel. Now I could put this inside a variable, and use it in a case statement, but I never seen a case statement used in a for loop where the answer is always the same answer. Here is a snippet of my code that would use a case statement…
local origSelLevel = subobjectlevel
local faces = $.ConvertSelection origSelLevel #Face
for f in faces do
(
local newSelection = #{}
case origSelLevel of
(
1: newSelection = polyop.getVertsUsingFace $ f
2: newSelection = polyop.getEdgesUsingFace $ f
)
continue coding...
)
continue coding...
as you can see, this example saves the original subobjectlevel in a variable prior to converting to faces and then uses that variable which never changes inside the for loop. So I am wondering, which of the 2 is best, use 2 functions or condense the script into one function and use a case statement, even though the answer never changes? Or better yet, is this one of those catch 22’s?
What 2 functions do you have in mind? Sometimes it’s better for clarity, sure. Anyway, for a snippet like this, I’d only adjust it a bit:
local origSelLevel = subObjectLevel
local faces = obj.ConvertSelection origSelLevel #face
local getSubUsingFace = case origSelLevel of
(
1: polyop.getVertsUsingFace
2: polyop.getEdgesUsingFace
)
for f in faces do
(
local newSelection = getSubUsingFace obj f
-- continue coding...
)
-- continue coding...
it might be not the best practice but how i would do:
fn convertPolyLevel node subs source:#object target:#vertex = if iskindof node Editable_Poly or iskindof node PolyMeshObject do
(
if source == #object then
(
case target of
(
#vertex: node.verts as bitarray
#edge: node.edges as bitarray
#face: node.faces as bitarray
default: node
)
)
else
(
convertAction = case source of
(
#vertex: case target of
(
#edge: polyop.getedgesusingvert
#face: polyop.getfacesusingvert
)
#edge: case target of
(
#vertex: polyop.getvertsusingedge
#face: polyop.getfacesusingedge
)
#face: case target of
(
#vertex: polyop.getvertsusingface
#edge: polyop.getedgesusingface
)
)
if convertAction != undfefined do
(
convertAction node subs
)
)
)
/*
convertPolyLevel $ #selection source:#vertex target:#edge
*/
or i would break it on three functions similar to what Swordslayer showed:
fn convertPolyVertLevel node verts target: =
(
)
fn convertPolyEdgeLevel node edges target: =
(
)
fn convertPolyFaceLevel node faces target: =
(
)
where we don’t need to check for source level type
i am NOT sure that obj.ConvertSelection works for a polymesh object
edited… NOT was missed
it’s better to use getselectionlevel instead of subobjectlevel in case of working with poly object.
Well, from the looks of things, once again I did not explain myself clearly. This is not your fault guys, this has to do with with my mental disability that I have, when it comes to explaining things.
In reply to Swordslayer, My question does not depend on 2 maxscript functions. The 2 functions has to deal with taking my original function that I made and having to make a duplicate function of the same exact instructions except for one line. That one line depends on if converting the selected faces into edges one face at a time or converting the selected faces into vertices one face at a time. Since I want to convert the faces one at a time, this means I need to do it in a for loop, but then, inside the for loop, it depends whether I am converting it to vertices or edges. It is kind of like taking 2 chefs in a restaurant. They are both chefs, and even though one is assigned to make chicken parm and another is assigned to make veal parm, the equipment needed are the same, and the ingredients are almost the same, except one chef uses chicken and the other uses veal. On the other hand, to cut cost down, you technically really only need one chef and have the other chef do something completely different.
On that note, I apologize for responding so late, as well as not putting any of work in here. I do understand that this makes it more difficult for others to give back responsive examples. However, I am not looking for any examples. I know how to build my script both ways. I am just looking for other experts opinions on what they have done when it comes to this type of situation. A simple answer of, “when I fall into these types of dilemmas I…” would be fine. Also, please do keep in mind, when I finish this script, I am uploading it on scriptspot, and I am thinking of suggesting my script to Autodesk to be implemented in the upcoming version of 3ds Max. So, the script will be encrypted. Unless, I can find a way to say that I was the first to come up with this idea for 3ds Max. I do not think I can copyright it, because it has been implemented in other 3D packages. However, if it has never been done in Max, I sure would love to be the first!!
are you looking for opinions or experts other than you?
honestly what you do in your first post doesn’t make sense for me at all.
EDIT: Oops, didn’t read Swordslayer’s post, pretty much the same.
You can assign functions to variables, which would allow you to decide which polyOp function to use just once outside of the for loop instead of deciding it on every iteration of the for loop.
So taking your original code:
local origSelLevel = subobjectlevel
local faces = $.ConvertSelection origSelLevel #Face
local polyOpFunction
case origSelLevel of
(
1: polyOpFunction = polyop.getVertsUsingFace
2: polyOpFunction = polyop.getEdgesUsingFace
)
for f in faces do
(
local newSelection = #{}
newSelection = polyOpFunction $ f
continue coding...
)
continue coding...
that’s exactly what Swordslayer showed above. but as i said the code (or method) doesn’t make sense and cannot work. first of all look in the mxs help and check what convertselection returns.