The more I downloaded things for the game, the more I noticed similar things at different scales.

Reading up in the forums suggests that no-one really knows what to do about scaling because the game intrinsically mixes scales.

Here is my take, and why I wont scale my game objects.

Why bother?

The need for this article arose for me because as a producer of mods for the game, notably of automata (i.e. moving objects) like trains and trams, I struck the question of what scale to produce things at relative to the real world and so as to fit in the SC4 game world. I intuitively made them to real world scale, but noticed that they sometimes looked a little small or strange in the game relative to buildings they passed by. This led me to look into the question of “What was the correct scaling?”.

I soon found that this was a difficult question to answer as the forums at SC4D were full of references of orthogonal projection, high viewing angles, distortions and proportionality, and elaborate scaling schemes and a lot of vague discussion on the right thing to do, but very little in the way of facts to back up their arguments for and against. It is distinctly possible that everyone is right and/or wrong in some way as I will attempt to show.

But more than anything, this fantastically vague comment in the BAT (a tool for producing models) Help file really got me going. “Because of the camera angle (line of sight) we have found that we need to exaggerate the heights of buildings vertically in order for them to appear plausible in the SC world. So if you want to make a house with an average 8 foot ceiling, your walls would want to actually be 4 meters high in the gmax environment in order to simulate this. The footprints along x and y should be true scale though. In other words, cheat your buildings a bit taller.”

A bit taller indeed. What does “appear plausible” mean? Why should I have to mangle a projection by amending proportions by ScaleX = 1, Scale Y = 1, Scale Z = 1.514? Was it chosen in error and this was discovered too late to change, or is this a throwaway? It reminds me of an old Monty Python sketch…

I will argue that we should not modify the projection (i.e. rescale) except under very strict conditions, and I will discuss this further on. Considering how important it is to maintain a consistent scheme of things in a game (and I seriously doubt the production team at Maxis allowed “laissez faire” in its teams) why would this “guideline” come about and why is not enforced consistently by all – both by Maxis in its game pieces and by modders in their pieces?

ASIDE: The net effect (of this vagueness) is that a downloader cannot know what scale rules have been applied in the model being downloaded and one has to rely on a feel of whether it’s right or not. This is too hit and miss, and not a sign of quality. At a minimum modders owe us to state the X:Y:Z scales they used (relative to real world dimensions) so that we as consumers of their productions can choose whether to use them (or not).


The SimCity Projection:

is classified as an orthogonal, parallel, axonometric, trimetric (three measures literally) projection. That is,

  • it is not a perspective true projection,
  • but all parallel lines remain parallel and
  • ratio (proportion) is preserved.
  • You can measure relationships on it.
  • It does distort the representation in a linear and particular way and this causes foreshortening of all three dimensions in differing amounts.
  • There is no additional distortion with distance from view, things just scale screen coordinates
  • The closer something is viewed the more it looks different from expectations of perspective. i.e. it doesn’t distort as perspective would.
  • It is tile-able in 3 dimensions and this is why it is used. All game elements can in theory be pre-prepared thus speeding rendering up (an entirely different topic)

I have seen propositions in the forums that argue “it (object x) did not look proportionate” and the like “so I scaled it up a bit”. This, like the BAT Help comment above, is bunkum in the context of the projection. It preserves proportion. A door in the middle of a wall will be that way however it is viewed. If you manually rescale outside the projection weirdness can ensue.

I have a real problem imagining a bus-stop with a roof 5 or 6 m from the ground because it didn’t look proportionate. To what? – and we will return to this later on, because the “damage” was done far earlier by Maxis.

The issues with projection are caused by the optical effects (scaling) of the projection which is different from 3-point perspective (but not a lot mind you), and other visual furphies conjured up by the brain which has conceptions of its own. However perspective projections also have distortions which we don’t seem to react to in the same way.

Here is a formal definition of the projection. A trimetric projection is a 3D axonometric projection where no two axes are equal, and three different foreshortened scales are required. It is defined by two exposure angles D and E as in the diagram.

Projection example

Exposure angles D and E (D+E < 90) result in trimetric angles B=D+90, C=E+90 and A=180-(D+E)

In SimCity (at high zooms) we are viewing the cube from an elevation of 45 degrees, and an azimuth of 67.5 degrees (from x axis). The trimetric projection is equivalent to the perspective view at infinity. Z is UP.

The angles D and E are related to Azimuth (Az) and Elevation (El) by
Tan D = cos(El) / tan(Az) and Tan E = cos(El)* tan(Az)

This gives D = 16.32495 deg and E = 59.63881 deg. Hence B=106.32495, C=149.63881, A = 104.06324

Texture example

If you look at this BAT texture for the highest resolution (xxxxx4x0) in Reader these are the angles (D, E) the render makes with Horizontal.

ASIDE: as Simfox showed, lighting is at right angles from the left making vertical lines give horizontal shadows

