From ba98ae3386509946835ffdc3697b6ec0dfc13449 Mon Sep 17 00:00:00 2001 From: karl Date: Fri, 15 Jan 2021 13:56:53 +0100 Subject: [PATCH] Minor kdtree fixes/workarounds Not sure why, but it misses some collisions with that t >= 0.0 clause... --- ECS/Systems/CollisionSystem.h | 2 +- Util/kdtree.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ECS/Systems/CollisionSystem.h b/ECS/Systems/CollisionSystem.h index 5dbacc6..368baf7 100644 --- a/ECS/Systems/CollisionSystem.h +++ b/ECS/Systems/CollisionSystem.h @@ -83,7 +83,7 @@ class CollisionSystem : public EntitySystem { glm::vec3 direction_glm = mouse_look->get_look_direction(); Vector direction = Vector(direction_glm.x, direction_glm.y, direction_glm.z); - Ray ray(origin, direction * 5.0); + Ray ray(origin, direction); Vector collision_position(0, 0, 0); Triangle *result = kdtree->intersect_ray(ray, collision_position); diff --git a/Util/kdtree.h b/Util/kdtree.h index c711ebf..24ff907 100644 --- a/Util/kdtree.h +++ b/Util/kdtree.h @@ -122,7 +122,7 @@ class KDTree { // No collision here either. Does it make sense to also check the far node? // Only if the axes are not parallel and if that area is not behind us - if (ray.direction[node->axis] != 0.0 && t >= 0.0) { + if (ray.direction[node->axis] != 0.0) { // FIXME: should include && t >= 0.0 // It does make sense to check the far node. // For this, calculate a new ray origin and continue towards that direction, but with // the new origin (we can leave behind what we already checked)