defold / defold/defold

box2d - add b2d.body.get_gameobject and get_collisionobject OR/AND make b2d handles indexable

Open
#12,795 0 comments 0 reactions 0 assignees View on GitHub
box2d discuss engine feature request physics
Dominant language
C++
Stars
6.3k
Forks
455
Avg merge
2d 2h
Merged PRs (30d)
129

Description

_Is it a private platform specific feature? (i.e. would it break your NDA?)

Then please add your feature request in the corresponding extension repository!_

**Is your feature request related to a problem? Please describe (REQUIRED):**

I know there is already a feature request open for the get_user_data and set_user_data, but I think the need is still relevant.

Right now, you cant get back the gameobject or the collisionobject (component) for a b2d body handle.
For efficient scripting of box2d, the basics is to be able to act on the object the body is attached to.
Moreover, we maybe need to get also the full url of the collisionobject component which represent the body, because maybe the executing code is a manager that dont know where the body comes from.

Moreover, a body handle cannot be used as a table key, because the equality as index of table is not implemented (it is by value instead of by references), so the only reliable way to index a body is to index the url of its collision object component.
So 2 body handles referencing the same object are equals when using == operator, but if used as table keys, they defines different keys. Since we get a different handle at each call to b2d.get_body(), be can never find efficiently a body in a table (as a key). We need to loop over all the table values/keys and compare each values/keys using == operator.

**Describe the solution you'd like (REQUIRED):**

I want to get the url of the gameobject and collisionobject so I can write reusable code relative to physical objects.
I want to do

```lua

local function super_b2d_function(body)
local obj = b2d.body.get_gameobject(body) -- return body hash or body url?
local pos =go.get_position(obj)
go.set_position( pos + b2d.body.get_linear_velocity()) -- really poor example I know
end

--- pick any gameobject having a collision object
local function pick_object(x,y)
local hits = b2d.world.overlap_aabb(b2d.get_world(),{lower=vmath.vector3(x-1,y-1,0), upper=vmath.vector3(x+1,y+1,0)}, nil,1)
if not hits or #hits==0 then return nil end
local shape_id = hits[1].shape_id
return b2d.body.get_gameobject( b2d.shape.get_body(shape_id))
end
```
This will permit to write reusable physical behaviours for b2d objects, without knowing anything about the gameobject.

**Describe alternatives you've considered (REQUIRED):**

Right now we need to track in a global registry the link between every created body and its gameobject.
And be carefull because body handles are not indexable.

**Additional context (OPTIONAL):**

This feature request is the result of my struggling during the Box2d scripting challenge.

I dont know if we really need the set_user_data feature, unless we could create bodies that are NOT attached to collisionobjects components, from scratch.
If bodies must always be created as a collisionobject component, I think we should not have the set/get user data functions, but only a get_gameobject function. Or it will be confusion.
As a final note, the new b2d scripting API make all the existing physics module a bit confusing, it is not clear how things are related to each other. Moreover, the Editor UI itself is confusing about bodies and shapes, since shapes properties are (in the editor) defined at the collisionobject level (so the body level), but in the API it is linked to the shapes.

P.S. I know this is a messy feature request 😆, I merely wanted to get your feedback and opinions on these points

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the existing b2d scripting API for body, shape, and collisionobject relationships, including how handles behave as table keys. Clarify whether the desired result is gameobject lookup, collisionobject URL lookup, indexable handles, or some combination, then define and test the API behavior for each supported case.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, lua
Domain
api, game-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.