T3D 1.1 Preview - Offset Mounted Image Always Render Unfixed in 1.1P - RESOLVED

#1 I think this might have been lost in the scene changes for zoning that Rene made.

I also made a change around this area... but in looking at it i don't see how it could cause the weapon to not render.

#2 Yep. THREED-1690.

#3 This is actually not really an issue with mounted images being culled but rather the old issue with the player getting culled when the eye node starts travelling outside the player's bounding box. There previously was a hack that forced the control object back into the render list if it got culled.

The real problem here is with the ambiguity over what the world-space bounds really mean. To the render system, the AABBs mean "this is the entire bounds of the object" whereas the to the player physics it means "this is the collidable volume of the player". Really, both should be kept separate without the physics code causing problems elsewhere by letting its own restricted view futz things up for the rest of the code.

Ideally, I would not like the previous ugly hack (introduced by myself) seep back in but not sure yet how to solve this more elegantly without addressing the root problem here (which is beyond the scope of this).

#4 Fixed for final.

I ended up putting the hack back in as the only way to properly fix it is an intrusive change to the abomination that is the Player class. It must not mix up collision shapes with bounding volumes. That's typical Torque legacy crap.

Unfortunately, the hack means that the Player object will be forced into each and every render pass. So, reflections and shadow maps all see the Player object being forced into their batches. This sucks but it's the only way to ensure that the incorrect Player bounds won't end up causing render issues.

#5 Good enough for 1.1. and better than a weapon that flashes in and out of render like a dimensional ghost.
;)

#6 Unfortunately, after pondering about this some more I realized that this has much more serious ramifications than addressed by that hack. The player setting incorrect bounds causes it to consistently zone and cull incorrectly. While the above hack forces the local player's object back into the render, it doesn't help a bit with zoning and culling of other player objects.

For 1.1 final, going in and actually fixing the root cause of this is out of question as this part of collision is deeply ingrained into the legacy ShapeBase and Player code.

So, for now, it requires a workaround. What I'm thinking of is to let the Player class store separate bounds that are computed from the TSShape model bounds and then let zoning and culling systems recognize player objects and take these bounds instead of the Player's world box. I don't like it a bit but it's the only practical solution ATM I think.

#7 Renee, for those who are model illiterate could you explain by incorrect bounds that causes this issue?

how can we see if a player has incorrect bounds?

#8

Quote:how can we see if a player has incorrect bounds?

It always has :)

Sorry for my obfuscated explanation. The problem is quite simple really.

There's two things that an object like a player needs:

1. It needs to have some kind of collision shape in order to detect interpenetration with other stuff.
2. It needs to have a "bounding volume", i.e. some invisible shape that surrounds the entire player, in order for other subsystems like zoning and culling to be able to work with the object independent of the actual model that is being used.

Now, the thing is, those need to be different. For a player, you will usually want to have a way smaller collision shape than the player's actual physical size simply because otherwise the box-shaped nature of the collision becomes very apparent to the gamer and it feels to the player like he's ultra-fat in the game world.

The bounding volume, however, must be precise. It must contain any and all parts that belong to the player. Otherwise you see the player object not being assigned to zones when it should be and being culled when in fact, some part is still visible.

The problem now is that the Player class abuses the bounding volume as the collision shape. This means that the bounding volume will almost always be "wrong" in that it won't be a valid bounding volume because it really is a collision shape.

That's very difficult to untangle as that is a mistake that has been made way back by the original devs in 1750 (or whenever the original code was written... don't remember exactly) and it's deeply ingrained in the Player class.

So, workaround for now, proper solution (Player making its final journey to the trashbin... and probably culling incorrectly along the way) later.

#9 Ah, and BTW, the player's collision box (and for the reason just outlined, thus also its bounding box) are determined with the various "boundingBox" properties of PlayerData.

//Edit: And you can see the bounds simply by selecting the player in the editor.

#10 bad bounds ... possibly anything to do with these?
www.garagegames.com/community/forums/viewthread/125671
www.garagegames.com/community/forums/viewthread/125672

#11 Need to check these out. From a quick scan, they appear to be most likely caused by something else.

#12 Would changing the bounds/collision box to a capsule help alleviate the apparent 'fat player' boxiness issue? Or is that idea something too far-reaching in scope to bother with since it would only be a stop-gap measure?

#13 One thing to keep in mind is that the "bounding volume" for visibility and occlusion will need to be big enough to hold the Player's geometry and its mounted shapes geometry even when the Player is going through a full range of animations (could be costly to auto-calculate).

#14

Quote:Would changing the bounds/collision box to a capsule help alleviate the apparent 'fat player' boxiness issue? Or is that idea something too far-reaching in scope to bother with since it would only be a stop-gap measure?

Unfortunately, that would amount to the same amount of intrusive work on the Player class than separating its collision shape from its bounding volume. The problem is that the Player class is *directly* abusing the world-space AABB functionality it is inheriting--which, however, is meant for bounding volumes and nothing else.

So, any kind of proper fixing would require in-depth changes to the Player class.

Quote:One thing to keep in mind is that the "bounding volume" for visibility and occlusion will need to be big enough to hold the Player's geometry and its mounted shapes geometry even when the Player is going through a full range of animations (could be costly to auto-calculate).

Yep. The nice thing is you can be pretty conservative about the bounds. If you cull a bit later than you should for a few animated humanoid objects, then that's no thing at all. The problem is culling when stuff is still visible :)

The bad thing really is the abuse as collision shapes--which have pretty much *exactly* the opposite requirement of bounding volumes in that you fit them inside not outside (for players that is; for level geometry you fit outside usually).

#15 @Matt
The design issue with having a large enough bounds to fully hold the player and any weapon that he might be holding is that you end up recording hits on the playerObject which clearly missed - plus Ai bang into all sorts of things that they should avoid when moving.

This was the basis of my original whinge about wanting the offset, mounted image to be able to penetrate a smaller bounds and still render.

#16 I was referring to the visibility/occlusion "bounding volume" which Rene was proposing be separate from the collision "bounds".

#17 Fixed in 1.1 Final.