vrayMeshImport

[JulianD]

Hello everyone!

I'm a bit stuck with the vrayMeshImport() function. I have multiple vrayproxies in my scene that I try to import as editable mesh. I need to have every editable mesh in a variable in order to work with those later.
Everytime I get the vrayMeshImport() in a loop the result I have is: iteration of a mesh = vrayproxy ^ selection.count. Example, I have 2 vrayproxies I'll get: 2 meshes of VrayProxy001 and 2 meshes of VrayProxy002. If I have 3 vrayproxies I'll get: 3 meshes of Vrayproxy001, 3 meshes of Vrayproxy002, 3 meshes of Vrayproxy003, ..and so on.

I currently have 3 vrayproxies: VRayProxy001, VRayProxy002, VRayProxy003

My code:

newMesh = #()

f = getCurrentSelection()

for i = 1 to f.count do
(
print (i as string)
obj = f[i]
print "selected obj: "
print obj
newMesh[i] = vrayMeshImport obj
newMesh[i].name = obj.name
print "newMesh: "
print NewMesh[i]
)
print "-----"
newMesh

log:

#($VRayProxy:VRayProxy002 @ [105.451233,63.242535,-15.809784], $VRayProxy:VRayProxy003 @ [105.451233,148.749832,-15.809784], $VRayProxy:VRayProxy001 @ [121.075500,-3.243168,-15.809784])
#()
"1"
"selected obj: "
$VRayProxy:VRayProxy002 @ [105.451233,63.242535,-15.809784]
"newMesh: "
$Editable_Mesh:VRayProxy002 @ [0.000000,0.000000,0.000000]
$Editable_Mesh:VRayProxy002 @ [0.000000,0.000000,0.000000]
$Editable_Mesh:VRayProxy002 @ [0.000000,0.000000,0.000000]
"2"
"selected obj: "
$VRayProxy:VRayProxy003 @ [105.451233,148.749832,-15.809784]
"newMesh: "
$Editable_Mesh:VRayProxy003 @ [0.000000,0.000000,0.000000]
$Editable_Mesh:VRayProxy003 @ [0.000000,0.000000,0.000000]
$Editable_Mesh:VRayProxy003 @ [0.000000,0.000000,0.000000]
"3"
"selected obj: "
$VRayProxy:VRayProxy001 @ [121.075500,-3.243168,-15.809784]
"newMesh: "
$Editable_Mesh:VRayProxy001 @ [0.000000,0.000000,0.000000]
$Editable_Mesh:VRayProxy001 @ [0.000000,0.000000,0.000000]
$Editable_Mesh:VRayProxy001 @ [0.000000,0.000000,0.000000]
OK
"-----"
"-----"
#(#($Editable_Mesh:VRayProxy002 @ [0.000000,0.000000,0.000000], $Editable_Mesh:VRayProxy002 @ [0.000000,0.000000,0.000000], $Editable_Mesh:VRayProxy002 @ [0.000000,0.000000,0.000000]), #($Editable_Mesh:VRayProxy003 @ [0.000000,0.000000,0.000000], $Editable_Mesh:VRayProxy003 @ [0.000000,0.000000,0.000000], $Editable_Mesh:VRayProxy003 @ [0.000000,0.000000,0.000000]), #($Editable_Mesh:VRayProxy001 @ [0.000000,0.000000,0.000000], $Editable_Mesh:VRayProxy001 @ [0.000000,0.000000,0.000000], $Editable_Mesh:VRayProxy001 @ [0.000000,0.000000,0.000000]))

My array newMesh contains 9 values (instead of 3!) and in my viewport I have 3 meshes for every vrayproxy ( = 9 meshes in total instead of 3).
Can someone help me out with this? I don't understand why the selection.count influences the number of importation of a vrayproxy. I don't know if it's a issue or not?

Thank you

[^Lele^]

newMeshes = vraymeshimport $

Is enough to get all the selected proxies imported as meshes.

You may have to change the selection you pass to it individual nodes, if you're trying to achieve a node by node mesh import, like so (i changed your code and variables slightly to have it clearer for myself):

(
    newMeshes=#()
    proxies = selection as array --this is a COPY of the selection set

    for proxy in proxies do
    (
        clearSelection() --select nothing
        select proxy --select the current proxy in the selection array
        newMesh = vrayMeshImport $ --store it into a variable for further mesh operations, like renaming
        newMesh.name = (proxy.name + "_importedMesh") --rename it
        newMesh.wirecolor = proxy.wirecolor --make it the same wireframe color as the original proxy
        newMesh.transform = proxy.transform
        append newMeshes newMesh --add it to the meshes array

        print "newMesh: "
        print NewMesh
    )
    clearSelection() 
    select proxies --restore the original selection
    print "-----"
)

[JulianD]

works like a charm!
Thanks A LOT for the explanations!

[^Lele^]

works like a charm!

