was wondering if there is a chance that thinkbox can implement a real slowdown for timegraph in the new version of krakatoa. the interpolation does not really work. lets pretend we bake the particles to real objects, they have keyframes, and we can stretch them out allowing us to slow down the objects animation. wouldnt this same functionality be possible with particles in the prt loader?
i know weve talked about this before a year ago, and the reason to not do it was performance i think, but what if the user decides to “lose” the performance to interpolate positions correctly? would this be hard to implement?
i think it would be a very powerful feature and give the timegraph a whole nother meaning
speaking of which, would it be possible to implement part of this script
(
local start = 0.0 --this is the first frame
local end = 1000.0 --this is the last frame
local step = 20 --this is the number of samples per frame
local cnt = start as integer --this is the counter for the current frame number
local theParticleFileName = (FranticParticles.GetProperty “ParticleFiles”) --get the output PRT file name
FranticParticles.SetProperty “Presets:SaveRenderHistory” “false” --disable history saving
for t = start to end by (1.0/step) do --loop from start frame to end frame with the given step
(
local theFileName = FranticParticles.ReplaceSequenceNumber theParticleFileName ((floor t) as integer) --figure out what the saved file will be called
deleteFile theFileName --make sure it does not exist yet
render frame:t vfb:off --call the renderer at a sub-frame to save a PRT with full frame
if doesFileExist theFileName do --if it was found,
(
local theBaseFile = (getFileNameFile theFileName) --grab the base file name, then build the new file name with suffix SubFrame_
local targetFilename = getFileNamePath theFileName + substring theBaseFile 1 (theBaseFile.count-4) + “SubFrame_00000” + getFileNameType theFileName
targetFilename = FranticParticles.ReplaceSequenceNumber targetFilename cnt --set the target frame number based on the integer counter stored in cnt
deleteFile targetFilename --make sure it does not exist before saving over it
renameFile theFileName targetFilename --rename the saved file to the new file name
)
cnt+=1 --increment the integer frame counter by one
)–end t loop
)–end script
We cannot discuss 2.0 outside of the Beta forums, so I moved your thread.
We now support sub-frame sampling and sub-frames in file names in XMesh, and we could potentially do the same with PRT files.
It would be optional and I think it is doable (but I will leave it to Darcy to decide).
I don’t see why you need Maxtrix to do the PRT sub-sampling the other script does. Maxtrix is quite outdated and meant for rendering cameras.
But, your proposal means that the user has to know and bake the slowdown during the saving.
So he cannot reuse the data again and again to create different arbitrary slowdowns, just one.
And if the saving takes 3 hours, he has to redo it again when it turns out the director wants it 2% faster
But I think this might fit in something we are discussing/working on right now. Let’s see how that will turn out…
And yes, unless released, Krakatoa 2 is Beta (and it was especially before we announced it at Siggraph). There were NDAs and stuff…
its always possible to do a proxy anim, to get timing right, once animation is “approved” we can be sure to use this in production workflow, either way i would think it makes sense for the krakatoa framework to be able to slowdown particles…
if a director wants a different fume sim, you have to make another one too,
i dunno… i would just love to see a real slowdown of particles for krakatoa (it would just make sense to have the real inteprolation and not linear), just like is possible with objects that are baked to keyframes…
hope that will be implemented when kraka 2 comes out
and of course curious about the method u are working on,
in my simple mind i would assume it wouldnt be that hard to slow down the particles
