Hey guys,
So after a while of setting up, using and pushing out a scripted material plugin to the art team here we have it all working as we would like, more or less.
2 problems are bugging me.
- to make it robust, I have ended up with quite a few places containing fat try-catch blocks to prevent the following scenarios:
a) someone has local paths in the material and someone else opens the file. (or the file has moved/been deleted etc. and the filename is nolonger valid)
b) undefined values exist in the delegate (which is I think valid - it indicates an unassigned texture parameter) and scripted UI requires a bitmap value, not undefined
c) to make sure things do not erroneously cause exceptions during loading - I’m using the ‘loading’ variable to try to block this in the whole function but I do not trust it fully yet (not a rational fear!)
which leads on to
- it can be SLOOOOOW to load up a scene with a few materials. I am going to dig in and investigate what is taking the time and the exact order of handlers etc. on scene load and see if it gives any clues. I suspect it is related to 1.
This has got me to thinking about asking you guys if you have any shared experiences and ideas. Here’s a couple I have thought of:
I could store the filenames in a simple array and valideate that array by checking the file exists - replace missing with defaults/missing texture and then just fill the material - basically just bypassing the tricksy bitmap handling in mxs
Switch to a SDK plugin or solution of some kind - I hope this is not necessary though - it seems sledgehammery, and I do not have the skillset for it myself.
I have thoroughly trawled the web for similar issues and had a look at the asset management interface and asset stream stuff, it didn’t work for me but I am willing to try again if anyone else has had better luck.
Look forward to a discussion! 
cw
Heh, is this Max, Maya, XSI or?
If it’s Max, the ATSOps interface should be fairly useful (it’s a bit odd but it does work, presuming your P4 default client is set up correctly etc…)
SamiV.
apologies - it is 3dsmax - 2011 I am using at the moment.
We have never hooked up the asset tracking in max to our perforce - I’ll have to ask about that.
In our plugin, we get around this issue by saving out the material parameters (including texture paths) to a file - the material description that gets used in the game. When someone opens a Max file, if they don’t have the textures locally then the defaults get used instead. The artist can then hit a button on the UI to load up the actual material that was exported to the game and this load process also syncs all of the textures from perforce. That way we make the slow part (syncing and loading the textures) under the control of the artists instead of when the file is opened. It’s still slow, but at least the artists can control it a bit. Our material plugin has one button to load only that one material and another button to load all of the materials in the scene.
Yeah, scripted material front ends are cool, we’ve used them for years, but they aren’t the fastest horse in the barn. I don’t believe there’s an alternative to the try/catch you described when dealing with Bitmap objects on the delegate. We convinced them to change that to not throw an exception several releases ago, but IIRC they botched it somehow and ended up backing out the change in a service pack or something.
Instead we focused some effort on making sure the External Files paths order is optimized for each user’s discipline… so when a bitmap fails to load we can find it in its new location as fast as possible. We have a pre-Max-startup script that does that.
[QUOTE=bcloward;16303]When someone opens a Max file, if they don’t have the textures locally then the defaults get used instead. [/QUOTE]
For this, how is it handled, do you do this in a callback on load or something before the materials try to initialise?
cheers for all the ideas, folks. 
