Just wanted to add my first thoughts on Stoke. I am at a phase right now in my life where I am beginning to consider (and probably will) start up my own one-man studio out of my office work space. This means stacking up on plugins that provide the features that clients often request. Ember is most likely going to be on my short-list but I might not be able to afford it to begin with, so I could see Stoke being a great stop gap for me. However, one thing I would really like to see in Stoke that would seal the deal as a simple to use plugin that does some things very fast without spending much effort in Magma, would be to just convert any particle system into a spacewarp. And/Or the ability to load velocities from PRTs and turn it into a spacewarp.
I’ve done so many projects over the last years where I often emit particles as velocities in FumeFX and while it works, I don’t find it ideal because it’s not smooth unless you use a lot of particles. What would be ideal would be to create a volume around the particles and inside the volume the velocities are interpolated based on the particles speed. So lets say I created a simple particle system with just some particles going upwards, instead of creating a spacewarp that has a radius around each particles that influences the velocity, I would like it if the whole region of space that the particles move through to pick up on those velocities so that I basically get a stream of upwards velocity without gaps. If the particles would begin to turn, the interpolation would make it so that the spacewarp’s velocities would gradually start to turn as well. After having used Houdini Apprentice, the way you can grab velocities from anything is really powerful and useful (and the reason I am so excited for Ember). Just having this one more feature in Stoke would to me, make it a perfect stop-gap until I could afford Ember. Of course this feature would be really handy for not just FumeFX but also RB dynamics, hair and cloth.
At the moment I feel that if I could afford Krakatoa, I would just generate lots of partitions with its current toolset and look past Stoke until I could afford Ember. Unless I am missing something that Stoke can do that couldn’t be done with Pflow, FumeFX and Krakatoa alone in its current build? What I am testing right now is to see the difference in how Stoke treats Spacewarps as opposed to Pflow/FumeFX. The biggest thing I see about Stoke’s feature right now is the ability to generate a lot of particles (and I guess if you have Frost, you wouldn’t really need Krakatoa). But if you have Krakatoa, generating lots of partitions may take a little bit longer but it’s not a huge deal. Thoughts?
The “Fluid Motion” mode of the particle interpolation kind of does this already, but I think you want something between the current two modes.
Right now Stoke can take a few particles and put their velocities into the voxels As Is, and if you use very large voxels, it might smooth it out so there is some velocity in every point in space around them. If you enable Fluid Motion, the whole bounding box will be filled with data because of the way the divergence removal recalculates all voxels.
I suspect you just want to filter the empty voxels to have a smooth falloff based on their neighbors to avoid the “no motion” regions?
Ideally your last sentence is what I am after, but what you said is already possible isn’t far off from what I want either. I must admit I haven’t played with Stoke as much as I wanted to so my post was based on what I read on the Stoke feature page, rather than trying to do something like this. Let me actually try what you suggested and I’ll share my thoughts again. If this works the way it sounds like it does based on what you described, I’d be very happy already!
So with Ember, I have an Ember_Force where I can pick a SimEmber or PRTEmber to generate a spacewarp. I don’t see a Stoke_Force? That’s what I meant by “However, one thing I would really like to see in Stoke that would seal the deal as a simple to use plugin that does some things very fast without spending much effort in Magma, would be to just convert any particle system into a spacewarp. And/Or the ability to load velocities from PRTs and turn it into a spacewarp.” Am I missing something?
Sorry to jump in here, but isn’t that what stoke is? I mean it isn’t a literal ‘spacewarp’ but it does exactly what you want a spacewarp to do in this case - unless I am missing something?
You are too hung up on the “SpaceWarp” thing.
We HATE the SpaceWarps, but they are necessary evil.
Both Stoke and Ember accept Force SpaceWarps as valid FIELD sources. This is not what these SW were implemented as, though. They were meant to define acceleration for particles, we abuse them as Velocities. That’s kind of ok.
Then in Ember, we added the Ember Force SpaceWarp in order to be able to apply Ember velocities to other Max systems like MassFX, Hair or even PFlow that know about Forces. So it is a workaround to integrate Ember deeper with Max.
Stoke on the other hand was NOT meant to be used as a source of anything. It is the end goal to produce moving particles and that’s it. Stoke is a simple tool that gets data from all possible sources, creates fields and particles, and saves the particles or renders them directly via Krakatoa or Frost.
Ember is the product that will be able to go both ways and in the future not only read, but also write FXD files and manipulate FumeFX simulations. It is the product that will do the advanced field processing, crazy logic and all the Houdini-type things people expect from a node-based tool.
In other words, Stoke is the entry level version of Ember. Don’t expect it to cannibalize all of Ember’s functionality.
What is on these videos is what Stoke is designed to do.
I have listed our future plans (a few missing features) in the Builds section.
We don’t have plans to make it do much more than that, and we want to keep it cheap.
That being said, we don’t know the price of Ember yet, either…
Yeah, no I get what you were saying. I guess the way I see Stoke right now, I feel that if I get Krakatoa, I don’t really need Stoke. Stoke makes some things easier, but it’s nothing I can’t achieve using Krakatoa alone. And having Stoke without Krakatoa seems fairly pointless too? Stoke is very fast at generating lots of particles from pflow, FumeFX and more but I can simply just use krakatoa to generate lots of partitions and forego the cost of Stoke alltogether. Stoke doesn’t seem necessary to have in my library if I already own Krakatoa. That’s why I felt that if I had the extra feature of being able to use Stoke as a quick way of generating forces for other 3dsmax plugins that I use, such as FumeFX, built in plugins like MassFX etc that accepts spacewarps, it would be very a very useful tool until I could afford Ember. It just seems to me that if I own Krakatoa, I would just rather save up until I can afford to get Ember. Stoke doesn’t do anything that can’t be done with Krakatoa alone – at least not anything significant.
Does any of the other beta testers feel any differently? My mind is open.
When I go into studios to do different projects, i’d say about 50% (at least) of the time they want to direct velocities in a specific way whether it be for fluids or rigid bodies. For one feature film, I was asked to spill blood onto an altar and then have the blood magically rise at very distinct points in a fluid like manner but also very directed. I convinced that studio to get a license of Naiad, and it went very smoothly as in Naiad I was able to control velocities exactly the way I want. On another feature film project a client wanted Smoke/Clouds to come out in this very directed way, like a magical effect, following concept art that someone had done for them. It’s pretty easy to come up with cool looking FumeFX motions but when a director is drawing lines on your shots things tend to get tricky.
I have lots more examples like those, and when trying to do these effects in 3dsmax, it can be a tricky prospect to really control your velocities. You can emit velocities using a particle source object, but it really isn’t ideal and not nearly as flexible and fast as doing it in say Houdini. This costs me time and headaches. This is the main reason I am so excited about Ember, not just because you can have all the fancy interaction setups using Magma, but to be able to more directly control my velocities. With Stoke I was briefly hoping, after I thought I’d misunderstood the feature set of Stoke, I’d get a very quick way of generating forces that I could then use with FumeFX, TP, Pflow or even Rayfire. While I understand that Spacewarps is not the most elegant implemented solution of forces in 3dsmax, it’s the only mass-supported feature of velocities we have in 3dsmax. But then I understand that we get into the discussion of what Stoke is meant to be as opposed to Ember.
The main reason for this thread was just for me to add my thoughts on why I, when I’m ready to start up my own one-man business, should spend money on Stoke and not just wait for Ember. If there are great reasons to invest in Stoke when you have Krakatoa, I’d love to hear them. I went through and looked at all the videos on that tutorial page.
I know at least one person on the Beta that would disagree after having used both Krakatoa and Stoke in actual VFX production.
But I cannot talk for him, let’s see if he will have the time to jump in and comment…
(I am not that person, just for the record I will guess his first name is Charley though)
What I am really interested in is the creation and distribution along animated meshes with animated maps, as this is where both pflow and TP are pretty much dead slow. Being able to have some control over velocity is a bit of a bonus, certainly not intense ember field like control but still a usable amount of control none-the-less.
Regardless of the velocity if you can get past the shortfalls of pflow/tp 's single threaded handling of maps (not 100% sure about animated meshes with TP) I am all for it. Pflow seems like nothing will ever happen in that regard, as for TP I can’t say.
Ok, yeah, that’s a valid point. I don’t run into situations a whole lot where I need to emit particles from animated maps but of course that’s not to say that other people don’t and that I won’t run into projects in the future where I will need that – and of course a significant time increase is valuable. I guess it all comes down to when it crosses that threshold of “this is enough time saved to justify the cost.”
Don’t get me wrong, I am grateful to be on the beta and I certainly can use it to generate a lot of particles from FumeFX or other particle systems quickly. My mind has just been so wrapped around struggling with velocities the last couple of years as more and more of my work has been directing fluids.
There was a project a month ago I did for a studio that required a lot of advecting particles into FumeFX and Stoke would have saved me time – perhaps even enough time to have justified the cost of Stoke (though I don’t know what the price will be yet). When I am working at studios, I always have to convince people to purchase plugins and the question always comes back; “do you really need it?”. Once I do my own thing, I’ll be asking myself that question too. I think experience with Stoke on a production will really answer that question for me. Perhaps I’ll run a test of generating lots of partitions and compare how much time I save when using Stoke instead.
Very late jumping in here but yes Stoke and Krakatoa allowed me to create an effect that would have been very difficult with just Krakatoa and another particle system. The general idea was to use existing prt’s then give them movement with Stoke.
We can manipulate prt’s with Magma and Modifiers but getting those particles to move individually is tricky with either of those solutions. There are a number of uses for Stoke that have been discussed, here’s one that I’ve run into. It’s very common to get client feedback that asks for slight changes to our big particle sims. In some cases I have been able to use Stoke to address these changes and that has been faster than revisiting the sim.
I will guess his first name is Charley though)