I’m wanting to get more info on how most production houses keep their pipeline efficient and part of that is making sure that no unnecessary processor power is being used (At least this is the way I would imagine it to be). My question is: How do most houses feel about using tools that require scriptJobs (or something similar in other packages) to work?
I ask this because I have recently built a selection GUI that relies heavily on the use of a scriptJob and want to make sure that this would even be used in production.
Although I try to avoid it, at the end of the day you’ve got to get things working for your artists, so do what you must.
It’s pretty important to make sure that each callback/scriptJob/whatever cleans up after itself. For example, if you have a tool like that that has a GUI Window, you could make the Window’s onClose event (or whatever your chosen package supports) clear out the scriptJob’s and events.
I think in Maya there isn’t a windows onClose command - I think I remember that was something I used scriptJobs to check for. I ended up having a small “Master ScriptJob” that fired when my GUI was closed and killed off the other scriptJobs I had going, then killed itself.
Another thing that you really have to do is make sure whatever script you are using to register the scriptJob or callback checks first to see if it’s already registered. If so, either don’t re-register, or kill the older one. A lot of artists duck in and out of their tools a lot, and if a callback is constantly getting registered the system will take a dive eventually.
As long as you don’t let them run out of control they’re usually fine – they’re there to get you out of sticky situations, after all.
That being said, if you have 600 items each with their own scriptJob to see if they’re selected … it’s not going to be pretty. One event that checks if any relevant object is selected is much better.
And better yet is finding another way around the problem.
At this point I’m working with around 20 or 30 controls. The scriptjob basically looks at what’ selected, tokenizes it and measures the length. The GUI has a very specific naming convention to eliminate any other objects activating the scriptjob. The script then works it way down a nice series of switch statements to insure it knows what it’s selecting and then selects the object. Work pretty seamlessly and I haven’t seen any issues, but always looking to know more and understand what I’m doing better.
We have a couple of tools that use scriptJobs, one of our TA’s thinks they’re evil and will chastise anyone for using it, but I think it has it’s place.
As long as you make sure the -kws flag is on which will clean them with the scene you are usually ok.
We had a plugin that we got from another stuido that had rogue API scriptjobs that kept changing settings, running checks on meshes and other stuff, needless to say it was a pain in the ass and we took it out as fast as possible.
So just be aware of them, let your other TAs know about them and add a ton of error checking to the scripts they call
In the script job command, you can choose to parent it to a piece of UI, so that it will automatically be killed when the GUI is destroyed - very handy!
I use them all the time - most commonly to “auto-refresh” a window with what is selected.
[QUOTE=whargoul;2508]In the script job command, you can choose to parent it to a piece of UI, so that it will automatically be killed when the GUI is destroyed - very handy!
I use them all the time - most commonly to “auto-refresh” a window with what is selected.[/QUOTE]
I do the same for modeling tools, creating a scriptjob status UI that can’t be ignored/dismissed without killing the scriptjob
( although it may be minimized to save screen real estate )
Yeah I use the “bind to UI” thing too so that if the window which is using the scriptJob is closed, the scriptJob gets killed.
I have a couple of scriptJobs which are used in our in-house tools, as most of you already said it’s mainly for just updating UIs when selections change. I try to use them as little as possible though, I’m really not sure of the overhead (seems like no performance hit at all on our stuff), but I imagine if you’re using a lot of them with complex functions then you could really kill performance…
I use Max callbacks for a number of things. Most common are selection callbacks, and any scene-specific rollouts have a callback that will close them when a new scene is opened.
There are other more specific-purpose reasons, but these are the general purpose ones. I assume Max callbacks are like Maya scriptjobs?
I have used them throughout tools that need to report back to Gui’s to update selections, as well as running setup scripts based on attribution types that are flagged on model data within a scene, when the model is selected.
They certainly have their place, not found any other way to do the things they do… maybe I’ haven’t looked hard enough.
Thinking them evil and not using them at all would be cutting out some potential that can be achieved, pretty closed minded, however yeah badly implemented and managed can lead to problems.
I’d be more concerned with not using the “blinddata” and maya’s inability to store it properly thanks to how it is stored on the mesh as mesh data gets reordered and mesh up occasonally leave blind data umm… mulch and pointless with the potential for doig more work and frustrations.
I also use scriptJobs to keep GUIs up to date. Attaching them to the window is also my preferred way to kill them. ScriptJobs are great! They make artists happy when the GUI responds to them appropriately.
[QUOTE=rhexter;2525]
I’d be more concerned with not using the “blinddata” and maya’s inability to store it properly thanks to how it is stored on the mesh as mesh data gets reordered and mesh up occasonally leave blind data umm… mulch and pointless with the potential for doig more work and frustrations.[/QUOTE]
I find blind data stores values relevent to the original area even when verts get re-ordered.
This can be very useful.
Perhaps we need a “Fun with Blind Data” Thread?
One extra little thing I did was write a function which looks for a scriptJob matching a string, and if found, kills the scriptJob. I put this function in with the name of the scriptJob command before I call any scriptJob, so that I know there can only ever be one of each running at any given time. Useful for when updating code, since you can just re-launch the script and everything updates nicely inside Maya.
I have found that the strategy you mentioned is very useful. Right now I’m using a global int array that holds any script job created by the script and eliminates duplicates. Keeps everything running nice and neat.
[QUOTE=claydough;2532]
Perhaps we need a “Fun with Blind Data” Thread?[/QUOTE]
Yeah could be useful… I’ve run into a few problems with it for some reason not that I’ve written anything myself with the intention of using blinddata since Maya 4, where upon it got screwed on a regular basis and caused much pain.
Never bothered since, which is prolly not the best and I’m probably missing an opportunity to do some things I wouldn’t usually do.
I’m also curious to hear about other’s experiences with blind data in maya.
we’ve been overloading vertex alpha with alot of properties, but working with vert alpha in the maya viewport is a pain in arse - i’d much rather use blind data, but have always heard horror stories about it.
Sectors - for the AI (this was supplemented with splines to define the area, presumably for the enemies)
Sound effects - only used for the floor, eg. wood, water etc.
Initially it was tricky to work with because BlindData is essentially history (at least that’s what my tools coder told me), so if you’ve got the construction history on expect lots of re-work everytime you cut, seperate or combine the mesh. So, as a workaround, I turned the construction history off when editing the collision mesh.
This has had an interesting effect on my workflow from that point onward where now I would work without the construction history and model, unless I needed the manipulator eg. after applying a UV projection or refining a primitive. :D:
To bring the thread back on topic, I find ScriptJobs can be incredibly useful. The process of setting up and destroying is better described in the Maya 2008 docs tbh. I’ve only written two tools utilising it though: an auto-update for textures on a clicked object and a paint weights visualiser. Looking at the scripts now, they’re a little clunky and I’d optimise them much better these days
