Hey guys i have big problem to resave particles with prt loader in pflow back to prt. I have realflow 2013 simulation saved directly in realflow to prt with all available channels. In pflow i am using krakatoa prt bitrh and in global event i am putting krakatoa prt update. I am using group selection by box to separate some particles and assignim them different mapping. So when particles go tru that box they will have different material. This everything is working but.
The problem i have is when i want to prt particles in pflow behave exactly like in krakatoa prt loader i need to check in pflow krakatoa prt update node id and positon channels because when i chceck to also use velocity channel the bahaviour is different. The problem is when i am saving back this particles into prt they have zeros in velocity channels, so i can use them with motion blur. Do you know how to do in a way where i can save all chanels back like it was from raw prt but only add new chanels from pflow?
So i thought maybe i can reuse channels somehow in magmaflow in a way where i put newly saved particles from pflow in prtloader, i put magma modifier on top and in the magma modifier i put as an inpul old particles from old prtloader with loaded raw realflow particles and i conect thyr channels somehow with particles from pflow, but it doesnot work, so my second problem is if that is possible
The problem seems to come from the PRT Update operator not applying the Velocity channel from the original simulation. I understand why you have to uncheck it - when PFlow finds a Velocity that is no 0,0,0, it advances the particles forward according to the intergration step, so their positions are up to a Frame ahead of the original simulation. A possible solution would be to add a Magma to the PRT Loader being loaded by PFlow, and subtract a fraction of the Velocity from the Position channel BEFORE the PRT is loaded into PFlow. Now the Velocity is expressed in Units Per Second, so you will have to divide your Velocity vector by a certain number to adjust the Position according to your Integration Step in PFlow. If the Integration is 1 frame and your Frame Rate is 24 FPS, you will need to divide by 24. If the Integration Step is half a frame, you will have to divide by 48 etc.
Once the adjusted Position and the original Velocity are loaded into PFlow, it will add the Velocity to the Position and hopefully bring it back to the exact position that RealFlow saved.
When you save new PRTs from this PFlow, both Position and Velocity should be better than what you had before.
Please let me know if this makes sense and whether it works for you.
You can achieve a similar result using DataOps in Max 2014, or in PFlow Box #3 in earlier versions.
If we could ensure that the ORDER (Index) of particles won’t change between the incoming PRTs from RealFlow and the outgoing PRTs from PFlow, you could simply ParticleQuery the Position channel from the former into the latter using the Index channel as ParticleIndex input. But if your PFlow changes the order due to multiple events or some other internal calculations, the particles could go off-sync. There is currently no way to query a particle by ID (although it is on the Wish List for future updates).
Bobo thanks, but the problem i think is, when i check in prt update operator position and id the particle moves exactly like in prt loader, so when i will chcek also velocity it adds them offset because of additional speeed i chceked so they start to be off. I am missing there possibility to read the velocity (so it can be saved in prt) but not apply it in pflow.
Please try reading what I wrote in my previous post. That is exactly what I explained.
If you
*Check Position
*Check Velocity
→ PFlow shifts the particles by one frame ahead because it Integrates the Position by Velocity. This is a problem.
So if you
*Add a Magma to the PRT Loader that is loaded by the PFlow
*Load the Position, subtract the Velocity divided by (FPS/Integration Step), output as Position
→ Your PFlow positions will now be shifted BACKWARDS by one frame, and when the Integration happens, it will be move the particles FORWARD and they should go back to the expected Positions! This is the solution.
As for the Velocity Query By Index, here is what you need to add in a Magma to PRT Loader002, referencing the original PRT Loader001:
Bobo i am sorry, the setup looks complicated to me to do it without your help, can you please show me some screenshot for magma flow where you are showing how to substract velocity from position related to integration step of pflow. Realy thanks a lot and sorry for bothering