Possible game camera methods and optimisations *spawn

[ERP]

I'm going to go with Christer on this one the sorts of optimizations your talking about usually just aren't worth the effort.

You might get something if you could precalculate object level occlusion, but practically more often that not it's just quicker throw the polygons at the GPU if you try and get too clever building the display list ends up taking longer than just rendering it.

What you can do with more constrained cameras in not create the areas you never see, but if your designers are going to stick cameras in world after it's been built, you probbly don't even get that.

 

[MrFloopy]

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."

First off, awesome work. GOW is totally not my type of game, but loved the complete quality, loved the camera presentation, but so much more loved your memory management scheme: let the designers worry about it, brilliant! and don't even get me started with doors!!

However, are you saying there were no performance/quality, scheduling or budgetary advantages to your camera system as opposed to a traditional third person camera?

 

[tha_con]

However, are you saying there were no performance/quality, scheduling or budgetary advantages to your camera system as opposed to a traditional third person camera?

Yes, that's what he's saying. I don't know why people think a fixed camera offers advantages over a free camera. It simply doesn't, at least, if you WERE to develop a game like that, it would take far far longer than simply keeping everything within the scope of what the GPU can render.

I mean, think about it. It's a pretty big waste of time to "test" every area and angle to see what you can and cannot render. Those kind of optimizations are a huge waste of time and effort.

 

[idsn6]

Yes, that's what he's saying. I don't know why people think a fixed camera offers advantages over a free camera. It simply doesn't, at least, if you WERE to develop a game like that, it would take far far longer than simply keeping everything within the scope of what the GPU can render.

I mean, think about it. It's a pretty big waste of time to "test" every area and angle to see what you can and cannot render. Those kind of optimizations are a huge waste of time and effort.

You would be very hard-pressed to find a developer that thought finding a PVS was a "huge waste of time". That includes Sony Santa Monica and God of War.

 

[Neb]

Is that from the GOWIII tech presenation?

 

[idsn6]

GOW 1.

 

[zed]

Yes, that's what he's saying. I don't know why people think a fixed camera offers advantages over a free camera. It simply doesn't, at least, if you WERE to develop a game like that, it would take far far longer than simply keeping everything within the scope of what the GPU can render.

having a fixed camera or a camera following a set path, offers quite a few advantages
2 main ones
A/ see what static objects are not visable, PVS in above parlance?
B/ if the camera doesnt come to close to an object perhaps then u dont require such high quality texture

I mean, think about it. It's a pretty big waste of time to "test" every area and angle to see what you can and cannot render. Those kind of optimizations are a huge waste of time and effort.

this is usually done automatically during map creation phase

 

[MrFloopy]

I don't know why people think a fixed camera offers advantages over a free camera. It simply doesn't, at least, if you WERE to develop a game like that, it would take far far longer than simply keeping everything within the scope of what the GPU can render.

I mean, think about it. It's a pretty big waste of time to "test" every area and angle to see what you can and cannot render. Those kind of optimizations are a huge waste of time and effort.

Notice I mentioned the Project Triangle. All project decisions will effect that triangle, it's just a matter in which way.

You are just thinking performance benefits. If you know that while traversing a corridor or room you will only see three walls, you can spread your art budget between three rather than four (or more) walls.To me that is a much bigger win than any performance issues. Although you'll have to go a long way to convince me that there are no situations where a performance benefit would not also occur.

 

[Christer Ericson]

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.

I'll repeat one more time: the camera can pan, tilt, and zoom depending on what the player does. For example, if the player does an instant kill, the combat designers often have the camera pull in really close for the kill effect. This happens near instantaneously, and certainly too fast to be able to stream in any textures. As you can lure an enemy to just about any location and kill it there, the camera can also zoom in on just about any texture. Those surfaces you cannot get close to, those are not easy (read non-practical) to deduce. In other words, everything you just said does not hold true for our game!

You are still making assumptions without really paying attention to what goes on in a God of War game with respect to the camera. The camera -- and the game, affecting it -- does much more than you think it does. My point still stands: anyone who thinks the camera is "fixed" or that you can easily "optimize" things due to how our camera has been set up is naive about the system.

