Collider.bounds.intersects not working as intended. With Room Building

Hey All! So I'm working on a script for dungeon building and I've almost got it complete. But I am having one last problem and that is Room Collision.



As you can see rooms are colliding with each other and I don't want that.

So I've decided to try and use bound.intersects to check if a room will either collide with another room.

And I can't get it to work properly. The problem is (and I understand this is how it is)



That even though the boxes aren't touching at all (or they are by 0.0000000001) it's still calling it a collision.

How would I go about seeing if like one box was actually in another box?

Here's the code that checks for collision.

Code (CSharp):

1.  public bool CheckRoomCollision(GameObject obj)
2.         {
3.             Debug.Log(obj);
4.             var bounds = obj.GetComponentInChildren<Collider>();
5.             foreach (Transform child in transform)
6.             {
7.                 var childCol = child.GetComponentInChildren<Collider>();
8.          
9.                 if (childCol != null)
10.                 {
11.                     bounds.enabled = false;
12.                     bounds.enabled = true;
13.                     childCol.enabled = false;
14.                     childCol.enabled = true;
15.                    // Debug.Log(bounds.bounds.min);
16.                    // Debug.Log(bounds.bounds.max);
17.                    
18.                      if (bounds.bounds.Intersects(childCol.bounds))
19.                      {
20.                          //if(bounds.bounds)
21.                        
22.                          return true;
23.                      }
24.                 }
25.             }
26.            
27.  
28.             return false;
29.         }
30.  

If anyone could point me in the right direction that would be cool!

 

You wouldn't be using real world geometry to do it, but instead some high-level representation of your rooms that is infallible.

Real geometry suffers from floating point imprecisions and doesn't count as particularly reliable.
You can, in many scenarios, rely on comparing differences with a sufficiently small number, but there are too many combinations for your use case to make this a viable solution.

In other words, you don't use bounds to detect whether things are touching each other. You can however, make an attempt to temporarily convert the tile's world center into a whole integer (thus transfer it from world space to abstract space), make sure the conversion is correct, then reason about the integers themselves which are infallible.

 

Your mistake is mixing up logic and geometry. These two domains have nothing in common. Geometry should be the output of logic, while logic should be readable, debuggable, and infallible. You can use a crane to construct a building, but you can't (or shouldn't) use a crane to correct its blueprint or modify a room or two. Try to separate the domains, first in your head, acknowledge that what you're doing is first and foremost on a level of abstraction much higher than your actual meshes, and that as a human you naturally reason about this on a level that has nothing to do with world coordinates or bounding boxes, and why shouldn't your program reason about it on the same level? Ultimately you will see that the code becomes much more manageable, and you can soar from there.

 

This is a good solution. I'll have to mess around,

My next solution was to just... Shoot a Physics.BoxCast where a room is going to spawn to see if it will collide. So I'll have to take this into consideration

 

I get that. By logic it should work, but by geometry standards it won't. I should probably stay away from bounds then in this case scenario

 

You can still use them for generous overlaps. Just not for touching, that will always disappoint you. (When I say generous, I don't mean "truck-sized" generous, but there is this miniscule tolerance similar to Z-fighting, if you're always above it, you're fine)

 

I just solved my problem. I think it's a good solution, however there might be better ways to go about it.

Basically all I'm doing is grabbing a point of where the rooms snap. Shooting out a raycast in the direction the room is set too with the maxDistance of the room.bounds.magnitude (so the size of the bounding box)

And then basically telling it to return true if the raycast hit's something.



As you can see there's no overlapping now!

There needs to be some optimization. With 60+ rooms it starts to slow down.

However I don't think I need that many rooms. So honestly it won't be a big problem. But def could use room for improvement

 

Yes, you can hack it like that, it's ok. If it works, it works.
But you can already see it limits your scalability. Hopefully it'll do for your current specs.