Creating a water buoyancy system: Page 2

Creating a water buoyancy system

dotted

@cybereality said: Can gravity scale be negative?

I might suggest: gravity-value, linear_damp (for all motion) and space-override (SPACE_OVERRIDE_COMBINE)

Area 'gravity' combined with global gravity can achieve any buoyancy needed. Linear damp can be used to modestly tweak overall speeds.

Collision layers and co-incident areas can apply different effects to different objects via different settings.

cybereality

Space override is pretty neat. Never tried that before. That is definitely a cleaner way to do it. And I didn't realize you could adjust linear damp there (I was doing it manually, which was a hack). But it still doesn't seem to resolve the bouncing at the edge.

cybereality

Okay so it got it sort of working. Thanks for the tip @dotted . Basically you need Areas, the main body of water and the edge of the water. Both are set to space override combine. For the body of water Area, set gravity to - 19.6 (so the object will float) and on the edge Area, set gravity to -9.8 so it i will level off and stay still. You probably want to also test changing linear damp on the 2 areas (I found numbers between 1 and 2 work). It's not perfect, but it seems to working pretty good.

xyz

Damping is precisely what is needed for "natural" behavior as it stands in for drag force. There is considerable amount of drag force applied to the object when submerged, in direction opposite to movement.

Drag force is always proportional to velocity. If you want precise simulation, calculate buoyancy (proportional to volume/area submerged) and underwater drag (proportional to velocity) and subtract them from the gravity force. Or just inject proper buoyancy and and drag forces into the system each frame.

It can be done with any of the suggested methods; gravity scale, injected forces, etc... But you don't really need any elaborate setup.

# 2D, y axis points downwards

var waterLevel = 100
var fullySubmergedLevel = 200
var maxBuoyancy = 20.0  # if greater than gravity, object will float
var gravity = 9.8
var fluidDrag = .1

func _process(delta):
	var buoyancy = clamp(range_lerp(position.y, waterLevel, fullySubmergedLevel, 0.0, maxBuoyancy), 0, maxBuoyancy)
	var drag = 0
	if position.y > waterLevel:
		drag = linear_velocity.y * fluidDrag # nor a proper drag calculation but good enough for this
	gravity_scale = (gravity - (buoyancy + drag)) / gravity

Drawback of using a separate Area for "water edge" (or hardcoded "edge" as in above example) is that it doesn't take object's size/volume into consideration. Larger the object, larger its "edge area" will be. If all objects are roughly the same size then it's ok. But if you need more generalized system it's better to calculate buoyancy from object's size.

Leakbang

I'm working in 3D, I tried tinkering with your code but didn't manage to get it work in a 3d environment. Also since I'm using areas, I can't use a general variable like waterLevel to determine if an object is submerged or not. I have to use an on_body_entered trigger to detect if an object is in the water or not. The biggest problem with the area node is that I can't know how submerged the object is. I have no idea how can I determine how submerged the object is.

xyz

Find top and bottom of your object and top of the water. Submersion can be easily calculated from that. You can get that info from your collision shapes, but it may differ depending on what collision shapes you're planning to cover. You may have to do some transform calculations, depending on the setup.

Alternative is, and it may be better in your case, to parent to each of your objects any node that inherits VisualInstance (say simple cube mesh), make them adequate size, and get their bounding boxes using get_transformed_aabb() method which returns axis aligned bounding box of the object (AABB). Then just use y coordinates from AABBs

Of course if your objects already have meshes, you can just use that meshes to get bounding boxes.

Leakbang

Yeah the bounding box idea is great! I think that would work out nicely. However, how can I find the top and bottom of the object? I suppose raycast comes to mind, but I think that's one of the worst ways to do it, since a lot of things can go wrong. Theoretically, I could define a top and bottom point on the object itself, but then it won't work if the object rotates.

xyz

Also, don't use my code directly. It's at pseudocode level, just to illustrate parameters that are involved in the calculation. If you want to play with it, play in 2D, as it only really operates in one (vertical) dimension. Although, it still shows proper influence of particular parameters to the overall motion.

