// MIT License | |
// Copyright (c) 2024 Nathan V. Morrical | |
// Permission is hereby granted, free of charge, to any person obtaining a copy | |
// of this software and associated documentation files (the "Software"), to deal | |
// in the Software without restriction, including without limitation the rights | |
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
// copies of the Software, and to permit persons to whom the Software is | |
// furnished to do so, subject to the following conditions: |
// Copyright (c) 2023 Tomasz Stachowiak | |
// | |
// This contribution is dual licensed under EITHER OF | |
// | |
// Apache License, Version 2.0, (http://www.apache.org/licenses/LICENSE-2.0) | |
// MIT license (http://opensource.org/licenses/MIT) | |
// | |
// at your option. | |
#include "/inc/frame_constants.hlsl" |
GPU Gems 1 - Chapter 23. Depth of Field: A Survey of Techniques | |
GPU Gems 2 | |
GPU Gems 3 - Chapter 28. Practical Post-Process Depth of Field | |
GPU Pro 1 - Realistic Depth of Field in Post-Production | |
GPU Pro 2 - Post-Proccessing Effects on Mobile Devices | |
GPU Pro 3 - | |
GPU Pro 4 - Images Space -> First Two Chapters | |
GPU Pro 5 - 241 - Bokeh Effects on The SPU | |
GPU Pro 6 - |
- 2011 - A trip through the Graphics Pipeline 2011
- 2015 - Life of a triangle - NVIDIA's logical pipeline
- 2015 - Render Hell 2.0
- 2016 - How bad are small triangles on GPU and why?
- 2017 - GPU Performance for Game Artists
- 2019 - Understanding the anatomy of GPUs using Pokémon
- 2020 - GPU ARCHITECTURE RESOURCES
Coding practices are a source of a lot of arguments among programmers. Coding standards, to some degree, help us to put certain questions to bed and resolve stylistic debates. No coding standard makes everyone happy. (And even their existence is sure to make some unhappy.) What follows are the standards we put together on the Core team, which have become the general coding standard for all programming teams on new code development. We’ve tried to balance the need for creating a common, recognizable and readable code base with not unduly burdening the programmer with minor code formatting concerns.
void main() | |
{ | |
vec3 positionX = backproject(depthTexture(pixelCoordinateI), inverseViewProjectionMatrix); | |
vec3 normalX = normalTexture(pixelCoordinateI); | |
// get ONB to transform samples | |
mat3 orthoNormalBasis = computeONB(normalX); | |
// select samples for pixel out of pattern | |
int patternOffset = getPatternOffset(pixelCoordinateI); | |
float ao = 0.0; |
There is a nice GIF illustrating a technique called "frustum culling" in this Kotaku article: http://kotaku.com/horizon-zero-dawn-uses-all-sorts-of-clever-tricks-to-lo-1794385026
The interwebs being what they are, this has also led to some controversy.
Some people have interpreted the opening sentence "Every time you move the camera in Horizon Zero Dawn, the game is doing all sorts of under-the-hood calculations, loading and unloading chunks of world to ensure that it all runs properly," as being about the GIF; that's not what frustum culling does, but that's probably not what the article's author meant anyway.
// The following code is licensed under the MIT license: https://gist.github.com/TheRealMJP/bc503b0b87b643d3505d41eab8b332ae | |
// Samples a texture with Catmull-Rom filtering, using 9 texture fetches instead of 16. | |
// See http://vec3.ca/bicubic-filtering-in-fewer-taps/ for more details | |
float4 SampleTextureCatmullRom(in Texture2D<float4> tex, in SamplerState linearSampler, in float2 uv, in float2 texSize) | |
{ | |
// We're going to sample a a 4x4 grid of texels surrounding the target UV coordinate. We'll do this by rounding | |
// down the sample location to get the exact center of our "starting" texel. The starting texel will be at | |
// location [1, 1] in the grid, where [0, 0] is the top left corner. | |
float2 samplePos = uv * texSize; |