Which 3D object to use, and how to get its position through code?

Question

Hi forum!

Intention
I'm trying to create biological cells that divide and interact with each other in a 3D gravity-free environment. This question is about the physics implementation.

The only physical interaction they should have is a force that attracts them to each other when they touch each other. If cell A and cell B touch each other, there should be a force that acts on both such that their centers end up at a user-defined resting distance from each other.

Implementation
I'm thinking I need to have CollisionShape to detect when the cells touch each other. So far I've gone with CollisionShape shaped like a sphere, and a spherical CSGMesh as visual component. I plan to use GDscript.

Thoughts
I'm wondering which "body" type that would be best for my implementation of the cells? I think it's a choice between "Area" and "RigidBody". Spontaneously I'm thinking that RigidBody would be better, but I need the cells to be able to overlap.

Question1: can RigidBody overlap each other? I.e. given two RigidBodies A and B shaped like spheres, can parts (or all of) A be inside the radius of B (and vice versa)? Or are RigidBody "rigid" in the sense that it doesn't allow objects to be "inside" of it.

My guess is that they don't allow objects "inside", which results in my second question.

Question2: would Area at all be useful for my implementation?

I'm thinking it can, if I can just manage to get the physics of it to work. Area clearly let's other areas be "inside" of them, so this object is probably perfect for me. This is my current approach, but the problem is that I can't find the "position" of an Area, which gets me to my third question.

Question3: how to get the position of a) a RigidBody and b) an Area (through GDscript)?

So far I've been trying to get the position of Area through get_pos(), simply calling "position", and self.position, but I get an error in either case. For details, see here the code where I've commented "THE PROBLEM", where I try to get the position of SpaceCell.

Answer 1

Ad 1

Yes, RigidBodies can, in fact, overlap each other - you just have to exclude them from each other's collision layers. In short, collision layer are layers that the object appears in, and collision mask are layers that object scans for a collision. You can read more about it here.

Ad 2

The Area is a great idea for your implementation, but it is not meant to be moved directly. The best way to do this is to make Area a child of, for example, RigidBody, and then to move this RigidBody instead.

Ad 3

You have to take it out of the transform. That means you have to use transform.origin, or global_transform.origin.

There is one more thing - if there really is only one force that will be applied to these cells, then KinematicBody is a far better bet than RigidBody. RigidBody implements full physics, which is inertia, bouncing, rotating and every other possible outcome of collisions. You can control it via integrate forces method but in your case, it is an overkill.

KinematicBody, on the other hand, doesn't have those effects but gives you much more precise control over its behavior. Given that you don't need them, it can save you many troubles. You can control it via move and collide or via move and slide function.

EDIT:

Ok, so I was wrong, and as kidscancode said there is nothing wrong with moving Area, especially when you do not need collision. Sorry for the misleading answer, I am too just learning :)

Comments

The Area is a great idea for your implementation, but it is not meant to be moved directly. The best way to do this is to make Area a child of, for example, RigidBody, and then to move this RigidBody instead.

There is nothing wrong with moving an Area around. If overlap is all you need, then additional nodes are not required.

---

Thanks a lot for the replies! And thanks for the idea of using KinematicBody... I think that will give me some performance improvements as well. Currently the code gets a big drop in FPS after around 1000 instances.