Update

graphics.md

@@ -21,12 +21,16 @@ Since the 90s computers started using a dedicated hardware to accelerate graphic
 
 ## 3D Graphics
 
-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.
+This is a general overview of 3D graphics, for more technical overview of 3D rendering see [its own article](3d_rendering.md).
 
-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).
+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. 3D graphics can very often bee seen as **simulating the behavior of [light](light.md)**; there exists so called *[rendering equation](rendering_equation.md)* that describes how light behaves ideally, and 3D computer graphics tries to approximate the solutions of this equation, i.e. the idea is to use [math](math.md) and [physics](physics.md) to describe real-life behavior of light and then simulate this model to literally create "virtual photos". The theory of realistic rendering is centered around the rendering equation and achieving **[global illumination](global_illumination.md)** (accurately computing the interaction of light not just in small parts of space but in the scene as a whole) -- studying this requires basic knowledge of [radiometry](radiometry.md) and [photometry](photometry.md) (fields that define various measures and units related to light such as [radiance](radiance.md), radiant intensity etc.).
+
+In 2010s mainstream 3D graphics started to employ so called [physically based rendering](pbr.md) (PBR) that tries to yet more use physically correct models of [materials](material.md) (e.g. physically measured [BRDFs](brdf.md) of various materials) to achieve higher photorealism. This is in contrast to simpler (both mathematically and computationally), more [empirical](empiricism.md) models (such as a single texture + [phong lighting](phong_lighting.md)) used in earlier 3D graphics.
+
+Because 3D is not very easy (for example [rotations](rotation.md) are pretty complicated), there exist many **[3D engines](3d_engine.md)** 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 a **virtual camera** and **virtual 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, so called [scene graph](scene_graph.md)).
 
 There is a tiny [suckless](suckless.md)/[LRS](lrs.md) library for real-time 3D: [small3dlib](small3dlib.md). It uses software rendering (no GPU) and can be used for simple 3D programs that can run even on low-spec embedded devices. [TinyGL](tinygl.md) is a similar software-rendering library that implements a subset of [OpenGL](opengl.md).
 
-**Real-time** 3D typically uses an **object-order** rendering, i.e. iterating over objects in the scene and drawing them onto the screen (i.e. we draw object by object). This is a fast approach but has disadvantages such as (usually) needing a memory inefficient [z-buffer](z_buffer.md) to not overwrite closer objects with more distant ones. It is also pretty difficult to implement effects such as shadows or reflections in object-order rendering. The 3D models used in real-time 3D are practically always made of **triangles** (or other polygons) because the established GPU pipeline works on the principle of drawing polygons.
+**Real-time** 3D typically uses an **object-order** rendering, i.e. iterating over objects in the scene and drawing them onto the screen (i.e. we draw object by object). This is a fast approach but has disadvantages such as (usually) needing a memory inefficient [z-buffer](z_buffer.md) to not overwrite closer objects with more distant ones. It is also pretty difficult to implement effects such as shadows or reflections in object-order rendering. The 3D models used in real-time 3D are practically always made of **triangles** (or other polygons) because the established GPU pipelines work on the principle of drawing polygons.
 
 **Offline rendering** (non-real-time, e.g. 3D movies) on the other hand mostly uses **image-order** algorithms which go pixel by pixel and for each one determine what color the pixel should have. This is basically done by casting a ray from the camera's position through the "pixel" position and calculating which objects in the scene get hit by the ray; this then determines the color of the pixel. This more accurately models how rays of light behave in real life (even though in real life the rays go the opposite way: from lights to the camera, but this is extremely inefficient to simulate). The advantage of this process is a much higher realism and the implementation simplicity of many effects like shadows, reflections and refractions, and also the possibility of having other than polygonal 3D models (in fact smooth, mathematically described shapes are normally much easier to check ray intersections with). Algorithms in this category include [ray tracing](ray_tracing.md) or [path tracing](path_tracing.md). In recent years we've seen these methods brought, in a limited way, to real-time graphics on the high end GPUs.

tranny_software.md

@@ -1,3 +1,26 @@
 # Tranny Software
 
-Tranny software is [software](software.md) developed withing the culture of the toxic LGBTFJJJGIIQWWQW SJWs fascist trans feminist [pseudoleftists](pseudoleft.md) who hardly know anything about good technology and instead focus on pushing their gospel with things such as [codes of conduct](coc.md) and excluding strait white males in the name of inclusivity. Such software is retarded. It is practically always a high level of [bloat](bloat.md) with features such as [censorship](censorship.md), bugs and [spyware](spyware.md).
+Tranny software is a harmful [software](software.md) developed within and infected by the culture of the toxic LGBTFJJJGIIQWWQW SJW [pseudoleftists](pseudoleft.md), greatly characterized e.g. by [codes of conduct](coc.md) and excluding straight white males from the development in the name of inclusivity. Such software is retarded. It is practically always a high level of [bloat](bloat.md) with features such as [censorship](censorship.md), bugs and [spyware](spyware.md).
+
+To be clear, *tranny software* does NOT stand for *software written by transsexuals*, it stands for a specific kind of software infected by [fascism](fascism.md) (in its features, development practices, culture, goals etc.) which revolves around things such as sexual identity. Of course with good technology it doesn't matter by whom it is made.
+
+Some characteristics of tranny software are:
+
+- **It is typically [FOSS](foss.md)** because a big part of trannyism in software is the development process and interaction with public (and with [proprietary](proprietary.md) software the development is not open to public). In theory we may call a proprietary software *tranny* if it e.g. very aggressively promote some [SJW](sjw.md) bullshit -- in fact most companies are nowadays infected by [SJWism](sjw.md) -- but it's not so common to use this term for proprietary software.
+- **Typically has a [code of conduct](coc.md)** or some equivalent "SJW guideline" (excluding the anti-COCs).
+- Sometimes promotes SJW fascism in other ways, e.g. [LGBT](lgbt.md) flags etc.
+- **It is typically [bloat](bloat.md) and [capitalist software](capitalist_software.md)**, and generally just very bad software at least from the [LRS](lrs.md) point of view. This is partly because devs try to be "inclusive" and afraid to refuse [PRs](pull_request.md) from "diverse people" (who are mostly incompetent, again trying software development e.g. as part of proving that "minorities can program too"), partly because their software doesn't even aim to be good but rather popular (as it is to serve to promote political ideas etc.).
+- **It often has SJW "features"**, e.g. "slur filters", "diverse" characters in games etc.
+
+Examples of tranny software are:
+
+- [Rust](rust.md)
+- [Linux](linux.md)
+- [Firefox](firefox.md)
+- [Lemmy](lemmy.md)
+- [Chromium](chromium.md)
+
+Example of software that doesn't seem to be tranny software:
+
+- all official [LRS](lrs.md)
+- TODO