Possible game camera methods and optimisations *spawn

[Christer Ericson]

Mod: This thread spawned from the GOW3 game thread. The nature of game camera's is a worthwhile debate but not one for the game thread.

Is it even fair to compare UC2 and GoW3, especially considering GoW is a game that always controls what you see (fixed camera)?

FYI, the camera is NOT fixed. It is highly scripted to provide a highly cinematic play experience, yes, but in no meaning of the word is the camera fixed! Within the setup cinematic parameters there is a LOT of room for the camera to adjust (zooming, panning, etc) to the action that happens on the screen (where the player is, where the enemies are, etc). Because of the amount of adjustments the camera system can make automatically, there are very few assumptions that can be made about what to render or not render.

Not only has the camera system in GoW been described in detail at a lecture at GDC in the past, but if you paid attention during game play, it would be apparent that the camera does have several degrees of freedom outside of its scripted nature.

We could easily allow the user full control of the camera during game play. The reason we do not is because we feel it breaks the cinematic experience that we have carefully crafted, not because there is some geometry missing if you turn around (as you imply).

 

[SG79]

Could potentially break the flow and open a can of worms of complaints. It's the one area where Team Ninja consistently shot themselves in the foot by providing a completely controllable camera system. Ironically, the one game in the modern series not to suffer any camera woes was the DS game because of the pre-rendered backgrounds.

 

[ultragpu]

Sorry, Dude! I didn't mean to be rude :smile:! I was just thinking that its realtime GI u were talking about as you posted a very dynamic shot of Kratos in mid air over the Horse. When the concept came down to baked GI, I felt let down. Thats all !

Anyways the shot u posted above shows more of Post processing and bloom than GI on and OFF to me. Maybe I am watching this on a tiny Ipod Touch screen is the reason I can't see it, but , seriously I can't see any bounced light in that shot either.

No need to be sorry dude, we're only discussing after all and I'm glad to be corrected so that I can differentiate them better. Maybe it's the nature of youtube vid anywau not showing enough IQ, I'll wait for the final game to have another look.

FYI, the camera is NOT fixed. It is highly scripted to provide a highly cinematic play experience, yes, but in no meaning of the word is the camera fixed! Within the setup cinematic parameters there is a LOT of room for the camera to adjust (zooming, panning, etc) to the action that happens on the screen (where the player is, where the enemies are, etc). Because of the amount of adjustments the camera system can make automatically, there are very few assumptions that can be made about what to render or not render.

Not only has the camera system in GoW been described in detail at a lecture at GDC in the past, but if you paid attention during game play, it would be apparent that the camera does have several degrees of freedom outside of its scripted nature.

We could easily allow the user full control of the camera during game play. The reason we do not is because we feel it breaks the cinematic experience that we have carefully crafted, not because there is some geometry missing if you turn around (as you imply).

Thanks for clearing that up for us mate, that's exactly what I was thinking from my previous post on that note. Also I would still love to be able to view the titans in multiple angles just to appreciate the beauty if given the chance, like pressing R3 for a free FPS view.

 

[Turok]

FYI, the camera is NOT fixed. It is highly scripted to provide a highly cinematic play experience, yes, but in no meaning of the word is the camera fixed! Within the setup cinematic parameters there is a LOT of room for the camera to adjust (zooming, panning, etc) to the action that happens on the screen (where the player is, where the enemies are, etc). Because of the amount of adjustments the camera system can make automatically, there are very few assumptions that can be made about what to render or not render.

Not only has the camera system in GoW been described in detail at a lecture at GDC in the past, but if you paid attention during game play, it would be apparent that the camera does have several degrees of freedom outside of its scripted nature.

We could easily allow the user full control of the camera during game play. The reason we do not is because we feel it breaks the cinematic experience that we have carefully crafted, not because there is some geometry missing if you turn around (as you imply).

Ah, sorry about that. Twas just an ill-informed assumption on my part.

 

[phat]

A camera on rails affords nearly as many shortcuts as one that's fixed. I am certain that GOW3 doesn't have any fancy realtime AO or GI simply because with a scripted camera those things can be pre-computed and scripted too. Even the occlusion culling and texture streaming can be pre-computed and scripted.

