Fixing the Talos Bridge Collision

[Sigurð Stormhand]

I'm making this thread to document attempts to finally nail down a fix for the Talos Bridge collision mesh. The original issue is covered in our change log here, it's from 2011, so lacks an indexed entry in the tracker.

For those unfamiliar with the issue, essentially the bug involves the collision for the Talos Bridge (the main entry to the Imperial City) "dropping" so that it is no longer aligned with the visible model. This would be bad enough if it was a visual glitch, but because the bridge is made up of multiple sections if only one sections bugs out NPCs can get stuck, or in worse cases they can fall through entirely and end up trapped inside the mesh. The UOP fixes this by placing invisible collision meshes just below the surface of the bridge that NPC's can walk on which stops them falling through the world. However, these meshes seem to be subject to the same issue. Their collision can "rise", creating a step NPC's can get stuck on.

To further complicate this, it appears to only affect users with Intel CPU's (anecdotally).

To finally nail this down I'm going to attack the problem from two directions:

1. Try to fix the collision on the bridge meshes so it's less likely to glitch out. Lokhansheart has given me some pointers on how we might do this by breaking the collision into sub shapes.

2. Replace the rectangular collision meshes with trapezoidal ones with sloped sides. That way, if they "rise" NPC's and the player should still be able to traverse the bridge, even if they do seam to float.

 

Next post to have the dump from our Discord covering this, after I have slept.

[Arthmoor]

Worth noting that part of the reason that UOP did what it did is because the bridge may not be fully loaded depending on how you approached it. So the collision boxes have significant overlap with the actual bridge in order to handle cases where the NPCs on it loaded, but the bridge itself didn't yet.

[Sigurð Stormhand]

The reality is, regardless, the fix is glitchy.

[Sigurð Stormhand]

Discord dump:

Quote

 

Lorkhansheart — 5/9/2025 22:57
The collision for the kit pieces of the Talos Bridge need:

The MOPP vertices welded,
The single MOPP shapes could also benefit from being broken down into separate shapes because collision that is too big can cause issues,
In the Rigidbody settings, the Penetration Depth needs to be 5 to 25% of the smallest radius of the Nif,
The Collision of the ICBridge01 is misaligned by .001 on the y-axis,

That last bullet point might not matter but I listed it anyways 

This was checked on the vanilla Nif so I don't know if these have already been addressed currently or previously by UOP (edited)

Sigurð Stormhand — 5/9/2025 23:07
So, I don't think the Y alignment is relevant to the issue with the bridge rising or falling. It it's off by 0.001 Bethjesda Units that's not going to matter in the in-game atl all.
[23:10]
If there's a problem with the collision mesh loading (rather than a more general issue loading collision in that cell) I would think it'll be your second or third point. Have you observed these sorts of issues in other meshes? I'm not opposed to optimising the collision, but it would be good to have something to compare this against to have an idea if this is likely to fix the bug.

Lorkhansheart — 5/9/2025 23:15
I don't have any specific examples on  hand unfortunately for most of the information in regards to Oblivion but the penetration depth but actually can also be applied to various other Nifs such as those of miscellaneous items
[23:16]
Especially in UOPs case, say an Apple in vanilla looks like it's placed right in the CS but in-game it isn't and Havoks all over place - UOP then changes the placement of said apple to counteract this
[23:17]
Theoretically, fixing the penetration depth settings on all necessary Nifs could possibly make the UOP position esp edits redundant (edited)
[23:18]
Obviously not all of them ofc, some will still need adjustment but a good portion will be good on their own
[23:20]
Also by necessary Nifs that includes any objects that are in placement together, for example the apple and the bowl the apple is placed in and the table the bowl is on would all need their penetration depth settings adjusted to more "proper" values (edited)

Sigurð Stormhand — 5/9/2025 23:29
So, essentially, you're saying that a lot of the floating items in-game could be fixed by increasing the penetration depth of the collision?
[23:29]
If that case, it seems like the penetration depth on the bridge might be too high, if anything.
[23:30]
I can try cleaning up the collision, but I' thinking that if anything helps it will be sub-shapes.

