SMLightning: After much consideration, i've decided to sticky this thread.


I have been experimenting with awareness and buildings.
I have built simple scenes and placed characters who have been programmed with a a simple advanced AI:
SHOOT PLAYER IF AWARE of PLAYER
IDLE DANCE ALWAYS
THe NPCs I've place do not have a ranged weapon, so the net effect is that the NPC will turn and face me if he is aware of me, otherwise he dances.

By walking around, I can tell if the NPCs can see me.


Here is the result of my study:

Blocks I,II,III are 3 separate buildings. I moved next to each NPC and noted whether each of the NPCs dances or faces the captain.
A can see B
B can see A,C,D,E,F
C can see B,D,E,F
D can see B,C,D,E,F
E can see B,C,D,E,F
F can see B,C,D,E
This is what you expect.

However, if blocks I and II are combined into a single building, here are the results:
A can see B
B can see A,F
C can see nothing
D can see nothing
E can see F
F can see B,E,

The only way I can explain this is that GA computes a bounding box that contains the building and then uses the bounding box to determine awareness.

C & D can't see anything because they are in the box. They can't see each other either.
B can't see E because the line of sight between the head of B and the head of E passes through the bounding box.

What this suggests is that if you are building interiors, you need to:
1) build the floor and the walls out of separate buildings.
2) if the scene is going to have boxes or a desk, these need to be separate objects. Otherwise their height contributes to the bound box of the floor and it can make it so that NPC cannot see things.