GOW3 really can't be compared, in terms of pushing the technical envelope, against UC2 because of the latter's free camera.

 

[ShadowRunner]

A camera on rails affords nearly as many shortcuts as one that's fixed. I am certain that GOW3 doesn't have any fancy realtime AO or GI simply because with a scripted camera those things can be pre-computed and scripted too. Even the occlusion culling and texture streaming can be pre-computed and scripted.

GOW3 really can't be compared, in terms of pushing the technical envelope, against UC2 because of the latter's free camera.

Why not, if a design descision was made that allows a graphical advantage without sacrifice to gameplay then that decision should be applauded and credit given where its due. All games can be compared in terms of pushing the technical envelope.

 

[T.B.]

GOW3 really can't be compared, in terms of pushing the technical envelope, against UC2 because of the latter's free camera.

You did read Christer's comment, did you?

 

[phat]

Yes, my post was in response to Christer's comment, which I find a bit disingenuous.

 

[tha_con]

Yes, my post was in response to Christer's comment, which I find a bit disingenuous.

Why? Everything he said was true. "Scripted" means it follows on a set path while the character is in motion, however, the game has dynamic camera angles that adjust based on the actions of the character. There is no way for them to predict what will and will not be rendered, because the person could pull off a certain QTE that would change the way the camera moves, etc.