Sigurð Stormhand
I can try cleaning up the collision, but I' thinking that if anything helps it will be sub-shapes.

Lorkhansheart — 5/9/2025 23:31
Only one way to know fully

@Sigurð Stormhand
So, essentially, you're saying that a lot of the floating items in-game could be fixed by increasing the penetration depth of the collision?

Lorkhansheart — 5/9/2025 23:31
If I remember correctly overall it would be a decrease
[23:32]
I'll need to double check

Sigurð Stormhand — 5/9/2025 23:32
I've never encountered this issue myself, is the thing, so it's not like I can test for it once I fix it.

@Sigurð Stormhand
I've never encountered this issue myself, is the thing, so it's not like I can test for it once I fix it.

Lorkhansheart — 5/9/2025 23:33
I haven't either, I figured I'd just take a look at it and see if I could help in any way
[23:34]
Does anyone know someone (or preferably is someone ) who can repeatedly reproduce the bug?

Lorkhansheart
I'll need to double check

Lorkhansheart — 5/9/2025 23:38
Penetration Depth: Serves as a general guideline for Havok for how much it allows penetration on the object. Lower values decrease clipping and decrease performance when the object is moving, higher values increase performance but allow more penetration to occur. The Motion Quality type increases the effect this setting has. This setting also works on statics, useful for preventing the player or other actors from getting stuck in an object.

@Lorkhansheart
Penetration Depth: Serves as a general guideline for Havok for how much it allows penetration on the object. Lower values decrease clipping and decrease performance when the object is moving, higher values increase performance but allow more penetration to occur. The Motion Quality type increases the effect this setting has. This setting also works on statics, useful for preventing the player or other actors from getting stuck in an object.

Sigurð Stormhand — 5/9/2025 23:41
Right, so more penetration would make collision more forgiving. (edited)

@Sigurð Stormhand
I've never encountered this issue myself, is the thing, so it's not like I can test for it once I fix it.

llde — 5/9/2025 23:52
I think the FPU precision may affect the problem. So exact same game configuration(and mods) could differers on experience. This may involve not only different vendors (Intel-AMD) but also different series or generations inside a cpu serie itself (notwithstanding microcodes and bios)
[23:54]
However for the FPU to have a this significant impact means there is probably a degenerate computation happening (handling of different NaNs, multiple errors in intermediate computations increasing by magnitude in the final result,etc)

Sigurð Stormhand — 5/9/2025 23:57
Can you dumb that down a bit? Are you saying that hardware would be a factor, but there's probably something screwy in the game code? (edited)

@Sigurð Stormhand
Can you dumb that down a bit? Are you saying that hardware would be a factor, but there's probably something screwy in the game code? (edited)

llde — 5/9/2025 23:58
basically
[23:58]
the FPU is the part of the processor that is involved with floating point math
[23:58]
and many cpu had precision issues

Sigurð Stormhand — 5/9/2025 23:59
The issue sees to affect not only the original bridge collision, but also the collision boxes we placed separately to mitigate the problem. Is it likely that impriving nif collision will help?
May 10, 2025

llde — 5/10/2025 0:00
well yes, most of precision issue can be mitigated

Sigurð Stormhand — 5/10/2025 0:00
My current plan is to just create sloped "collision rhomboids" that the NPC's can walk over instead of boxes with square edges.

llde — 5/10/2025 0:00
may be a worthy solution
[0:01]
alas, I myself never experienced this issue in more then 10 years of Oblivion

Sigurð Stormhand — 5/10/2025 0:05
19 years, never had a problem. (edited)
[0:05]
Must be my hand-built AMD gaming machines. (edited)

@Sigurð Stormhand
Must be my hand-built AMD gaming machines. (edited)

llde — 5/10/2025 0:06
amd too

Arthmoor — 5/10/2025 0:07
For Skyrim it was feasible to do what you're discussing because there's a collision radius value on many Havok enabled objects. This allowed us to correct foaters at the mesh level in many cases. It's not perfect though because it's harder to tune that for really small things like coins.

