Possible game camera methods and optimisations *spawn

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.

 

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?

 

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.

 

Is that from the GOWIII tech presenation?

 

GOW 1.

 

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

this is usually done automatically during map creation phase

 

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.

 

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.

 

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

 

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.

 

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.

 

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

 

*fixed*

 

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.

 

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

 

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:

 

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.