I was/am trying to get a setup going to produce velocities that follow a spline and on top of that I was going to add some noise vector parameters so particles that are being advected by these velocites would move in a nice, flowing like manner. I’ve been messing a little bit with trying to use the mapping coordinates of a spline that’s turned into a mesh but I haven’t really gotten it to work. Any chance someone would be willing to help me get started?
After successfully producing this, I’d like to try and use the Ember_force Spacewarp to see how it works in conjunction with FumeFX. Any advice/pointers appreciated!
I would suggest using the Krakatoa PRT Hair object to sample the Spline to particles.
Then you can use the Tangent and Normal channels to get the orientation of each point based on the spline’s curvature, and sample those particles with ParticleSumRadius. Simply add the Tangent (and/or Normal) channels to the list of channels to sample, divide each one of them by the Weight output, and you will have the average Tangent and Normal vector within the specified Radius. Play with the radius as needed. Output the result as Velocity and voila!
If you output the value as Force channel though, you can make a Space Warp, but you will have a very hard time accelerating your PFlow particles correctly unless you add a very high Drag.
It is much better to use Ember Follow and simply assign the Velocity to the particles so they would stay on the spline…
Attached is an attempt with Force, Ember_Force and Drag of 20% (Max2010+): EMB_FollowSpline_v001.zip (19.8 KB)
Let me know if you encounter any problems with this approach, and I will try to help…
Even easier with Stoke - create a PRT Hair, drop a Magma and copy the Tangent into Velocity (multiplied by some factor), pick the PRT Hair as Field Source and off you go…
Unfortunately, the Field filter function is missing the PRT_Hair entry, so you would have to modify the script a bit. I will fix this internally. The modified script is included in the ZIP below.
Attached is an example scene (Max2010+) with Stoke: STK_FollowSpline_v001.zip (35.6 KB)
Of course, this does not give you a Space Warp, but I am seriously thinking about that now
I suspect we could expose a Force channel from Stoke and make the Ember_Force accept Stoke as a valid source…
Thanks for posting the example! At first I didn’t notice that you edited your post but I did catch it as I was about to reply. Really appreciate it. Regarding this little bit you said at the end, this would make me a very happy person! I do a lot of FumeFX work and for better or worse, Spacewarps are really the only real source for velocities that we have right now.
Edit: Just tested your example, exactly what I was looking for. Thank you!
I was modifying your vecnoise SimEmber file and was able to easily split out the vectors, and multiply the ABS value of the Y axis so I could run some FumeFX smoke through an Ember_Force and have it travel stronger in the Y axis but with some noise on X and Z. What I am stuck with is trying to figure out a way of not having the Ember_Force accelerate my FumeFX indefinitely. I am not sure how to tell SimEmber and Ember_Force that once you reach a certain velocity you stop. SimEmber and EmberForce doesn’t have a concept of how fast the voxels are moving so FumeFX just looks at the Spacewarp vectors and keeps accelerating. Any way at the moment to counter this?
This is AWESOME. I combined two Sim Ember forces with Particle Flow (your spline one, and a simple one using vecnoise – I know I could combine them into one magma flow but it’s fine having them separate for now). Going to do a FumeFX sim next using these Ember Forces. The particles move beautifully and being able to control it with the spline to go exactly where I want it to is fantastic. Going to post a simple preview here in a little bit.
Here’s a very simple preview based on the Spline solution you posted with some VecNoise added. I really like it because it’s following the spline perfectly, and I can use it with FumeFX for my next step since it’s using Ember_force.
Next step to make this complete for me is to attract velocities towards the spline if they stray too far away. Should be able to work that out.
Still feel I haven’t had enough time to really dig into Magma more than to create the basics I’ve needed for certain jobs but a lot of things are making sense and I can at least modify your flows with predictable results. There are a couple of concepts of Magma that I don’t fully understand, like I haven’t used a system that uses divides as much as Magma does but I’m going to go through the tutorials and learn the thinking behind it. Naiad seemed weird first times I used it too but everything is crystal clear with how it works now so I hope I can adjust if I make some time and really sit down, watch all the tutorials and learn the basics of Magma. A lot of the logic does feel familiar which is why I feel comfortable adjusting existing Magma flows, it’s just a couple of concepts that feel odd to me right now. Thanks for being so helpful Bobo, it’s very much appreciated.
This is the major pain with Space Warps and the reason we are attempting to stay away from them. They are Forces, and the value they provide is an Acceleration. In Max, adding a Wind or Gravity Force without any Drag Force to counter-act it (resistance of the medium) will result in particles accelerating forever.
Stoke, SIM_Ember+Ember_Follow and FumeFX+FumeFX Follow all apply Velocities to the particles. In other words, the particles are stuck in the medium and flowing WITH the medium. If the medium is not moving (no velocity), the particles stop. The same effect can be achieved in PFlow by adding a Drag of 100% and increasing the Force so that the resulting Velocity is reset on each frame. This is why Stoke creates much more beautiful motion from Turbulent Wind than PFlow with the same Wind - the one uses Velocity, the other uses Acceleration by Force.
The CORRECT solution which is planned for Ember is to allow you to inject Velocity fields directly into FumeFX, so you don’t have to go through a Space Warp. Kreso even proposed to open the Effectors for us so we could have Ember set ANY channel inside of Fume, not just velocities. Since you are one of two main FumeFX Beta gurus, we would hope you would assist us with getting that workflow right in the near future…
Ember has a steep learning curve. It took me a week to get comfortable thinking in Ember terms, and I had a pretty good Magma knowledge at that point.
This is another reason we wanted to have Stoke as an “Ember Light” product where you get some of the abilities, but none of the learning pains…
Here are the major points to keep in mind:
*Ember uses two Magma flows - one initializes fields on frame 0, the other processes the fields on every evaluation step.
*The Simulation flow distinguishes between two major types of fields: Velocity, and everything else. The Velocity field is the “driver”, all other fields (both Scalar and Vector fields) are automatically advected on each frame according to the Velocity field.
*If you don’t Initialize the Velocity field, it is 0 everywhere and nothing will move.
*If you only initialize the Velocity field on frame 0, it will remain static over time and the other fields will flow through the same field during the whole simulation.
*If you set the Velocity field on every frame, the field will change during the simulation and things will be even cooler
*You can reset any field during the simulation at any time, or inject more data by adding to an existing field - for example, you could use InputChannel:Density, Add a value to it (e.g. if a sample is inside an object or close to a surface or whatever rule you want) and output to Density. The result will be more Density injected into the Density field which then gets advected by the velocity - if you sample the Density field with a PRT Ember and render in Krakatoa, you will get smoke emitting at the source and moving with the velocity field…
Most of the time, you don’t need half of the Ember-specific operators, and the non-Ember operators are identical to the ones found in Krakatoa Magma.
Instead of looping through existing particles, SIM Ember loops through all voxels of the grid according to the current spacing settings.
Normally, you provide the Position channel as input to Ember operators to tell them where to sample, so you can explicitly force it to sample somewhere else and not at the current iteration’s voxel position.
PRT Ember does not simulate, it simply creates a particle if you set a Density value greater then 0 for the current sampling point. It behaves like PRT Volume or PRT FumeFX, but has the ability to input data from various sources via the InputField operator. So PRT Ember could be used to recreate PRT Volume by using the Ember>LevelSet operator, PRT FumeFX by using the InputField operator with a FumeFX or FXDs as the source, and so on. To a large extent it is similar to PRT Maker, but it has implicit loops along X,Y and Z of the Grid, while PRT Maker would require you to produce the loop yourself out of a linear loop through N particles…
This is the simplified description of the Ember basics. There are of course some powerful operators in the Ember category that make sense in the world of fluid simulations, but in a lot of cases you can produce quite interesting results without knowing the advanced features…
Please keep on posting questions, this will help both sides since we need to create documentation, and you need to understand Ember…
Thanks for the posts, it does help a lot. I remember you did mention the integration with FumeFX and possibly its effectors and I am very excited about this future. It will make FumeFX and Ember go together like bread and butter and will be a tool no one using 3ds max would want to go without. Even with the issues of acceleration, being able to use Ember_force is still producing some rather nifty results not possible without Ember.
At the moment I am using a copy of my spline with wider radius and a shell on it to check when particles are going too far away from the spline and trying to use the normals to direct the particles back towards the spline. Not sure yet if this is the best approach. I’ll keep you updated on the progress and whatever issues I run into. I appreciate all your help.
I did use the levelset a couple of months back to create voxels and used the Ember map to render hand sculpted clouds which was really cool. Probably similar to your mushroom example on the Ember page. Lots of very awesome stuff in Ember and I am doing my best to wrap my head around all these concepts and get to a point where I feel very confident with Ember. Step by step!
Would you have any issues with posting your Mushroom cloud example? I realized you used the spline approach rather than a levelset of the geometry as I was going through the videos again and it seems that I can learn a lot from this example and apply it to what I am doing right now.
In the meantime I’ll see if I can replicate your magma flows from the video. It’s a very cool example.
Ok, so I thought I had created a setup that would push the particles back towards the spline if they strayed too far away. Here’s what I did:
Opened your file – everything worked
Added a vecnoise and added it as another Ember force – that produced the quicktime I posted and worked as expected
Attached is a screenshot of what I attemped to do next to draw the particles backtowards the spline if they moved too far away from the spline, I just used the normals of a cage to create velocities pointing back to the spline
I attached a screenshot of exactly what I added. As soon as I try to step a frame, Max crashes. What am I doing wrong?
I think I solved it. I had forgotten to change the new SimEmber object to use the Normal instead of Tangent. That seems to have fixed the crashing and I believe it’s all working the way I wanted it to now.
Edit: Works like a charm! I get a really nice fluid like motion that never leaves the area I define around the spline. Next step is to try and use this in conjunction with FumeFX. www.tobbeo.net/pathfollow_withvecnoise_constrained.mov
I get a lot of crashes when using Ember_Force with FumeFX. My theory was at first that perhaps if FumeFX are sampling velocities from EmberForce where it doesn’t have any, but I added a constant velocity/force and used an ADD node to make sure that even outside the sampled particle areas there is a little bit of velocity and it did seem to help but the crash just came later instead. If I increase the ParticleSumRadius it does not crash.
I think you are getting a Division By Zero in some places. My bad!
You can add a test (Switch operator) for ParticleSumRadius:NumParticles Greater than 0 and pass the result of the Division to the Output only if the NumParticles > 0, otherwise output 0,0,0 instead.
To make this easier in the future, we want to eventually allow each output to be weighted or not via a per-channel option instead of requiring an explicit Division by Weight and this > 0 test…
Also, our internal version of Ember already has a new ParticleSplat node that does with any particle channel exactly what Stoke does with Velocities on a grid, so you can produce a perfectly nice scalar or vector field from any particle channel in just one operator!
We are in the same time zone . I just tend to be a night owl. There’s no rush, I am just playing around trying to work out these issues. Yes, PFlow sees the force. With Pflow everything works fine using the forces (instead of EmberFollow). With FumeFX I am not using PFlow at all, I am just using a simple source, and a force ember spacewarp (follow spline example you gave me). Before I added the switch, FumeFX would sim but would crash if it went outside the ParticleSumRadius (at least that’s my assumption since if I increase that value, I don’t get crashes). After adding the switch, FumeFX just starts simming but doesn’t go past the first frame. It just sits there idle. Max isn’t frozen and no CPU usage is showing up in task manager.
Edit: Adding the switch causes the Pflow setup to crash if I step a frame. Without the switch it works fine.
Can you save the Flow (or make a screenshot of your Magma editor) and post it?
I assume it is exactly like mine, but I want to be sure…
Also, is it possible that Fume goes out of the SIM Ember bounding box at any point? I wonder what value is provided by Ember_Force when asking outside the Ember grid…
Sure! Here’s the pflow max file that crashes once I’ve added your switch (remove the switch and it works fine). It uses the FollowSpline you supplied, as well as a VecNoise SimEmber and another SimEmber to make sure that the particles don’t go too far away from the spline. I know I could probably combine these but my knowledge is limited right now so when I got it working I was happy even if it uses three SimEmbers.
And here’s the FumeFX, it just uses the FollowSpline Ember Force. With the Switch operator it won’t go past frame 1, without it does simulate but will crash if the ParticleSumRadius is too low.
I expected it would be this error, but I did not expect it to crash Ember.
Basically, your Logical operator (Greater Than 0) is wrong.
The value coming out of the ParticleSumRadius is an Integer.
Your second value is 0.0 (a Float). In my example, I had it changed to Integer and meant to tell you about it, but I assumed you would replicate my flow exactly…
Open the flow, select the Greater operator, select “Integer” from the Value Type list and it should start working…
We have it on the list to remove this limitation and make 0==0.0 work without conversion in all Magmas, but right now it is necessary to match the types.
It is only Ember that crashes Max instead of reporting an error under these circumstances, so this is a bug…