Oblivion's Havok handling being what it is, the mesh level solution may not work since Havok doesn't settle objects until you interact with one. Skyrim set of the Havok settling as soon as you walked into the area. Which is what Oblivion Remastered is now doing too.
[0:08]
The Havok implementation is why things tend to explode in Oblivion since it sets the whole thing off all at once.

Lorkhansheart — 5/10/2025 0:10
It will still have improvements because the "explosion" will be less violent and extreme compared to vanilla

Arthmoor — 5/10/2025 0:11
The explosion happens at all because all of the objects suddenly becoming active cascades through the level as they all start hitting each other while settling out.

llde — 5/10/2025 0:11
I wonder if we found optimal value range of these values if it can be somehow clamped in-code
[0:11]
Havok code is unfortunately a mess
[0:12]
Ida barely can make sense of 10% of it
[0:12]
the only one who attempted to actually decode something on it was Alenet when he attempted the IKFoot impl

@llde
I wonder if we found optimal value range of these values if it can be somehow clamped in-code

Lorkhansheart — 5/10/2025 0:12
Anywhere from 5 to 25% of the smallest radius stored in the shapes of the Nif iirc is what is optimal for other games where these tweaks show improvements

Arthmoor
The explosion happens at all because all of the objects suddenly becoming active cascades through the level as they all start hitting each other while settling out.

Lorkhansheart — 5/10/2025 0:14
Exactly, the less the active objects move around while in the process of setting out the less intense the cascade

Arthmoor — 5/10/2025 0:15
I think it might be best to set up a smaller scale test that would fix this stuff in one or two cells and see how it pans out.

Sigurð Stormhand — 5/10/2025 0:16
This isn't a terrible idea, and if you want to go through and make the adjustment to some misc objects like bowls, then stack them, and get it tuned, I say go for it.
[0:16]
I don't have the time to do this yself, currently, I'm afraid.

Lorkhansheart — 5/10/2025 0:18
I can try later on, is there a specific cell or portion of a cellwhere the "explosion" problem is particularly bad even with UOP tweaking the placements?

Arthmoor — 5/10/2025 0:19
Nothing I can think of off hand in the original game.

Sigurð Stormhand — 5/10/2025 0:20
Luthor Broad's Bed and Board. (edited)

slowpard — 5/10/2025 0:20
I suppose you can just write a script patching the value for all misc nifs
[0:20]
For test purposes

 

 

[Arthmoor]

Surely you mean the game is glitchy?

[Sigurð Stormhand]

21 hours ago, Arthmoor said:

Surely you mean the game is glitchy?

Are you saying all our patches are glitchy as a result?

[Sigurð Stormhand]

I should add that I'm planning to push this out ahead of the next UOP so we can get some testing done.

[Arthmoor]

34 minutes ago, Sigurð Stormhand said:

Are you saying all our patches are glitchy as a result?

Well I guess that's one way to look at it. If the game's collision system is this big of a mess then why is this bridge the only place one runs into weird collision issues?

Either way I don't really want to see going back to relying only on the bridge pieces because they don't all load in at once.

[Sigurð Stormhand]

2 minutes ago, Arthmoor said:

Well I guess that's one way to look at it. If the game's collision system is this big of a mess then why is this bridge the only place one runs into weird collision issues?

Either way I don't really want to see going back to relying only on the bridge pieces because they don't all load in at once.

Well, that's no the plan, so don't worry.

[Aikanikuluksi]

Just a thought; hopefully not too silly, as I haven't tested it myself:

Even not knowing the detailed workings of the game engine, it superficially seems to make sense that, as NPCs are persistent objects in memory, they are already present when a cell loads, and thus any platform crucially supporting them perhaps should also be. A platform that is freshly loaded into memory as a temporary object when the cell loads perhaps doesn't always make it in time to stop the already present NPC from plunging to death. Or so it might seem.

