Why does the PreCombine thing make the game "faster"?

[YouDoNotKnowMyName]

Hello everybody!

 

I know what the PreCombine system does.

I know that it basically takes lots of meshes in a worldspace and "combines" them into a few big meshes.

I know how to generate & re-generate PreCombines ...

 

But why does this make the mehes and textures "load faster"?

Why is it faster to load a few big meshes rather then lots of small meshes?

 

Yeah, I know that with lots of small files you have more "overhead" (file headers, ...) that need to be loaded, but that can't be the only reason?

(The "file header" of NIF files isn't THAT big ...)

 

 

I guess this is something that I never understood / always wanted to know ...

 

 

Maybe somebody knows something about this ...

 

 

 

 

(I think this might be a thing with computers in general. Because whenever I do a backup of my harddrive, it takes much much longer to copy small files then to copy the same amount multi-GB-files)

[niston]

simply spoken: because one big mesh can be drawn at once by the GPU, which is faster than asking it to individually draw a lot of small meshes. that's precombines. If there is lots of stuff to draw, precombining makes a significant difference - especially on weaker hardware.

 

previs works by determining at design time -while making the game content/mod- which objects will be visible from where (in game space), so that this does not need to be determined by the game itself at runtime, which saves on cpu and/or gpu cycles.

 

those techniques come with their own drawbacks, of course...

[YouDoNotKnowMyName]

simply spoken: because one big mesh can be drawn at once by the GPU, which is faster than asking it to individually draw a lot of small meshes. that's precombines. If there is lots of stuff to draw, precombining makes a significant difference - especially on weaker hardware.

 

previs works by determining at design time -while making the game content/mod- which objects will be visible from where (in game space), so that this does not need to be determined by the game itself at runtime, which saves on cpu and/or gpu cycles.

 

those techniques come with their own drawbacks, of course...

But I mean that doesn't make any sense!

 

Imagine this:

You (the graphics card) have a piece of paper (the screen) and the task to draw lots of different shapes (meshes).

Now if you were using "precombines" you would have some shapes that are not really "connected" but just loosly grouped together.

 

How would that make the process of drawing all the shapes faster?

You still have to draw the same number of shapes which takes the same time as if they were just "on their own" and not grouped together!

 

I just don't get it ...

 

 

I know what PreVis is. Kind of ...

It's just like loading up the game, standing in one spot and looking around and saying "ok, I can see this part of mesh IDxxxxx, I can't see the mesh IDxxxxy, ...". So if the player is at position xyz and looking in the direction V W, then disable the mesh IDxxxxyand so on ...

Then move to a different sport and repeat .....

 

But how "detailed" is this process?

For how many "positions" and "view angles" does the CK compute this?

And wouldn't this generate HUGE ammounts of data (like a few TBs) ?

(The "higher" the "resolution" of this process, the more data)

I mean it would have to compute this for EVERY POSSIBLE position / view angle combination in existance!

Wouldn't this take like a supercomputer and a few weeks time to process for an entire worldspace?

[pra]

I suspect precombined meshes are in a special format, which is more efficient to render.

Or, it's about the I/O of reading the individual NIFs, and/or loading and evaluating of individual forms

[YouDoNotKnowMyName]

I suspect precombined meshes are in a special format, which is more efficient to render.

Or, it's about the I/O of reading the individual NIFs, and/or loading and evaluating of individual forms

Yeah, but if I had 10 files and "merged them" they would still be the same size as the 10 single files, right?

 

Sam for I/O: Reading or writing 10 "discrete files" would take the same time & effort as a 1 big file, right?

[Deleted77601483User]

Following your paper example, without precombines you'd first need to put the pencil on the paper, then draw the shape and then lift up the pencil, then repeat. With precombines, it's like putting the pencil down and drawing all shapes before lifting it up. While you're still drawing the same amount, using the latter way is much faster.

[YouDoNotKnowMyName]

Following your paper example, without precombines you'd first need to put the pencil on the paper, then draw the shape and then lift up the pencil, then repeat. With precombines, it's like putting the pencil down and drawing all shapes before lifting it up. While you're still drawing the same amount, using the latter way is much faster.

Yes, that's why I said "non connected or non overlapping" shapes.

(Precombines get generated for a few cells at a time, not all objects "touch each other" or are "next to each other")

 

So you would have to "lift the pen" anyway while "switching from drawing one shape to anohter" ....

[Deleted77601483User]

Yeah well that is a limitation of how pens work in real life, but for your pc that limitation doesn't exist. So without precombines your game would have to think like "Okay so this item is a rock with this model right here" (putting the pen down) and after drawing it, your game would say "Okay that's done, let's move to the next one" (lifting it up) and then it would repeat this process for the other objects like other rocks and trees etc. It's a lot more performance-friendly for the game to just say "Okay here's the entire environment with this mesh" and draw it all in one go. They both take approximately the same amount of disk, but it's faster to open a file once than many times.

[YouDoNotKnowMyName]

Yeah well that is a limitation of how pens work in real life, but for your pc that limitation doesn't exist. So without precombines your game would have to think like "Okay so this item is a rock with this model right here" (putting the pen down) and after drawing it, your game would say "Okay that's done, let's move to the next one" (lifting it up) and then it would repeat this process for the other objects like other rocks and trees etc. It's a lot more performance-friendly for the game to just say "Okay here's the entire environment with this mesh" and draw it all in one go. They both take approximately the same amount of disk, but it's faster to open a file once than many times.

But it would still have to load the different textures for the different "materials" (rocks, trees, whatever, ...).

So instead of just "lifting the pen" it would have to "switch to a different coloured pen" ...

 

But let's just talk about the meshes, lets leave textures out of the picture (haha) for now ....

 

The meshes are made up of triangles.

Lets say we have a GPU that can only draw one trianlge at a time.

And lets say that the meshes have to get loaded from memory by the CPU (don't know how this actually works, if the GPU does this by itself or what)

 

So, the GPU (or whatever) draws all the triangles for the first object. While it is doing that, the second object gets loaded from memory in the "background" (by the CPU), so that when the GPU is finished drawing the first mesh, it can draw the second mesh. While it is drawing the second mesh, the third mesh gets loaded from memory "in the background" ......

And so on ...

 

Why would havng all meshes "in one file" make this any faster?

The graphics card can only "draw one triangle at a time" anyway.

Edited January 1, 2021 by YouDoNotKnowMyName