3D rendering

[orost]

Many people's reaction will be that it's outrageous to propose a move from 2D to 3D at such a late state in a game's development, but as someone with some experience in 3D graphics I can tell you that it's not as big of a deal as it sounds. The vast majority of the game wouldn't need to be touched, all the logic would stay 2D, it's "just" a renderer rewrite. A lot of work, but perfectly feasible.

And I think it makes a lot of sense, Factorio puts a lot of effort into pretending to look 3D with its huge, accurately animated sprites. Real 3D could actually be faster and require far less video memory.

[katyal]

@Orost



To be clear the devs would be the pigs in this example. People who “do” work.
A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to “getting things done.” Their “eggs” are a renewable resource, and many get laid (eggs that is).

The players in this case are the chickens.

Its ultimately up to the devs to decide what is or isn't a reasonable amount of work. Who has less than one GB of vram these days anyways? Even with half a GB you'd have headroom.

My personal preference is for the game experience to get deeper rather than having part of the game engine rewritten for what? smoother rotation? IDK maybe I'm missing something here the whole thing just sounds silly to me.

[dee-]

Well, a move to 3D has some advantages and they're not only visual for having nice rotations as you said.

For example 3D offers many ways of different hardware accelerations, be it geometry instancing for drawing the 10k+/100k+ items, alpha blending, correct lighting and shadows for different times of day and weather, tone mapping, using massive parallel GPU calculations like CUDA/OpenCL (which are just PERFECT for Factorio!), etc pp.

Of course the devs have to decide if the possible gains are worth it and not we players. We can only bring up ideas and arguments. The more involved and knowledgeable players can give the devs hints, directions and practical knowledge. The number of players far outweights the size of the dev team and thus the chance for having one or more experts on a field of investigation are quite good.

[hoho]

using massive parallel GPU calculations like CUDA/OpenCL (which are just PERFECT for Factorio!)

No, not really. While the numbers on paper look nice the time it takes to transfer the data to GPU and back takes ages. not to mention GPU calculations are awfully inefficient as soon as any sort of conditionals enter the play, let alone conditional suroutine/function calls.

[dee-]

using massive parallel GPU calculations like CUDA/OpenCL (which are just PERFECT for Factorio!)

No, not really. While the numbers on paper look nice the time it takes to transfer the data to GPU and back takes ages. not to mention GPU calculations are awfully inefficient as soon as any sort of conditionals enter the play, let alone conditional suroutine/function calls.

Yeah, the numbers are impressive. Conway's Game of Life on GPU using CUDA

For Factorio it depends if it is calculation-heavy (fluid dynamics, power network) or logic-heavy (train routing, inserter picking/dropping). Where all the items moving on belts belong to I don't know.

[hoho]

Game of life is so trivial that it's not even funny. You should look how "efficient" modern GPUs are at as basic tasks as sorting or just even random memory access

Another thing to note is that even in Game of Life it takes nearly 100k identical elements to be "simulated" with identical algorithm for each and every one of those elements in order for GPU to provide a meaningful speedup. In a game like factorio, even the biggest bases won't have enough *identical* entities to simulate for it to make sense to offload to GPU.

[dee-]

Game of life is so trivial that it's not even funny. You should look how "efficient" modern GPUs are at as basic tasks as sorting or just even random memory access

Another thing to note is that even in Game of Life it takes nearly 100k identical elements to be "simulated" with identical algorithm for each and every one of those elements in order for GPU to provide a meaningful speedup. In a game like factorio, even the biggest bases won't have enough *identical* entities to simulate for it to make sense to offload to GPU.

GPU sorting sucks

-> github
One commenter however said it's misleading. Dunno.

No seriously, it's really interesting for me to be confronted with problems.

And I do think moving items on a belt by simple rules (x++/y++/if in corner/...) with 10.000's of belt objects and even more items on them is a nice playfield for parallel computation.
It would be interesting to know what's the bottleneck within Factorio and if it could be leveraged by parallel computation.

Edit: idea - why have the belts move the items? Just have every single item move by itself through a matrix multiplication with a "ground field matrix" which is determined by the placed belt (going straight up, going from left to the bottom, etc.) that way no logic at all is needed for simple movement: every tick is just the application of the movement matrix below the item on the item's current position. Currently no idea about collision checks, tho maybe textures mark occupied space and then use a shader to react with the item's hitbox?

[hoho]

GPU sorting sucks

It does if you take into account that this sorting used absolutely best possible data structures for GPUs that you likely can't use reasonably well in a factorio-like game. There essentially was zero random access and the sorting scaled linearly with memory bandwidth, not so much with compute speed.

And I do think moving items on a belt by simple rules (x++/y++/if in corner/...) with 10.000's of belt objects and even more items on them is a nice playfield for parallel computation.

