FLUIDOS II for Daz Studio - update 2.2 [commercial]

1101112131416»

Comments

  • AlbertoAlberto Posts: 1,382

    mikethe3dguy said:

    So the water mass is the pool water that originally comes with the pool. I had to downscale and raise it slightly because its geometry collides a bit with the pool shell mesh. I'm using it after multiple failed attempts to fill the pool using various primitive cubes and spheres. Prior to the problems I started having with the pool overflowing (possibly caused by setting "Enable OpenCL" to off? Not sure - might try to change back to on) it filled the pool just right. The problem here may be that I have the sinks enabled from the first frame so the water hasn't dropped and settled yet? This image is from a fairly early frame, but those depressions caused by the sinks don't go away even by the end of the 150 frame simulation. Not at all what I expected.

    Edit: No, it's not "Enable OpenCL" that's affecting the water level.

    Do not downscale nor raise the pool water. It doesn't matter that its geometry collides with the shell mesh. The solid obstacle has priority; when the obstacle and the initial fluid mass collide, the cells shared by them will be considered only solid cells. Moreover, you can use a primitive cube that overlaps with the shell and be ever wider than the Domain: Only the free space covered by the cube inside the Domain will be filled with fluid.

    Forget the sinks, they're causing a horrible effect due to overlapping with the water. If you move downward the initial Fluid mass, you won't need the sinks.

  • mikethe3dguymikethe3dguy Posts: 515
    edited August 2023

    Alberto said:

    mikethe3dguy said:

    So the water mass is the pool water that originally comes with the pool. I had to downscale and raise it slightly because its geometry collides a bit with the pool shell mesh. I'm using it after multiple failed attempts to fill the pool using various primitive cubes and spheres. Prior to the problems I started having with the pool overflowing (possibly caused by setting "Enable OpenCL" to off? Not sure - might try to change back to on) it filled the pool just right. The problem here may be that I have the sinks enabled from the first frame so the water hasn't dropped and settled yet? This image is from a fairly early frame, but those depressions caused by the sinks don't go away even by the end of the 150 frame simulation. Not at all what I expected.

    Edit: No, it's not "Enable OpenCL" that's affecting the water level.

    Do not downscale nor raise the pool water. It doesn't matter that its geometry collides with the shell mesh. The solid obstacle has priority; when the obstacle and the initial fluid mass collide, the cells shared by them will be considered only solid cells. Moreover, you can use a primitive cube that overlaps with the shell and be ever wider than the Domain: Only the free space covered by the cube inside the Domain will be filled with fluid.

    Forget the sinks, they're causing a horrible effect due to overlapping with the water. If you move downward the initial Fluid mass, you won't need the sinks.

    Thanks, that's helpful inside info. before when I tried a big cube I ended up with "thick" water all over the deck - nowhere for it to go so it just stayed there. I'll try the "pool water" prop as it is without modifications then. All the water acted like it was much more viscous than real-world water, which is why I kept driving the cell size down, trying to get something that behaved more like water.

    Post edited by mikethe3dguy on
  • Alberto said:

    mikethe3dguy said:

    So the water mass is the pool water that originally comes with the pool. I had to downscale and raise it slightly because its geometry collides a bit with the pool shell mesh. I'm using it after multiple failed attempts to fill the pool using various primitive cubes and spheres. Prior to the problems I started having with the pool overflowing (possibly caused by setting "Enable OpenCL" to off? Not sure - might try to change back to on) it filled the pool just right. The problem here may be that I have the sinks enabled from the first frame so the water hasn't dropped and settled yet? This image is from a fairly early frame, but those depressions caused by the sinks don't go away even by the end of the 150 frame simulation. Not at all what I expected.

    Edit: No, it's not "Enable OpenCL" that's affecting the water level.

    Do not downscale nor raise the pool water. It doesn't matter that its geometry collides with the shell mesh. The solid obstacle has priority; when the obstacle and the initial fluid mass collide, the cells shared by them will be considered only solid cells. Moreover, you can use a primitive cube that overlaps with the shell and be ever wider than the Domain: Only the free space covered by the cube inside the Domain will be filled with fluid.

    Forget the sinks, they're causing a horrible effect due to overlapping with the water. If you move downward the initial Fluid mass, you won't need the sinks.

    Okay, so I'm finally making some good progress, thanks in large part to your suggestions! I'm hoping you might have a tip or two to help me get the rest of the way. This image is 10 frames after the G8M landing in the pool, chosen to show the splash. What I'd like to get is a more realistic splash. At the moment the water is behaving too much like a viscous liquid - it's splashing reasonably well, but needs more energy and variation near the impact point. It's flying too far and the "scale" of the splash seems too large if that makes sense. Also, while I've got "Include Diffuse Particles" turned on, I'm not sure it's having any effect (all its parameters are at default now).

    Cell Size = 5.0

    G8M Object Type set to Force Field, and Intensity is at 0 until impact where it's ramped to 2000 over a period of 10 frames (at peak intensity for 3 frames). Previously I had tried as high as 500 with insufficient splash effect.

     

  • mikethe3dguy said:

    Alberto said:

    mikethe3dguy said:

    So the water mass is the pool water that originally comes with the pool. I had to downscale and raise it slightly because its geometry collides a bit with the pool shell mesh. I'm using it after multiple failed attempts to fill the pool using various primitive cubes and spheres. Prior to the problems I started having with the pool overflowing (possibly caused by setting "Enable OpenCL" to off? Not sure - might try to change back to on) it filled the pool just right. The problem here may be that I have the sinks enabled from the first frame so the water hasn't dropped and settled yet? This image is from a fairly early frame, but those depressions caused by the sinks don't go away even by the end of the 150 frame simulation. Not at all what I expected.

    Edit: No, it's not "Enable OpenCL" that's affecting the water level.

    Do not downscale nor raise the pool water. It doesn't matter that its geometry collides with the shell mesh. The solid obstacle has priority; when the obstacle and the initial fluid mass collide, the cells shared by them will be considered only solid cells. Moreover, you can use a primitive cube that overlaps with the shell and be ever wider than the Domain: Only the free space covered by the cube inside the Domain will be filled with fluid.

    Forget the sinks, they're causing a horrible effect due to overlapping with the water. If you move downward the initial Fluid mass, you won't need the sinks.

    Okay, so I'm finally making some good progress, thanks in large part to your suggestions! I'm hoping you might have a tip or two to help me get the rest of the way. This image is 10 frames after the G8M landing in the pool, chosen to show the splash. What I'd like to get is a more realistic splash. At the moment the water is behaving too much like a viscous liquid - it's splashing reasonably well, but needs more energy and variation near the impact point. It's flying too far and the "scale" of the splash seems too large if that makes sense. Also, while I've got "Include Diffuse Particles" turned on, I'm not sure it's having any effect (all its parameters are at default now).

    Cell Size = 5.0

    G8M Object Type set to Force Field, and Intensity is at 0 until impact where it's ramped to 2000 over a period of 10 frames (at peak intensity for 3 frames). Previously I had tried as high as 500 with insufficient splash effect.

    I don't know all your parameters, but it certainly seems that a Cell size of 5 is too much, try to reduce it to 1. This will make the simulation take longer but create smaller "drops".
    Another parameter you can try taking advantage of the simulation you already have done, is to change the Marker Particle; by default I think it is set to 3, try setting it to 1, or even 0.5, that should make the splash droplets not gather in large groups. You can do that by recalculating your current simulation, without having to do it all over again.

    As for the distance, it seems that the value you use for repulsion is too big. Is it necessary to use a repulsion value? Wouldn't the "natural effect" of the body entering the water be enough? From what you say it seems not, but I don't know if you have tried using a geoshell on the character, maybe that would help.

  • mikethe3dguymikethe3dguy Posts: 515
    edited August 2023

    capitanharlock80 said:

    I don't know all your parameters, but it certainly seems that a Cell size of 5 is too much, try to reduce it to 1. This will make the simulation take longer but create smaller "drops".
    Another parameter you can try taking advantage of the simulation you already have done, is to change the Marker Particle; by default I think it is set to 3, try setting it to 1, or even 0.5, that should make the splash droplets not gather in large groups. You can do that by recalculating your current simulation, without having to do it all over again.

    As for the distance, it seems that the value you use for repulsion is too big. Is it necessary to use a repulsion value? Wouldn't the "natural effect" of the body entering the water be enough? From what you say it seems not, but I don't know if you have tried using a geoshell on the character, maybe that would help.

    The cell size is set that way intentionally, hopefully temporarily but we'll see. Before I had tried it at 2.3 and 3.0 but usually couldn't make it all the way through the (long, like 8 hours, though some have been as short as 3.5 hours) simulations without driving cell size up. DS would completely crash, usually after about 75% to 95% completion. I'm hoping that once I can solve my other issues I can then drop the cell size again and eventually get a successful completed simulation. If you've run into this and have any suggestions other than raising cell size to prevent crashing I'm all ears! Just looked up Marker Particle and that looks like a great suggestion! I ended up setting the Intensity so high because I wasn't getting enough energy out of the "splash" without doing so, Maybe I can drop it if the Marker Particle reduction has the effect you describe. Fluidos treats animated moving solids as if they are still, so that's why the "force field" on the G8M is necessary. Without it he just slips into the water with barely a ripple. How would a geoshell help?

    Thanks for the suggestions!

    Post edited by mikethe3dguy on
  • mikethe3dguy said:

    The cell size is set that way intentionally, hopefully temporarily but we'll see. Before I had tried it at 2.3 and 3.0 but usually couldn't make it all the way through the (long, like 8 hours, though some have been as short as 3.5 hours) simulations without driving cell size up. DS would completely crash, usually after about 75% to 95% completion. I'm hoping that once I can solve my other issues I can then drop the cell size again and eventually get a successful completed simulation. If you've run into this and have any suggestions other than raising cell size to prevent crashing I'm all ears! Just looked up Marker Particle and that looks like a great suggestion! I ended up setting the Intensity so high because I wasn't getting enough energy out of the "splash" without doing so, Maybe I can drop it if the Marker Particle reduction has the effect you describe. Fluidos treats animated moving solids as if they are still, so that's why the "force field" on the G8M is necessary. Without it he just slips into the water with barely a ripple. How would a geoshell help?

    Thanks for the suggestions!

    I don't have any crash problems with Fluidos. Maybe once or twice but it's nothing usual. From what Alberto says it's something related to insufficient RAM, I work with 64GB and that's why I guess I haven't had that kind of problems.

    I think the Market Particle can help you quite a bit to get a more realistic splash as it won't clump the drops together, but it will only help with that, not with your problem of displacement too far away.

    The GeoShell helps because sometimes the particles can go through or not react properly directly on the character or other objects. Alberto has an example video with a crystal glass, where champagne is poured, and it's a comparison of how it looks with or without GeoShell, take a look at it.

    Maybe you should approach the splash in another way, maybe instead of using attraction/repulsion forces in character body, you can try with Forces. You can parent this Force to the character, and activate it and give it the force you want at the right moment. I even think there is a kind of "whirlpool" style force, maybe it would be good to get a realistic splash effect.

    Anyway, for testing purposes, I recommend you to create a new scene with a much smaller domain, and drop an object into the water to see the splash it causes, and what you have used to make it realistic (general parameters, forces, repulsion, ...).
    In fact, now that I've told you this, I can think of another way you could create the splash... You could have the "normal" character, without forces or repulsion or anything, just enter the water and move the liquid; but, for the splash, use another object, like dropping a rectangle at a certain speed, similar in size to the character. So it's the rectangle that causes the splash, not the character.

    Good luck! Fluids is not always easy, and sometimes it's very stressful, lol... But when in the end you get the desired result, it's cool!!!

  • mikethe3dguymikethe3dguy Posts: 515
    edited August 2023

    capitanharlock80 said:

    I don't have any crash problems with Fluidos. Maybe once or twice but it's nothing usual. From what Alberto says it's something related to insufficient RAM, I work with 64GB and that's why I guess I haven't had that kind of problems.

    I think the Market Particle can help you quite a bit to get a more realistic splash as it won't clump the drops together, but it will only help with that, not with your problem of displacement too far away.

    The GeoShell helps because sometimes the particles can go through or not react properly directly on the character or other objects. Alberto has an example video with a crystal glass, where champagne is poured, and it's a comparison of how it looks with or without GeoShell, take a look at it.

    Maybe you should approach the splash in another way, maybe instead of using attraction/repulsion forces in character body, you can try with Forces. You can parent this Force to the character, and activate it and give it the force you want at the right moment. I even think there is a kind of "whirlpool" style force, maybe it would be good to get a realistic splash effect.

    Anyway, for testing purposes, I recommend you to create a new scene with a much smaller domain, and drop an object into the water to see the splash it causes, and what you have used to make it realistic (general parameters, forces, repulsion, ...).
    In fact, now that I've told you this, I can think of another way you could create the splash... You could have the "normal" character, without forces or repulsion or anything, just enter the water and move the liquid; but, for the splash, use another object, like dropping a rectangle at a certain speed, similar in size to the character. So it's the rectangle that causes the splash, not the character.

    Good luck! Fluids is not always easy, and sometimes it's very stressful, lol... But when in the end you get the desired result, it's cool!!!

    My PC has 64GB too though. Very confused as to why I'd have crashing problems with Fluidos. Never have had that happen before in DS except in odd situations. Now that I recall, Alberto did have me try a geoshell on the figure, but later thought it was best to remove it. Experimenting smaller at this point is probably a good idea. I did that in the beginning but the reason I stopped is that it seems every change I make has multiple unpredictable effects, so it feels like if I'm working on a different setup (smaller, simpler test scene) that everything I learn from it won't actually apply to my final scene.
    Like I said: according to the manual Fluidos treats animated moving objects as if they are static - it calculates NO force from objects moving through fluid in the timeline.

    Thanks!

    Edit: Actually now that I think again, the geoshell was on the pool "shell" itself, not the figure.

    Post edited by mikethe3dguy on
  • AlbertoAlberto Posts: 1,382

    mikethe3dguy said:
    Like I said: according to the manual Fluidos treats animated moving objects as if they are static - it calculates NO force from objects moving through fluid in the timeline.

    Well, not exactly. If you set the Enable moving obstacles property of the Domain to On, Fluidos can calculate the effect of the moving object on the fluid. What Fluidos cannot do is calculate the effect of the fluid on the obstacle.

    The paragraph in the manual should be rewritten because initially, Fluidos treated the obstacles as static only. The last part of the paragraph, however, mentions the Enable moving obstacles feature. 

    I concede that the Force field could do a better job than the simple solid obstacle in many instances.

    mikethe3dguy said:
    Also, while I've got "Include Diffuse Particles" turned on, I'm not sure it's having any effect (all its parameters are at default now).

    To see the diffuse particles you should add an additional Fluidos Mesher and change its Mesh type to Diffuse particles. There is included a specific shader for this mesher: Fluidos Whitewater. You can change the size of the particles also.

  • Have a question that's kinda off the wall.

     

    If I wanted to create a loop of the fludios, could I:

    1. Generate a 1-60 frame fluidos simulation (or what ever number)

    2. Copy the generated files

    3. Rename them accordingly to 61-120, then again 121-180 etc etc. (I have a batch renamer that could do this)

    4. go back to the main scene, and set both the domain to 180 frames, and remove/add keyframes for completion from 0% at frame 0 and 100% at frame 60, to 0% at frame 0 and 100% at frame 180, then move the duplicated fluidos files into their directories, and have it basically loop the same 60 frames 3x.

     

    I'm thinking of a waterfall type scenario and instead of running a simulation for 1200 frames with assets animating, if I could loop say 120 or so frames It would save on the simulation time. (took me just over 8hrs for 300 frames) it would save hours of simulation time so to speak.

     

     

     

  • AlbertoAlberto Posts: 1,382

    lorddayradon said:

    Have a question that's kinda off the wall.

     

    If I wanted to create a loop of the fludios, could I:

    1. Generate a 1-60 frame fluidos simulation (or what ever number)

    2. Copy the generated files

    3. Rename them accordingly to 61-120, then again 121-180 etc etc. (I have a batch renamer that could do this)

    4. go back to the main scene, and set both the domain to 180 frames, and remove/add keyframes for completion from 0% at frame 0 and 100% at frame 60, to 0% at frame 0 and 100% at frame 180, then move the duplicated fluidos files into their directories, and have it basically loop the same 60 frames 3x.

     

    I'm thinking of a waterfall type scenario and instead of running a simulation for 1200 frames with assets animating, if I could loop say 120 or so frames It would save on the simulation time. (took me just over 8hrs for 300 frames) it would save hours of simulation time so to speak.

    You don't have to copy and rename the files, you only need the original files. Do your step 4 without moving anything in the data directories. The keyframes of completion will do all the needed work to repeat the sequence.

  • Alberto said:

    lorddayradon said:

     

    4. go back to the main scene, and set both the domain to 180 frames, and remove/add keyframes for completion from 0% at frame 0 and 100% at frame 60, to 0% at frame 0 and 100% at frame 180, then move the duplicated fluidos files into their directories, and have it basically loop the same 60 frames 3x.

     

    I'm thinking of a waterfall type scenario and instead of running a simulation for 1200 frames with assets animating, if I could loop say 120 or so frames It would save on the simulation time. (took me just over 8hrs for 300 frames) it would save hours of simulation time so to speak.

    You don't have to copy and rename the files, you only need the original files. Do your step 4 without moving anything in the data directories. The keyframes of completion will do all the needed work to repeat the sequence.

     

    DUDE!  That soo rocks! Thank you.

     

     

  • AlbertoAlberto Posts: 1,382

    lorddayradon said:

    Alberto said:

    lorddayradon said:

     

    4. go back to the main scene, and set both the domain to 180 frames, and remove/add keyframes for completion from 0% at frame 0 and 100% at frame 60, to 0% at frame 0 and 100% at frame 180, then move the duplicated fluidos files into their directories, and have it basically loop the same 60 frames 3x.

     

    I'm thinking of a waterfall type scenario and instead of running a simulation for 1200 frames with assets animating, if I could loop say 120 or so frames It would save on the simulation time. (took me just over 8hrs for 300 frames) it would save hours of simulation time so to speak.

    You don't have to copy and rename the files, you only need the original files. Do your step 4 without moving anything in the data directories. The keyframes of completion will do all the needed work to repeat the sequence.

     

    DUDE!  That soo rocks! Thank you.

     

     

    You're welcome.
  • Hey, have another question.

     

    In my latest testing I've noticed that the texture applied to the Mesher appears to scroll from Left -> right if looking from the Front.

    I'm working on a lava Fluid running down a Volcano, and though the fluid behaves as it should per settings, from top to bottom, and weaving in and out solid obstacles, but the texture appears to kind of scroll from left to right.  I suspect this may have to do with some sort of reference to the top left of the mesh (or somewhere) each frame, and the texture is applied in relation to that reference point.  But if that reference point moves or changes, then the texture applied shifts and is drawn from the new reference location.   Depending on how the fluid moves, it can cause the effect of the texture moving (scrolling) in a direction other than what the fluid is moving.   In my case as the fluid flows down the side of the mountain, The magma texture (bright orange hot magma and darker almost black for less hot) appears to scroll across the surface of the magma from left to right rather than follow the movement direction of the magma itself.  Is there a setting I can adjust to set the direction of this scroll and speed, or just have it locked in reference to the cells that flow down?

     

     

  • AlbertoAlberto Posts: 1,382

    lorddayradon said:

    Hey, have another question.

     

    In my latest testing I've noticed that the texture applied to the Mesher appears to scroll from Left -> right if looking from the Front.

    I'm working on a lava Fluid running down a Volcano, and though the fluid behaves as it should per settings, from top to bottom, and weaving in and out solid obstacles, but the texture appears to kind of scroll from left to right.  I suspect this may have to do with some sort of reference to the top left of the mesh (or somewhere) each frame, and the texture is applied in relation to that reference point.  But if that reference point moves or changes, then the texture applied shifts and is drawn from the new reference location.   Depending on how the fluid moves, it can cause the effect of the texture moving (scrolling) in a direction other than what the fluid is moving.   In my case as the fluid flows down the side of the mountain, The magma texture (bright orange hot magma and darker almost black for less hot) appears to scroll across the surface of the magma from left to right rather than follow the movement direction of the magma itself.  Is there a setting I can adjust to set the direction of this scroll and speed, or just have it locked in reference to the cells that flow down?

    Hi. 

    It's problematic to use a non-procedural shader to texture the fluid. The UV map of the generated fluid is a simple planar one, and this map changes at each frame because the mesh is different at each frame.

    Possibles workarounds:

    • Add an additional mesher that shows the particles (besides the mesher that shows the fluid mass). The shaded particles will move in the correct direction.
    • Or use a simulation of fire. It could be tricky because you have to find the ideal settings to get the fluid to go downwards, starting from high temperatures and then cooling. But it's possible. Moreover, the particles mesher, the fire mesher, or both will have a color proportional to their temperatures.
    • On the other hand, the plugin PARSIS can help to create particles that change color based on their lifetime, and you can embed them in the fluid mass.

     

  • ImagoImago Posts: 4,902

    lorddayradon said:

    Hey, have another question.

     

    In my latest testing I've noticed that the texture applied to the Mesher appears to scroll from Left -> right if looking from the Front.

    I'm working on a lava Fluid running down a Volcano, and though the fluid behaves as it should per settings, from top to bottom, and weaving in and out solid obstacles, but the texture appears to kind of scroll from left to right.  I suspect this may have to do with some sort of reference to the top left of the mesh (or somewhere) each frame, and the texture is applied in relation to that reference point.  But if that reference point moves or changes, then the texture applied shifts and is drawn from the new reference location.   Depending on how the fluid moves, it can cause the effect of the texture moving (scrolling) in a direction other than what the fluid is moving.   In my case as the fluid flows down the side of the mountain, The magma texture (bright orange hot magma and darker almost black for less hot) appears to scroll across the surface of the magma from left to right rather than follow the movement direction of the magma itself.  Is there a setting I can adjust to set the direction of this scroll and speed, or just have it locked in reference to the cells that flow down?

    You can control a bit more that behaviour using ABAS and animating the Vertical and Horizontal Offsets.

    I did it a couple of times and after few attempts I managed to find the right settings to have the fluid "flow" in the right way.

  • Alberto said:

    Hi. 

    It's problematic to use a non-procedural shader to texture the fluid. The UV map of the generated fluid is a simple planar one, and this map changes at each frame because the mesh is different at each frame.

    Possibles workarounds:

    • Add an additional mesher that shows the particles (besides the mesher that shows the fluid mass). The shaded particles will move in the correct direction.

    Do I just add the mesher, and play with it's particle settings? 

    • Or use a simulation of fire. It could be tricky because you have to find the ideal settings to get the fluid to go downwards, starting from high temperatures and then cooling. But it's possible. Moreover, the particles mesher, the fire mesher, or both will have a color proportional to their temperatures.

    This sounds the most complicated and think I might avoid it.

    • On the other hand, the plugin PARSIS can help to create particles that change color based on their lifetime, and you can embed them in the fluid mass.

    I'll look into this. Is it a Daz thing or independant?

     

    Imago said:

    You can control a bit more that behaviour using ABAS and animating the Vertical and Horizontal Offsets.

    I did it a couple of times and after few attempts I managed to find the right settings to have the fluid "flow" in the right way.

    Yes I was think of this also as a solution.

     

    Thanks for the tips.

  • mikethe3dguymikethe3dguy Posts: 515
    edited December 2023

    Alberto,

    I finally gave up in August on trying to get a realistic splash as I just could no longer afford to spend so much time in the learning process, and moved on to other things. I just did come back to Fluidos though and got a simpler animation (with just gentle water movement, no splashes) up and running fairly quickly. But I have a question. I'm now rendering my first Fluidos animation (180 frames) and in early stages testing renders of that image sequence to find the "sweet spot" between render time per frame and image quality. I'm seeing "Fluids reconstruction - Fluidos Mesher" happening for about 2-3 minutes per frame on every frame. Is there some way to easily "bake" the simulation into the scene file so that it doesn't have to add so much time to the render of each frame?

    Thanks

    Post edited by mikethe3dguy on
Sign In or Register to comment.