FLUIDOS II for Daz Studio - update 2.2 [commercial]

Alberto

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.

mikethe3dguy

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.

mikethe3dguy

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.

 

capitanharlock80

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.

mikethe3dguy

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!

capitanharlock80

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!!!

mikethe3dguy

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.

Alberto

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.

lorddayradon

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.

 

 

 

Alberto

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.

lorddayradon

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.

 

 

Alberto

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.

lorddayradon

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?

 

 

Alberto

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.

 

Imago

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.

lorddayradon

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.

mikethe3dguy

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

Elor

I bought Fluidos II Lite a couple of days ago and today, I wanted to see how it worked on my Mac (running MacOS 10.14), so I loaded one of the scene included with the product, before launching a fluid simulation.

I tried with the latest Public Beta, and each time, Daz will crash a couple of second after I launch the simulation. It crashed too while using Daz Studio 4.21.0.5.

Here the log just before the crash (I removed what Daz is doing when it's shutting down itself):

2024-07-16 14:57:26.234 [INFO] :: Finished asset load (open): 0m 0.391s - /Scenes/AlvinBemar/Fluidos II/Fluidos II scene 1.duf
2024-07-16 14:57:26.584 [INFO] :: Unlocking viewport redraw...
2024-07-16 14:57:26.584 [INFO] :: Viewport redraw unlocked.
2024-07-16 14:57:31.657 [WARNING] :: QWidget::setMinimumSize: (/QLabel) Negative sizes (0,-536870910) are not possible
2024-07-16 14:57:34.034 [WARNING] :: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

2024-07-16 14:57:34.035 [FATAL] :: Unhandled exception: Unknown Exception. DAZ Studio must now shut down.

Alberto

Elor said:

I bought Fluidos II Lite a couple of days ago and today, I wanted to see how it worked on my Mac (running MacOS 10.14), so I loaded one of the scene included with the product, before launching a fluid simulation.

I tried with the latest Public Beta, and each time, Daz will crash a couple of second after I launch the simulation. It crashed too while using Daz Studio 4.21.0.5.

Here the log just before the crash (I removed what Daz is doing when it's shutting down itself):

2024-07-16 14:57:26.234 [INFO] :: Finished asset load (open): 0m 0.391s - /Scenes/AlvinBemar/Fluidos II/Fluidos II scene 1.duf
2024-07-16 14:57:26.584 [INFO] :: Unlocking viewport redraw...
2024-07-16 14:57:26.584 [INFO] :: Viewport redraw unlocked.
2024-07-16 14:57:31.657 [WARNING] :: QWidget::setMinimumSize: (/QLabel) Negative sizes (0,-536870910) are not possible
2024-07-16 14:57:34.034 [WARNING] :: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

2024-07-16 14:57:34.035 [FATAL] :: Unhandled exception: Unknown Exception. DAZ Studio must now shut down.

Could you tell me the name of the scene?

Did you try another scene?

Could you upload the Fluidos II log file? This is inside of the logs subfolder in the Baked files folder of the Domain (check the property Baked files folder of the Domain). The Daz log isn't very useful in this case.

Elor

I forgot to describe my Mac so if it's useful: it's a Macbook Pro with a M1 Pro chip (one with 10 CPU Cores, 16 GPU Cores and 32 GB of RAM).

For the log in my previous message, it was Fluidos II scene 1.duf but I also tried Fluidos II scene 1 - Stabilization example, and Fluidos II scene 2. All ended with Daz shutting down with the same error in Daz Log.

I also tried to create a scene with a Fluidos Domain and a Fluidos Sink, moving them to make sure the sink was inside the domain (I didn't touch any setting outside of defining a directory to store bakedfiles) and Daz also shut down when I hit Run Fluidos Simulation, without writting any log in the bakedfiles directory.

As for Fluidos logs, none are visible outside of one from 2020 (called 23-Apr-2020 09h36m43s.txt) which is either one you included or one the Daz QA team included. I don't think it's related to my computer because it's about a computer with an GTX 1070.

Alberto

It isn't your computer.

There is a bug. Let me fix it, please.

 

Alberto

Elor said:

I forgot to describe my Mac so if it's useful: it's a Macbook Pro with a M1 Pro chip (one with 10 CPU Cores, 16 GPU Cores and 32 GB of RAM).

For the log in my previous message, it was Fluidos II scene 1.duf but I also tried Fluidos II scene 1 - Stabilization example, and Fluidos II scene 2. All ended with Daz shutting down with the same error in Daz Log.

I also tried to create a scene with a Fluidos Domain and a Fluidos Sink, moving them to make sure the sink was inside the domain (I didn't touch any setting outside of defining a directory to store bakedfiles) and Daz also shut down when I hit Run Fluidos Simulation, without writting any log in the bakedfiles directory.

As for Fluidos logs, none are visible outside of one from 2020 (called 23-Apr-2020 09h36m43s.txt) which is either one you included or one the Daz QA team included. I don't think it's related to my computer because it's about a computer with an GTX 1070.

I sent you a PM.