Eh yes, only for very simple scenes, however.
Should you need to run something similar on big scenes, you may want to put Max into its most performant state (which means changing some UI modes, stopping redraws, and so on), or the process could take a long time.
Poke me should the need arise (i have some functions to do that.).

[JulianD]

Eh yes, only for very simple scenes, however.
Should you need to run something similar on big scenes, you may want to put Max into its most performant state (which means changing some UI modes, stopping redraws, and so on), or the process could take a long time.
Poke me should the need arise (i have some functions to do that.).

Well, I think that would come in handy actually. I'm listening.

[^Lele^]

It's attached, and commented.
Have fun!

[JulianD]

Thank you very much!

As far as I understand you use setSuperExpertMode() to get a rid of all the UI functions of 3ds max and get them back with resetSEMode().

You are sure that just hiding them make the process faster?
What about functions that use the timeline (like adding key every frame)?

Anyway that's an awesome code! Thanks again!

[^Lele^]

You're very welcome!

As far as I understand you use setSuperExpertMode() to get a rid of all the UI functions of 3ds max and get them back with resetSEMode().

Umh, not quite, sorry for being a bit cryptic there.
setSuperExpertMode takes one argument: true or false.
When set to true (and this is the key bit) it will collect the state of the various UI elements, before hiding everything.
When set to false, it will check their previous state, and set them to whichever that was. So if you had, say, the timeline hidden, it won't bring it back.
The resetSEMode() will turn everything back to factory defaults, regardless of the pervious state of the various UI elements. So to keep to the analogy, a hidden timeline would be made visible again.

You are sure that just hiding them make the process faster?

Wish that i wasn't, ahah.
Particularly with the code i provided you for proxies, which selects stuff in viewport, there are a zillion things which get broadcast on selection, UIs which get loaded, and so on and so forth.
Feel entirely free to see if it really does what i say it does, it should be easy enough to try out.
For example, a simple test is to run the proxy script on many proxies, and with the command panel in create mode, and in modify mode.
The latter will be many times slower.
I'd love some modern feedback on issues, should you find any, or on the actual benefit of each bit.

What about functions that use the timeline (like adding key every frame)?

The hiding of UI parts should affect nothing of the inner processes.
However, it will prevent the updates until those UI elements are turned back on, which is where some of the speedups come from.

As an added thought, you may want to disable the undo system as well, if the process is known to take memory.

with undo off 
(
-- looping function in here
)

will do the trick, at the expense of -guess what- not having an undo entry.

Should you need to time stuff, and it wasn't clear to you, ask away (or i'll add it to the current script.)

Anyway that's an awesome code! Thanks again!

Pffft, i wish it was. But you're still very welcome!

[JulianD]

Thanks for the explanations!
I had gotten the point of the functions but I didn't make myself clear explaning it haha.

I'll try to include your *.ms in the beginning of my code to use your functions anytime I need them. Like in C there's a preprocessor #include THEFILE.h. Maybe the maxscript include() function may work the same way. Still have to test it out.

[^Lele^]

Include and any other external method in MXS has one issue: the functions and variables become global, which risks "poisoning" the max session in case of error.
Maybe you could put them in a struct, and include that, but i fear it wouldn't be much difference.
In general, i avoided both when i could, and would copy/paste the needed code over, so it stayed in local scope, and i wouldn't hear artists yelling at me. ^^

[JulianD]

Well the include maxscript file is a great function if it works the way I imagine it. I thought of writing all my functions in seperate files:
StringFunctions.ms
OptimizeMAX.ms
AnotherOne.ms

and just call them anytime I need them
include "StringFunctions.ms"
include "OptimizeMAX.ms"
include "AnotherOne.ms"

That may work, right? But as you said if there's ONE little mistake in a function file, it will crash.

[^Lele^]

It would work, yes.
However, because it'd make the scope global, you'd risk variables clashing, and IF it errored out the variables would be left in memory for the max session, instead of being dumped like they do with a local scope.
The global scope is often the source of *much* frustration (scripts which run only the second time, and so on) for maxscript beginners, and to this day i try to avoid it for anything but a rollout name (so that it can be closed when running the same script multiple times.).
If you know what you're doing, though, and have tight control on your variables names, go to town with includes and structs.

[^Lele^]

I am WRONG.
Include is fine, it's fileIn which is not.
From Maxscript's manual:

Because include is a compile-time construct, the current MAXScript scope is maintained within the included file. This is opposed to the fileIn() method described in Running Scripts, whose script file content is compiled in a global scope context.

[JulianD]

I am WRONG.
Include is fine, it's fileIn which is not.
From Maxscript's manual:

Oh ok I get it. There's one last test I have to make to be sure to not doing something wrong: testing if including a maxscript file (include "functions.ms") in a script01.ms and in a script2.ms doesn't crash IF script01.ms and script2.ms are fileIn a script3. That may sound a bit weird but I have all my scripts docked in one big rollout (which is my masterMenu.ms in my startup script folder).