Didn't devs just recently optimize exactly this scenario to make it use negligible amount of computing time?
One should *never* try to optmize calculations before algorithms are already optimized.

A massive problem with moving stuff to GPU would be that whenever e.g inserter needs to take an item from a chest and insert it to a assembling machine it needs to go through two different lists:
1) stuff inside chest
2) stuff allowed to be inserted to the assembler

That requires quite a bit of random access considering there are different lists for pretty much every single inserter. The lists themselves probably aren't big but that only means the time one spends collecting the data to be sent to GPU for computing could be better spent on CPU to just do the calculation itself saving the relatively costy transfer to GPU and back (that also has HUGE latency).

[dee-]

I'm really not experienced enough on this so I will accept your reasoning
I agree GPU is restricted in flexibility and this constant swapping between CPU/GPU and data/logic will hurt more than it helps. So GPU compute is probably not as useful as I hoped.

[hoho]

Just because I can't see a good reason to offload some things to GPU doesn't mean nothing could. I would think wind and pollution spreading could be mapped relatively well to GPU. Sure, current model of it seems to be very trivial and it wouldn't really help with much but it would allow making the pollution/weather simulation much more detailed and dynamic.

Only problem would be that if such a thing was added (and was mandatory) it would mean I probably couldn't play it any more on my laptop that only has integrated GPU with lousy shader support

[sillyfly]

I don't know a lot about this GPU for general tasks thing, but it seems to me this would be totally unrelated to using 3D rather than 2D graphics, wouldn't it?
I mean - wouldn't you still be able to send whatever computation you wish to the GPU even if _as a graphical processing unit_ you use it solely for 2D stufF?

[hoho]

Yes, you are correct. "General purpose" calculations on GPU doesn't have anything to do with 3D rendering.

[golfmiketango]

My basic understanding is that the biggest problem in 2016 with GPGPU is that there is no working driver model. There are a handful of competing frameworks, and although, for example, you can layer opencl on top of stream or vice-versa, I get the impression that if you do so, you are forced to throw out too many babies with the bathwater -- those "compatibility layers" are, afaik, just toy implementations, implemented so somebody can say "also supports foo" in a marketing brochure.

Consider this: In the present day, the SME's maintaining LLVM/DX12 have failed to produce a compatibility layer sufficiently usable to entice big game studios to leverage gpgpu in games developed with unreal engine, unity, etc. So, seriously, should Wube throw it's hat into that ring and try to solve this? Obviously not. The cost simply dwarfs the likely benefit to factorio.

That's mid-2016. In a couple of years, who knows? This is definitely a work-in-progress. Eventually, it's safe to bet that either a clear winner of the present framework/standards war will emerge, or a new approach will be conceived, or game engines will start working out these problems one-by-one, in a way that their consumers can conveniently leverage.

It's not a fundamentally broken idea to use gpgpu in factorio. It's just an incidentally losing proposition, right now, to use it for almost anything.

The only real exceptions are, i.e., bitcoin mining, video transcoding farms, and so on, which is to say, highly specialized tasks, for which the benefits of gpgpu are sufficiently game-changing to justify high equipment and systems-administrative costs.

Disclaimer: I am no expert on this stuff, and, I could very plausibly have some false impressions about some of the gory details. However, I am pretty confident that my conclusion -- that gpgpu would cause more hassles than anything else for most of factorio's user-base -- is right.

[Flight]

Things like items becoming smaller when on top of a belt and drones flying inside each other would look too weird if the game was 3D.

[MeduSalem]

Disclaimer: I am no expert on this stuff, and, I could very plausibly have some false impressions about some of the gory details. However, I am pretty confident that my conclusion -- that gpgpu would cause more hassles than anything else for most of factorio's user-base -- is right.

You are probably entirely right.

A friend of mine who works at Siemens tried to do some things with it for a dissertation, where he tried offloading raytracing calculation to the GPU using GPGPU (nothing innovative back then, as Nvidia themselves showed something like it done in CUDA). Seemed like a good idea to his superiors back then until he really got into it.

From what I got out of the conversations we had while he was frustrated dealing with it the various competing frameworks are all anything but "ripe" and many of them lack the compatibility necessary between various platforms and that's what's eventually the dealbreaker for most companies. It gets better slowly, but not fast enough to encourage the masses.

On top of that from what I got the GPUs are also harder to program for GP stuff even with the frameworks available because they also lack certain abilities CPUs have, requiring workarounds which are usually performing slow (defying the purpose) or the GPU expects certain things in a way very differently than a CPU does due to the GPU normally dealing with graphics data, requiring programmers to re-think everything. Probably the most ugly part with some of the frameworks is the memory management which is basically entirely in the hands of the programmer which for some is too much freedom for their own good as it requires a lot of additional experience the programmers could rely on that someone else did for them.

