I am retiming a realflow sim as prt loader via the retime graph, interpolate sub-frames activated. Movement works fine, but I am using the vorticity channel to color the fluid. As this channel doesn’t get interpolated, there’s heavy stuttering/jumping in the rendering.
My approach so far:
Create two additional copys of the prt loader. If my “master-render” prt loader was at frame 124.3, i was setting one of the additional prt loaders via max script controller to 124 “floor”, and the other to 125 “ceil”. By taking the 124.3 minus the floor 124, i get the 0.3 inbetween.
Now to what i wanted to do with magma -->
I added both additional prts with InputParticles, wanted to wire out the vorticity with a ParticleQuery, and blend both values with the 0.3 factor derived by script to get a smooth vorticity. The result should pipe into my render-prt vorticity channel.
Problem:
Index is not constant across the loaders, but ID is. But i cannot find a way to get the ParticleQuery ID based, it only seems to work on Index. Worse than that, InputParticle doesn’t seem to deliver the ID or the Vorticity channel to the ParticleQuery operator, althoug they are present. Magma complains, that those are non existent channels. Funny thing is, that Velocity, Position etc work.
In short words: I want to blend the vorticity (or in fact any arbitrary channel where it’s necessary) of a prt loader according to the retime to avoid stuttering- how do i do that?
Best regards and thanks a lot for any hints,
Michael
First of all, I tested reading a Vorticity channel from a BIN file loaded by one PRT Loader into another PRT Loader (loading the original BIN sim without Vorticity, so Indices were aligned) and it worked ok in Krakatoa v2.1.4, but failed in 2.1.5 which is missing the Index channel for some reason (bug, already logged).
Regarding your real problem, there is currently no direct solution. I spoke to the lead developer and he plans to implement both interpolation of more channels when the Interpolate… option is on in the PRT Loader, and particle lookup by ID channel in Magma for the cases where more flexibility is needed.
That being said, I cannot give you any ETA when that might make it into an actual build.
A crazy workaround might be to dump the Vorticity (which is a vector after all) into the Position channel and resave to a new PRT sequence, then load that with Interpolation using the same retiming curve as your other loader, and try to read the interpolated Position channel as new interpolated Vorticity into your main PRT Loader.
You might want to remove the Velocity channel when saving this new PRT sequence. With Velocity, you will get a cubic interpolation between the frames. Without, it is supposed to perform just linear interpolation between the two frames.
I have not tested this and the kind of interpolation applied to Position might make no sense for Vorticity, but you can surely try…
EDIT: I tested it with Velocity/Cubic interpolation and it looked good. I retimed both to play 10 frames over 100 frames, looked smooth…
thanks a lot for your help and your time!
That is indeed a crazy workaround - gonna grab the 2.1.4 and give it a try. Let’s hope I won’t need velocity or any other channels to color something, as my prt files are over a GB each - Krakatoa is still the most comfortable way to get rid of that nasty empty serverspace
I’ll report back tomorrow wether i got it working or not.
I just looked and I actually used a 2.1.3 build. But I am pretty sure 2.1.4 should work too. Just don’t use 2.1.5.
What were you running before? 2.1.x is not really necessary for this, I just wanted to let you know 2.1.5 Public Beta is broken
So the short step by step plan is this:
*Create a PRT Loader at the origin
*Load the PRT file with Vorticity
*Drop a Magma on top and pipe Vorticity into Position
*Open Krakatoa, switch to Save mode, specify a new PRT file name
*Set Save Channels to Position, Velocity and ID
*Set range to the frame range of your sequence and hit SAVE PARTICLES
Once you have the new sequence,
*Disable the Magma on your first PRT Loader.
*Create a new PRT Loader at origin and pick the new sequence
*Add a new Magma to the first PRT Loader.
*Set a flow with InputParticles pointing at second PRT Loader
*Use ParticleQuery with the InputParticles and InputChannel Index to read Position and output as Vorticity.
*Alternatively, output the data as PRTViewportColor for checking purposes.
*Now check Interpolate in both PRT Loaders and keyframe both with the same retiming animation (you could even instance the Graph track’s controller)
If everything worked ok, the first PRT Loader should now have interpolated Vorticities from the second PRT Loader’s positions.
Since the second sequence is a copy of the first, the particle count AND index should match as long as the timing is the same for both, so no ID is needed for access. The ID is only needed for the PRT Loader’s interpolation of Position values.
I am actually using an older build of Krakatoa, it’s 2.0.1.4693
With that build and InputParticles + ParticleQuery set to vorticity, it outputs the error message “Magma InputParticles did not have channel “Vorticity”: | ID: 3 | Input Index: 1 | Connected To ID: 2 |”, although it apparrently is there, because the repositioning works. But that’s not really important, as i need the position channel anyways.
But now wiring the position via InputParticles + ParticleQuery out of the modified loader into the source one just outputs a cloud of zeros - wired into output:position sets all particles to the origin, wired to output:color yields a pitch black cloud.
So i went ahead and installed 2.1.4.48313, problem persists, whatever channel i load via InputParticles + ParticleQuery outputs a bunch of zeroes. Vorticity also outputs the error above ( "Magma InputParticles did not have channel “Vorticity”).
I attached a screenshot from my Magma flow, could you check wether i’m doing something wrong here?
Very strange. When I did this in 2.1.3, I did not get an error. Note that I was loading BIN files from RealFlow, not PRTs, but that should make no difference if the Vorticity->Color works on that PRT Loader, another PRT Loader with Magma should be able to see that, too.
I have no reasonable explanation. I am going to enable 2.1.4 here and play with it. I know 2.1.5 does not work (but the error is that Index channel does not exist), and I used 2.1.3 (because I happened to have it in a folder from previous testing). It would be very cool if you could confirm whether or not 2.1.3 produces the same error in your scene…
Ok, it’s still not working in 2.1.3, but it seems, that it’s something about the freshly saved prt.
When i just copy the prt loader with the same source file, take prtloader001 and wire the vorticity into position, then go to prtloader002, ad a magma and read in the position from prtloader001 via InputParticles, ParticleQuery and InputChannel:Index out to position of prtloader002, both line up perfectly.
Now i save out prtloader001 (the one with vorticity to position) as prtloader003, with even only position as export channel, load that file back in again, and try to apply the position of prtloader003 to prtloader002 via InputParticles, ParticleQuery and InputChannel:Index, all particles gather in one single point.
Edit: and with the same .prt source file, it is also not complaining about the vorticity. Works fine. (2.1.3). But with the rendered out prt, same issue. I have to add “Vorticity” as an extra channel, but when dealing directly with the .prt in a loader, the channel is present and recognised. It just doesn’t work from one .prt to the other.
If you want, i could ftp you one of the source prts, the one i’m testing with is ~300MB.
Well it seems to be that disabling viewport particle display for the loader that you are loading into the InputParticles does no good for your viewport feedback.
…
Ok, tried it again, and that seems to be the problem. Magma flow takes the amount of viewport particles of the loader that you are accessing via InputParticles and only uses those for the other loader at viewport level - when you hit render, all is fine. So if you reduce the viewport particle count of the referenced loader compared to the other, only the number of particles visible in the vieport of the referenced loader gets processed when you update magma flow.
My mistake was, that i “automatically” disabled the viewport display for the freshly created “velocity to position” loader, as the particles were all over the place. Same viewport settings for both loaders now, one hidden, all fine.
OMG sorry for bothering you with that “strange case”…
That was also the reason for the non existent channel warning, as it didn’t find a single particle
At least I guess I found the solution (knock on wood), and maybe my little struggle can be a help to other users.
I had no clue that magma just uses the particle viewport settings when you hit update - i always though it iterates through the whole bunch and in the end displays just the amount that you specified.
Thanks a lot again for your patience and I am really looking forward to the new builds!
Michael
Actually it is very useful for both of us to know what you did wrong.
The first thing I did was set both PER Loaders to 100% and make sure they are in-sync particle count wise because we were using Indices and not IDs. I totally failed to suspect the cause, and now I have learned something for my future support activities!
So don’t worry, no problem at all.
Also, your original question caused two Wishlist items to be added to our Krakatoa To Do list (query by ID in Magma, Interpolate more channels by PRT Loader), which is great!
