Need somone to translate some of the technobable into normal people understanding for me. :D
Body Forces?
"Body forces: Add a spatially constant force such as gravity to the simulation. Nevertheless, this force is an animatable parameter. The unit are m/s2."
Lol, I have know idea what any of that means. Is it's how the fluid particles get pulled, ie the default of Y at -9.81 simulates how Earth gravity works? If it was all set to say X at the same -9.81 the fluid would fall sideways at the same speed?
Could body forces me used insead of or along with Velocity to effect the output? Im assuming that since Velocity is on the emitter, once the particle is ejected it's no longer effected if the Velocity is changed via keyframing. But it WILL be effected along with all other existing particles created if the Body Force is changed via keyframing. Example: At frame 30, BodyForce is default and 30 frames of fluid have been produced into a puddle. The the Body Force is reversed on the Y to +9.81. All the existing particles emited would lift of the ground...
Is this even in the ball park of what Body Forces are and how they can be manipulated? :D
Suggestion for updates: Why not just call it "Gravity"? Most can get the concept of sidways gravity (X: +9.81) but "Body Force" seems like a very vague term that many would think effects a character mesh. Or perhaps adding mouse over descriptions like, "This effects created fluids like gravity would on the (X) axis.*shrug*
One last question: Which parameter effects "Flow" ie how many particles of fluid are emited per keyframe?
It's planed fire and smoke in a future version of FLUIDOS.
This is amazing news.
But right now the mesher creates particles as a cloud of actual polygons, which could be less than efficient for fire/smoke when you generally want more of them than for foam effects.
It's a 3Delight-specific primitive (I don't even know if Iray has a dedicated particle primitive like that...), so I will understand if you don't want to bother. But I figured it doesn't hurt to ask =)
Need somone to translate some of the technobable into normal people understanding for me. :D
Body Forces?
"Body forces: Add a spatially constant force such as gravity to the simulation. Nevertheless, this force is an animatable parameter. The unit are m/s2."
Lol, I have know idea what any of that means. Is it's how the fluid particles get pulled, ie the default of Y at -9.81 simulates how Earth gravity works? If it was all set to say X at the same -9.81 the fluid would fall sideways at the same speed?
Hi!
In fact, as you figured out, the term "body forces" is a technical term for Fluid Dynamics. They are named so to differentiate them from the Surface forces. The body forces acts on all the fluid, whereas the surface forces, only act in the frontier between the fluid and non-fluid objects.
The body forces in the Fluid Domain are the same as gravity, but you can point to any direction you wish. That is, you can consider them as one gravity force you could force to change along time (its direction and intensity).
E.g. if you set Force X=0, Force Y= - 9.81 and Z = 0, the force points downwards.
Force X = 0, Force Y = 3.1, Force Z =0 points upwards.
Force X = -5, Force Y =0, Force Z= 0 points to the left.
Force X= 1, Force Y = 1, Force Z =1 points upwards and forward and right (that is, diagonally).
Could body forces me used insead of or along with Velocity to effect the output? Im assuming that since Velocity is on the emitter, once the particle is ejected it's no longer effected if the Velocity is changed via keyframing. But it WILL be effected along with all other existing particles created if the Body Force is changed via keyframing. Example: At frame 30, BodyForce is default and 30 frames of fluid have been produced into a puddle. The the Body Force is reversed on the Y to +9.81. All the existing particles emited would lift of the ground...
Is this even in the ball park of what Body Forces are and how they can be manipulated? :D
Suggestion for updates: Why not just call it "Gravity"? Most can get the concept of sidways gravity (X: +9.81) but "Body Force" seems like a very vague term that many would think effects a character mesh. Or perhaps adding mouse over descriptions like, "This effects created fluids like gravity would on the (X) axis.*shrug*
The problem is that "Body forces" is anything but vague term. It's a technical term. But, in fact, as you've pointed out, this term could be confused with similar terms outside the fluids dynamics environments. Let me think how to handle it.
One last question: Which parameter effects "Flow" ie how many particles of fluid are emited per keyframe?
The velocity (x, y and z), in cm/s units is that parameter. How many particles?, depends on the size of the Source and the cell size (and other variables). It's better to think in terms of volume of a real liquid, as water. If you have a cuboid source 2 cm per size with a velocity x = 10 cm/s , in a keyframe (30 FPS) , 2 X 2 X 10 / 30 = 1.33 cm3 of fluid have entered the Domain,
It's planed fire and smoke in a future version of FLUIDOS.
This is amazing news.
But right now the mesher creates particles as a cloud of actual polygons, which could be less than efficient for fire/smoke when you generally want more of them than for foam effects.
It's a 3Delight-specific primitive (I don't even know if Iray has a dedicated particle primitive like that...), so I will understand if you don't want to bother. But I figured it doesn't hurt to ask =)
Thanks again!
I'm open on suggestions about this point. I agree with you that the polygons aren't the answer.
To create an ocean is a simple setup in Fluidos (a cube primitive filling the lower part of the Domain as a fluid mass), but it could be a hard challenge for the computer. It depends on the level of details needed. A low level of detail isn't a problem, but if you want details like this https://www.daz3d.com/ireal-animated-ocean-water-system, the task could take a long time and would need a lot of memory.
However, you can simulate a small region for the foreground details, and use a backdrop or a less detailed simulation for the backgrounds.
By the way, I'm preparing an update (almost finished) with a new Flow Fluidos Force that can simulate wind over the water surface, this way can be simulated open sea waves.
To create an ocean is a simple setup in Fluidos (a cube primitive filling the lower part of the Domain as a fluid mass), but it could be a hard challenge for the computer. It depends on the level of details needed. A low level of detail isn't a problem, but if you want details like this https://www.daz3d.com/ireal-animated-ocean-water-system, the task could take a long time and would need a lot of memory.
However, you can simulate a small region for the foreground details, and use a backdrop or a less detailed simulation for the backgrounds.
By the way, I'm preparing an update (almost finished) with a new Flow Fluidos Force that can simulate wind over the water surface, this way can be simulated open sea waves.
These videos were done in Carrara, but, as the fluid simulation engine is the same, they can be recreated in Daz Studio.
In DIM you will see three packages: FLUIDOS for Daz Studio Tutorials, FLUIDOS for Daz Studio Content and FLUIDOS for Daz Studio (Win 64-bit) [or Win 32-bit]. The last one is the plugin itself.
When you install the Content, you'll get the manual (pdf) at ReadMe's library folder.
There are two video tutorials and a recipes pdf too.
This is the setup of the river. There is a source in one extreme of river bed, and a sink in the other. A cube is used for the initial water. It was added a little value to Force X to force the water to flow. The smoothing is for avoid the staggering over the river bed. Diffuse particles are enabled.
Here are the Source Properties. All velocities are set to zero. The body forces will push the water.
Here are the Sink Properties
The cube properties:
The terrain acts as a obstacle, thus, no changes were done, but the parenting to Domain.
These are the properties of the first mesh, for reconstructing the water mesh.
These are the properties of the second mesh, for reconstructing the Whitewater (Diffuse particles).
The meshes should be enabled after concluiding the simulation process.
The .duf file is attached. If you load it in Daz Studio, don't forget to adjust the preferred device.
To create an ocean is a simple setup in Fluidos (a cube primitive filling the lower part of the Domain as a fluid mass), but it could be a hard challenge for the computer. It depends on the level of details needed. A low level of detail isn't a problem, but if you want details like this https://www.daz3d.com/ireal-animated-ocean-water-system, the task could take a long time and would need a lot of memory.
However, you can simulate a small region for the foreground details, and use a backdrop or a less detailed simulation for the backgrounds.
By the way, I'm preparing an update (almost finished) with a new Flow Fluidos Force that can simulate wind over the water surface, this way can be simulated open sea waves.
You already answered my question about waves. Waiting for the update :-)
Does the future fonctionnality about smoke will also integrate openvdb ? I'm more than interested as I do my render in Octane.
To create an ocean is a simple setup in Fluidos (a cube primitive filling the lower part of the Domain as a fluid mass), but it could be a hard challenge for the computer. It depends on the level of details needed. A low level of detail isn't a problem, but if you want details like this https://www.daz3d.com/ireal-animated-ocean-water-system, the task could take a long time and would need a lot of memory.
However, you can simulate a small region for the foreground details, and use a backdrop or a less detailed simulation for the backgrounds.
By the way, I'm preparing an update (almost finished) with a new Flow Fluidos Force that can simulate wind over the water surface, this way can be simulated open sea waves.
You already answered my question about waves. Waiting for the update :-)
Does the future fonctionnality about smoke will also integrate openvdb ? I'm more than interested as I do my render in Octane.
Thanks
It's good to know your interest. In fact, I was considering using OpenVDB in that FLUIDOS version.
hola Alberto soy Ariel de youtube aca te adjunto el duf de mi escena,espero que me ayudes ,a hacer analisis acerca de mis fallas desde ya muchas gracias por el soporte tecnico
I sent the update that solves this issue to the store. They're testing it.
Argh I guess I'll have to be patient (Throws toys out of pram)
In the meantime, this problem is easy to avoid. Only save the the scene the first time you create a Domain in it, before parenting anything. Reload and never will occur unparenting in this scene. If you have a old scene already with all unparented from domain, load the scene and reload; never again the objects will be spontaneosly unparented from domain.
hola Alberto soy Ariel de youtube aca te adjunto el duf de mi escena,espero que me ayudes ,a hacer analisis acerca de mis fallas desde ya muchas gracias por el soporte tecnico
¡Hola, Ariel!
Ya revisé tu archivo. Hay varios problemitas, el más importante de todos, el que te está dando los resultados extraños, es el número de cuadros por segundo de la simulación (Frames per second en Main Settings), es demasiado pequeño: 1. Esto te da una simulación muy mala, con muy poca exactitud. Usa mejor el valor predeterminado de 30.
Reduce el tamaño de la línea temporal (Timeline), que sea el mismo número de cuadros (Number of frames) que le pides al simulador, es decir 30 en tu caso; aunque para esta simulación que pretendes, yo recomiendo mejor 60 cuadros para que se vea un avance mayor de flujo.
Otra cosa que vi es que respecto al Sorce, el tamaño de los lados "y" y "z" son 0; deben tener algún valor que no sea cero.. De hecho, para lo que quieres, una fuente, "Size (y)" debería ser el mayor de los valores, por ejemplo 10, mientras que "x" y "z" pueden ser 2.5. Las velocidades deben ser cero para "x" y "z", pero no para "y", de este modo el líquido viaja en sentido vertical.
Por cierto, hay un problema en el plugin que produce que la primera vez que grabas una escena con un dominio recién agregado, cuando recargas la escena, todo lo que adheriste al dominio queda por separado. Ya envié una actualización a la tienda, la están revisando, espero que pronto esté disponible (via DIM). Pero, por el momento, hay una forma simple de evitar el problema: la primera vez que agregues un dominio a una escena, grábala y vuelvela a cargar, así ya no se separará lo que esté en el árbol del dominio. Y para escenas que ya presentan el problema al recargarlas, solamente vuelve a adherir los nodos al dominio y graba, ya no volverá a suceder tampoco el error.
Te agrego un .duf con unos arreglos que hice a tu escena.
To create an ocean is a simple setup in Fluidos (a cube primitive filling the lower part of the Domain as a fluid mass), but it could be a hard challenge for the computer. It depends on the level of details needed. A low level of detail isn't a problem, but if you want details like this https://www.daz3d.com/ireal-animated-ocean-water-system, the task could take a long time and would need a lot of memory.
However, you can simulate a small region for the foreground details, and use a backdrop or a less detailed simulation for the backgrounds.
By the way, I'm preparing an update (almost finished) with a new Flow Fluidos Force that can simulate wind over the water surface, this way can be simulated open sea waves.
You already answered my question about waves. Waiting for the update :-)
Does the future fonctionnality about smoke will also integrate openvdb ? I'm more than interested as I do my render in Octane.
Thanks
It's good to know your interest. In fact, I was considering using OpenVDB in that FLUIDOS version.
Hello Alvin
Oh yes!!! I want, I WANT, ...:-) I don't know if Openvdb is usable in Iray but to have the files ready to be imported in Octane would be amazing! I'd pay for that !!
The only affordable solution I found was Blender but I'm lacking experience with it and the workflow is not easy (at least for me). But the results was promising in Octane and to have "real" smoke and fire is a big plus for quality compared to plane with texture
Comments
Heya,
Need somone to translate some of the technobable into normal people understanding for me. :D
Body Forces?
"Body forces: Add a spatially constant force such as gravity to the simulation. Nevertheless, this force is an animatable parameter. The unit are m/s2."
Lol, I have know idea what any of that means. Is it's how the fluid particles get pulled, ie the default of Y at -9.81 simulates how Earth gravity works? If it was all set to say X at the same -9.81 the fluid would fall sideways at the same speed?
Could body forces me used insead of or along with Velocity to effect the output? Im assuming that since Velocity is on the emitter, once the particle is ejected it's no longer effected if the Velocity is changed via keyframing. But it WILL be effected along with all other existing particles created if the Body Force is changed via keyframing. Example: At frame 30, BodyForce is default and 30 frames of fluid have been produced into a puddle. The the Body Force is reversed on the Y to +9.81. All the existing particles emited would lift of the ground...
Is this even in the ball park of what Body Forces are and how they can be manipulated? :D
Suggestion for updates: Why not just call it "Gravity"? Most can get the concept of sidways gravity (X: +9.81) but "Body Force" seems like a very vague term that many would think effects a character mesh. Or perhaps adding mouse over descriptions like, "This effects created fluids like gravity would on the (X) axis.*shrug*
One last question: Which parameter effects "Flow" ie how many particles of fluid are emited per keyframe?
Thanks! :D
Hello Alberto! Thank you very much for this plugin, it's such an awesome timesaver! =)
I have one question...
This is amazing news.
But right now the mesher creates particles as a cloud of actual polygons, which could be less than efficient for fire/smoke when you generally want more of them than for foam effects.
Would it be possible in the future to have an option to have them created as RiPoints? http://www.hradec.com/ebooks/CGI/RMS_1.0/rman/prman_technical_rendering/users_guide/RISpec-html/section5.html
It's a 3Delight-specific primitive (I don't even know if Iray has a dedicated particle primitive like that...), so I will understand if you don't want to bother. But I figured it doesn't hurt to ask =)
Thanks again!
Hi!
In fact, as you figured out, the term "body forces" is a technical term for Fluid Dynamics. They are named so to differentiate them from the Surface forces. The body forces acts on all the fluid, whereas the surface forces, only act in the frontier between the fluid and non-fluid objects.
The body forces in the Fluid Domain are the same as gravity, but you can point to any direction you wish. That is, you can consider them as one gravity force you could force to change along time (its direction and intensity).
E.g. if you set Force X=0, Force Y= - 9.81 and Z = 0, the force points downwards.
Force X = 0, Force Y = 3.1, Force Z =0 points upwards.
Force X = -5, Force Y =0, Force Z= 0 points to the left.
Force X= 1, Force Y = 1, Force Z =1 points upwards and forward and right (that is, diagonally).
Yes, you're right.
The problem is that "Body forces" is anything but vague term. It's a technical term. But, in fact, as you've pointed out, this term could be confused with similar terms outside the fluids dynamics environments. Let me think how to handle it.
The velocity (x, y and z), in cm/s units is that parameter. How many particles?, depends on the size of the Source and the cell size (and other variables). It's better to think in terms of volume of a real liquid, as water. If you have a cuboid source 2 cm per size with a velocity x = 10 cm/s , in a keyframe (30 FPS) , 2 X 2 X 10 / 30 = 1.33 cm3 of fluid have entered the Domain,
You're welcome. If you have more doubts or you think I didn't anwered clearly your questions, don't hesitate to ask.
I'm open on suggestions about this point. I agree with you that the polygons aren't the answer.
Thanks to you!
Sorry, I missed your question.
To create an ocean is a simple setup in Fluidos (a cube primitive filling the lower part of the Domain as a fluid mass), but it could be a hard challenge for the computer. It depends on the level of details needed. A low level of detail isn't a problem, but if you want details like this https://www.daz3d.com/ireal-animated-ocean-water-system, the task could take a long time and would need a lot of memory.
However, you can simulate a small region for the foreground details, and use a backdrop or a less detailed simulation for the backgrounds.
By the way, I'm preparing an update (almost finished) with a new Flow Fluidos Force that can simulate wind over the water surface, this way can be simulated open sea waves.
These videos were done in Carrara, but, as the fluid simulation engine is the same, they can be recreated in Daz Studio.
Okay, time to headbut this wall again Always fun.
I deleted my copy of Tutorial 1 and re-entered as per the video in a fresh scene.
I didnt get the same errors so I assume I made a mistake or DS burped the first time.
Everything was as per the video except that the 'Disable Prievew' step (around 11:50 of the video) failed to show the mesh?
As such the animation showed no mesh as well.
Was the mesher itself enabled?
Fluidos Mesher
Enable On
The mesher is in the same position as the Domain? You can do that easily by Copy-Paste the Domain to the mesher.
Both the Domain & Meshers translate & Rotate values are 0.00
Try to enable and disable the mesher to refresh.
It doesn't copy only the position but also the folder you used in the Domain. SO the question is mandatory: The mesher has same folder as the Domain?
No Change.
Screenshot attached
log Log files attached
Could you show the "Currently Used" properties of Domain, Source/Sink and Mesher, please?
Are there any instructions for this? I can't install it.
Okay
I saved the file last night as it was getting late and when I load it parenting is gone (if anything else who knows).
re-parent nodes.
Cant run as it wont recognise domain again.
create a blank domain
run simulation
runs way too quick, the file is stuffed again.
Looks like I have to re-create the file from scratch again.
Q: How do I save the scene without it breaking the scene when I load it?
I'm not going to get anywhere if I have to re-invent the wheel every day.
The plugin installs via DIM, and then you have to register with your serial number (instructions for how to register: https://www.daz3d.com/forums/discussion/comment/3916516/#Comment_3916516)
In DIM you will see three packages: FLUIDOS for Daz Studio Tutorials, FLUIDOS for Daz Studio Content and FLUIDOS for Daz Studio (Win 64-bit) [or Win 32-bit]. The last one is the plugin itself.
When you install the Content, you'll get the manual (pdf) at ReadMe's library folder.
There are two video tutorials and a recipes pdf too.
That is awesome. thanls for sharing that infor :)
Sorry, this is a bug. Read here how to avoid: https://www.daz3d.com/forums/discussion/comment/3928161/#Comment_3928161
I sent the update that solves this issue to the store. They're testing it.
You're welcome.
You already answered my question about waves. Waiting for the update :-)
Does the future fonctionnality about smoke will also integrate openvdb ? I'm more than interested as I do my render in Octane.
Thanks
It's good to know your interest. In fact, I was considering using OpenVDB in that FLUIDOS version.
hola Alberto soy Ariel de youtube aca te adjunto el duf de mi escena,espero que me ayudes ,a hacer analisis acerca de mis fallas desde ya muchas gracias por el soporte tecnico
Argh I guess I'll have to be patient (Throws toys out of pram)
In the meantime, this problem is easy to avoid. Only save the the scene the first time you create a Domain in it, before parenting anything. Reload and never will occur unparenting in this scene. If you have a old scene already with all unparented from domain, load the scene and reload; never again the objects will be spontaneosly unparented from domain.
¡Hola, Ariel!
Ya revisé tu archivo. Hay varios problemitas, el más importante de todos, el que te está dando los resultados extraños, es el número de cuadros por segundo de la simulación (Frames per second en Main Settings), es demasiado pequeño: 1. Esto te da una simulación muy mala, con muy poca exactitud. Usa mejor el valor predeterminado de 30.
Reduce el tamaño de la línea temporal (Timeline), que sea el mismo número de cuadros (Number of frames) que le pides al simulador, es decir 30 en tu caso; aunque para esta simulación que pretendes, yo recomiendo mejor 60 cuadros para que se vea un avance mayor de flujo.
Otra cosa que vi es que respecto al Sorce, el tamaño de los lados "y" y "z" son 0; deben tener algún valor que no sea cero.. De hecho, para lo que quieres, una fuente, "Size (y)" debería ser el mayor de los valores, por ejemplo 10, mientras que "x" y "z" pueden ser 2.5. Las velocidades deben ser cero para "x" y "z", pero no para "y", de este modo el líquido viaja en sentido vertical.
Por cierto, hay un problema en el plugin que produce que la primera vez que grabas una escena con un dominio recién agregado, cuando recargas la escena, todo lo que adheriste al dominio queda por separado. Ya envié una actualización a la tienda, la están revisando, espero que pronto esté disponible (via DIM). Pero, por el momento, hay una forma simple de evitar el problema: la primera vez que agregues un dominio a una escena, grábala y vuelvela a cargar, así ya no se separará lo que esté en el árbol del dominio. Y para escenas que ya presentan el problema al recargarlas, solamente vuelve a adherir los nodos al dominio y graba, ya no volverá a suceder tampoco el error.
Te agrego un .duf con unos arreglos que hice a tu escena.
Hello Alvin
Oh yes!!! I want, I WANT, ...:-) I don't know if Openvdb is usable in Iray but to have the files ready to be imported in Octane would be amazing! I'd pay for that !!
The only affordable solution I found was Blender but I'm lacking experience with it and the workflow is not easy (at least for me). But the results was promising in Octane and to have "real" smoke and fire is a big plus for quality compared to plane with texture