Which is something that I heard critics complain about the more recent low-level APIs like DX12 and Vulkan too, meaning that it either performs exceptionally well or absolutely horribly depending on the programmer's skill due to lacking the necessary abstraction layers that do all the dirty work for the programmer, so they have to code their own. So GPGPU is more like a mad science project currently, tech demos to show if something can be done, rather than something developers really desire to work with just to squeeze out an uncertain amount of additional performance. With DX12/Vulkan they will probably have no choice though. There are actually people who really curse AMD for coming up with Mantle in the first place, creating the trend of making everything more low-level again. My friend is one of them.

So it may have some applications for huge companies with GPU based super computers who are willing to spend the necessary "spare change" on something highly specialized, but you are absolutey right when mentioning that when the huge game engine companies like Epic Games with their Unreal Engine or Unity Technologies with Unity with their countless licensees can't be arsed to support GPGPU by 2016 it should be a warning sign that the stuff is not yet ready for mass application or that they didn't find enough practical applications to deem the investment worthwhile... and they surely have a couple of people at their companies dedicated to research GPGPU possibilites.

And for good reason, from a project management view nobody really wants to be the guinea pig for AMD or Nvidia and who ever else provides propriety or open frameworks, like OpenCL from Khronos, etc, and then be left in the dust by betting on the wrong horse when someone actually brings an end to the framework madness or maybe even an entirely different approach altogether.

[MrGrim]

How about we keep the pressure on asking for basic multi threading before we get into the weeds of GPU computing? This is one of the few games keeping me on quad core parts for the few hundred extra Mhz.

As for a 3d factorio, that'd be pretty damn sweet, but I think low priority at this stage really.. maybe multi threading instead?

[MeduSalem]

How about we keep the pressure on asking for basic multi threading before we get into the weeds of GPU computing? This is one of the few games keeping me on quad core parts for the few hundred extra Mhz.

As for a 3d factorio, that'd be pretty damn sweet, but I think low priority at this stage really.. maybe multi threading instead?

Doesn't the game use multicore processors already? I am pretty sure there is even a setting in the options menu exactly for that, or ist that one just gimmicky?

[bobingabout]

I can't help but noticed that one of the primary arguments is flawed. 3D takes less memory than 2D? what? NO!!! 3D would take far more memory! For starters, what we have as a sprite now would require a 3D model and a skin, on multiple surfaces. The only cases where the sprites take more memory are those like the biter animations that have multiple angles with several sprites for an animation per angle.

The reason 2D in this case takes insane amounts of memory is because... Everything is loaded into memory, and used exclusively from there!

This is actually a mechanic of most modern sprite graphic libraries. if you go back to older games like Red Alert 2, they also used quite a lot of sprites, but if you place a structure as an example, that you haven't placed before in that session, the game pauses briefly and the CD-ROM spins up as it loads the graphics for that object. That pause is one reason why modern graphics engines also load the image first. it also depends on how you program your interfaces to the graphics engine, it's perfectly viable that a change in the way the game is programmed would use less video memory, but to do that it would have to constantly load and unload graphics as and when they were needed. Of course, if you actually have 1 of everything on screen at the same time, you need all graphics loaded at the same time, and the issue has the same result, and with a game like factorio, having everything on screen at the same time is perfectly possible.

[Sean Mirrsen]

However, everything being said, I can only wonder how neat it would have been to see Factorio in the graphics style and complexity of, say Total Annihilation. The game you see on the screen is entirely sprites, however every unit and structure in the game is stored and scripted/animated as 3D models, which are rendered into sheets on-the-fly as the units move, turn, animate, and interact.

It would certainly make adding new content to the game easier, at least.

[ssilk]

I thought a while on this.

I would mean the following way would be the way, Factorio might go, cause it already works more or less like so for Reason from Propellerheads:

- Factorio is equipped with a service for a full 3D-renderer.
- Someone (at first only the internal artists) can send the 3D-modells, entity-description and instructions for postprocessing to this renderer and the graphic returns.
- This can be done not only offline (Modder sends models and saves the returned graphics in his mod),
- but also online in real-time (mod includes only the 3D-models and the graphics is stored at the players computer only).
- The advantage is then, that the graphics are only rendered in the deep resolutions (when fully zoomed in), if really needed.

The logical next step would then be, that the renderer is inside Factorio binary.
O.K., I mean that might be an long term target.

And if the postprocessing is included it would make things much easier than now, cause everything can be re-rendered into a bit different graphic style. More contrast for example - or think to the problem with the colorblinds... (viewtopic.php?f=80&t=22760)
So the internal graphics-development would be easier in general.

But having real 3D-graphics in the current Factorio for most (not all) graphics? Hm. I think from now on about 5-10 years and then it is possible, cause then we have the hardware to an affordable price.