drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2022-05-21 23:20:09 +02:00
parent f0c3f6aecf
commit e54040171b
24 changed files with 159 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

4
graphics.md
View file

@ -17,11 +17,11 @@ We can divide computer graphics in different ways, traditionally e.g.:
- **[real time](real_time.md)**: Trying to work with images in real time, e.g. being able to produce or analyze 60 frames per second.
- **offline**: Processes or creates images over longer time-spans, e.g. hours or days.
Since the 90s computers started using a dedicated hardware to accelerate graphics: so called [GPU](gpu.md)s. These have allowed rendering of high quality images in high FPS, and due to the entertainment and media industry (especially gaming), GPUs have been pushed towards greater performance each year. Nowadays they are one of the most consumerist [hardware](hardware.md), also due to the emergence of general purpose computations being moved to GPUs (GPGPU) and lately the mining of [cryptocurrencies](crypto.md). Most lazy programs dealing with graphics nowadays simply expect and require a GPU, which creates a bad [dependency](dependency.md). At [LRS](lrs.md) we try to prefer the [suckless](suckless.md) **software [rendering](rendering.md)**, i.e. rendering on the [CPU](cpu.md), without GPU, or at least offer this as an option in case GPU isn't available. This many times leads us to old and forgotten algorithms used in times before GPUs.
Since the 90s computers started using a dedicated hardware to accelerate graphics: so called [graphics processing units](gpu.md) (GPUs). These have allowed rendering of high quality images in high [FPS](fps.md), and due to the entertainment and media industry (especially gaming), GPUs have been pushed towards greater performance each year. Nowadays they are one of the most consumerist [hardware](hardware.md), also due to the emergence of general purpose computations being moved to GPUs (GPGPU) and lately the mining of [cryptocurrencies](crypto.md). Most lazy programs dealing with graphics nowadays simply expect and require a GPU, which creates a bad [dependency](dependency.md). At [LRS](lrs.md) we try to prefer the [suckless](suckless.md) **[software rendering](sw_rendering.md)**, i.e. rendering on the [CPU](cpu.md), without GPU, or at least offer this as an option in case GPU isn't available. This many times leads us towards the adventure of using old and forgotten algorithms used in times before GPUs.
## 3D Graphics
3D graphics is a big part of CG but is a lot more complicated than 2D. It tries to achieve **realism**, i.e. looking at least a bit like what we see in the real world. Due to this 3D can be though of as **simulating the behavior of light**. There exists so called *rendering equation* that describes how light behaves ideally, and 3D computer graphics is all about trying to approximate the solutions of this equation.
3D graphics is a big part of CG but is a lot more complicated than 2D. It tries to achieve **realism** through the use of [perspective](perspective.md), i.e. looking at least a bit like what we see in the real world. Due to this 3D can be though of as **simulating the behavior of light**. There exists so called *rendering equation* that describes how light behaves ideally, and 3D computer graphics is all about trying to approximate the solutions of this equation.
Because 3D is not very easy, there exist many **3D engines** and libraries that you'll probably want to use. These engines/libraries work on different levels of abstraction: the lowest ones, such as [OpenGL](opengl.md) and [Vulkan](vulkan.md), offer a portable API for communicating with the GPU that lets you quickly draw triangles and write small programs that run in parallel on the GPU -- so called [shaders](shader.md). The higher level, such as [OpenSceneGraph](osg.md), work with [abstraction](abstraction.md) such as that of **camera** and **scene** into which we place specific 3D objects such as models and lights (the scene is many times represented as a hierarchical graph of objects that can be "attached" to other objects).