[beta5 & previous] Collision code allow the Eye and Weapons to clip through meshes

#1 This is actually not so much a bug with the engine, but a setting. The reason this occurs is by default the bounds of the character doesn't extend to the end of the weapon or the near clip plane. An easy fix for this is to simply set the bounds to match the size of your player and what he's carrying better. The best way to fix it though would be to either dynamically resize the bounds to match the size of player and carried objects, or add a bounding box to the weapon which would prevent it from going through walls and could be additionally modified to have the character animate moving the weapon out of the way as seen in a few games.

#2 @Bryan

Thats not a fix, that's a hack and a horrible one at that.

Changing the size of the collision box in code leads to other issues with your game that are even more unacceptable. This biggest problem your 'solution' causes is that the Box Collision mesh is drawn from the location of the Bounds node, which is always centered in between the feet of a character. However since the players arms extend out forward, if you expand the Collision Box like you are suggesting, the player mesh will end up with a massive collision box. This will cause issues with the player model hitting or getting suck on various scene objects and worse yet, will allow the character to be easily 'shot' with weapons since their collision box will be so large that you can shoot at void space by the characters back and still hit them! Both of these issues (and others that I haven't mentioned) are unaccaptable in any game.

Also you are neglecting the fact that meshes like the Boombot, ForgeSoldier, to name but a few, never had this problem when they were assets for TGE or TGEA.

Its still a bug and a serious one at that while will greatly impact Torque3D being used seriously in projects.

#3 Actually TGE had this problem just as bad, and I'm pretty sure TGEA did as well, though I didn't do any first person stuff with it. Expanding the bounding box was only my example of an easy fix, and it does in fact work pretty well as that's what I've done. The ideal fix though would be to add collision detection to the weapon which would also add the bonus of being able to animate it to make it appear the player is hugging the wall or at least interacting with it better then the typical FPS. As for expanding the bounding box making it easier to shoot you, that's a serious limitation of the Torque engines brought about by not having hit boxes, which is desperately needed for any decent FPS.

The fact still remains though that the bounding box of the character is allowing you to approach a wall closer then the extent of the weapon and the near clip plane which causes the weapon to clip with the wall and then allow you to see through the wall. It's not actually an engine bug.

EDIT: Another possible fix which some games do, is to extend your bounding box just beyond the near clip plane but not the weapon, and then render the weapon as a static GUI object over top the scene rather then as part of the scene. This however means you can't have dynamic lighting(Something which was immediately pointed out in the videos of Crysis by many people). If I remember correctly, TGE 1.5 did this "fix" but before that the player definitely clipped with the wall. TGEA may have done this "fix" from the start, but it's really an ugly hack in such a beautifully shaded engine as T3D.

#4 I can't comment on the technical aspects, but I agree that somehow, someway, by somebody, this needs to get fixed...in a usable fashion. This is something we used to see in games, literally, 10 years ago. Back then it was acceptable. Now, the moment a player sees something like this, it reeks of an "amateur" game made with "amateur" tools.

#5 I agree that this affects peoples views on how good the engine is, but the problem is a rather complicated one, and all fixes have their drawbacks. First off this is definitely not a bug as the collision detection is functioning exactly as it should, which means the fix lies in extending the weaponimagedata to support collision detection. Of course if you simply add collision detection to the weapon your even more likely to get stuck in corners then if you just extend the player bounding box. This leads to the solution which I first saw in the game "The Darkness" whereupon when the player hit a wall or surface with the weapon the arm was animated to lift the weapon out of the way. This provided more immersion to the game, but if T3D was to implement it, it would mean adding a hitbox to the end of the gun and adding animations to the player to move the gun based on the angle you are facing the wall. The majority of games don't want to deal with this complexity so nearly all of them simply don't render the weapon in the world scene and instead render a GUI object over top the scene. This however means you can't do dynamic lighting that interacts with the weapon, and typically it just doesn't look all that great because of it being static or only basically animated.

I would prefer the method used in "The Darkness," but then it adds to the complexity of how the weapon has to be modeled and then creating additional animations for the weapon arm.

#6 The whole problem is caused by the weapon being rendered as any other normal object in first person. In most games the weapon is drawn using different frustum values, causing it to never be clipped against level geometry. The Source-engine games are a good example of this: even the huge weapons always draw on top of everything else, irregardless of their coordinates. The weapon models are more like 3D overlays.

For games were the weapon is to be rendered normally along the rest of the scene (usually the case in FPS games where the player can see his/her own body), a whole host of measures must be taken to prevent the gun from clipping, and so far I have only seen animation solutions, which anyone can implement in T3D, TGEA or TGE today, with little to no source code changes, by checking if the area in front of the player has enough space for the weapon (see containerBoxEmpty()) and changing the weapon-holding animation (usually an armThread) to one that lowers the weapon or something like that.

Basically, you'd need to apply in first person the same solution as you would to prevent weapon clipping in 3rd person or for NPCs.

#7 @Bryan

Sorry Ive made numerous games with TGE and TGEA and never had this problem there. In those engines the mounted weapon image/shape was pushed in-ward back towards the camera so that it would not clip through and the eye node only clipped through if you set your collision box up really wrong with the bounds shape.

#8

Quote:
mounted weapon image/shape was pushed in-ward back towards the camera

I figured that had something to do with using an eye-offset in TGE, but after a quick test of my old TGE AI demo it works if mounted on the player directly too.

Would be nice to have it back.

#9 It is a bug, just as Logan as described it. I've much lamented it myself... and others. I know that weapon pushback did work in TGE, but somewhere between then and now it doesn't.

The reason that the player bounds was originally set so ridiculously huge was because the weaponImage would disappear at certain viewing angles when it clipped the player bounds.

That was a long-standing bug that was fixed recently in another beta. The player bounding box was reduced to be more form-fitting to the player model. This only exaggerated the problem with the non-functioning "push back" and the camera/eye-node clipping through walls/objects. We know that weapon pushback did work at one time, so yes it needs to be fixed. Camera collision is a separate problem, and it should be resolved too.

#10 @Logan: In TGE and TGEA it was certainly possible to not have the weapon or eye clip with walls, but prior to TGE 1.5 the stock character most certainly had this problem, and the fix ended up being simply rendering the weapon seperate from the rest of the scene. This fix works well enough, but I think it also messes up the perspective of the camera as it's difficult to tell just how close to an object you really are. An animation solution creates the best level of immersion, and you could easily implement it just now. My original post was really just saying that there is no bug in the collision detection. It's basically the same thing as saying there is a bug in the engine because everything is rendering pink just because you happened to make all your textures pink. I apologize but it's just a pet peeve of mine when someone is blaming code for user error or lack of understanding.

#11 @Bryan

Thats understandable and in cases where it really is the user using the engine incorrectly I agree, but in this case it is truely 100% a bug and not a user error, or even an art problem (which we originally thought it was, but a bunch of us did some testing and confirmed that the error isnt in the art). Something broke in the engine between then and now and now its failing and giving a truely unexpected and unwanted behavior.

BTW the weapon pushback functionality has been in Torque since at least the 1.0 days when we were recompiling Realm Wars releases and building the original Lore Invasion. It wasnt a great solution since it created a huge disconnect, but it at least prevented weapons from firing inside of walls :)