It's not like he told us we have full control when we don't, or that he said it isn't "on rails". What about his post was disingenuous, aside from the fact that he didn't poo poo on a high profile title like most of B3D? (Granted, he's working on the game, but still).

I don't understand why you guy's don't leave this BS in the technical discussion forums and just talk about the damn games here, it's irritating at times because you're so freaking fickle and picky about it. Get over it.

 

[phat]

I felt that Christer was exaggerating the generality of the camera. A camera on branching glide paths isn't significantly more general than a camera on a non-branching glide path, and still far, far less general than the free camera of most other graphics engines.

If he wanted to convince folks that the graphics engine is actually much more general than the game design needs/uses, he should acknowledge that the on-rails camera does give them a lot of simplifying shortcuts but that they chose not to take any of them to keep the engine general, rather than implying there aren't any shortcuts to be taken.

 

[ShadowRunner]

Why? Everything he said was true. "Scripted" means it follows on a set path while the character is in motion, however, the game has dynamic camera angles that adjust based on the actions of the character. There is no way for them to predict what will and will not be rendered, because the person could pull off a certain QTE that would change the way the camera moves, etc.

It's not like he told us we have full control when we don't, or that he said it isn't "on rails". What about his post was disingenuous, aside from the fact that he didn't poo poo on a high profile title like most of B3D? (Granted, he's working on the game, but still).

I don't understand why you guy's don't leave this BS in the technical discussion forums and just talk about the damn games here, it's irritating at times because you're so freaking fickle and picky about it. Get over it.

The technical slant on things is what makes this place my forum of choice. Its a valid point that the camera, though not fixed, certainly has inherent advantages with regards to graphics, and there is no need to be upset about discussing it. I would be suprised if the developers are not taking advantage of the cameras degree of predictability, for instance i would expect the level to be built so that only things that the camera will ever see will be modeled so while the camera could be made freeroaming a lot more work would need to be done on the levels themselves. All games do this including FPS/TPSs, no need to model the back of a building if you will never actually see it, but having a camera like GOWs should mean the amount the camera can possibly see is reduced.

On the other hand though the camera in GOW being pulled back to show huge scale means it is at dissadvantage in some respects over a FPS/TPSs which tend to have environments that take advantage of the fact that the camera is always at eye level.

 

[Christer Ericson]

I felt that Christer was exaggerating the generality of the camera. A camera on branching glide paths isn't significantly more general than a camera on a non-branching glide path, and still far, far less general than the free camera of most other graphics engines.

If he wanted to convince folks that the graphics engine is actually much more general than the game design needs/uses, he should acknowledge that the on-rails camera does give them a lot of simplifying shortcuts but that they chose not to take any of them to keep the engine general, rather than implying there aren't any shortcuts to be taken.

Since you are a hotshot armchair graphics engineer, let's turn it around, and You tell Me exactly what these optimizations are that we can do with the camera system in GoW3 that you can't do in a game where the user has full control over the camera at all times. It should be easy for you to put the money where your mouth is and simply prove me "disingenuous" rather than spouting what, from where I'm sitting, is nonsense claims on your part.

You're the one claiming stuff, I call bull on it, and so now you prove it!

This should be fun.

 

[JPT]

You're the one claiming stuff, I call bull on it, and so now you prove it!

This should be fun.

/me gets the popcorn....

 

[London Geezer]

To add to the comparison with Uncharted 2, i'd like to refresh everyone's memory. Without taking anything away from what i consider the best looking game i've seen in my life, on top of being one of the best experiences too.
I've played it very recently (ie i finished it a few days ago and still play the off level here and there) and i can tell you that although you can in fact move the camera to various degrees, there are limitations:
First of all, there are in fact some sections where you cannot move the camera AT ALL.
Secondly, in the area where you can move the camera 360 degrees, i wouldn't consider the camera 'completely free'. Far from it. It is still very much bound by certain limits. The most important being that Nathan is always at the center, it's not like you can point the camera wherever you want at all times. Even i can see how those limits could 'help' ND cut some corners, if they wanted to.
It is also a very clever camera system: just yesterday i was playing around with it and trying to point the camera in a way so that i could see Helena (is that her name?) from up close (as in turn around so that she would be in the path between the camera and Nathan). Imagine my surprise when i noticed that the sneaky little thing would turn around in a hundred ways to avoid letting me see a very blurry Helena for more than a fraction of a second.

Morale of the story, even a camera which you can turn 360 degrees on the same axis is very much limited. And quite rightly so! Do we really want a camera you can point at a wall to see how detailed the texture is (just to post about it on internet forums) in a game like GOW, or any other action game? Just play the bloody game and enjoy the experience it provides you!

 

[patsu]

It is also a very clever camera system: just yesterday i was playing around with it and trying to point the camera in a way so that i could see Helena (is that her name?) from up close (as in turn around so that she would be in the path between the camera and Nathan). Imagine my surprise when i noticed that the sneaky little thing would turn around in a hundred ways to avoid letting me see a very blurry Helena for more than a fraction of a second.

I like that trick ! Makes Elena feels real. ^_^



I read long ago that the GoW1 and 2 developers made the games such that the level designers have much control of the engine behaviour, so that the engineers don't have to change their game code too frequently to chase the designers' visions.

Perhaps the camera is one that can be positioned "freely" (in real time) by the designers even though in the final game it may be locked for cinematic effect.

 

[phat]

Since you are a hotshot armchair graphics engineer, let's turn it around, and You tell Me exactly what these optimizations are that we can do with the camera system in GoW3 that you can't do in a game where the user has full control over the camera at all times. It should be easy for you to put the money where your mouth is and simply prove me "disingenuous" rather than spouting what, from where I'm sitting, is nonsense claims on your part.

You're the one claiming stuff, I call bull on it, and so now you prove it!

This should be fun.

For starters, because you [the programmer] have control over the glide path of the camera, you can greatly control the amount of vertex and texture data the engine has to manage. Since the amount of data needed for a surface is inversely proportional to the square of the camera's distance to that surface, the fact that a camera on a glide path only ever gets close to a very few surfaces of your choosing affords huge savings.

When compiling a level from the master art assets to the on-target representation, the pre-determined camera paths can be used to pre-compute the MIPMAP and LOD ranges for all surfaces in the level so that texture and vertex data outside those ranges can be eliminated from the on-target build.

If you need streaming for your levels, a camera constrained to a glide path makes this a one-dimensional problem. All resources can be thrown at streaming along the trajectory of the camera's linear path. Even if there are branches in places, the problem is still piece-wise one dimensional.

In the extreme, you can treat your level as a branching/reversible cinematic, with the position of the camera along its glide path being your point in time.

A constrained camera also allows you to minimize/hide artifacts with a naive shadow buffer implementation. In other words, you can get good looking shadows without having to be extra clever.

 

[Christer Ericson]

For starters, because you [the programmer] have control over the glide path of the camera [blah blah blah]

Brilliant stuff. Except the fundamental assumption you made about the existence of some sort of "glide path of the camera", that the remainder of your post rested on. There is no "glide path of the camera" in any God of War game. Your assumptions of how the camera works may (may!) have held true for, say, Panzer Dragoon 15 years ago, but it just isn't how the camera works in GoW3.

There are paths, but not for the camera but for the equivalent to a "camera dolly" (in film terms). Continuing the film analog, one could say that our game camera is mounted on the dolly arm and can move both in and out, can pan, tilt, and zoom, etc. (In actuality, our camera is more sophisticated than a dolly cam and can do things no physical camera could do.) Which of these movements the camera makes is dependent on parameters that our camera designers have carefully set, but ultimately on the location of the player and the enemies on screen. This decision is made at run-time, not tool-time. I repeat: for every game frame, we determine at run-time the position and orientation of the camera. In other words, the possible movement space for the camera is an irregularly-shaped 3D volume, not some simplistic "glide path." As a general rule, neither position nor orientation of the camera within this volume can be predetermined for any particular game play moment.

So I'm afraid your assumption of how the camera system works in GoW3 is wrong, as is everything else you claimed based on those assumptions.

But moreover, even if it WAS possible to predetermine it, it just isn't a good idea anyway. First, the time to implement such a system would be better spent doing something else. Second, it would detrimentally affect the time it takes to build levels which negatively affects what art and design can achieve in a fixed amount of time. Third, just outright rendering those objects in the first place would be faster than trying to be "clever."

 

[London Geezer]

Third, just outright rendering those objects in the first place would be faster than trying to be "clever."

I think that pretty much closes this conversation. Next!!

 

[tha_con]

Brilliant stuff. Except the fundamental assumption you made about the existence of some sort of "glide path of the camera", that the remainder of your post rested on. There is no "glide path of the camera" in any God of War game. Your assumptions of how the camera works may (may!) have held true for, say, Panzer Dragoon 15 years ago, but it just isn't how the camera works in GoW3...

Also, good stuff Christer. I learned a lot reading that, very interesting stuff! I had always assumed that the camera was, at times, on a "path". Very interesting to know it's all calculated in real time. Is this the same way that the previous camera's worked? (If you know, of course).

 

[phat]

This decision is made at run-time, not tool-time. I repeat: for every game frame, we determine at run-time the position and orientation of the camera. In other words, the possible movement space for the camera is an irregularly-shaped 3D volume, not some simplistic "glide path." As a general rule, neither position nor orientation of the camera within this volume can be predetermined for any particular game play moment.

So I'm afraid your assumption of how the camera system works in GoW3 is wrong, as is everything else you claimed based on those assumptions.

I underestimated the amount of articulation that your camera has, but I do realize that it's not on a simple line curve, and have considered this in my previous post.

The volume that the camera position can occupy is a mere sliver of a level's total volume and still only allows the camera to get close to or zoom in on a very few surfaces of the programmer's choosing, so pre-determining the MIPMAP and LOD ranges will still give you a huge reduction in your data set. By huge I mean a factor of 8, 16, or more, depending on your maximum resolution MIPMAP and LOD.

How do you scan your camera through its path volume? You can manually hint your level sweep tool, based on the camera dolly rigging. You can exhaustively sweep through the control parameters of the dolly. You can randomly sample those parameters. Or you can gather camera position data as a player does an exploratory sweep of a level.

As a simplification, you can ignore camera orientation and just do omni-directional proximity to surfaces to probe their MIPMAP and LOD range. You can then special case places where the camera can do long zooms.

But moreover, even if it WAS possible to predetermine it, it just isn't a good idea anyway. First, the time to implement such a system would be better spent doing something else. Second, it would detrimentally affect the time it takes to build levels which negatively affects what art and design can achieve in a fixed amount of time. Third, just outright rendering those objects in the first place would be faster than trying to be "clever."

The level optimization sweep need not be done every incremental build. For iterative development and play testing, you can use unoptimized levels with framerate problems or lower detail. You can run the level optimization sweep only per night, per week, or per SCM build.