IMPORTANT UPDATE 7/12
It appears that gates are transparent.
The bounding box of a gate and of disguised gates do NOT block line of sight. This means that by replacing the building with a disguised gate that uses that building, most of the problems will be solved.
1. NPCS can see (awareness tests and commands that depend on awareness work.
2. NPCs can transition onto and off of these disguised gates.
There are some problems if you move a disguised gate to far off the ground. It isn't a visiblity problem, but appears to be pathing issue. My guess is the the AI uses the ground geometry to figure out paths.

IMPORTANT UPDATE 7/15
It appears that some of the pathing problems are due to how the building is created in the building editor.

Edited in by SMLightning.

Tairon96 has found that how the building is edited in the building editor affects how captains walk on it.

Here is his original post:

Tairon96 wrote:Subject changed from:
"Collision detection glitch! Invisible steps??"
to
"Maxis Team read this! Floor bounding boxes faulty! Causer of problems detected! Tip for GA-creators!"

I was edited yesterday a great interior property made by codyr2391. But problem I found was there seems to be an invisible barrier my test captain could only pass in one direction


In the video you can see, my captain is bounched back as if there is a force field wall (There is none!). So I had to rip codyr2391's bridge apart to use it... Now I just experienced the the problem with an object I was editing today, too!

And I found an explanation for the yesterday's problem. Look here:



My captain (this time my real one) was stumbling between to wall sections. Fortunately he can jump - my test captain can't because I want check if all regions are reachable. So my real captain jumped and after several tries he managed to jump over the invisible obstacle. It looks like there is the complete section higher than you can see - my captain walks in midair!

Before I started today editing this wall section there were now such problems. I used a lot of <shift> and <ctrl> movements for editing. Is this causing these problems???

Is there any one out there who has experinced this problem, too?

And the result of his investigations:

Tairon96 wrote:Here are the videos:

(They are my first commented videos on YouTube It was not so easy

First video: How to not edit your floor object!



And the second video: How to avoid this bug!



And the third video shows Iraultza87's perimeter wall I have edited for my adventure. Now there are no invisible steps between the wall sections. Do you want to join for a walk?

UPDATE 8/2

Just because you have fixed the visibility problem, you can still have problems with NPC walking on buildings.

It is my experience that any NPC activity on buildings as floors is buggy. Here is a very simple example:
NPC using basic AI, "mindless", patrol with way points.


If you change the building to a disguised gate (using the same building piece), you get better results:


However, you still have problems using a disguised gate as a bridge.


It appears that it uses the ground under the bridge for path calculations.

that's very clever, and I will indeed take your tips. well done

Domo Oregato, mr sporeato.

Very nice analysis indeed.

Very well done! Excellent, in fact! That is truly amazing and I will use your tips in any interiors I make! Thankyou!

Thanks.
I'm working on and adventure and a video demoing this.

Interesting, that helps explain why the AI breaks a little bit. Well done, the diagram was very interesting

My brain hurts!

Video added to first post.

Nice work! This explains why AI behavior seemed unpredictable. It's just is a little unintuitive.

But I think this video shows one other problem which is much more relevant and game-damaging, and probably related to the Line of Sight behavior you've catalogued.

At the end, when you Jet Pack up to the top of the Yellow block. Your avatar lands on the edge of it.

Your left foot is angled and flush with the slope of the building, and looks as you'd expect.

However... your right foot is sunken into the top of the building. It SHOULD be flush with it.

This demonstrates poor collision detection and/or clipping plane computation. This is a big issue for this game right now, and we've gotten zero response from Maxis on it so far.

I've asked for a Dev response, don't know if they have time to reply at this moment but I have asked for you. Good information solidly presented.

that just solved something for me!
this needs to be stickied or added into a tutorial somewhere!

Excellent demonstration you've put together here.

At the moment, I would advise everyone to place 'responsive' NPCs in open areas and not too close to buildings and if you need an interior setting, use it for walk-through or decorative purposes only, unless you manage to work a way around - given the patience, of course.

I'm looking forward to the Dev's response and hope a solution is on the way soon.

There is something else you need to know too.

The bounding box creation also influences paths. By keeping the walls, floor, and roof separate you can reduce issues with paths you layout with your ai. Also be sure to place enough path points so that curvature doesn't mess up the pathing either. Paths on buildings works, but its finicky. You will have to test a lot.

Collision boxing is also a bit odd. It's not the same for everyone so it has something to do with the relationship of creature parts and particular shapes. It can also be influenced by processor performance. Slower or busier processors will cause more clipping issues. I figure this due to the fact that some people have a ton of clipping issues where others do not on the same objects.

Because of the way collision detection and avoidance works, the ai can't transition well or at all onto objects. They either must be on them or off them. The Ai also gets confused (little ? over their head) if the plane they are standing on is too close to the ground plane. There seems to be a minimum distance the surface they stand on needs to be from the ground, in order to avoid problems.

So you can build a mission in a "space ship" or building or what have you but it will take quite a bit of tweaking to get it to work. Large open space works better than narrow corridors and such.

Personally I think its all a little to finicky to rely on solely and this information should just be used to create some accents to your adventures.

Khorzho wrote:Nice work! This explains why AI behavior seemed unpredictable. It's just is a little unintuitive.

But I think this video shows one other problem which is much more relevant and game-damaging, and probably related to the Line of Sight behavior you've catalogued.

At the end, when you Jet Pack up to the top of the Yellow block. Your avatar lands on the edge of it.

Your left foot is angled and flush with the slope of the building, and looks as you'd expect.

However... your right foot is sunken into the top of the building. It SHOULD be flush with it.

This demonstrates poor collision detection and/or clipping plane computation. This is a big issue for this game right now, and we've gotten zero response from Maxis on it so far.

I've seen the problem too. It does seem that the coordinates of the skin do not mesh with the coordinates of the blocking volume used for collision detection. In general, it seems that the problem escalates when you scale up the object. I didn't scale up the object in my demo, but buildings are naturally bigger than other props. The places where I have an issue with this is when items are dropped and they sink below the skin to that they are invisible or when NPCs walk entirely into walls. As for feet sinking into the floor, it is more a visual annoyance for me.

I don't mind simple visual bugs. I'm old enough to have played some really crude graphic games (I'm 41 years old).

It is a tough design decision. Which is worse, having characters sink into the object or have them float above? From an aesthetics point of view, sinking in is better?

My bigger issue with collision detection is that fast moving objects (like my captain with speed 5, jump 4, glide 4) can move so fast that the collision against the blocking volume on the surface nearest the captain is missed and you collide with the blocking volume on the far side of the object. The net result is that you are now trapped INSIDE the object.

This would explain why I haven't really suffered from this problem; I make each part of rooms and the like seperatly.