Loading...
> >

FLUIDOS II for Daz Studio - update 2.2 [commercial]

1…1011131516

Comments

  • capitanharlock80capitanharlock80 Posts: 36

    I'm sorry to say this because I like the plugin and you've done a great job, but honestly I have a love/hate relationship with it, lol

    I always end up "wasting" a lot of time trying to get what I want, sometimes I get it and sometimes I don't, but every scene/animation I try is a battle for me.

    Weak points in terms of what I intend to do:
    - It doesn't behave well in animations, it doesn't properly follow the animation nor does it react as it should to whatever characters/objects there are.
    - If the fluid passes/touches an object in animation, it passes through it, I've created a torus as a solid object and thicker at 10, and nothing, it keeps passing the fluid through it (BTW, I use directional force for movement).
    - The Domain should be able to be rotated to adapt it to the scene, I told you that before, right now if you rotate it that has influence in the direction; that is to say, if you rotate it 90º to the right that doesn't affect the axes of the fluid source and this will be calculated at -90º with respect to the domain once rotated (in case you don't understand, even if you rotate the domain to 90º, for the simulation (fluid source) it will continue being 0º. That's a problem because you may have worked on perfecting the right parameters you are looking for and then you can't apply it to another scene, because the domain can't be touched (you can move it, but not rotate it in any axis).

  • AlbertoAlberto Posts: 1,383

    Hi!

    capitanharlock80 said:
    - If the fluid passes/touches an object in animation, it passes through it, I've created a torus as a solid object and thicker at 10, and nothing, it keeps passing the fluid through it (BTW, I use directional force for movement).

    Check this:

    1. Did you parent the torus to the Fluidos domain?
    2. Was the Object type property of the torus set to Solid obstacle?
    3. Had the Cell size property of the Fluidos domain a value lower than the diameters of the torus?

    capitanharlock80 said:
    - It doesn't behave well in animations, it doesn't properly follow the animation nor does it react as it should to whatever characters/objects there are.

    Besides the previous points check if the Enable moving obstacles property of the Fluidos domain was set On.

    capitanharlock80 said:

    - The Domain should be able to be rotated to adapt it to the scene, I told you that before, right now if you rotate it that has influence in the direction; that is to say, if you rotate it 90º to the right that doesn't affect the axes of the fluid source and this will be calculated at -90º with respect to the domain once rotated (in case you don't understand, even if you rotate the domain to 90º, for the simulation (fluid source) it will continue being 0º. That's a problem because you may have worked on perfecting the right parameters you are looking for and then you can't apply it to another scene, because the domain can't be touched (you can move it, but not rotate it in any axis).

    You should rotate also the Meshers accordingly, the easier method is a Copy-Paste of the parameters of the Fluidos domain to the Mesher.

    If you want to conserve the orientation of the gravity forces with respect to the scene, you should change also the values in the Fluidos domain gravity properties. For example, if you rotate 90 º around the axis Z, then set the gravity Force X to 9.81, and the others (Y and Z) to 0.0. For liquids, it's easier to set all gravity forces to 0.0 and add a Directional force of 9.81 intensity pointing to the bottom.

    On the other hand, the position and rotation of the Fluidos Domain should not be animated, they have to be fixed.

    Let me know if this doesn't solve your issues, please.

  • capitanharlock80capitanharlock80 Posts: 36

    Thank you for your answers, I answer you in quote:

    Alberto said:

    Hi!

    capitanharlock80 said:
    - If the fluid passes/touches an object in animation, it passes through it, I've created a torus as a solid object and thicker at 10, and nothing, it keeps passing the fluid through it (BTW, I use directional force for movement).

    Check this:

    1. Did you parent the torus to the Fluidos domain? > Yes, of course it's within the domain, in fact the fluid gets to interact with it (it changes its direction a bit), but so to speak, it's not "hard" enough to prevent the fluid from passing through it. It's funny because I saw your example video where a wine is poured into a glass (where you used a geoshell) so it should be able to be done without a problem, I don't understand. BTW, I also did the tests with things other than a torus, like a geoshell over the part I'm interested in, but in this case the fluid is not even generated, even though it's hollow.
    2. Was the Object type property of the torus set to Solid obstacle? > Yes, it's set to solid object and even tried to set the thicker to 10, the result with the thicker may be a little better, but it still passes through.
    3. Had the Cell size property of the Fluidos domain a value lower than the diameters of the torus? > Yes, the source doesn't touch the torus, it's smaller, I even tested making it smaller than I wanted, but with the same result. In fact, if the source touched the torus it would probably no longer generate liquid, which is what seems to happen to me with the geoshell.

    capitanharlock80 said:
    - It doesn't behave well in animations, it doesn't properly follow the animation nor does it react as it should to whatever characters/objects there are.

    Besides the previous points check if the Enable moving obstacles property of the Fluidos domain was set On. > Yes, it's ON

    capitanharlock80 said:

    - The Domain should be able to be rotated to adapt it to the scene, I told you that before, right now if you rotate it that has influence in the direction; that is to say, if you rotate it 90º to the right that doesn't affect the axes of the fluid source and this will be calculated at -90º with respect to the domain once rotated (in case you don't understand, even if you rotate the domain to 90º, for the simulation (fluid source) it will continue being 0º. That's a problem because you may have worked on perfecting the right parameters you are looking for and then you can't apply it to another scene, because the domain can't be touched (you can move it, but not rotate it in any axis).

    You should rotate also the Meshers accordingly, the easier method is a Copy-Paste of the parameters of the Fluidos domain to the Mesher. > Yep, I always copy/paste the Mesher after moving or resizing the Domain.

    If you want to conserve the orientation of the gravity forces with respect to the scene, you should change also the values in the Fluidos domain gravity properties. For example, if you rotate 90 º around the axis Z, then set the gravity Force X to 9.81, and the others (Y and Z) to 0.0. For liquids, it's easier to set all gravity forces to 0.0 and add a Directional force of 9.81 intensity pointing to the bottom. > It's curious that precisely the gravity continues to work well even if the domain is rotated, it's a parameter of the Domain and in only one direction, down, so that works.
    What doesn't work, or rather is altered by rotating the domain, are the velocities that one can set in the Source, that's the problem. I'm now using directional forces instead of velocities in the source, so I will test if there's the same problem with that or not. NOTE: Anyway this problem is secondary, it's only to go faster to take advantage of a set already made in a scene for another one, but it's not really very important, it's more annoying the problem of how the program works (how it interacts) with moving objects; in fact, I don't know if I had told you, the problem of going through the torus may be due to this, because it's moving.

    On the other hand, the position and rotation of the Fluidos Domain should not be animated, they have to be fixed. > I don't want to animate it, just to be able to position it where I think is appropriate according to the scene, and I can move it, but not rotate it (I mean, I can rotate it but then the liquid goes in the wrong direction, precisely because it has been rotated... although now that I work with directional forces instead of specifying the velocity in the source, maybe I can do it without that problem, I still have to test it).

    Let me know if this doesn't solve your issues, please.

    IMHO it would only need to interact better with moving objects to be a perfect program!
    Thanks and congratulations for the work!

  • Richard HaseltineRichard Haseltine Posts: 97,297

    The size question was about the cell size of the domain - those are the divisions into little cubes, each of which is an entity in the simulation. If the cells are larger than an obstacle the sinulation is going to wrap around it without interacting, which sounds to be what you are seeing.

  • capitanharlock80capitanharlock80 Posts: 36

    Richard Haseltine said:

    The size question was about the cell size of the domain - those are the divisions into little cubes, each of which is an entity in the simulation. If the cells are larger than an obstacle the sinulation is going to wrap around it without interacting, which sounds to be what you are seeing.

    "Fluidos II very high resolution" sets the Cell size to 0.4, in my test I start with a Cell size of 1, but then tried 0.4 even 0.25, same result, the liquid goes through the solid... so in this case I think the problem is that this solid is in motion, something that seems that the program doesn't calculate properly (because for example the same happens with the behavior of a liquid stuck to a moving object; the behavior of the liquid is not realistic). The program doesn't calculate the motion of the solid in the future and how the liquid should behave due to that motion, so the incorrect calculations make the liquid go through it, because the path of the liquid seems to follow the path marked by that solid "in the past" not in the present/future of the simulation.

     

    Maybe I'm not explaining myself well, so I will give an example that will be better understood:

    Let's imagine that we want to simulate the behavior of a hose that someone uses to water the garden.
    The hose is intended to simulate the movement that would be made when watering the garden, so it has movement sideways and also a little up and down.
    If you put a Source right at the end of that hose, without it interacting with any solids, the liquid will behave correctly (it will simulate realistically).
    If, on the other hand, you want to put a Source that is a little inside the end of the hose (imagine an elongated torus to simulate that end of the hose), in this case, since that end (torus) will be moving, the simulation will be wrong and the liquid will end up going through the solid (unrealistic simulation).

  • capitanharlock80capitanharlock80 Posts: 36

    My hose example might look like this demonstration video, but with the bottle moving

    Bearing in mind that the source is inside the bottle... How would it look like if that bottle was moving, would it contain the liquid or would it go through it...? Interesting to know, I'll try it, although I won't be able to do it for a few days :-/

  • capitanharlock80capitanharlock80 Posts: 36

    Just now I have done a test, with Cell size of 0.4, and with framerate of 120fps in the Domain, and here you can see the result and the problem.

    It seems that the liquid doesn't follow the movement of the source.

    fluidos_screen_1.jpg
    768 x 420 - 16K
    fluidos_screen_2.jpg
    753 x 402 - 20K
  • AlbertoAlberto Posts: 1,383

    capitanharlock80 said:

    Just now I have done a test, with Cell size of 0.4, and with framerate of 120fps in the Domain, and here you can see the result and the problem.

    It seems that the liquid doesn't follow the movement of the source.

    Is the source inside the torus? Could you show me a top view of the torus and the source?

    What is the size of the source?

  • capitanharlock80capitanharlock80 Posts: 36

    Alberto said:

    capitanharlock80 said:

    Just now I have done a test, with Cell size of 0.4, and with framerate of 120fps in the Domain, and here you can see the result and the problem.

    It seems that the liquid doesn't follow the movement of the source.

    Is the source inside the torus? Could you show me a top view of the torus and the source?

    What is the size of the source?

    I can't right now but I'll send you a screenshot as soon as I can.
    But yes, the source is inside the torus, and it's small enough to not touch any of the torus walls. The cell size is 0.4, the source I would have to check but I guess it should be 1.0

    Anyway I've seen that using the direction forces I have some problems, so I've gone back to using the velocities in the source... And now that I'm in another simulation, I want to tell you another problem, this time of speed, because it's extremely slow... it has been 1h 30m of a 60 frames simulation and it's at 23%, d'oh!
    Checking the log I've seen this:

    09-Oct-2022 02h24m19s

     

    Frame: 13

    Step time: 0.005

     

    Update Fluid Cells:          2.2819

    Num Fluid Cells: 2456

    Num Marker Particles: 8880

    Reconstruct Fluid Surface:  0

    Current Volume = 3.88852

    Update Level set:            0.093

    Reconstruct Output Surface: 0

    Advect Velocity Field:        33.0469

    Apply Body Forces:            5.078

    Pressure solver success true Iteration #: 8 Estimated Error: 6.53686e-07

    Update Pressure Grid:        0.4539

    Apply Pressure:              8.046

    Viscosity Solver Iterations: 182

    Estimated Error: 0.00034

    Apply Viscosity:            81.9059

    Extrapolate Fluid Velocities: 3.047

    Update Diffuse Material:      0

    Update PIC/FLIP Velocities:  0.125

    Advance Marker Particles:    0.4379

     

    ---Percentage Breakdown---

    Update Fluid Cells:          1.6

    Reconstruct Fluid Surface:    0

    Update Level Set:            0

    Reconstruct Output Surface:  0

    Advect Velocity Field:        24.5

    Apply Body Forces:            3.7

    Apply Viscosity:              60.8

    Update Pressure Grid:        0.3

    Apply Pressure:              5.9

    Extrapolate Fluid Velocities: 2.2

    Update Diffuse Material:      0

    Update PIC/FLIP Velocities:  0

    Advance Marker Particles:    0.3

     

    Update time:   134.531

    Total time:    5363.34

    I understand that this indicates 2.23m per frame, but if so, the animation should be almost finished.
    It seems that there's some process that slows everything down, could it be due to the error shown? "Estimated Error...."

    I see that it's shown in the "Apply Body Forces" section, the funny thing is that I don't have any forces applied, other than specifying that the object is solid.

    Additional note: In the simulations I've been running for a long time, this velocity problem seems to only appear when viscosity is used.
    BTW, it would also be nice to be able to make use of all available power, I have 2x3090 and a R9 5950x, but the program only uses one 3090 for the simulation? Would it be possible to optimize the program to use all the available power that can be on a computer?

     

    Thanks!

  • AlbertoAlberto Posts: 1,383
    edited October 2022

    capitanharlock80 said:

    I can't right now but I'll send you a screenshot as soon as I can.
    But yes, the source is inside the torus, and it's small enough to not touch any of the torus walls. The cell size is 0.4, the source I would have to check but I guess it should be 1.0

    This is the problem: All solids should be volumetric objects. The torus is volumetric, but its volume is its insides. Surfaces are not recognized, like the internal surfaces of the torus. So, your source is inside a solid and won't work.

    capitanharlock80 said:

    Anyway I've seen that using the direction forces I have some problems, so I've gone back to using the velocities in the source... And now that I'm in another simulation, I want to tell you another problem, this time of speed, because it's extremely slow... it has been 1h 30m of a 60 frames simulation and it's at 23%, d'oh!
    Checking the log I've seen this:

    09-Oct-2022 02h24m19s

     

    Frame: 13

    Step time: 0.005

     

    Update Fluid Cells:          2.2819

    Num Fluid Cells: 2456

    Num Marker Particles: 8880

    Reconstruct Fluid Surface:  0

    Current Volume = 3.88852

    Update Level set:            0.093

    Reconstruct Output Surface: 0

    Advect Velocity Field:        33.0469

    Apply Body Forces:            5.078

    Pressure solver success true Iteration #: 8 Estimated Error: 6.53686e-07

    Update Pressure Grid:        0.4539

    Apply Pressure:              8.046

    Viscosity Solver Iterations: 182

    Estimated Error: 0.00034

    Apply Viscosity:            81.9059

    Extrapolate Fluid Velocities: 3.047

    Update Diffuse Material:      0

    Update PIC/FLIP Velocities:  0.125

    Advance Marker Particles:    0.4379

     

    ---Percentage Breakdown---

    Update Fluid Cells:          1.6

    Reconstruct Fluid Surface:    0

    Update Level Set:            0

    Reconstruct Output Surface:  0

    Advect Velocity Field:        24.5

    Apply Body Forces:            3.7

    Apply Viscosity:              60.8

    Update Pressure Grid:        0.3

    Apply Pressure:              5.9

    Extrapolate Fluid Velocities: 2.2

    Update Diffuse Material:      0

    Update PIC/FLIP Velocities:  0

    Advance Marker Particles:    0.3

     

    Update time:   134.531

    Total time:    5363.34

    I understand that this indicates 2.23m per frame, but if so, the animation should be almost finished.
    It seems that there's some process that slows everything down, could it be due to the error shown? "Estimated Error...."

    These times are only the engine simulation times. If you have the mesher enabled, the reconstruction of the fluids slows down the process.

    capitanharlock80 said:

     

    I see that it's shown in the "Apply Body Forces" section, the funny thing is that I don't have any forces applied, other than specifying that the object is solid.

    The gravity forces are included in this step.

    capitanharlock80 said:

    Additional note: In the simulations I've been running for a long time, this velocity problem seems to only appear when viscosity is used.

    Yes, the viscosity requires extra calculations.

    capitanharlock80 said:

    BTW, it would also be nice to be able to make use of all available power, I have 2x3090 and a R9 5950x, but the program only uses one 3090 for the simulation? Would it be possible to optimize the program to use all the available power that can be on a computer?

    I plan to work to increase performance for the next update, but it'll take a while.

    capitanharlock80 said:

    Thanks!

    You're welcome!

    Post edited by Alberto on
  • Writer25Writer25 Posts: 7

    Alberto said:

    Jovanni said:

    Has anyone been able to import openvdb from blender to daz3d? :D

    If you have vdb files of simulation of liquids, the vdbs are probably level sets, these can be transformed to meshes using remeshing in Fluidos II. But for smoke, fog, explosions, the current version (V2.1) cannot read these vdbs, but the plugin ABAS can do it (see https://youtu.be/FfGlaJyXXVo).

    Hey there,

     

    I've been trying out your plugin and I defintilty see potentional in this, since it works great when you make the fluid sims nativily in DAZStudio. However I'm running into an issue when I'm trying to import external .vdb liquid files from Blender.

    When I've import them, I try to remesh them as described in the manual. I rename them as fluid00000x, set them in a bakefiles subfolder designated in the fluidos domain, and try running the remesh option in the simulator... Only this doesn't seem to work, as the simulator seems to go through them immediately, and doesn't convert the .vdb files into the required.ply.

    Any idea what I'm doing wrong? The long-term plan is to use this plugin to render the externally made .vdb's in DAZstudio... so I hope that it can be resolved.

    Greetz!

  • AlbertoAlberto Posts: 1,383

    Writer25 said:

    Alberto said:

    Jovanni said:

    Has anyone been able to import openvdb from blender to daz3d? :D

    If you have vdb files of simulation of liquids, the vdbs are probably level sets, these can be transformed to meshes using remeshing in Fluidos II. But for smoke, fog, explosions, the current version (V2.1) cannot read these vdbs, but the plugin ABAS can do it (see https://youtu.be/FfGlaJyXXVo).

    Hey there,

     

    I've been trying out your plugin and I defintilty see potentional in this, since it works great when you make the fluid sims nativily in DAZStudio. However I'm running into an issue when I'm trying to import external .vdb liquid files from Blender.

    When I've import them, I try to remesh them as described in the manual. I rename them as fluid00000x, set them in a bakefiles subfolder designated in the fluidos domain, and try running the remesh option in the simulator... Only this doesn't seem to work, as the simulator seems to go through them immediately, and doesn't convert the .vdb files into the required.ply.

    Any idea what I'm doing wrong? The long-term plan is to use this plugin to render the externally made .vdb's in DAZstudio... so I hope that it can be resolved.

    Greetz!

    The vdb file must be of Level set type. Could you upload one of the vdb files so I could examine it? 

  • Writer25Writer25 Posts: 7
    edited December 2022

    Thank you for the quick response and of course. 

    It doesn't seem the attach a file option is working for me, but I've uploaded it to mega.nz. 

    You can find it here: https://mega.nz/file/Q6RD1bRT#xxD2v7AlUDdwYLVLBwispXujAz2Du6ttchvym97f8Fk

     

    It's a simple simulation of a standard cube being liqufied and dropped into the the domain (so basically a cookie-cutter test run to see if I could import a simple liquid simulation from Blender). Frame 15 (mega.nz link) is the one where it has just made contact with the bottom of the domain.

    Post edited by Writer25 on
  • AlbertoAlberto Posts: 1,383

    Writer25 said:

    Thank you for the quick response and of course. 

    It doesn't seem the attach a file option is working for me, but I've uploaded it to mega.nz. 

    You can find it here: https://mega.nz/file/Q6RD1bRT#xxD2v7AlUDdwYLVLBwispXujAz2Du6ttchvym97f8Fk

     

    It's a simple simulation of a standard cube being liqufied and dropped into the the domain (so basically a cookie-cutter test run to see if I could import a simple liquid simulation from Blender). Frame 15 (mega.nz link) is the one where it has just made contact with the bottom of the domain.

    I checked the vdb.

    The vdb_view utility (included in OpenVDB) couldn't open it. Houdini couldn't open it.

    Examining more in-depth, I found that it isn't a level set, it's not even a fog-type vdb. It's a Points-type vdb (contains particles information).

    Try to see if there is an option to export level set vdbs.

     

     

  • Writer25Writer25 Posts: 7

    Alberto said:

    Writer25 said:

    Thank you for the quick response and of course. 

    It doesn't seem the attach a file option is working for me, but I've uploaded it to mega.nz. 

    You can find it here: https://mega.nz/file/Q6RD1bRT#xxD2v7AlUDdwYLVLBwispXujAz2Du6ttchvym97f8Fk

     

    It's a simple simulation of a standard cube being liqufied and dropped into the the domain (so basically a cookie-cutter test run to see if I could import a simple liquid simulation from Blender). Frame 15 (mega.nz link) is the one where it has just made contact with the bottom of the domain.

    I checked the vdb.

    The vdb_view utility (included in OpenVDB) couldn't open it. Houdini couldn't open it.

    Examining more in-depth, I found that it isn't a level set, it's not even a fog-type vdb. It's a Points-type vdb (contains particles information).

    Try to see if there is an option to export level set vdbs.

     

     

     

    I see no such option in Blender and to be honest I've got no idea what the difference between these level sets and point-type vdb are. Is point-type vdb a more outdated form of storing vdb data in OpenVDB? Is there a way to convert points-type vdb into level sets? I don’t know why but the answers to these questions are very hard to find on the internet. (When googling “blender fluid level set” I get no hits that delve into the subject, which is very odd considering the extensive documentation and tutorials Blender normally has.)

    To be honest I’m starting to feel defeated. I was hoping that this plugin could be used as the bridge to render vdb files from external software’s directly in DAZ… If Blender can only write points-type vdb that’s dead in the water, right? :/

  • Richard HaseltineRichard Haseltine Posts: 97,297

    You can render VDBs driectly in DS, no need to use Fluidos unless the situation specifically requires it.

  • Writer25Writer25 Posts: 7

    Richard Haseltine said:

    You can render VDBs driectly in DS, no need to use Fluidos unless the situation specifically requires it.

    Sorry if I'm going to sound like a noob asking this, but that only works for smoke vbs right? what I want is a "closed" mesh liquid simulation (akin to what's show here in the previews with the liquids), preferably with particle data (foam/bubbles/spray) imported as well.

  • AlbertoAlberto Posts: 1,383

    Richard Haseltine said:

    You can render VDBs driectly in DS, no need to use Fluidos unless the situation specifically requires it.

    But Daz Studio cannot read this particular type of vdb file.

  • AlbertoAlberto Posts: 1,383

    Writer25 said:

    Alberto said:

    Writer25 said:

    Thank you for the quick response and of course. 

    It doesn't seem the attach a file option is working for me, but I've uploaded it to mega.nz. 

    You can find it here: https://mega.nz/file/Q6RD1bRT#xxD2v7AlUDdwYLVLBwispXujAz2Du6ttchvym97f8Fk

     

    It's a simple simulation of a standard cube being liqufied and dropped into the the domain (so basically a cookie-cutter test run to see if I could import a simple liquid simulation from Blender). Frame 15 (mega.nz link) is the one where it has just made contact with the bottom of the domain.

    I checked the vdb.

    The vdb_view utility (included in OpenVDB) couldn't open it. Houdini couldn't open it.

    Examining more in-depth, I found that it isn't a level set, it's not even a fog-type vdb. It's a Points-type vdb (contains particles information).

    Try to see if there is an option to export level set vdbs.

     

     

     

    I see no such option in Blender and to be honest I've got no idea what the difference between these level sets and point-type vdb are. Is point-type vdb a more outdated form of storing vdb data in OpenVDB? Is there a way to convert points-type vdb into level sets? I don’t know why but the answers to these questions are very hard to find on the internet. (When googling “blender fluid level set” I get no hits that delve into the subject, which is very odd considering the extensive documentation and tutorials Blender normally has.)

    To be honest I’m starting to feel defeated. I was hoping that this plugin could be used as the bridge to render vdb files from external software’s directly in DAZ… If Blender can only write points-type vdb that’s dead in the water, right? :/

    Daz Studio (and Fluidos and ABAS) can read these vdb files: https://www.openvdb.org/download/ (sample models), these: https://www.thepixellab.net/vdb-clouds-pack, and these: https://jangafx.com/software/embergen/download/free-vdb-animations/  (at least in part).

    The point type is a format to store particles' information unlike the level-set and fog types. The latter types store surfaces or volumes.

    What addon are you using in Blender to create the fluid simulation? If possible, I could check it and tell you if there is a possibility to transform the data.

     

  • Writer25Writer25 Posts: 7

    Alberto said:

    Writer25 said:

    Alberto said:

    Writer25 said:

    Thank you for the quick response and of course. 

    It doesn't seem the attach a file option is working for me, but I've uploaded it to mega.nz. 

    You can find it here: https://mega.nz/file/Q6RD1bRT#xxD2v7AlUDdwYLVLBwispXujAz2Du6ttchvym97f8Fk

     

    It's a simple simulation of a standard cube being liqufied and dropped into the the domain (so basically a cookie-cutter test run to see if I could import a simple liquid simulation from Blender). Frame 15 (mega.nz link) is the one where it has just made contact with the bottom of the domain.

    I checked the vdb.

    The vdb_view utility (included in OpenVDB) couldn't open it. Houdini couldn't open it.

    Examining more in-depth, I found that it isn't a level set, it's not even a fog-type vdb. It's a Points-type vdb (contains particles information).

    Try to see if there is an option to export level set vdbs.

     

     

     

    I see no such option in Blender and to be honest I've got no idea what the difference between these level sets and point-type vdb are. Is point-type vdb a more outdated form of storing vdb data in OpenVDB? Is there a way to convert points-type vdb into level sets? I don’t know why but the answers to these questions are very hard to find on the internet. (When googling “blender fluid level set” I get no hits that delve into the subject, which is very odd considering the extensive documentation and tutorials Blender normally has.)

    To be honest I’m starting to feel defeated. I was hoping that this plugin could be used as the bridge to render vdb files from external software’s directly in DAZ… If Blender can only write points-type vdb that’s dead in the water, right? :/

    Daz Studio (and Fluidos and ABAS) can read these vdb files: https://www.openvdb.org/download/ (sample models), these: https://www.thepixellab.net/vdb-clouds-pack, and these: https://jangafx.com/software/embergen/download/free-vdb-animations/  (at least in part).

    The point type is a format to store particles' information unlike the level-set and fog types. The latter types store surfaces or volumes.

    What addon are you using in Blender to create the fluid simulation? If possible, I could check it and tell you if there is a possibility to transform the data.

     

    I see, that's already more info that I could gather from 2 hours fo searching. Thank you. :') 

    I'm using the "standard" in-built liquid simulator that comes free with every copy of Blender; the simulation type I've tried to run is FLIP.

    To help you pin-pointing my exact setup; this is the .blend file I've tried exporting (you'll need to adjust the cache path but beyond that it should be good to go): https://mega.nz/file/oiYA3D6a#gYNO1z05f0VZm-G_yPAXoiFWJL_rxGn6FdrX4cCBxVo

  • AlbertoAlberto Posts: 1,383

    Writer25 said:

    I see, that's already more info that I could gather from 2 hours fo searching. Thank you. :') 

    I'm using the "standard" in-built liquid simulator that comes free with every copy of Blender; the simulation type I've tried to run is FLIP.

    To help you pin-pointing my exact setup; this is the .blend file I've tried exporting (you'll need to adjust the cache path but beyond that it should be good to go): https://mega.nz/file/oiYA3D6a#gYNO1z05f0VZm-G_yPAXoiFWJL_rxGn6FdrX4cCBxVo

    I reviewed the Blender manual and some sites. The manual says this about the VDB files in the cache:

     OpenVDB
    Advanced and efficient storage format. All simulation objects (i.e. grids and particles) are stored in a single .vdb file per frame.

    The standard fluid simulator in Blender uses these VDB files as storage files, but not for exporting the simulation. This is similar to the plugin PARSIS for Daz Studio: It saves particles data in VDB files, but not for export.

    However, Blender can export its fluids simulation as OBJ Animation (you must bake the mesh first).

     

  • Writer25Writer25 Posts: 7

    Alberto said:

    Writer25 said:

    I see, that's already more info that I could gather from 2 hours fo searching. Thank you. :') 

    I'm using the "standard" in-built liquid simulator that comes free with every copy of Blender; the simulation type I've tried to run is FLIP.

    To help you pin-pointing my exact setup; this is the .blend file I've tried exporting (you'll need to adjust the cache path but beyond that it should be good to go): https://mega.nz/file/oiYA3D6a#gYNO1z05f0VZm-G_yPAXoiFWJL_rxGn6FdrX4cCBxVo

    I reviewed the Blender manual and some sites. The manual says this about the VDB files in the cache:

     OpenVDB
    Advanced and efficient storage format. All simulation objects (i.e. grids and particles) are stored in a single .vdb file per frame.

    The standard fluid simulator in Blender uses these VDB files as storage files, but not for exporting the simulation. This is similar to the plugin PARSIS for Daz Studio: It saves particles data in VDB files, but not for export.

    However, Blender can export its fluids simulation as OBJ Animation (you must bake the mesh first).

     

     

    Alright, then we've found the crux of the issue. I'm aware of how the export proces for animated obj. files (sequences) works for Blender, and also know of a plugin which would the import of this within DAZ for animation.

    However the thing that had me so stocked about your plugin, was the fact that it also support bubble/foam particle effects in itself. I understand this is done through instancing to reduce the load on the software? Which is a shame since if you export into .obj all the instances are converted back into objects, causing immense file bloat and more memory drawn from the GPU when you eventually render the .obj file.

    So in conclusion; FLUIDOS II cannot take point-type vdb files at the moment, and will also likely not be able to do so in the (near) future? 

     

  • AlbertoAlberto Posts: 1,383

    Writer25 said:

    Alberto said:

    Writer25 said:

    I see, that's already more info that I could gather from 2 hours fo searching. Thank you. :') 

    I'm using the "standard" in-built liquid simulator that comes free with every copy of Blender; the simulation type I've tried to run is FLIP.

    To help you pin-pointing my exact setup; this is the .blend file I've tried exporting (you'll need to adjust the cache path but beyond that it should be good to go): https://mega.nz/file/oiYA3D6a#gYNO1z05f0VZm-G_yPAXoiFWJL_rxGn6FdrX4cCBxVo

    I reviewed the Blender manual and some sites. The manual says this about the VDB files in the cache:

     OpenVDB
    Advanced and efficient storage format. All simulation objects (i.e. grids and particles) are stored in a single .vdb file per frame.

    The standard fluid simulator in Blender uses these VDB files as storage files, but not for exporting the simulation. This is similar to the plugin PARSIS for Daz Studio: It saves particles data in VDB files, but not for export.

    However, Blender can export its fluids simulation as OBJ Animation (you must bake the mesh first).

     

     

    Alright, then we've found the crux of the issue. I'm aware of how the export proces for animated obj. files (sequences) works for Blender, and also know of a plugin which would the import of this within DAZ for animation.

    However the thing that had me so stocked about your plugin, was the fact that it also support bubble/foam particle effects in itself. I understand this is done through instancing to reduce the load on the software? Which is a shame since if you export into .obj all the instances are converted back into objects, causing immense file bloat and more memory drawn from the GPU when you eventually render the .obj file.

    So in conclusion; FLUIDOS II cannot take point-type vdb files at the moment, and will also likely not be able to do so in the (near) future? 

     

    I don't know about Blender, but Fluidos doesn't use instances in bubble/foam/spray particles. In fact, all those particles are contained in a single object. 

    And the problem with the point-type VDB files is that there are used as storage files, and there isn't a "standard" format for these files. Blender creates these only for internal storage purposes. Blender and only Blender uses them. In order to port them to another software, you need a bridge or a converter (with the risk that the format in Blender can be changed at any moment).

    I think that soon or later, Blender will be capable to export the simulation as level sets or fog VDBs, either natively or by means of an add-on. But, to my knowledge, not for now. 

  • Writer25Writer25 Posts: 7

    Understood. In any case thank you for all the help and explanation Alvin; I appreciate it and let's hope Blender will one day support such a feature. ^^

  • ioonrxoonioonrxoon Posts: 886

    @Alberto I've opened a ticket for this and Richard reported it as well I believe, but unfortunately nothing's being done, figured I'd let you know as well before returning it. There are no manual installers for the LITE version in library.

  • AlbertoAlberto Posts: 1,383

    ioonrxoon said:

    @Alberto I've opened a ticket for this and Richard reported it as well I believe, but unfortunately nothing's being done, figured I'd let you know as well before returning it. There are no manual installers for the LITE version in library.

    In fact, there is not manual installers for the plugin, only for the content. The installing is via DIM.

  • ioonrxoonioonrxoon Posts: 886

    Alberto said:

    ioonrxoon said:

    @Alberto I've opened a ticket for this and Richard reported it as well I believe, but unfortunately nothing's being done, figured I'd let you know as well before returning it. There are no manual installers for the LITE version in library.

    In fact, there is not manual installers for the plugin, only for the content. The installing is via DIM.

    Then why is it listed on the product page? I don't use dim and got it (+ some of the presets in advance, that are now past the 30 day date) based on this misinformation.

  • Dark45Dark45 Posts: 58
    edited December 2022

    In need of some guidance. I have a viscus liquid (syrup) that I am working with. I have everything set the way I'd like to, the consistancy and speed of which the syrup falls. But the issue is that it is choppy. It produces the liquid at frame 60 as an example, at that time it's just a blob. Then it does not move again until frame 65, then doesn't move again until frame 70.

    As you can imagine this makes the playback quite choppy. Anyone have an idea on what might not be set right? I've work with it in 30, 60, and 120 fps with the same result.

    Post edited by Dark45 on
  • AlbertoAlberto Posts: 1,383

    Dark45 said:

    In need of some guidance. I have a viscus liquid (syrup) that I am working with. I have everything set the way I'd like to, the consistancy and speed of which the syrup falls. But the issue is that it is choppy. It produces the liquid at frame 60 as an example, at that time it's just a blob. Then it does not move again until frame 65, then doesn't move again until frame 70.

    As you can imagine this makes the playback quite choppy. Anyone have an idea on what might not be set right? I've work with it in 30, 60, and 120 fps with the same result.

    Maybe you have to reduce the viscosity. What was its value?

  • AlbertoAlberto Posts: 1,383

    ioonrxoon said:

    Alberto said:

    ioonrxoon said:

    @Alberto I've opened a ticket for this and Richard reported it as well I believe, but unfortunately nothing's being done, figured I'd let you know as well before returning it. There are no manual installers for the LITE version in library.

    In fact, there is not manual installers for the plugin, only for the content. The installing is via DIM.

    Then why is it listed on the product page? I don't use dim and got it (+ some of the presets in advance, that are now past the 30 day date) based on this misinformation.

    Sorry, I missed your reply.

    Are you asking about the Install Types section?

    Install Types:  DazCentral Daz Connect DIM Manual Install

    I suppose it's alluding to the manual installation of contents. I didn't create this particular section (It's reserved for DAZ, because they made the installers)

    However, if you want to install the plugin manually, there is a way, but you have to use the DIM to download the files (but not for installation).

    This is the procedure for Fluidos original, but it's the same for Fluidos II Lite: https://www.daz3d.com/forums/discussion/comment/3922111/#Comment_3922111

    To register the plugin: https://www.daz3d.com/forums/discussion/comment/3916516/#Comment_3916516

Sign In or Register to comment.