#12 Two things:

For Gideon getting too close and you can see through walls:

Gideon's eye node is way too far forward. Load him up in the shape editor, and you will see it sticking out in front of the model. Move it back closer to his head, and things will get better.
If that is still not enough, you can move the near clip plane in. In the warrior level, it is set at 0.1 units. However, I think you will find that fixing his eye node is all that you need to do.

For the weapon in walls problem:

Like Manoel says, this could be fixed by monkeying with the near/far clip plane. This is what I did in a previous engine. I rendered everything, then pulled the far plane closer, and then rendered the gun. This works because the zbuffer is not really linear, and it has the effect of slightly decreasing the zvalues as they are written.
Another trick that people have used in the past is to clear the zbuffer around the weapon before drawing.

However, I don't believe any of these hacks will work in T3D, due to all the postfx. These need a valid depth buffer, not a hacked up one.
The true answer to fix this is to do collision on the weapon, and then IK the arm back, so it doesn't stick into the wall.

#13 After fixing Gideons Eye Node, I realize why the artist moved it so far forward - The model jumps around so much when running that you can see part of him. The answer to that would be to animate the eye node. but then with the way Gideon Moves that would probably give you motion sickness.

#14 I definitely prefer an IK solution to forcing the gun to render over top of the scene. As for the eye node and the near-plane clipping, just removing the head while in first person and placing the eye node over the body should fix that problem as well as allowing you to look down and see your body as long as the eye node is positioned so you don't see above the chest.

You definitely don't want to play with the near-plane too much as you can get rounding errors in the depth buffer if your near-plane value is too small.

#15 @Jaimi

Switch to the Boombot, the same problem exists. So while I will agree that there are issues with the Gideon model (as a side note I am doing a quick port of him as a fun side project for myself to conform him back to the stock DSQs), its not simply that model that has these problems.

#16 @Logan

The boombot has the same problem that Gideon has. Due to his shape, his eyenode is right at the edge of his bounding box. There's not an easy answer to this beyond decreasing the near clip or modifying his bounding box. Anything further that I can think of would require engine changes. It could conceivably be worked around by moving the eyenode into the model, and then hiding that portion of the model during rendering, but then it would have to be visible during the shadow pass.

#17 Logged as THREED-666 \m/ \m/

#18 thanks , Kenneth

#19 LOL what an oppropriate bug ID# for this particular problem ;)

"Mama always said physics were the Devil!"

#20 I've been taking a look into resolving this issue, so, two topics.

First off, the weapon-push-back from old TGE was indeed broken. I got that working again. But as a disclaimer this only applies to first-person with the weapon mounted to the players face, and the weapon (dts) must have a retractionPoint or muzzlePoint node.

It looks like the SteamPistol and the sniper are already setup with nodes, however, since they can only retract back as far as the node they are rendering relative to ( the camera node ) if the camera node itself sticks through the wall, "retraction" will fail.

On a side note, the sniper rifle is like 5 times the size of gideon... the other weapons are all a reasonable scale and don't look any smaller in first person. There's not a lot you can do to stop a 15 meter weapon from sticking through walls...

As for the camera-interpenetration problems in first-person, there's really nothing I can do in code to fix this. The camera node should never ever ever be outside the bounding box or it will stick into things.

I did experiment with moving the camera back using a raycast test like it does for third person but this really makes no sense, more than likely it would end up pushed into the players mesh or somewhere else unpleasant. Looking at the TGE code it does not do any camera corrections in first person.

So... I know its been said before, but this is an art problem. Here are some possible solutions...

1. Gideon has wild and exaggerated animations obviously designed for a 3rd person game, so, don't allow first person with him.

2. Move the camera node in right in front of his head and animate it to stay that way, if it still sticks out of the bounding box then it either has to be expanded or some of his movement animations need to be toned down.

3. Move in the camera node, don't bother animating it, and turn off rendering in first person.

Note: The original "torque orc" has the camera node tight to the head and animates it in the action animations.