Using building encapsulation as a means of graphics optimization (late stage development)

Question

Premise: reducing polygons, particle effects, animations, vertices to be shaded, and pixels which need to be shaded -> reduced graphics load

Premise: reducing the number of rate of production, consumption and transport calculations -> reduced CPU load

Premise: buildings (walls, foundations and ceilings) can be used to completely* enclose some set of factory components, and this enclosure can be detected programatically.

Idea: encapsulate enclosed subsections into logical units to reduce graphical and CPU load.

This idea is perhaps best illustrated using a common example. Imagine I have an iron ore miner which outputs to a belt at 240 ore/min, which in turn is consumed by, say, 8 smelters which are built on a connected set of foundations. The smelters are producing iron ingots which are merged into a single output belt carrying ingots at  240/minute.

I then completely* enclose those smelters with walls and a ceiling made of foundations.

What I now have is a single logical unit which takes ore as input, and produces ingots as output, with the conversion rate and total power consumption defined by a fairly simple set of rules. I will temporarily refer to this unit as an "encapsulated factory building", or "EFB".

At this point, there is no longer any need for the game to calculate all production components inside the EFB individually. Furthermore, as long as I am standing outside the EFB, there is no need for the game to render anything going on inside.

Now, I put an asterisk on the word "completely" before. Why? Well, because obviously there need to be "holes" of some kind in the EFB, ie, places where the belts can get in and out. These holes are provided by the conveyor walls, and I can see through those holes. So if we stopped rendering everything inside, and changed nothing else, it would look weird.

So, in order to make this work nicely something else should be changed. I suggest that if the player chooses to "encapsulate" a subsection of production in this way, all of the "holes" created by conveyor walls, doorways, and so on, be filled by a simple opaque black texture. A player could still walk through a doorway into the EFB, and once inside the game would need to render all of the machinery again - but at the same time, it could *stop* rendering anything going on outside the EFB.

To some degree this rendering optimization is already provided by techniques like occlusion culling. But deciding whether polygons should be rendered or not based on occlusion culling is itself a non-trivial (ie, somewhat expensive) operation. it is *far* faster to simply assert that an entire object doesn't need to be rendered, such that no polygons for the object even enter the rendering pipeline in the first place, no particle effects generated by the object even need to be considered, and so on.

If the player removes any wall, floor, or ceiling, or alters the internals of the EFB, then the encapsulation would be undone and all individual components would be processed as normal until the player "re-encapsulates" the building.

This would provide a truly gigantic performance boost when factories grow large.

Comments

Short answer, the CPU  needs to calcualte where all items are, regardless of  if its hidden or not. So the only thing you can save with enclosed things, are some GPU performance, which is not the game bottleneck atm.

---

No it doesn't. Why do you think it does?

---

I guess CrazyOdd didn't understand what the person said.

The suggestion is to identify group of building that could be simulated as one. Usually in this game you have a few inputs, a lot of machines and a few outputs. The idea is to internaly replace the simulation of every machine by just one big unit with specification that are dependent of the machine it tries to replace.

So first of all, yes you would lose some data (for example the place of every little object inside the factory) but that is data that you could consider not usefull.

In an ideal setup you would only need to know a few parameters to simulate the whole thing. Mainly, the input to output conversion rate, the throughput and the delai.

But when you start to think about it, in reality things are a bit more complicated. One thing that comes to my mind is managing a full output. In the real setup, internal lines would start to back up and prepare intermediate part in advance, storing some for later. And only them the inputs would start to backup. We can note that this problem existe also if ratios of each machine is not correct.
So the issue here is how you simulate that? At first glance it does seem like it could take so good calculation power making the idea not have as big of an impact as what one could hope for.

And that is without even speaking about the problem of when you have the go from the global simulation to the machine by machine one (when for example de player breaks it or enters it)

So in the end I am not sure if such a thing is interesting. As usual it would be a trade off first in the form of available detail data for minor improvement and then accuracy for bigger improvement. As if you really want you could sacrifice accuracy by trying to fit a model on the setup (by adjusting parameters in a predetermined easy to simulate model).