I’m using a stoke field and inputting pf system 1 and running it through a pVelocitySplat and outputting a velocity.
In pf system 2 I am trying to use fieldforce selecting the stoke field. Whenever I do this, the velocity display in the stoke field disappears and the magma log says there is no velocity channel.
Link to the file is below. Scrub and you will see the velocity from the stoke field working just fine. Now turn on the pf_field_follow and you will see it all breaks!
You are victim of Max’ dependency system. Max does not allow circular dependencies (A->B, B->C, C->A).
Unfortunately, due to the fact that Particle Flow uses one system to host all Particle Flows, your two PFlow systems become dependent on each other when you insert a Stoke Field Magma that depends on the first PFlow, and then the second PFlow depends on the Field Magma. (in the above example, A=PFlow1, B=StokeFieldMagma, C=PFlow2).
There are two possible workarounds here, both are related to using a cache to break the dependency circle.
Option 1:
*Instead of using a Stoke Field Magma, create a Stoke Field Simulator in the same place
*Open the Stoke Field Magma Editor, press Ctrl+A to select all nodes, press Ctrl+C to Copy.
*Open the Simulation flow of the Stoke Field Simulator, press Ctrl+A to select all nodes, press Del to delete them, press Ctrl+V to paste the flow from the old flow.
*Select the PVelocitySplat node and uncheck the Remove Divergence checkbutton.
*In the Stoke Field Simulator, switch the drop-down list from “Simple Fluid Solver” to “No Fluid Solver”. These two steps are necessary to keep the Velocity field exactly as it is coming from PFlow without tweaking it to make it more fluid-like.
*Delete the Stoke Field Magma object.
*Press SIMULATE in the Stoke FIeld Simulator - this will capture the velocities of the first PFlow on the grid on each frame AND cache the field to an OpenVDB sequence.
*In the second PFlow, pick the Stoke Field Simulator as the source object - the Velocity channel will be coming from the VDB sequence and the dependency will play no role because the Stoke Field Simulator does not create dependencies the same way the Stoke Field Magma does.
Your second PFlow should now roughly follow the motion of the first PFlow.
Because there are not enough driving particles in the first PFlow, some of the second PFlow’s particles might get stranded after a while. You can send them out by Speed Test to delete or hide when they stop, or try to add more driving particles.
You should be able to tweak the first PFlow and then press SIMULATE again to capture the new Velocity field as often as you want. It won’t be immediate effect as you probably hoped, but the simulation should take only a few seconds…
Option 2:
*Keep the Stoke Field Magma as is and use the Stoke Field Data Exporter to cache the field to OpenVDB manually.
*Then create a Stoke Field Loader from the resulting sequence and pick it as the source of the second PFlow’s Stoke Field Follow.
*Each time you change the first PFlow, you will have to resave the OpenVDB sequence to update the Loader.
*Note that you will still have to turn of the Remove Divergence option in the PVelocitySplat of the Stoke Field Magma, otherwise your second PFlow will move very differently.
No, it is because our Fields can only be Float or Vector, but Orientation is a Quaternion (Float32[4]).
ParticleSplat uses a grid and cannot process Quats.
NearestParticles can, but Stoke Fields refuse to save Quat channels too. So it is possible to split a Quat into 3 Vector fields, but the Field Follow does not provide a good way to recombine them to an Orientation.
Basically you are stuck because you need to use disk caching to work between the two PFlows. But we cannot save a Quat to the OpenVDB file, and the data is lost. A Stoke Field Magma CAN create a Quat value and output it to Orientation to control the orientation of PFlow particles via Stoke Field Follow, but you cannot use a Stoke Field Magma as we saw in the beginning
I will have to discuss this with the developer and see what can be done about it…
Let’s consider it a Bug for now, although it might be “As Designed”.
Saving to PRT with Orientation channel and loading via Krakatoa PRT Update works as expected, but when I sampled the same PRT’s Orientation via a Field Magma and passed it to a PFlow, the resulting orientation was not the same. So there could be other bugs hidden here…
Yes I went ahead last night and tried to export Orientation to find out that wasn’t working
Before moving onto the disk caching of prts solution. I wanted to try a work around and see if I could get it to work. I ended up having a problem with matching Orientations as well! Like you said maybe some bug. Please read on.
This is what I did…
In the first pflow using a data op, I took the euler rotation and exported it into a script vector.
In the field sim I tried using particlesplat and also tried nearest particle with particle query to read the script vector, and then export it into script vector channel.
On the second pflow system , I loaded the script vector using the field follow operator. Now in a data op below that I’m reading the script vector and outputting this back into the Euler rotation.
My results:
The Euler rotation values do not match… Easy way to see this is by using the show data in both of the data ops and comparing them.
There also seems to be a 2-3 frames (beginning frames) of missing values/lag from the exported field sim script vector.
I attached the file. You’ll have to re-sim the field sim. That should be fairly quick.
The scene you sent me had an Initialization flow problem - you must define the MXSVector channel in both flows. It was not defined in the Init. flow, so it never got saved.
That being said, there appears to be a bug in the Stoke Field Follow when reading a Vector channel into the MXSVector channel - all 3 components get set to the same value. I also changed the setup to output the Rotation as Angle and Axis (one Float and one Vector field). The Float filed goes out correctly and gets read back correctly, but the Axis Vector seems to be corrupted. For example, the output of the PFlow 1 would be [0.408, 0.408, 0.816], the Stoke Field shows it the same, but then it is reading as [0.816, 0.816, 0.816] and the last 2 particles are totally busted as
47 [0.816, 0.816, 0.816]
48 [0.816, 0.816, 0]
49 [0.816, 0, 0]
I have notified the developer to take a look. I suspect it is a bug in the Stoke Field Follow setting the MXSVector channel.
The good news is that setting the TextureCoord channel to MXSVector in the Stoke Field Follow brings in the correct data. So switching the DataOp to read from Mapping 1 produces the correct orientation! Note that the animation will be trailing by a frame due to the way the PFlow is evaluated. To fix the trailing, do this:
*After simulating, press the [+] icon in the Sim object to create a Stoke Field Loader with the same content
*Increase the Offset from 0 to 1 - this will load frame 1 on frame 0.
*If you now pick the Stoke Field Loader in the Stoke Field Follow, the rotation will match perfectly (reading the MXSVector into TextureCoord and then reading Mapping 1 into EulerRotation with the DataOp).
That’s interesting you were having a initialization error with the scene I sent. I’m running the latest build (Version 2.0.14.56383) in 2014 and 2015 and I am able to write out a mxs vector or any other channel without having it in the init flow! I get no errors when simming and the data loads in just fine.
No, I did not GET an error, it just wasn’t doing anything - when I tried to display the MXSVector channel as Color and Line in the Viewport, it was not on the list. The simulation did not error out, it just did not save the data, and the PFlow did not read it either since it was not there. Once I copied the Output>MXSVector from the Sim to the Init flow, it started caching the data.
We have posted an updated build 2.0.15.56764 that contains a fix for the Field Follow MXSVector loading. So your original scene (plus the added MXSVector Output in the Init flow) now works as expected (just a frame behind). You can do the Loader + Offset workaround to perfectly match the rotation.
In addition, due to popular demand (by one user ) we have implemented the ability to float the Output nodes by pressing SHIFT+CTRL+O.
The update installer of 2.0.15 is in the same download folder where 2.0.14 used to be…
) we have implemented the ability to float the Output nodes by pressing SHIFT+CTRL+O.