If you're in 3D, once you introduce fluid drag into the picture you'll need to work with full 3D force vectors since drag will affect other two velocity vector components as well. So in that case, it'd be easier to approach it as you initially intended - applying forces to rigid bodies and let the physics solver handle the rest.

xyz

@Leakbang said: However, how can I find the top and bottom of the object?

Just get the values from the bounding box. If your mesh is fairly compact it's good enough approximation:

var top = aabb.position.y + aabb.size.y / 2.0
var bottom = aabb.position.y - aabb.size.y / 2.0

You can also shrink/expand the bounding box prior to extracting the extents, using AABB.grow() That's useful sometimes.

If you want to exactly match colliders you'll need to extract information from collision shapes, which is more work and may not be worth it if you can get decent results with AABBs. Submersion amount is only a ballpark value here anyway, but that's good enough for visual simulation. So I'd vote for using AABBs as they make things considerably easier to handle.

It all really depends on how generalized a system you want to make. If all your objects are balls then everything gets much simpler. I'd recommend starting with such simpler system. Once you get it working you can experiment with adding more complex stuff.

cybereality

So here is the project I made. Maybe you want to try it. This is a basic solution using the space override. I would not use this if physics is a core part of your gameplay (as it's not realistic) but for special effects or just stuff floating in the water, it should be fine. Note, there is no need to use any code, the physics engine does everything, so should perform well. Press space bar to spawn more cubes.

Leakbang

So I started by implementing a drag calculation system and I think its a good starting point. Here is the code for it:

extends Area

const Drag = 3
const Density = 5

var objects = []

func _process(delta):
	if objects:
		for i in range(0, objects.size()):
			var AreaSize = objects[i].get_scale()
			var velocity = objects[i].linear_velocity
			var dragforce = 0.5 * Drag * Density * AreaSize * velocity * velocity
			objects[i].add_central_force(dragforce)

func _on_Area_body_entered(body):
	objects.append(body)


func _on_Area_body_exited(body):
	objects.erase(body)

It works perfectly when calculating vertical drag. However, it totally freaks out when there is any movement on x or z axis. It exponentially increases the speed of the object and launches it into space. I tried changing the force applied code to objects[i].add_central_force(Vector3(-dragforce.x, dragforce.y, -dragforce.z)) but it just launches the object in the opposite direction. Also how can I actually calculate the size of the object's bounding box? I thought I could get away with var bounding box = AABB(objects[i].translation, objects[i].get_scale()) but it doesn't work since the scale of an object doesn't represent its size.

xyz

That drag formula is scalar formula. It calculates absolute drag magnitude. Drag direction is always opposite to velocity vector. You can't just plug the velocity vector into that equation. Using multiplication operator like that will multiply vector components. And doing that will most likely change its direction when multiplied by itself.

If you look closely the equation boils down to some_constant * velocity_squared. I'd suggest you hardcode that constant for start and tweak it via trial/error for things to look decent. You can later add precise calculation based on object's apparent submerged section area.

To get the proper force vector, you need to calculate the scalar magnitude and then multiply it with normalized flipped velocity vector:

var my_drag_constant = 10.0  # calculate real drag constant here when things start working (if needed)
var drag_force_magnitude: float = my_drag_constant * velocity.length_squared()
var drag_force: Vector3 = -velocity.normalized() * drag_force_magnitude

And note that you can always use built-in velocity damping instead of this.

Second thing. No need to calculate the bounding box yourself (and it would take some work). Engine already has it. Just get it from the VisualInstance node api. And every bounding box knows how big it is :)

var bounding_box: AABB = object.get_transformed_aabb()
var bounding_box_size: Vector3 = bounding_box.size

EDIT: Have in mind that get_transformed_aabb() can't be called on physics bodies. Which is unfortunate since physics engine internally "knows" bounding boxes of everything it deals with. So you must have something visible (like MeshInstance) that coincide with physics body collider shape, and get bounding box of that.

