raidho36 wrote:Also, this game doesn't actually uses oblique projection, it uses regular axonometric orthogonal projection, hence objects are vertically shorter than horizontally. It's just the grid is rectangular, which as you know, causes a lot of issues due to that mismatch.
Factorio tries to use an oblique projection. In axonometric projections (which oblique projections are a special case of) objects always become vertically shorter than horizontally due to foreshortening, but the amount is relative. If the projection an object casts is longer or shorter depends on the angle at which the observer looks down at the XY plane (in this case) and the thereby caused foreshortening of values in Z-axis.
But this happens additionally to the depth objects have in X-axis which also happens to fall into the same axis as the Z-axis lies in the special case of top-down oblique projections, which is the fundamental reason for why it looks that weird. It's basically converging from one orthographic projection (top-down/plan) to the other (front/elevation).
Long story short... The effect of things becoming shorter/longer is the summed up effect of X-depth + Z-foreshortening * Z-height, while Y-width remains as it is, which looks weird in certain situations, especially when converging from one extreme to the other (meaning X-depth becoming Y-width and vice versa).
With other words: Don't use this special case of projection and rather have one where the Zf*Zh influence is equally distrubed between both the X and Y axis!
So... for almost all objects in Factorio the devs choose to have a view point angle resulting in a corresponding Z-foreshortening value that feels okay for the most part, since these objects never change their XY orientation.
But for trains the fundamental flaw of this special projection becomes obvious because they felt that even with the foreshortening value that feels allright for everything that is "static" the trains on the other hand change their shape too much when transforming from horizontal to vertical movement (X becomes Y and vice versa = weird situation desrcibed above) and no matter the amount of fiddling with the Z-foreshortening it can't be solved.
So what they did there instead is a cheat with something or a combination of the following:
- They used another view point angle for train sprites than for all other objects, one that results in even more Z-foreshortening, uncoupling the sprite from the XY plane all other objects lie in
- Compressing the actual length of the original object in X-depth before applying the actual projection (which is my bet)
Both of which would cause the mismatch with the grid for the sake of "aesthetic" appeal. So trains are the ones using a bastard-projection defying all rules, as if Top-Down Oblique wouldn't be already ugly enough. For me the projection the trains are using is the Ramsay Bolton of Factorio. *shudder*
That said I have to give the devs a lot of credit that they had the endurance to stand through these train related problems attached to the projection they chose. I would have probably fundamentally changed the projection to military or isometric/dimetric and re-rendered the sprites a long time ago just because I can't stand the thought of the "unclean" workarounds necessary.
Which is why I am already curious how the "fixed" solution will look like with 0.13
Shokubai wrote:This is not easy to quantify in terms of performance.
Sprites will use less(if any) GPU capability while Polygons will use most. You are adding a layer of hardware requirement. The additional work mentioned above is not really additional so much as using idle capability. It's like your GPU has 10 arms. Right now it's using like two(granted heavily). 3D polygons may use all 10 but the work will be distributed more efficiently.
Most modern GPU will handle millions of polygons easily. In a world like factory where polygon counts would likely be low per object due to the lack of object complexity, I could actually see the existing game in 3D as a performance boost on my own rig.
I am no GPU expert and don't claim to be, but since the unified shader stuff aren't shaders using basically the same functional units within the GPU to do everything? Wouldn't that mean if you start calculating polygons as intermediate step you take away possible hardware resources to do pixel calculation (which are probably necessary for textures or sprites), meaning that there actually is no real "idle" capability, just how you spend these units among geometry/vertex/pixel shaders?
But that set apart I still wouldn't like it if Factorio starts clogging the GPU with 80-90% workload due to polygons when a similar appealing game using sprites only uses like 30-40% of the GPU. It wears hardware off a lot faster.
For 3D shooters 90% workload on the GPU might be fine because I am only playing stuff like Doom for a couple of hours before shelving it, but running Factorio with 90% workload for 1000 hours and more the GPU fan bearing wouldn't be that happy, neither would be the circuitry with these 90°C grills nowadays... and I lost several graphic cards already that way back in the golden days. Last time with Crysis on my GTX 570 which were notoriously hot... it overheated just for a fraction of a second and it never really recovered from there on (though it took almost 2 more years to finally die off because of the damage done to the circuitry). One tiny fluctuation in air flow and your GPU spills out rainbow colors all over the screen for the rest of its life. Not worth it.
And fun part is... I am now back to a GTS 250 which is just fine for Factorio, probably because it is only using sprites. Probably wouldn't be able to do that if it was 3D based with polygons.