Torque3D Beta 1 Bug - Old BB/WeaponImage bug
by Scott Burns · in Torque 3D Professional · 05/06/2009 (9:31 am) · 5 replies
I've still only had limited time to put Beta 1 through its paces, but one thing I've noticed is that it would appear that old TGE bug where the WeaponImage disappears if it moves outside the bounding box is still hanging around.
Only mildly annoying since I already know the fix for it, but it'd be nice if this sucker could get stamped out for good.
Only mildly annoying since I already know the fix for it, but it'd be nice if this sucker could get stamped out for good.
#2
05/06/2009 (10:19 am)
That would be nice, I did a little a little searching but couldn't find it. If someone were to find that resource and it looks like a decent solution maybe we can integrate it. 
#3
Get Bounding Box of Animated Skinned Mesh
... it's linked from this post on the "weaponimage vanishing/player bounds" issue here.
Force Rendering of Object
Ken Holst said he logged the T3D issue here, but I don't know if that's a logged as in "will update the player model's bounding box" or "will come up with a coded solution for the issue". Latter solution would be best as player's bounding box size is used for collision when moving. Bigger box = bigger doorways needed.
Weapon Clips Away at Certain Rotations
05/06/2009 (10:55 am)
I think this is what I might have been thinking of Get Bounding Box of Animated Skinned Mesh
... it's linked from this post on the "weaponimage vanishing/player bounds" issue here.
Force Rendering of Object
Ken Holst said he logged the T3D issue here, but I don't know if that's a logged as in "will update the player model's bounding box" or "will come up with a coded solution for the issue". Latter solution would be best as player's bounding box size is used for collision when moving. Bigger box = bigger doorways needed.
Weapon Clips Away at Certain Rotations
#4
Yeah, this should be solved programmatically rather than by requiring data changes. The ugly thing is that this got nothing to do with the actual player code. Rather, it's the scene-level culling code where the player's bounding box simply fails the camera frustum test when the eye moves too far out the bounding box and the entire player shape won't get rendered. All SceneObjects tested for rendering undergo this same test.
The proper solution probably is to allow SceneObjects to temporarily toggle an "always-render" flag or something of the like which the Player shape could use while in first-person.
05/09/2009 (1:45 am)
Yeah, this should be solved programmatically rather than by requiring data changes. The ugly thing is that this got nothing to do with the actual player code. Rather, it's the scene-level culling code where the player's bounding box simply fails the camera frustum test when the eye moves too far out the bounding box and the entire player shape won't get rendered. All SceneObjects tested for rendering undergo this same test.
The proper solution probably is to allow SceneObjects to temporarily toggle an "always-render" flag or something of the like which the Player shape could use while in first-person.
#5
It was the by far simplest and most flexible approach
05/09/2009 (1:22 pm)
Its a sad thing that the simple yet powerfull setting TGE had for the player rendering was kicked in TGEA.It was the by far simplest and most flexible approach
Associate Steve Acaster
[YorkshireRifles.com]