DAABBCC - Dynamic Tree(aka AABB Tree) native extension for fast AABB collision detection

Don’t know :smiley:
it doesn’t matter in DAABBC. It just returns what you give it to it.
Except for the new Gameobject function. It gets local position (basically go.get_position). But there is GetWorldPosition() in the API so I can implement it if you need to.

1 Like

I am still testing the update, but here are my findings so far:

I am unable to build the example game project. I get a message:

/components/collections/main.collection
	The file 'null' could not be loaded.

I can’t figure out how to fix this.

Is there a difference between aabb.remove() and aabb.remove_gameobject()? The documentation implies they do the same thing.

Is gameobject position update iteration ON by default? It seems to be the case - might need to add that explicitly to docs.

I never saw this . Which example is that, build-in one or space-shooter? If space-shoter, then sprite scale9(1.3.7) can be the problem.
Let me check… I’ll let you know…

No difference at all right now.
aabb.remove_gameobject() is here for future use case.

Yes it is ON by default but it is not iterating when it is size is 0.

3 Likes

this is not related to aabbcc…
I was eager to test new sprite slice9 feature on 1.3.7 and I forgot to remove it :slight_smile: So it can’t work on 1.3.6 right now. I’m going to remove the slice9 and push it again in a while. Meanwhile, you can remove it from main.collection file using the text editor(just search for slice9, size and size_mode)

EDIT: Just removed the slice9 on git repo and it works on 1.3.6 now.

3 Likes

I can confirm this works for me now! Thank you.

@selimanac Thank you for all your work on this update.

I am driving myself crazy trying to make even a simple example work. After not being able to get the gameobject tracking to work, I reverted to the old method which I have worked with before.

The old method works for me in 2.0, but not in 2.1. I have no idea why.

This is the test. The moving square is tracked via AABB, and in update I check for collisions with the static square.

Code for gameobject tracking (does not work):


local aabb_group = nil
local static_square = nil
local moving_square = nil

function init(self)

	static_square = go.get_id("static_square")
	moving_square = go.get_id("moving_square")

	aabb_group = aabb.new_group()

	local moving_id = aabb.insert_gameobject(aabb_group, msg.url(moving_square), 100, 100)
	print(moving_id)

	go.animate(moving_square, "position", go.PLAYBACK_LOOP_PINGPONG, vmath.vector3(450,150,0), go.EASING_LINEAR, 5, 0, nil)
end

function update(self, dt)
	
	local position = go.get_position(static_square)
	local hits = aabb.query(aabb_group, position.x, position.y, 100, 100)
	if hits then
		pprint(hits)
	end
end

Old style code, which requires aabb.update() (works in 2.0, does not work in 2.1):

local aabb_group = nil
local static_square = nil
local moving_square = nil
local moving_id = nil

function init(self)

	static_square = go.get_id("static_square")
	moving_square = go.get_id("moving_square")

	aabb_group = aabb.new_group()

	moving_id = aabb.insert(aabb_group, 150, 450, 100, 100)
	print(moving_id)

	go.animate(moving_square, "position", go.PLAYBACK_LOOP_PINGPONG, vmath.vector3(450,150,0), go.EASING_LINEAR, 5, 0, nil)
end

function update(self, dt)

	local moving_position = go.get_position(moving_square)
	aabb.update(aabb_group, moving_id, moving_position.x, moving_position.y, 100, 100)
	
	local position = go.get_position(static_square)
	local hits = aabb.query(aabb_group, position.x, position.y, 100, 100)
	if hits then
		pprint(hits)
	end
end

Project is here:
aabb_gameobject_test.zip (4.7 KB)

I have to assume I am doing something silly, because your example project works.

Thanks for the help!

1 Like

I’m looking to it… looks like there is something wrong with .query
aabb.query_id works on your example by the way. I highly recommend you to use .insert as much as possible.

Is this because the iteration to update the gameobject position is costly? So for static objects that makes sense, but for objects that move (e.g. using go.animate) then presumably it should be better to use insert_gameobject rather than insert + continually doing update (which would require go.get_position)?

This is what exactly I meant to say. It is better to put static gameobjects by using aabb.insert. It saves from iteration.
For moving gameobject aabb.insert_gameobject.

1 Like

I found the problem. It is related to this and effects aabb.query and aabb.query_short

I push the fix at same 2.1 branch. Please clean your .internal folder or remove/add the extension again.

Keep on testing :slight_smile: Let me know if anything goes wrong.

3 Likes

Confirm this fixes my issue. Will let you know if anything else pops up. Thanks again for the work and prompt fixes!

1 Like

just for fun…
Tracking nearly 3000-3100 Gameobject in total .
~1300 Enemy ships. Collides with user ship, user bullets.
~1500 Enemy bullet. Collides with user ship.
1 user ship. Collides with enemy ships, enemy bullets and collectables.

Game window size 1920x1080, screen size is 480x270.
Not very optimized code, on my 10 years old cpu(2 GHz Dual-Core Intel Core i7) with ancient Intel HD Graphics 4000.
Worst fps doesn’t go down below 50.

8 Likes

Wow! This is amazing :heart_eyes:

I’m now working on a platformer code utilizing raycasts - I want to support both built-in and DAABBCC raycasts, as I believe there is a possiblity to make a component not depending on collisions detection - hope it will be also good for comparing the solutions and choosing the best :wink:

1 Like

I’m not sure if I understood correctly…
But I would like to let you know that there isn’t narrow-phase collision detection and manifold generation in daabbcc. There were, but I remove them all. It is now basically just a aabb test(very very narrowed version of box2D lib).
It might be possible to build a platformer just using raycast if you like the challenges :slight_smile:

2 Likes

Yes, I am aware of this, yet I don’t think it’s an obstacle or any inconvenience for me :wink:

1 Like

Great :slight_smile: I’m looking forward to seeing the results.
If you are going to need a simple manifold generation for checking contact point and depth, I can do that. Just let me know…

1 Like

Hi @Pawel , don’t deal with daabbc. I found tile raycast from one of my old projects. It is based on : Raycasting

I’m now preparing it as a native extension.

Don’t mind the fps, my machine can’t handle screen recording anymore…

9 Likes

Wow! It looks like exactly what I was aiming for, great example! :smiley:
And even greater that you plan to make it into an extension, thanks! :heart:

1 Like

Does/will it work basing on specific tiles (by tile id) or on collision object created from tile? E.g. could it detect also Defold’s collision objects with its shapes that are assigned to game objects as well?

It is tile based(by tile ID). But also returns intersection point.
You can find more info here: Raycasting

In this case you can simply use the build-in raycast? You don’t need anything else I suppose.

1 Like