We can now calculate the scales of foreshortening factors for each dimension. These are given by the relations
Fx = sin(Az)/cos(D),
Fy = cos(Az)/cos(E),
Fz = sin(El) where 0<Fx,Fy,Fz<1 , Fx*Fx + Fy*Fy + Fz*Fz = 2

So in this SimCity projection the foreshortening scales (see aside below for how they are used) are Fx = 0.96269, Fy = 0.75712, and Fz = 0.70711

Projection coordinates are given by:
X proj = (X.Fx.cos(D) – Y.Fy.cos(E))/Range
Y proj = (X.Fx.Sin(D) + Y.Fy.Sin(E) + Z.Fz)/Range
Where X,Y,Z are distances of a vertex from the origin
And Range = sqrt( (Xcam-X)^2 + (Ycam-Y)^2 + (Zcam-Z)^2 )
And Xproj, Yproj are resulting distances from centre of projection
and LHxyz z=up.

In BAT/gmax Range=190m for all rendering. (default rig)

Note that Fx.cos(D), Fy.Cos(E), Fx.sin(D), Fy.Sin(E), Fz are all constants and are the resultant projection scalars.

So at face value viewing something across the front is about what you would expect, down the side shortened and in height shortened. Just as above. So a 16 x 16 x 16 cube will appear to look a lot like a 16 x 12 x 11 cube when projected. But even if it were in a perspective projection it would look like this. We don’t have a problem with perspective, so why this projection?

It’s just that we are not accustomed to looking at buildings in this way. We usually view them from eye height, and much closer. Day to day objects at equivalently scaled distances look fine. A Rubik’s cube of side 56mm when viewed from 6.65m away has the same scale as a 16m cube viewed from 190m away. (try it)

And so this is where the fun and games started. At distance we don’t mind these proportions at all (they are like perspective) but up close and personal our brains become wayward and so this (inclination to the) notion of rescaling height arises.

And, while we are at it, why not rescale Y? Presumably we don’t feel inclined because we don’t care much about something receding from our view. Having a shortened height scale actually helps to see very tall buildings as a whole and I think it was a deliberate design choice. A lower elevation might have been more natural but it would mean less vertical screen coverage.

However, all up, the projection looks a little flattened but otherwise proportional and one easily gets used to it so I therefore hold that we should not rescale for reasons of the projection at all.

Zooming in and out is not quite what it seems.

The projection is zoom-able, that is, we can view from varying points of view. They differ in apparent range, although the rendering is done by scaling (an optical equivalent). Here another surprise exists. The perspectives of the zooms are not all the same. There are 6 zoom levels and here are the corresponding projections. I’ve called them 1 (most distant) to 6 (closest)

Az123456 67.5 deg Range 190 m      
ViewPoint m,deg D deg E deg Fx Fy Fz
El 456 45 deg 16.32495 59.63881 0.96269 0.75712 0.70711
El 3 50 deg 14.90920 57.20219 0.95607 0.70648 0.76604
El 2 55 deg 13.36473 54.16472 0.94960 0.65365 0.81915
El 1 60 deg 11.70092 50.36073 0.94349 0.59986 0.86603

The highest 3 zooms are the same, and as we zoom further out, we rise relative to the scene, giving us a better overview. This means that buildings look different depending on at which zoom we view them, but also that they are not just a downscaling of higher zooms. (You can’t just scale a 128x128 texture for a 4xx model, to a 32x32 texture for a 2xx model for instance, because the perspective also changes).

Note too that the Height scale becomes relatively LESS foreshortened the more we zoom out. Now the effect of varying perspectives is not readily obvious because the buildings are also getting smaller as we zoom out. I used gmax to scale up the smaller zoom levels to show the effect. Here follow the real sizes of the texture of a 16x16x16 cube straddling the origin, above the real texture, below the scaled up version of the texture with zoom. (I also maximized horizontal resolution)

Zoom Boxes1


Zoom Boxes2


All of this means that if you rescale outside the projection you will have to consider the effects at all zooms – and compensate independently for all of them. What’s more it might look good in say zoom3 but not in 4 etc. etc. This is where the many interpretations of what to scale by come from in my opinion, different people review their buildings for look and feel at different zooms and then the game does the rest.

Better yet, don’t rescale at all, and everything will be fine. The resolution of screen you review in has no effect in the projection, just more or less pixels are used to show the equivalent scene.


What is the smallest object representable at each zoom?

The gmax scripts say zoom should be Z1=8x, Z2=16x, Z3=32x, Z4=73x and Z5=146x. These are rendered using a Range of 190m by varying the field of view not the distance. Z6 which shows up in the game is Z5*2 (I think) or 292x, produced by stretching the Z5 texture. It therefore cannot contain more detail than Zoom 5 – just larger detail. If a larger texture (without exceeding 256x256) can be forced for Z5 then you can improve the Z6 look a lot.

I would like to discuss the concept of the smallest representable object at a given zoom. Just how big is the 3D object contained in one pixel of texture? Anything smaller that this cannot directly be represented (only implied).

