[polynurb]

hi!

what do i have to do so that when i import a material from the gallery via rhino, the zip is extracted to a network location?

(so that all render nodes have access to it)

right now no matter what paths i input (in standalone mxm editor), they always end up on the local computer.

thanks,

daniel

ps. also personally i would prefer if the gallery search window would not close after the first download.

[polynurb]

...just figured that they do get copied to the alternative path too.. but the ones active in the texture slots of the material within rhino still point to the local copy.

daniel

[JDHill]

As for the MXED Preferences MXM Gallery Alternative folder path, I'll see what I can do about using that. The fact is that the plugin does a bunch of extra work for you when you browse the MXM Gallery from it (as compared to using MXED, when started from outside of the plugin); basically it does a pack-and-go on the downloaded MXM, fixing bad texture paths, and copying all downloaded textures into a /textures folder to help keep things more organized. Some of that would have to change if I use the preferences path.

Regarding downloading multiple MXMs per MXED session, the plugin can't help with that. However, you may not be aware that the plugin actively monitors directories in its MXM Browser window. That means, if you view the MXED Preferences MXM Gallery Alternative folder path in the plugin's MXM Browser, you'll see new MXMs show up whenever MXED downloads them. So, you can just start MXED from the Start menu, rather than from the plugin, and download as many MXMs as you want -- you should see them appear in the plugin's MXM Browser immediately after they've been downloaded and unzipped by MXED. Of course the plugin is not going to do its pack-and-go stuff on MXMs downloaded this way, but that may not matter to you.

[polynurb]

thanks for the in-detail explaination..

i think i can well live with your suggestion about using the mxm browser within rhino, as it will solve both issues.

i also noticed that "presets" saved from the tabs are instantly accessible across several rhinos now without restarting the software... that is very good and i think it has not always been like that.

thnx,

daniel

[JDHill]

No, that's not true, but I may be able to make it so.

How it works now is along the same lines as how settings in Rhino generally work -- the last one to write the setting (in this case, a file containing the presets) wins. What you are probably referring to is due to the presets being loaded on-demand. Meaning, if you open two sessions, make a new preset in one, then look at the presets in the other, the new preset will indeed be there. If you try it again though, the presets have already been loaded in both sessions, so the trick won't work anymore.

[polynurb]

ha!.. in deed i did not try the trick twice.. but it worked once, as you say.

it is something that would be very convenient if possible at some point.

[JDHill]

No problem, I've changed things so that in the future, those drop-downs will re-read the presets file each time they're accessed. In general, you like to hit the file system no more than absolutely necessary, but I suppose people don't drop down these preset lists too often.

[polynurb]

cool...!! in times of ssds we can take that little increase of I/O i guess

thnx,

daniel

[JDHill]

Just so you know, it's not really that, it is that accessing the file system is much less deterministic than accessing memory. Where you have to write very little error recovery & notification logic for memory errors, since a memory failure basically means the application is not going to be running anymore afterward, with the file system, a failure doesn't usually mean the hard drive has crashed, so you have to be able to recover from the failure and figure out what the user wants to do next.