So, perhaps one might try making either the bridge elements or the additional collision boxes persistent. Persistent collision boxes would mess less with existing records. And perhaps this approach might also suit the bridge in Skingrad. The large bridge SE of Lake Rumare, where The Upper Niben river begins, might be susceptible as well, but maybe there just isn't much NPC traffic there, and any who might happen to fall are more likely to fall safely into water.

Finally, come to think of it, Beirand in Skyrim might appreciate something persistent under his feet when at his forge, unless that is already the case. He seems to sometimes have ended up dead below the platform he should be standing on.

P.S.
Regarding the Talos Bridge, perhaps one could even make do with a single, nice and smooth, ultra-long, end-to-end, persistent collision box?

Edited September 14, 2025 by Aikanikuluksi
mostly harmlessly, mainly for compactness and clarity

[Lefty Scaevola]

Somebody over at Nexus is reporting that rare bug where the added collision meshes are too high for some reason, and block NPCs on the bridge.  Did anybody ever figure that one out?  Was it maybe some other mod editing the base mesh that was used for this?

Edited Wednesday at 01:42 AM by Lefty Scaevola

[Arthmoor]

On 9/12/2025 at 9:50 PM, Aikanikuluksi said:

Regarding the Talos Bridge, perhaps one could even make do with a single, nice and smooth, ultra-long, end-to-end, persistent collision box?

That isn't feasible because the bridge spans more than one set of cell borders. It's the entire reason this bug exists in the first place. The center point of whatever mesh you use has to be loaded for it to matter, and it's not possible to guarantee this with such a large span. Which is why there's more than one of these collision boxes.

[Aikanikuluksi]

18 hours ago, Arthmoor said:

That isn't feasible because the bridge spans more than one set of cell borders. It's the entire reason this bug exists in the first place. The center point of whatever mesh you use has to be loaded for it to matter, and it's not possible to guarantee this with such a large span. Which is why there's more than one of these collision boxes.

I am a bit hesitant to contradict you, for obvious reasons. However, persistent references are part of the world data structure, not the cell data structure, and this is easy to verify just by looking at the structures in TES4Edit. Persistent references are grouped together in a single 'Persistent Worldspace Cell' (e.g. FormID 00023777 for Tamriel), and they are, as the name implies, persistently loaded in memory regardless of where their center points lie or which world cells are loaded. Temporary and visible-when-distant references on the other hand are indeed stored separately for each cell and loaded into memory (or purged from it) together with the cell. Persistent NPC references accordingly exist in memory before any per-cell temporary references are loaded that may or may not make it in time to catch the NPCs from falling. Hence, replacing multiple temporary collision box references with a single persistent one might well be worth a try, and I don't see any obvious reason why it shouldn't work.

P.S. This behavior should be relatively easy to verify by creating and placing a persistent world reference with a clearly visible mesh and checking whether it can be seen even at a distance where no cell is loaded. Or better yet, create a huge persistent barrier object with an attachment point in the far distance beyond loaded cells, and see if you can collide with it. If I recall correctly, some old version of Nehrim seemed to use persistent references rather than visible-when-distant references with LOD meshes to make certain notable structures visible from a distance, so I would expect the visible mesh at least to be loaded independently of any world cell, and I don't see why the collision mesh wouldn't be loaded as well. Unfortunately, I cannot help with this, as for the moment Oblivion has given way to Expedition 33 on my gaming PC.

P.P.S. Actually, creating this post began to feel a bit tiresome, and it now contains everything I have to say on the subject, right or wrong.

Edited Wednesday at 09:55 PM by Aikanikuluksi
for clarity and brevity

[Arthmoor]

14 hours ago, Aikanikuluksi said:

Persistent references are grouped together in a single 'Persistent Worldspace Cell' (e.g. FormID 00023777 for Tamriel), and they are, as the name implies, persistently loaded in memory regardless of where their center points lie or which world cells are loaded.

There is a difference between the reference being in memory and when it actually renders to be viewed. Rendering does not change because something is persistent. The coordinates still determine when something will be loaded for rendering. So it would still be necessary to have more than one object to cover the span.