I believe this has been addressed before, but I found that it has become a critical blocker in my current project.
I am shooting off a bunch of missiles. Each Misses break into X amount of missiles each spawning their individual trails.
So in order just to have krakatoa partition my trails I need to be able to pick which spawn gets incremented.
I just thought I’d mention this as a possible work flow issue. I imagine there is a workaround, but I have not encountered it.
So what I would like to have is able to specify what operators or events get incremented.
Just a suggestion,
Thanks,
Andrew
Workaround would be incrementing the Seeds manually (after disabling all the Seed options) and saving the partitions one by one using the Current Partition spinner and buttons.
Possible solution would be to add notes to PFlow operators and/or events that prevent (or allow) Seed incrementation at a local level.
Please outline the EXACT steps you need - I need to know why you want some spawns to be affected and some not and what is the percentage of spawn operators that have to be affected vs. those who should not be changed.
I guess adding a note containing the string “NoSeed” would be easy for the user, but if you have to do it on 100 operators and then remove it again to do something else, it would be a pain.
In other words - do you want to change the collection of non-affected spawns (or other operators with random seeds) often, or is it something you do once and leave that way forever?
Any other ideas for possible workflows - like for example manually selecting all operators to be affected by name in a multilistbox similar to the PRT Loader rollout, or a double list like for the Matte Objects Named Selection Set where you move all operators to be excluded from one list to another?
Suggestions are welcome.
Same issue as in…
http://support.franticfilms.com/wb/default.asp?action=9&fid=23&read=472
Where you need one particle system to be the same, and use that to drive other particle systems.
The simplest solution would seem to be adding controllers to the seeds, where a constant controller would be applied to those that don’t change. But you can’t assign controllers to seeds, so that’s no good.
I WOULD consider that incrementing is likely much more common than NOT incrementing, so I would think that you would want to have an override for the incrementing, not a “increment selected” type function.
Actually, I like the “No Seed” string idea, but you can’t add notes to an operator. How about adding it to the name of the operator. Like “Position Object (No Seed)” and you just check for the string in the names of the operators? That would be REALLY easy for a TD to see and say… “Oh here’s your problem, you aren’t incrementing the seeds.”
Actually, I like the "No Seed"
string idea, but you can't add
notes to an operator.
I beg to differ. Select an operator, right-click>Comments, enter "noseed".
The operator gets a red angle in the corner denoting that it contains a comment. Click on the red angle and the comment dialog pops up.
Same per Event - you could write "noseed" in the comment of the whole event and I would skip the seed incrementation of all operators in the event.
Of course, we could support both "noseed" in the name, in the comment, and an explicit list in Krakatoa. But I guess it would be better to find the best solution and stick to it, otherwise there would be too many ways to do something wrong.
Thanks for the feedback. I will try something today.
Oh, ok. I guess red marker would help me to know which operators were being excluded. That would work fine for me then.
- Chad
Oh, ok. I guess red marker
would help me to know which
operators were being excluded.
That would work fine for me
then.
I think your idea for the NOSEED in the names is better so I started implementing that. While at it, I made sure all the actions are logged in great detail.
All that’s left is to copy this code to the Increment Seeds On Deadline script and I will post the SP for you to test…
Unzip the two files to your Krakatoa’s Scripts folder, then restart Max.
Note that Max Legacy Particles will also be checked against NOSEED so you can use the method to disable seed changes in those, too.
Tested locally and on Deadline - seems to work.
Also note that partitioning on Deadline currently uses the Animation Range regardless of the render dialog settings. Might have to fix this in the future…