FluidVolume through which objects sink

[snoozbuster]

So, I decided I wanted to use a FluidVolume to simulate lava/water/snow and so on, but FluidVolumes seem to make things float. Is there anyway to make objects hit them and sink, as if the object wasn't buoyant enough to stay afloat? Would giving it the opposite gravity work? (eg if the gravity was (0, 0, -9.81), would giving it 9.81 for the gravity constant make things sink? Also, does it require a basin to sit in, or does it float?

EDIT: It floats. One question answered.

[Norbo]

Is there anyway to make objects hit them and sink, as if the object wasn't buoyant enough to stay afloat?

If the density of the fluid is decreased or if the density of the entities is increased (greater mass, lower volume), the entities will be less buoyant- just like normal fluid.

Would giving it the opposite gravity work? (eg if the gravity was (0, 0, -9.81), would giving it 9.81 for the gravity constant make things sink?

Well, it would make them float in the opposite direction...

Also, does it require a basin to sit in, or does it float?

The fluid is a volume, not particles or flowing water, so it is defined entirely by a surface plus a depth. It needs no actual container.

[snoozbuster]

If the density of the fluid is decreased or if the density of the entities is increased (greater mass, lower volume), the entities will be less buoyant- just like normal fluid.

So, a very low density but high damping would simulate a rather thick liquid through which entities sink?

Well, it would make them float in the opposite direction...

So they'd hit the top and float to the bottom, so to speak?

[Norbo]

Yup.

[snoozbuster]

Apologies for dragging up an old thread, but I had other things to work on, so I put this particular thing to bed for a while. Anyway, I was trying to get it to work, but it acts as if it's not there. I suspect this is related to using Z as up instead of Y. I swapped the Y and Z of the surface tris, those look fine, but it still doesn't work. Think you have the heart to change FluidVolume to always use the UpVector as the reference for direction of buoyancy? It's the only thing I can possibly think of.

[Norbo]

There is indeed a disabled bit of code in the FluidVolume.GetBuoyancyInformation which is needed to support non-Y fluid volumes. Changing it to hardcode-support another axis wouldn't be too hard. I won't be making any changes for that in isolation, but you could fiddle with that method to make it work.

The FluidVolume as a whole is on the rewrite list to bring it into the broad phase pipeline (like the DetectorVolume is in v1.2.0) and to make it less clunky.

[snoozbuster]

I tried changing all the Ys to Zs and the Zs to Ys, but it didn't work. I don't think I missed any... I'll have another look, though. At least now I know what I have to do.

[snoozbuster]

I gave it a thorough look, and I didn't find anything that might need to be swapped or any Zs/Ys I missed. Want me to post the edited code?

[Norbo]

I probably won't be able to give a thorough look at it until I finish up this other nasty problem I'm working on, so I'd suggest either waiting on the rewrite if you can (it will take at least a week before I can get to it, maybe more) or continue fiddling around.

In other words, if something else in there isn't working, I don't know what it would be off the top of my head so I wouldn't have a significant advantage in debugging it quickly.

[snoozbuster]

Oh, alright. It's not a big deal. I'll post again when I get back around to it, maybe you'll have fixed it by then. I personally don't find it a major deal, but one of the guys I work with has a different opinion.

[Norbo]

A full rewrite of the FluidVolume is low priority enough that I decided it would take a bit too long to get out. Instead, I went ahead and made some modifications to the existing form of the FluidVolume. It should now support non-Y directions.