This is another cause of arbitrary rescaling (in order to produce the best possible wow effect by fitting in more realism) and also produces some ridiculously oversized objects. Problems rapidly arise with thin objects like wires, and if anti-aliasing (which can allow implying smaller objects than can be drawn) is not used the result is blocky, out of scale objects, sometimes compounded by poor colour choice.

We should expect details to merge into the background as we zoom out, and arise as we zoom in. But also we should only see plausible details considering the restrictions of the resolution of the game. If it’s too small to fit we will just have to imagine them (and we can) – don’t try to jam them in, or live with the fact that they will be blurry.

ASIDE: look closely at Zoom6 - buildings vary in their blurriness because of the underlying texture quality they are made of.

I don’t think anyone has explored this aspect of representation and it is limited by the game design. It does offer another view of – what is reasonable?

The largest single texture produced for a render is 256x256 pixels although it is seldom all used. When a render result is larger textures are tiled and more than one texture is produced. BAT leaves a margin around the texture limiting full use of the texture space available. This shows up most with tall, long or wide very thin objects – like traffic poles or rail catenaries. The resulting textures are very small and end up very stretched in zoom 6.

ASIDE: A gmax/BAT script variable exists that can be tweaked is called viewportSlop. It is 8m around an object by default. This becomes the border space. Care needs to be taken in varying this variable as truncation of textures can result if it’s too small. I did the cubes above with viewportSlop= 0.5m.

The following table is my calculation of smallest representable object. Note that for flat tiles (eg. Rail, Road etc the implied scale = 128pixels = 16m or 1 pixel=1/8m= 125mm) (or slightly larger than two Rubik’s cubes!!!)
[Please feel free to verify this table – I’m putting forward my best guess]

Level Zoom x Rel Range Equiv Range m Pixel in m
Z1 8 18.25 444.00 1.734
Z2 16 9.125 229.00 0.895
Z3 32 4.5625 117.30 0.458
Z4 73 2 52.20 0.204
Z5 146 1 26.10 0.102
Z6* 292 0.5 13.05 0.102


Z6 is made by the game using Z5 textures and so cannot have more detail than z5. Thus these textures are marginally more expressive (sharper) than the flat tiles. We should also note though that scaling onto the screen will probably REDUCE the available resolution, since most textures will be down-sampled during rendering (i.e. smaller),. This evens things up.

As an example let’s say we can see some flowers in a window box on a house at the highest zoom. How big do the flowers need to be to be rendered. At what zoom should I not be able to see them.? By the above table should I be able to see house bricks at Z3? This also holds for other things.

Perhaps some experienced BATter can share their experience on this.


Are there circumstances where we should rescale?

Maxis clearly found reasons for rescaling objects. I list a number (and I’m sure not exhaustive) of reasons why we might tweak scales.

  1. Game Play - To me it appears that many Civic buildings were tweaked so that we can easily find them when editing/reviewing a city. Blow them up a bit in size and they are more easily spotted. Some of them were designed to be relatively huge compared to their function too. Same goes for monorail, elevated rail stations and the like. That el-rail is at 15.5m is acceptably plausible, but should the station also be 15-20m taller? Overpasses in real life (e.g. rail-bridge over road) are also closer to 8m than 15m (in fact many have clearances of only 4.5m). My point here is that it doesn’t actually matter as long as it is done very consistently.
  2. Artistic Effect – nice effects deserve to be noticed – the trains are too large to fit into the tunnel entrances but at least you can see them, the smoke from the steam train is crazy. I hold these to be less desirable as they actually pall after a while.
  3. Emphasis/Focus - Each zoom level seems to naturally lead to different focus. Taking level 3 to be area view, level 4 is more local, and so on. The highest zoom is where Sims are most relevant and point of focus and where rescaling shows up to be worst. How tall is a Sim? – I don’t know – but at this level should Sims be able to fit in a door? on a tram? be able to reach the roof of a bus-stop? or is it all actually irrelevant. I think yes to the above, and if Sims are 3.5m tall we are stuck with it.

So how do we deal with this? Has anyone surveyed this and, if so, can they share their findings please? Considering this aspect is probably the most fruitful for unification of the rescale arguments. It depends on what you are looking for – at what zoom, that determines if something looks too big/small etc. It may well be that at highest zoom we should actually not tweak, but at say zoom 3 we should. I’d like to see discussion on this one.


In summary

I have argued that on the grounds of projection we should not rescale, and this is but one view. If we are to increase SC world realism (and the majority of Modders seem to be aiming for this by introducing more world objects into the game) then we should adhere to the real world scales and represent them consistently. It is interesting that automata are generally not scaled, but buildings often are.

If on the other hand it’s all about the game – maybe we should determine clear rules by which scaling can be applied, so that those of us affected aesthetically by a mix of scales can be happy. This might be by zoom-level for various different reasons.

I, in any case, will not rescale objects I create, but I do look forward to a little discussion,

rivit (Ron) 21 Mar 2009