I hope you had a great and safe new year and that 2013 is wonderful.
To start off 2013, FluidSim is $10 off!
FluidSim is a realtime fluid simulation tool that easily integrates into projects. It supports both Unity Pro and Unity. (GPU features are only supported in Unity Pro.)
iOS support is now complete and on the store in the most recent version. Some features are not supported.
they discuss a Houdini option for generating the directional vector image (fluid sim) and I wonder if your tool can be used in a similar way, or generate the required maps?
Aaand lastly - is it possible that we might have an option for wrapping (or tiling) the image, as that would be handy for fog/cloud/etc, by using a “stopped” sim (by animating the UV co-ordinates (if it has any!))
2 - Access to the output texture is available from multiple methods. The FluidSim script has a material input and a string where you can type in the property name you want the texture to be set to. so for instance you could put in your own material with your own shader and tell it to set the texture in the “_MainTex” slot.
OR
The output texture is a public variable and you can access it from the script the same way you would with any other code.
ADVANCED SETUP:
You can setup FluidSim to output to a material on any object, the material does not have to be on the fluidsim actor. This allows you to have the sim space invisible while outputting to custom object.
3 - You can have as many inputs as your performance will allow. I have an artificial limit of 128 inputs set in the script only because I dont expect anyone to hit that high of a number. IF you need more, its a single variable change in the script.
4 - FluidSim has a buffer specificly for velocity, you can also have an influence specificly add color, velocity or collision or any combination of them. There is also a “starting velocity” you can apply to the whole sim as a value or a image across the image. the starting velocity will decay over time though where a influence actor “painting” across the sim can be told to influence the fluidsim every frame.
Fluidsim will already do feedback similar to a flow map and in many ways it will do it better, but trying to “add in” flow map specific techniques would likely negate the methods of a FluidSim.
If you look at the FluidSim video, the simulation seen in the begining sounds similar to what you are talking about. it uses four inputs that add color and velocity and the entire sim uses a texture for collision which the inputs interact with.
4.5 - The velocity texture buffer can be output and used with other shaders/ideas, FluidSim was designed to be as flexible and usage as possible. If you decide to use the velocity buffer directly, be aware, its color range is -1 to +1 to allow “fluid” to move in all directions.
5 - I am not sure I understand what you want out of the tiling, but its a standard Unity texture setup and I believe will allow what you want.
This is friggin awesome man, and thanks for selling it at doesn’t-hurt-your-wallet price.
I’m just playing around with it at the moment and I want to use it in a 2d platforming game. Basically I’m thinking about having it as a cool way of giving the player a trail. One thing that would be very useful to me is the ability to make the textures automatically shift the pixels when the fluid moves. At the moment if you were to load one of your examples and drag the plane around all the pixels stay in the same place relative to the place. Do you think you could advise me how I could add a feature like that? Basically just a method to tell all the pixels in all the maps to offset by a texture unit or something (but filling the edges with black). That way I could create the illusion that the smoke is infinite while only handling the smoke that’s near the player
Thanks for the answers. I guess I wasn’t clear about the wrapping, or tiling in x and y (last question). What I mean is that is it possible for the fluid sim to “wrap” its result across the texture space (so a fluid that “falls” through the bottom of the plane is “continued” up at the top)? I can see that functionality being very handy.
@ Divide
Hehe, I have a project where I want to do something similar. I wanted to make an “infinite” resolution sim. You mention doing a pixel offset, i think it would be relativily that easy, the harder part is it needs to be done across about 5 different buffers. At some point I intend to add the feature you mention, but I dont think that will be for a few week at a minimum because of my other work loads. If you decide to do it your self, look at the list of buffers at the top in the FluidSimScript. You would need to offset all of the buffers for it to work correctly. If I remember correctly, Color, Velocity, Collision, Pressure, Divergence.
@ bigSky
I understand now… like space invaders
Correct, I cant think of way to do this is the current setup, like my answer to Divide, I expect it would be fairly simple but it would need to be applied to all of the buffers to work correctly. one of the differences though is that for a truly “stable” sim, you want to clamp the edge pixels of a sim. so in reality you would want to cut off a few pixels from the sim and then write into those the repeated edges from the other side of the image. If you didnt it would either detect the image edge and do nothing, or it would “explode” and cause fluid to start shooting everywhere in the sim.
I will add it to the list of features to add and post once its available. I currently dont have an e.t.a., but I will try to get to yours and Divides requests without to long of a wait.
Hi Pheck Nice plugin on fluid simulation.
I am an artist. Sorry for my dumb questions.
I am currently developing a top-down infinite scrolling game, where a fish is swimming in a vast area of water. Particles are affected by the flow of water. Like this:
I found MASFluid . That effect is almost what I am trying to realize except for its fixed boundary. But it’s really hard for me to port that into Unity. so I tried to find fluid sim plugins in unity asset store. Fluid Sim seems to be the right one I need. But I still need to customize it alot. The question is: how to simulate and visualize particle movement in FluidSim. and by the way, how soon will the infinite sim feature be out. Sorry for dumb questions.
Although to be honest I dont really think that video shows off all the great results that are possible with this plugin. I will post some myself once I’ve had a few more weeks to play with it.
@ilya_ca
Thanks for the feedback,
There is a video link available in the asset store and on the official forum page. there is also a video link on the website. But your right, I did overlook adding one to this forum thread.
Here is a link and I will update the top of the thread:
hmmm… what you want is possible, but I worry about you getting enough resolution to be happy with it. I have similar plans but I have not had a chance ot set it up. I want to create clouds and then move them around hills by having them follow the velocity path of the fluid. I think an important test would be to first get unity to render enough particles to do what you want while looking at a normal map for the “motion”. If you can get that to work and it runs well enough, then fluidsim could easily be pluged in where the normal map is by use the fluidsim velocity buffer.
FluidSim also has a CPU mode which runs much slower, but the advantage is that the cpu method works with arrays instead of textures. you could then look into the array for what your vfx should do… Really it would only be an advantage if doing the texture lookup for thousands of particles isnt fast enough.
As for “infinite sim”… I am currently adding that to a different project of mine (about 70% done). Once I get it working I will be thinking about porting it to the fluidsim. I cant give an exact date and I would recommend not planning on it any time soon. There are a lot of factors in getting it to work and unfortunatly all of those factors could lead to potential setup problems for people down the road. Once I get my version complete, I will better be able to understand how easily it would integrate into other peoples projects and how it would impact performance.
I tried to used MSAfluid as the solver and make unity to render 5000 particles, and the result fps is around 30, not bad. The next step is that I will plug in FluidSim to replace MSAfluid. I tried to read your code, find that “velocityRenderTextureSource” is where the velocity buffer is, but still have no idea how to extract the pixel data in that RenderTexture into usable velocity array data. Could you provide a handy helper function? I am sorry that I just began to learn programming.
The other question is, did you use Jos Stam’s solution to solver Navier Stokes equation?
Yes, FluidSim was built using Jos Stam and other papers as reference, but its not explicitly the jos stam method because it has some changes.
hmmm… I dont know your setup well enough to provide a helper function. Any helper function I would create to get the velocity info at a pixel would use the GetPixel method (you would first need to convert the render texture to something getpixel works on). but if you tried to run that 5000 times a frame it would destroy performance so its not even worth thinking about that method unless you just wanted a proof of concept and didnt care about performance.
What I would recommend is one of two ideas:
1 - this system you are talking about sounds very complex but this system sounds like it would work very very well in dx11 using a compute shader. A compute shader could take in the velocity texture from fluidsim, compute all 5000 particles movements, then send the data back to be applied to the particles. you could even render your particles using a shader that looks at the computer buffer for position data so you wouldnt need to “get” the data back. (getting data back from a compute buffer can be slow compared to other ways of using that same data)
2 - since you want to update 5000 particles across two different systems, it may be better to use the CPU fluidsim since it stores everything in arrays then prints out textures. you could just have it bypass the print texture part to save perf then have you particles look into the velocity array for movement data. Since the sim would be running on the cpu you would need to run at a lower sim resolution to keep performance up compared to running everything on the gpu.
Outside of those ideas, how often do you need each particle to update its movement based on the velocity? if things move very slow you could just update 100 particles each frame which may run well enough with the getpixel method.
Sorry for dumb questions.