# Depth of Field Testing

This topic is 3963 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Sometime later this year I'm going to be heading and producing a game for my company for hopefully the Xbox 360. In any event me and my gfx programmer have thrown together a couple algorithms that build angular blur per pixel on the camera, so it looks as if the camera is looking through a 35mm lens. It hasn't been implemented yet since we are currently working on another project, but I was wondering how computationally expensive this would be. This is the basic algorithm: The 3D Engine renders the scene in the buffer. The angular blur algorithm calculates the pixel area blur on the scene from calculating per-vertex distances (this can be modified to give better performance), and blurs the area of pixels based on the angular blur equation. The scene is flushed and rendered. I've done effects like this before, just not not this computationally expensive. So from opinions in the forums what would you think the average time to calculate this would be on a standard 360.

##### Share on other sites
Quote:
 Original post by TheDirectorSo from opinions in the forums what would you think the average time to calculate this would be on a standard 360.

4.217ms

Seriously though, it's an impossible question to answer without many more details of *your* exact algorithm (post process vertex work?, per-object vertex work?, average tap size for the filter?), and how optimal *your* engine is (cost for a 2nd pass?, Z pre pass?), and how much *your* art content is [or is likely to be] stressing the GPU (are you vertex bound or pixel bound?, what draw [thus depth] distance?), and how *your* engine is using the 360 hardware (how many tiles?, default GPR allocation?, using the tesselator at all?, average shader length?, multiple tiling brackets?).

From what I understand of your description, it certainly sounds a feasible thing to do at a reasonable rate on a 360. If it's almost entirely post-process, I'd say you should be ok. If it requires writing per-pixel angular information for every primitive rendered, then it depends on a lot of the things I mentioned above. Implementation may also have a few gotchas depending on where you're doing the post process blur (e.g. if it's before tiling has ended, do you have enough information in the current tile to account for stuff blurred in from neighbouring tile(s)?).

##### Share on other sites
Lost Planet did per-pixel screen-space velocity stuff which apparently yield blurs of fast moving objects etc, relative to the camera. There are some (Japanese) slides kicking around with a brief description of the algorithm (google is your friend).

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 9
• 34
• 16
• 11
• 10
• ### Forum Statistics

• Total Topics
634122
• Total Posts
3015643
×