New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimization: collision layer with a single body #587

Open
parasyte opened this Issue Oct 14, 2014 · 4 comments

Comments

2 participants
@parasyte
Member

parasyte commented Oct 14, 2014

Each shape in the collision layer gets its own entity and body. This can get fairly heavy with enough shapes on the map. Optimize by squashing all shapes in the collision layer into a single entity/body.

@parasyte parasyte added this to the Future milestone Oct 14, 2014

@obiot

This comment has been minimized.

Show comment
Hide comment
@obiot

obiot Oct 15, 2014

Member

as I was saying on gitter, as a simple improvements, what about skipping objects with the WORLD_SHAPE type from the container update/draw loop ?

Member

obiot commented Oct 15, 2014

as I was saying on gitter, as a simple improvements, what about skipping objects with the WORLD_SHAPE type from the container update/draw loop ?

@parasyte

This comment has been minimized.

Show comment
Hide comment
@parasyte

parasyte Oct 15, 2014

Member

It's required for me.debug.renderHitBox actually.

Member

parasyte commented Oct 15, 2014

It's required for me.debug.renderHitBox actually.

@parasyte parasyte modified the milestones: Future, 2.1.0 Oct 26, 2014

@obiot

This comment has been minimized.

Show comment
Hide comment
@obiot

obiot Oct 30, 2014

Member

i was thinking about this, and I'm wondering if it's actually a good idea.

Considering that the quadtree is a rectangle based algorithm, and therefore relies on shapes bounding box, this could generate collision check with the (one) collision shape at every movement, as if the collision layer is complex there is chance that the bounding box would then take the whole level.

keeping the current implementation for sure create more shapes, but allow for less collision check per frame ? and I suppose that ultimately the trade off is for the end user to optimize the number of collision shapes he is creating.

(last but not least, with entities objects not being currently pooled by default, none of these collision shapes are being reused from one level to the other, which keeps the GC busy when changing level)

Member

obiot commented Oct 30, 2014

i was thinking about this, and I'm wondering if it's actually a good idea.

Considering that the quadtree is a rectangle based algorithm, and therefore relies on shapes bounding box, this could generate collision check with the (one) collision shape at every movement, as if the collision layer is complex there is chance that the bounding box would then take the whole level.

keeping the current implementation for sure create more shapes, but allow for less collision check per frame ? and I suppose that ultimately the trade off is for the end user to optimize the number of collision shapes he is creating.

(last but not least, with entities objects not being currently pooled by default, none of these collision shapes are being reused from one level to the other, which keeps the GC busy when changing level)

@parasyte

This comment has been minimized.

Show comment
Hide comment
@parasyte

parasyte Oct 30, 2014

Member

Suppose shapes are added to QuadTree instead of entities. This was how I originally envisioned the QuadTree would be used.

The entity bounds can still be used to lookup candidate collision pairs within the QuadTree. But what you'll get back is individual shapes, instead of an entity who references a body who references all of its shapes.

Member

parasyte commented Oct 30, 2014

Suppose shapes are added to QuadTree instead of entities. This was how I originally envisioned the QuadTree would be used.

The entity bounds can still be used to lookup candidate collision pairs within the QuadTree. But what you'll get back is individual shapes, instead of an entity who references a body who references all of its shapes.

@parasyte parasyte modified the milestones: 2.2.0, 2.1.0 Feb 7, 2015

@obiot obiot modified the milestones: 3.0.0, 2.2.0 Jul 9, 2015

@parasyte parasyte modified the milestones: 3.0.0, Future Jul 26, 2015

@obiot obiot added this to To Do (Core) in Roadmap Dec 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment