When incrementing seeds, the tp seed increment doesn’t go past the first level of Dynamic Sets. I fixed it myself, but thought this should be resolved for future releases anyway… it simply needs to be recursive… i’m sure you’ll make it prettier bobo… i just hacked it together real quick because we needed it… only tested once so far… but it worked!
Guess this should’ve gone to Bug Reports… sorry!
Changed In the IncrementAllPartitionValues function:
Thinking: (
if incrementThinkingRandomSeeds then
(
if matchPattern (g.name) pattern:"*noseed*" then
FranticParticles.LogProgress (" -Skipping Thinking Particles [" + g.name + "] - NOSEED requested via Object's Name.")
else
(
recursiveincrementTP g incrementvalue
)--end if not noseed
)--end if TP on
)--end TP case
Added above that function:
[code]
fn incrementdsops ds incrementvalue =
(
for op = 1 to ds.Operators.count do
(
theOp = ds.Operators[op]
if isProperty theOp “RandomSeed” do
(
–FranticParticles.LogProgress (" >Adjusting Random Seed in TP [" + g.name + “], Dynamic Set “+ ds as string +”, Operator “+ op as string+”…”)
theOp.randomSeed += incrementValue
FranticParticles.LogProgress (" +Random Seed in TP Operator adjusted by ["+ incrementValue as string +"] to [" + theOp.randomSeed as string + “].”)
)
)–end op loop
for dssub = 1 to ds.numsubs do
(
if (try(not matchPattern ds[dssub].comment pattern:“NOSEED”) and (matchpattern ds[dssub].name pattern:“DS*”) catch(false)) then
(
theds = ds[dssub]
incrementdsops theds incrementvalue
)
else()
–FranticParticles.LogProgress (" -Skipping TP [" + g.name + “] DynamicSet - NOSEED requested via DynamicSet’s Comment.”)
)
)
fn recursiveincrementTP tp incrementvalue =
(
theMD = tp.MasterDynamic
for i = 10 to themd.numsubs do --starts at 10 because there are more subanims in our version of tp...
(
incrementdsops theMD[i] incrementvalue
)
)[/code]
Side note: my load preset doesn’t seem to be actually loading my preset… doesn’t change my tp groups or even my output path… any chance you could check that? If anything, i’ll have a go at it tomorrow…
That’s the beauty of MXS-based UIs - instant DIY help.
TP Groups are handled by … TP. Krakatoa just provides a simpler more obvious UI to the renderable checkbox of the TP group. So I would not expect those to be affected by presets.
But the save PRT files path should be stored and restored. Which of the many options are you using to load presets?
Ahh… I can add my own functionality for storing the tp group settings… no biggie assuming the load preset dialog will work. Essentially i’m going to be dealing with two sections of dust independently (same max file) and will want the file and group settings to be set accordingly… Almost like a “save state” type of deal, preferrably by the load / save preset dialog (presets and history rollout), which is what i am using. The compare settings fields seems to pick up the settings, but it doesn’t change my save particles field when i hit Load preset.
^^ Haven’t had time to check the preset thing… any word?
…I’ve been busy (really this only took me an hour) modifying the code for tp to make the partitioning faster, as per your suggestion on cgtalk a while back… forums.cgsociety.org/showpost.ph … tcount=405 I got the paritions down to 10 minutes from 2 hours. Before I post it up for anybody, I was thinking maybe I could try and add a postframe render callback for the perframe progress…? Would that even work…? I’ll probably try it later anyway. We’re only really using tp here right now, so it doesn’t matter too much, but I also want to make it so it only does it this way only if there is a TP it’s working on (for everybody who uses pflow too).
