The scene contains a EmberSim (solver None), EmberForce(was try to get some force with box#2), a simple grid, and a pflow system with an EmberFollow.
So I have the EmberSim using the velocities of the the Fume grid and that in turn piped into the pflow system.
So EmberFollow is causing velocity influence on the grid but it seems to be tenfold short, as if I could set the percentage to 1000% it may be correct. It reminds of the the force percentage in the standard force op how 1000% in pflow is equal to 100% influence in the old legacy particle systems when using a spacewarp such as wind or gravity.
If I add the 30.0 float multiplier to match the internal timing with the FPS, the pflow system now appears to match corrects but the SimEmber display velocities are insanely long.
So should these velocities display as such? It doesn’t appear to be an accurate representation. Is say this because if I switch the pflow display to lines they nearly match the un-multiplied results of the SimEmber Fume Velocites.
So can something be done to get these to match or display properly? or if I could set the percentage param to 3000% would it then match? can EmberFollow have some internal automagic ?
This is because the velocities from FumeFX come in as Units Per Frame. Ember, just like Krakatoa, works in Units Per Second, so you must multiply by the FPS. The Display options in SIM Ember do NOT compensate for this, you are going to see 30 times longer velocities displayed - that’s what the value is once multiplied. You can enter 0.033 in the “Scale” field for Vector Channel (Velocity) display to make them look like the stuff shown elsewhere.
Keep in mind that PRT Loader does the rescaling internally when showling lines. PFlow does it too (internally PFlow uses units per tick!).
But if you use PRTViewportVector to show raw data in, say, a PRT Volume sampling velocities from particles, you would have to DIVIDE the value by the FPS or you would get the same overlong vectors drawn, so this is not exactly a new problem.
Things we could do to simplify the user experience:
*When Velocity is selected for Display in SIM Ember, scale it down to Units/Frame automatically. This would be bad because it would not show the RAW DATA, in other words if you pipe the same values into Velocity and, say, Mapping2 and show the one or the other, the viewport would display them differently, making things even more confusing.
*Another checkbox “Velocity Per Frame” in the Display controls area might be a better option, and it would be checked by default. When “Velocity” is selected for display and the option is checked, the value will be scaled down by the FPS for display only. When unchecked, the raw data would be shown.
*Read the velocities from FumeFX in Units Per Second. This would remove the necessity for multiplying the value by FPS before passing it to the Velocity field of Ember.
I think doing the last 2 would simplify things, but I will have to wait and see what the rest of the team thinks about this.
So I can get massFX Force in Box#2 to work BUT how do I get rid of these lingering velocities. They keep effecting after the “good” velocities have done their job. I was hoping that since I was using the Density channel with Fire that when there was no longer fire there would be no density. That seems to be incorrect.
Density and Velocity used to be required in earlier builds of Ember. In the current Alpha 2, you don’t have to specify either, they default to 0 if not provided.
You could simply read the Velocity from the FumeFX, compare with some threshold to filter out the ones you want, multiply with whatever numbers you want and output as Force. Connect with Ember Force and apply to your Box #2.
Use the logic of Magma to filter out only the velocities you want. Use the Display in SIM Ember to show the actual Velocity vector, scaled down as much as needed…
Well since fire is only there for a few frames should it not default to zero? That was what I was hoping would happen. I can’t tell what is happening without the debugger or some sort of PDViewer
For instance if I create a PRT FumeFX and a simple magmaFlow inputChannel=Fire->outputChannel=Density and after all the fuel has burned there is no longer any Fire and the magmaFLow fails, the nodes goes red, why? shouldn’t it still be writing 0.0, fire says 0.0 in PDV.
So to help clarify some confusion, is density a seed that lives forever? or is it evaluated per time sample? Doesn’t a 0.0 coming from an input push that out to the grid?