Static Collections and PreCombines

[Glitchfinder]

Those images are just the wireframe models, which allow you to see what is being displayed behind normally opaque objects. You can try that yourself by using the "twf" console command.

[Qrsr]

I remember there is TFC 2, 3, 4 but these may or may not work and may be bugged or not. I hope the twf is working as intended. If it is not, meaning, if what we see is not what the game actually culls or not then the entire project aim can be influenced in a bad way. So i really dont trust it.

If only one varialbe is missing the entire picture can be off from what is expected to see as true. So im coming to what i was saying in the beginning, if im testing with a suppressed system every little change is noticable, and if i see a better performance, better mouse movement less laggy image sequences (FPS), etc. then i know my system performs better.

And im seriously curious now about the entire city being SCOLed with the occlusion markes set. If this is done, we really know if its working or not.

[Glitchfinder]

Like I said, twf (aka toggle wireframes) does exactly what it says: It renders wireframe models rather than rendering the entire triangles. Occlusion checks are unaffected because they're handled in a completely separate part of the code that doesn't understand the concept of a wireframe. After all, checking if occlusion is working as intended is one of the biggest reasons to ever have a wireframe renderer in the first place.

If you directly compare my three screenshots, you can see the differences in occlusion caused by using the different techniques. For example, only the first screenshot occludes the back half of the top of Dartmouth Professional Building, because that's an impact of your occlusion boxes. On the other hand, the entire Boston Public Library is rendered in the second screenshot despite the occlusion box you put inside, because it is now a single object due to being SCOLed. The third screenshot shows much more effective occlusion at direct angles such as behind Boston Public Library, but suffers from less effective occlusion at indirect angles and higher distances (such as the right edge of the screen) due to rounding errors present in Umbra's system.

Speaking of which, I should redo the screenshots with LODs turned off via the "tll" console command, since LODs make the wireframes more confusing while not actually contributing much of a performance hit. First up, Unbound World without SCOLs:

Next, Unbound World with SCOLs:

And finally, Bethesda's own precombines with no mods other than the unofficial patch:

[Qrsr]

The first and last picture doesnt make sense, since in the first picture it should completely hide the library. Since i net it into at least one occlusion box. The image however shows bits not occluded, why is that?

When you look into the center of the first image you will notice the fire barrel. Right?

I assume the light around the fire barrel is breaking the occlusion for some reason. At least it looks like this in the image. Since the upper, left, right, etc parts are almsot idential (first and third image).

 

It really seems that the (manual) occlusion is either not working as intended, or broken due to the light next to the library wall or the twf command does not display the (manual) occlusion correctly.

Otherwise if you look again in the center of the first and third image, if the first image would show the occlusion correctly, then there is almost no difference to automatic occlusion, done by precombination (Umbra).

 

Since im experiencing stuttering only next to heavy light source usage, i must say im more and more under the impression the light can break the occlusion. I have to play around with no, some and heavy light usage, with and without shadow caster lights and with and without spotlight type of lights. Im pretty sure the answer is the lighting...

[Glitchfinder]

21 minutes ago, Qrsr said:

The first and last picture doesnt make sense, since in the first picture it should completely hide the library. Since i net it into at least one occlusion box. The image however shows bits not occluded, why is that?

That would be the case if you had that section of the library occluded. But you do not. This is what you have occluded there:

For reference, my screenshots were taken from a bit behind that set of three red markers you can see in top center of the image.

[Qrsr]

O m g this explains all, but i knew i fixed this in past. Thanks, now i have to fix it again. Im pretty sure this was broken due to one of the latest patches where i forgot to flag the master file "ESM" for the time being.

[Qrsr]

I was thinking about the SCOL and the disability to not hide any SCOL via occlusion planes. Now.. is it even required if the entire kit piece kit is just one mesh in the end? SCOLs reduce draw calls or am i mistaken?

• More models = more drawcalls
• Less models = less drawcalls

If combining 3000 kit pieces its just 1 model instead of 3000 models. Better?

If the engine can only handle up to 15000 draw calls or something till it bloats ... and we have a uGrid 5 meaning
 

0 0 0 0 0

0 0 0 0 0

0 0 x 0 0

0 0 0 0 0

0 0 0 0 0

X = center / player char

0 = cell

EXAMPLE:

• If each cell consists of like 1000 craw calls
• A uGrid 5 environment/cluster is 25 cells
• This would scale up to 25000 draw calls without precombination enabled
• In Downtown BC each cell has a minimum of 1000 loose objects or kit pieces or meshes or models or whatever you call them

The engine is forced to its knees. And remember 25000 is just an example, its probably much more, much much more ... If i combine the majority if obejcts per cell in those dense clusters, i think i can come easily below 15000 or 10000 etc.... this would create a super stable environment.

Addendum: I found this very good post by alex77r4
 

Quote

If you know what is a draw call you must know is a mono-thread process. As only one thread can make the draw calls the mono-core turbo speed is critical.

Your i5-2500K have 3.3 base and 3.7 turbo mono-core but as you have overclocked it we can't know if you have turbo.

Probably not because have 4.4 constant in all cores is better than 3.7 mono-core.

 

You ask if whit a new cpu you go to have more frames: YES
Because the main diference in the new CPUs not was the speed or the number of cores. Is the IPC = Instruction Per Call.

We are reaching spedd limits and nanometers limit. Have more cores not help mono-core task. But increase the IPC increase the computer power.

 

If you want more FPS with your actual CPU remove JK to reduce the number of objects and that reduce the number of draw calls = CPU work.

Some vegetation mods are famous by reduce FPS in old machines, because the trees have more leafs and more branches = more draw calls.

Some cities like Markarth, Riften and Solitude have a lot of objects and, if you add JK, more and more objects = more draw calls.

 

Additionally, DirectX 11 suport multi-thread render but is the game that must use it. Multi-thread render is a capacity that only some games use.

Skyrim, of course, not use it. The render engine in Special and Aniversary is the same as in Legenary. Only change the creation of the window.