Entity collision geometry
The current way of defining the geometry of an entity is through it’s bounding box. This works for basic collision detection, but prevents us from having more complex entities and basically makes the world rather flat when navigating. It prevents us from being able to enter into houses, or walk beneath archways or bridges. One solution is to set the affected entity to be non-solid and instead create multiple invisible “collision entities” as children. However, this has a plethora or disadvantages (does not scale with the entity, clutters the entity space etc.).
Instead we need a mechanism whereby we can define “collision geometry” for each entity. This is geometry which is independent from the bounding box, but scaled along with it. It should therefore probably occupy a normalised space.
We should probably aim to allow for arbitrary meshes as collision geometry, but initially we should be able to get pretty far by only relying on multiple bounding boxes (freely placable within the normalized space).
Blueprint information
- Status:
- Started
- Approver:
- Erik Ogenvik
- Priority:
- High
- Drafter:
- Erik Ogenvik
- Direction:
- Needs approval
- Assignee:
- Erik Ogenvik
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Deployment
- Milestone target:
- None
- Started by
- Erik Ogenvik
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
This blueprint should be marked as dependent on "Use Bullet as physics system" .Bullet has all needed functionality in definition and usage of collision geometry.
True. The first Bullet implementation will use the bounding boxes for collision geometry. Once that's in place we'll have to implement support for proper geometry, as defined here.
The main issue is that so far we've only handled geometry shapes that also have their corresponding implementations in WFMath. As we add collision geometry we'll instead deal with things like capsules and arbitrary meshes. Since this will be handled by Bullet there's no need to also implement them in WFMath. /Erik
Work Items
Dependency tree
* Blueprints in grey have been implemented.
