TGEA 1.7.0 Beta 1 - Polysoup/Character Collision

#1
Also when colliding when polysoup objects, the player doesn't seem to know what a vertical surface is. Stand next to it and use whichever directional key to move youself to collide with the structure and you'll walk right up the face of it. Some places are faster in the accent than others, so fast you'll beat someone to the top who used the jetpack!

#2 Yeah I noticed that I could walk up the walls when I was playing around with the demo.

#3 This is because of the Player collision.

The Torque player is a box! In this case a rather big box. There is a setting in PlayerData which you can use to control the box dimensions.

#4 Walking up walls is definitely a bug somewhere. We have it logged and will look into it.

The Player's feet not always matching his collision is how Torque has always worked. I didn't fine tune the bounding boxes on all of the different characters so some of them will make it more obvious than others.

It is something we have talked about a few times around the office since it is one of those "cute" Torquisms that we would like to fix but it currently isn't on any schedule to fix this properly. That said, if you have a working solution then come talk to us and we would possibly be interested in buying it off of you.

If I were to look into properly fixing this problem I would separate the Player's collision shape from its bounding box (they are one and the same right now which causes rendering issues if you shrink down the collision shape), switch the Player's collision shape from a box to a cylinder (matches the expected collision response of a humanoid better and can be tighter), and investigate some sort of *very* simple IK solution for getting the Player's feet to conform to the surface under them (there was code in a Game Developer Magazine article a few years ago that would probably work).

#5 Matt is aware of this of course, but for those that aren't:

(Note: theory stuff here, not directly related to the bug at hand, but more of an explanation of why the Player class operates the way it does)

The Player class makes a performance optimization trade off for collisions--normally, a bounding box overlap test is simply an early out for collision, and with most classes in the scene if a bounding box overlaps, more accurate collision tests are performed.

In the case of the Player class however, a bounding box overlap is treated as a "real" collision, which gains you a lot of performance (fine level collision tests are expensive), but loses collision accuracy.

It is possible (if you are relatively experienced with Torque collision, or are willing to spend some time to learn, it's kind of tricky!) to have the Player class do full collision testing past the bounding box overlap early out, at a cost of performance. This would be especially useful in single player games, or minimal multi-player where there aren't a lot of Player class objects wandering about your game.

#6 Hrm... played with this a bit myself... seems like if we were talking ridgids, it'd be a miscalculation of the impulse-vector, along with a cornercase. You'll notice the totally flat end of the polysoup building reacts as expected, same with overhangs, but the domed normals aren't providing enough push-back to counteract the straight fall-down from gravity.

played a bit with

// Subtract out velocity
         VectorF dv = collision->normal * (bd + sNormalElasticity);
         mVelocity += dv;

parsing in

// Subtract out velocity
         VectorF dv = collision->normal * (bd + sNormalElasticity);
		 if (mVelocity > -dv) mVelocity += collision->normal * bd;
		 else mVelocity += dv;

instead, and actually ended up with *faster* wall-climb. As to raising the sNormalElasticity by a factor of base-10, um. Aside from moon-walking, didn't seem to resolve it either.

#7 This is really funny. I can't believe I just read what I read. You mean to tell me that this problem has been going on for a while now. You know it's a bug, and yet you're not scheduling a fix for it. How in the world can you put out a product knowing there is a bug and not try to fix it. It's not a "Cute" bug. It makes your game look like it's a second rate dishrag of a game. No one wants their players running around with their feet hovering over the terrain, unless it's flying on purpose.

#8 @ Jeramy - whoa dude. no one said the fact the players have use a bounding box was a bug. They've stated multiple times it's for performance reasons. If you don't want that, you just gotta change the way the engine does collision checks for the player, as was stated.

Personally, i have infact at one time replaced the bounding box with a collision mesh using similiar routines from the vehicle classes. so it can be done.

#9 Jeramy, I think you made a mistake buying this engine. Your blog, your posts, all uneducated, ignorant, quick to jump the gun without reading what you're attacking. You should go spend $500,000 on your dream engine that does everything you want with no effort whatsoever.

#10 I'm with Chris on this one.

#11 Bounding boxes aren't bugs. They can be annoying (why is there an arrow almost piercing my player?) but they are not a bug. Bounding spheres would be cool, though.

#12 @Jeramy: As Matt said, the bounding box needs to be adjusted for differences in character size. This isn't a "bug"

BTW, I missed your blog entry before... Minions of Mirth has 75,326 registered players since this morning. We also have a lot of single player people who haven't registered for online play. The game was built with TGE 1.3

TGEA 1.7 with a decent art budget is capable of much more in the graphics category. So, you should be able to get at least 10x that number of people looking at your game. Get cracking! :)

#13 Right, so. back on topic:



probably not 100% correct, but the last is the impression given when as the op stated, a player collides with a polysoup instance.

#14 I tested out the V3D demo and noticed this too. you can just walk right into the wall and slowly inch up it. i didn't notice this odd behavior with my TGE 1.5.2 implemenation of polysoup.

#15 I agree that a cylinder shape would make a better collision bounds for the player. This is what the Unreal 2003 engine uses and in my experience it works better than a box. Namely, when running by objects, in any direction, the player just slides off of them and can keep moving.

However, with an axis-aligned bounding box (AABB) like Torque uses (if I remember correctly), running in certain directions causes the player to have this "wall" in front of him, that gets caught on things like poles or other players, thus causing the player to completely stop moving, when it seems the player should just bounce off of these things and keep running forward.

This issue came up in a previous project I worked on. We wanted to address it but it fell too low on the priority list to do anything about it.

I would like to work on this but unfortunately I'm too swamped with other projects at the moment. It would be really cool to see this addressed. For anyone interested, a great book on collision detection is "Real Time Collision Detection". It has a section on using a cylinder bounding volume on page 112 under the "Sphere-swept Volumes" section. Although the author doesn't recommend actually using a cylinder, but a sphere-swept line instead for better performance.

#16 We've used a swept ellipsoid (capsule) very effectively at various times.

#17 @ Matt: Cool, thanks for the tip! A quick google search for swept ellipsoid reveals this paper that looks interesting:

http://www.three14.demon.nl/sweptellipsoid/SweptEllipsoid.pdf

Are there any resources you'd specifically recommend?

#18 Walking up wall should be fixed in Beta 2. Please retest if you get a chance. Thanks!

#19 Hmmm, I can still walk up walls in TGEA 1.7.0 release. Anyone else getting this?

With some models, like Kork, I can't walk up walls. But if I run directly at a wall and then hold down jump while still running directly at it every second jump is about double the height.

#20 Yep still does it.