Leakbang

Oh wow that's amazing! Thank you very much for helping me put this all together. I did what you said, I added the buoyancy force and I think that's it! It works out very nicely. Here is the final code:

extends Area

const Drag = 3
const Density = 5

var water_level = 4

var object_mass = []
var objects = []

func _process(delta):
	if objects:
		for i in range(0, objects.size()):
			# Get the bounding box from the rigidbody's MeshInstance
			var bounding_box: AABB = objects[i].get_child(0).get_transformed_aabb()
			var bounding_box_size: Vector3 = bounding_box.size
			# The area of the touching surface
			var area = bounding_box_size.x /5
			var top = bounding_box.position.y + bounding_box_size.y / 2.0
			var bottom = bounding_box.position.y - bounding_box_size.y / 2.0
			
			var velocity = objects[i].linear_velocity
			var drag_force = 0.5 * Drag * area * Density * -velocity.normalized() * velocity.length_squared()
			
			var buoyant_force: Vector3
			
			if top < water_level:
				# The +10 pushes the object up. Otherwise, it would just float
				buoyant_force.y = object_mass[i] + 10
			else:
				var immersion = (water_level - bottom) / bounding_box_size.y
				buoyant_force.y = object_mass[i] * immersion
			# apply the force
			objects[i].add_central_force(drag_force + buoyant_force)

func _on_Area_body_entered(body):
	objects.append(body)
	object_mass.append(body.weight)


func _on_Area_body_exited(body):
	objects.erase(body)
	object_mass.erase(body.weight)

I tested it in various situations, and it's really solid. It can easily be expanded to support more features. The constant values here should be more tested through trial and error to find the optimal values, but as it stands it's pretty good.

Leakbang

Is it possible to actually see the bounding boxes that are made? That would be very helpful and makes fine tuning a breeze.

Leakbang

@Leakbang said: Is it possible to actually see the bounding boxes that are made? That would be very helpful and makes fine tuning a breeze.

Found this addon that easily allows me to do that: https://github.com/Zylann/godot_debug_draw

cybereality

You can get the size of the collision object. So:

collision_object.shape.shape.extents

And the size will be extents * 2.0

xyz

@cybereality Only box shapes have extents property, and it's in parametric space. Unfortunately, no transformations are taken into account, not even shape's own matrix. I tried to look up some generalized painless way to extract world space bounding boxes from collision shapes, but couldn't find any. Seems it's only doable for visual instances. But this is probably inexpensive. Engine needs to maintain these AABBs anyway for things like frustum culling.

cybereality

Godot has an AABB class. https://docs.godotengine.org/en/stable/classes/class_aabb.html

Doesn't look like you can directly convert a collision shape to an AABB, though.

However, you can get the points in a ConvexPolygonShape (for example). https://docs.godotengine.org/en/stable/classes/class_convexpolygonshape.html

So create a new AABB, loop though all the points in the shape, and add them to the AABB using expand.

xyz

It's doable for sure, but imho too much hassle for the coder and too much work for cpu since you still need to transform each vertex in each shape each frame back to global space. For a generalized system you'll also need to support transformed parametric shapes (possibly non-proportionally scaled). At least box, sphere, and cylinder.

It's too bad because Bullet can return any bounding box of any collision shape in any frame of reference, I'm guessing without any (or just minimal) additional cost. Instead of coding this in GDScript I'd much rather spend energy on pestering developers to just expose btCollisionShape::getAabb() via the Godot api. Much less work and better results in total :)

Megalomaniak

@xyz said: It's too bad because Bullet can return any bounding box of any collision shape in any frame of reference, I'm guessing without any (or just minimal) additional cost. Instead of coding this in GDScript I'd much rather spend energy on pestering developers to just expose btCollisionShape::getAabb() via the Godot api. Much less work and better results in total :)

https://github.com/godotengine/godot-proposals/issues

« Previous Page Next Page »