Sansha said:
I'm actually curious about this myself; what differentiates pre-rendered to real-time animations?
minimacker said:
Honestly, I don't know what I talking about at the time. I think I was trying to differentiate, say, the destruction of a building with visible falling pieces from a programmed "sink into the ground" like we've seen in the pre-release videos except in AI form. I guess the best word I could use is a "dynamic AI".
The AI seems to take the shortest route, which makes me wonder if they react to things. They don't seem to take detours if there's a pileup ahead. Neither do they change course until it's too late. From what I saw from Node's LAN Party pre-release of the game, they have a very poor pathfinding. Which means this shouldn't be as taxing on the CPU as you mentioned in your first post.
Pre-rendered means just that, the animations are rendered out in some small movie clip format and played back on some 2D sprite. That's what's done in the previous SimCities when representing things like traffic congestion on a road.
You're thinking dynamic behaviour from physics vs. playing back keyframed/canned animations, but even then, the game's graphics engine has to process and render it out.
The sim objects in SimCity are not sprites, but full 3D models, and even at the low poly they are, they are still rendered in real-time. Meaning the computer has to calculate what frame of animation it is in, interpolate to the next keyframe, depending on how fast you're playing the game at, deform the mesh based on the bone placement and weight of the mesh vertices. Then render the deformed mesh to the screen. The game obviously uses multiple materials for different skin colours to make the sims unique looking (somewhat), then add in lightning and shadows. You're looking at a different draw call per sim, maybe 2 if you count shadows. This adds up the more sims (cars or people) you have on screen. It can't be pre-rendered because the graphics engine has no idea what distance and angle the camera will be looking at the 3D model.
Even on pathfinding, it's not just pathfinding for one sim, but all the sims who have to recalculate their route if there's a blockage somewhere, or a route gets destroyed or created, or a new desire has popped up, etc. etc. These things add up.
And there's more to a game and rendering engine than just pathfinding and physics that can affect the performance load.
I don't play Dwarf Fortress so I can't tell you how "fast" it's simulation runs at (how many updates or ticks it runs per second). But for comparison, even if updates in SimCity are handled once a second, it is still rendering things out in 3D at say, 30fps. A sim might not change it's goal from time=0:00 to time=0:01, but in that second it still has to draw it to the screen 30 times (assuming he's on the screen). Sure, the sim might only be 10 pixels tall, but what if there's 100 of them? 200? 500?
Buildings are also dynamic, since we have no prior knowledge of where it's placement would be. Even though it is static in the world, it might be playing animations and is still being hit by light that changes over the course of the day and night cycle. And depending on your graphics quality, it would also be casting shadows to the other buildings around it. Ask any graphics programmer and they will most likely say lighting is the #1 expensive call in any engine. Even if there's only one light from the sun. But there's multiple light sources in SimCity, as at night, you get street and building lights glowing in the skyline, casting light onto the ground.
And again, each building is its own draw call. Even simplifying the material costs and sticking with just a diffuse, removing the need for specular and normal maps, given the scale of the visuals. And no need for baked shadow maps, since light is dynamic. You're still talking about rendering hundreds of buildings that could be being built or demolished, playing animations, from small trailer parks to big condo high rises. Again, it adds up.
I don't know how SimCity handles it's occlusion, where larger buildings up close to the camera could block smaller buildings in the distance from being rendered. It's important in say, first person shooter games to only draw what's visible to the camera/player eyes to maintain a fast framerate, but calculating what is and isn't visible could be taxing with all the boundary checks. Given the scale of the game's environments though, I wouldn't be surprised if there's little occlusion being done, so if you're viewing the city from sim level as if you were really there, it might render the whole city out. It could be more taxing to calculate every building's visibility in relation to every other, due to the sheer amount, than to merely render it all out and have closer objects to the camera overlap the distant ones. I'll have to look more into it when it's released.
And of course any post-processing stuff like anti-aliasing, tilt-shift, depth of field, filters, etc., as well as what resolution you're playing at.
That's just graphics. There's also the underlying simulation data being played.
What the sims are doing, what the buildings are doing, what the agents for power, sewage, water, transit, etc., and where. Then also sending that data to the server farm to update the other cities, and getting updates from them, to factor into yours. Which buildings have a lot of garbage and have to flag a dump truck to pick it up. How much coal is being mined out and transported to neighboring cities, or to the worldwide market place.
There's a series of videos [https://www.youtube.com/watch?v=dtr44vtCKWk] describing the sim system. It's from an older build from last year, but the underlying principles probably hasn't changed. And of course, the larger the city and its population, the more agents are flying around interacting with each other.
From my understanding, the game does make use of multicore CPUs, however it's limited to one CPU per task, so that's one core for the sim mode, another for handling the graphics, and others for sound and such. So in that case, a faster dual core is probably better than a slower quad-core.
I can't say it's more or less complex compared to DF since I don't play it, but it's probably comparable in different ways. Games often make use of various tricks to improve performance that might not apply to a game design like this one, so it in essence might have to brute force it sometimes. There's a ton of stuff going on that we're not aware of, and all these things add up that impacts performance.