How do you scan your camera through its path volume?

I mentioned before that we (Phil) did a thorough description of the camera system at GDC (in 2008). You should do the research and read up on what the camera system does instead of making incorrect guesses. As a bonus, you'd know the answer to this question!

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.

I'm afraid this is crazy talk. We "could" also, for example, prerender every possible screenshot of the game based on every possible input, and just pick the appropriate image to display based on the input history. The game will ship on several million BluRays, but it "can" be done.

There's a lot of things that fall into what you "can" do, but just aren't worth it in a real-world game development environment. Trying to deduce what can or cannot be rendered based on the setup of our camera system falls into that category.

 

[Phil Wilkins]

Hi, I wrote the camera system in question.

All the rendering system knows about the camera is it's position and orientation. The constraints, curves, coefficients, and state used to generate the camera make it prohibitively complex to extract any useful information mechanically from them.

For a start you'd have to sweep through all possible positions of the player. Then multiply that by all possible positions of every other active camera target. Then again by all previous states of the camera, and I'm not even sure that's actually possible.

The best you can do, is what we do, which is to have the artists and camera designers talk to each other about what they're doing.

So this is all entirely separate from the rendering engine. In fact, I regularly have to explain to new rendering guys why they can't derive much useful information from the camera system. Nor should they assume anything about it. If anything we're in a less predictable position than any given third or first person player controlled camera, because our designers can pull a mile out, just as the player triggers a move that folds the FoV down to frame the character.

 

[Phil Wilkins]

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.

Funnily enough that actually is the control for the debug camera in the development version of the runtime.

 

[Danalys]

You could still stream small segments scaling in detail for distance they'd just be high enough res to stand up to scrutiny when zooming. There'd still be areas of a room you'd never see.

 

[Phil Wilkins]

However, are you saying there were no performance/quality, scheduling or budgetary advantages to your camera system as opposed to a traditional third person camera?

We had a team of 4 camera designers on GoW3, and ~1/3 of a programmer. Every level requires a camera design stage that has potential cross-dependencies with every other department, well, other than concept art. That alone tips the scheduling and budgetary considerations seriously against us. This is not an easy road.

The only performance benefits are that we can focus asset creation quality on what we want to look at. Sometimes this means that we don't need to build the back wall of a room. Or we can unload an area behind us that we can no longer see. Although often we'll just swap it for a lower detail version of the same area (think of the horse / chain section of GoW2).

That's entirely in the domain of the artists and designers though.

 

[Phil Wilkins]

You would be very hard-pressed to find a developer that thought finding a PVS was a "huge waste of time". That includes Sony Santa Monica and God of War.

Amusingly that process is still entirely driven by the artists and designers. There is no mechanical discovery of PVS.

 

[Phil Wilkins]

There is no mechanical discovery of PVS in God of War.

*fixed*

 

[Danalys]

so we could say that God of War gives the artists more leeway to decide where they should have more detail because of the camera angles, once they know what they will be.

 

[patsu]

Based on Christer's post and example, it's decided by the artists/designers and the player (e.g., where Kratos happens to be at the killing moment).

 

[Danalys]

the players can make a moment that's zoomed in but they can't force a camera angle that shows stuff that the designers and artists have decided wont be seen.

 

[patsu]

the players can make a moment that's zoomed in but they can't force a camera angle that shows stuff that the designers and artists have decided wont be seen.

I suspect so, but there are probably a wide range of possibilities once Kratos is set loose in a level, especially when they are fighting on a mobile Titan/level:

the camera can pan, tilt, and zoom depending on what the player does.

 

[Danalys]

If the cameras direction is generally fixed then theoretically you could have most of two walls never seen. It's been a while since I've played a God of War title but I think I remember it switching camera angles on you but only so you would see a different angle of where you had been in much less detail. I think the geometry it's pushing is really impressive even if it can take some clever steps to minimise what it neads to keep in memory at any one time.