View Issue Details
|The Dark Mod
|0005190: Frontend optimizations due to connectedness of entities/surfaces
|One of the inefficiencies of current frontend is that objects are often pushed into visleafs where they don't belong.
This usually happens for sloped walls, when the object is completely indoors, but its bounding passes through the wall, so the entity is also considered to be outdoors.
This results in excessive draw calls in such cases.
The idea is to exploit connectedness property of an object to better determine which areas is belongs to.
If the object bounds don't overlap any visportal, then the whole object belongs only to the area/visleaf where its test point (chosen arbitrarily) belongs to.
Hopefully, it is possible to deduce connectedness of many objects automatically.
However, spawnargs for forcing connectedness / disconnectedness are still necessary.
|No tags attached.
I'm still a bit scary that we might have situations where mapper puts e.g. a barrel into the wall and it should be visible in both rooms.
The suggested optimization would definitely break such a case.
Such cases should be rare, but it still sucks to fix them all the time...
Instead, I decided to improve the algorithm for searching the areas covered by an entity.
Right now we check oriented bounding box against BSP tree.
I decided to check BVH trees of static models instead, since they should give slightly better bounds.
This did not work out: I did not receive any noticeable improvement in Perilious Refuge regarding the number of entities drawn in view.
The only difference that I found was BVH code giving MORE refs, and it turned out to be because it uses "<=" instead of "<" comparison in box-vs-plane check =)
Despite my worries about performance of such a check (I planned to enable it only for the very start of the level), it actually worked pretty fast even globally.
Still, it is a little bit slower because I changed "common children" important optimization to several areas in a node, which only slowed things down.
Perhaps the reason for this is that most of our models are very low-poly and BVH has little effect.
Perhaps that's because the whole issue of static entity leaking a wall almost never happens.
Really, this is the problem only when entity is within room A, but it's oriented bounding box ix so large that it touches room B behind a wall.
Anyway, I decided to not commit this.
It is a big change which obviously gives nothing =(
|new => assigned
|TDM 2.09 => TDM 2.10
|TDM 2.10 => TDM 2.11
|TDM 2.11 => TDM 2.12
|related to 0006243
|Note Added: 0016009
|TDM 2.12 => TDM 2.13