In the world of [computers](computer.md) (especially in [computer graphics](graphics.md), but also e.g. in physics simulations etc.) 3D model is a representation of a [three dimensional](3d.md) object, for example of a real life object such as a car, [tree](tree.md) or a [dog](dog.md), but also possibly something more abstract like a [fractal](fractal.md) or [function](function.md) plot surface. 3D models can be displayed using various [3D rendering](3d_rendering.md) techniques and are used mostly to simulate [real world](real_world.md) on computers (e.g. [games](game.md)), as real world is, as we know, three dimensional. 3D models can be created in several ways, e.g. manually with 3D modelling software (such as [Blender](blender.md)) by 3D [artists](art.md), by 3D scanning real world objects, or automatically by [procedural generation](procgen.md).
3D models can be represented in many ways -- the **mainstream "game" 3D models** that most people are used to seeing are polygonal (made of triangles) boundary-representation (recording only surface, not volume) [textured](texture.md) (with "pictures" on their surface) 3D models, but be aware that many different ways are possible and used too, for example various volume representations, [voxel](voxel.md) models, [point clouds](point_cloud.md), [implicit surfaces](implicit_surface.md), [spline](spline.md) surfaces, [constructive solid geometry](csg.md), [wireframe](wireframe.md) etc. Models may also bear additional extra information and features, e.g. bone rigs for animation, animation key frames, density information, [LODs](lod.md) and so on.
In the world of [computers](computer.md) (especially in [computer graphics](graphics.md), but also in physics simulations, 3D printing etc.) 3D model is a representation of a [three dimensional](3d.md) object, for example of a [real life](irl.md) object such as a car, [tree](tree.md) or a [dog](dog.md), but also possibly something more abstract like a [fractal](fractal.md) or [function](function.md) plot surface. 3D models can be displayed using various [3D rendering](3d_rendering.md) techniques and are used mostly to simulate [real world](real_world.md) on computers (e.g. [games](game.md)), as real world is, as we know, three dimensional. 3D models can be created in several ways, e.g. manually with 3D modeling software (such as [Blender](blender.md)) by 3D [artists](art.md), by 3D scanning real world objects, or automatically by [procedural generation](procgen.md).
There is a plethora of different 3D model types, the topic is very large when viewed in its whole scope because 3D models can be used and represented in many ways (and everything is yet more complex by dealing with different methods of 3D rendering) -- the **mainstream "game" 3D models** that most people are used to seeing are polygonal (basically made of triangles) boundary-representation (recording only surface, not volume) [textured](texture.md) (with "pictures" on their surface) 3D models, but be aware that many different ways of representation are possible and in common use by the industry, for example various volume representations, [voxel](voxel.md) models, [point clouds](point_cloud.md), [implicit surfaces](implicit_surface.md), [spline](spline.md) surfaces, [constructive solid geometry](csg.md), [wireframe](wireframe.md) etc. Models may also bear additional extra information and features, e.g. material, bone rigs for animation, animation key frames, density information, [LODs](lod.md), even [scripts](scripting.md) and so on.
**3D formats**: situation here is not as simple as it is with images or audio, but there are a few formats that in practice will suffice for most of your models. Firstly the most [KISS](kiss.md) one is (Wavefront) **obj** -- this is supported by almost every 3D software, it's a text format that's easy to parse and it's even human readable and editable; obj supports most things you will ever need like UV maps and normals, and you can [hack](hack.md) it even for a primitive keyframe animation. So if you can, use obj as your first choice. If you need something a little more advanced, use **COLLADA** (.dae extension) -- this is a bit more [bloated](bloat.md) than obj as it's an [XML](xml.md), but it's still human readable and has more features, for example skeletal animation, instancing, model hierarchy and so on. Another noteworthy format is e.g. [stl](stl.md) used a lot in 3D printing. For other than polygonal models you may have to search a bit or just represent your model in some sane way, for example heightmap is naturally saved as a grayscale image, voxel model may be saved in some dead simple text format and so on. Also be always sure to **distribute your model in universal format**, i.e. don't just share Blender's project file or anything like that, that's like sharing pictures in Photoshop format or sending someone a Word document, only retards do that -- yes, you should also share the project file if possible, but it's more important to release the model in a widely supported, [future proof](future_proof.md) and non discriminating format.
Let's now take a closer look at a basic classification of 3D models (we only mention the important categories, this is not an exhaustive list):
- by **representation**:
- **boundary representation**: Captures only the object's boundary, i.e. its surface, so we really end up with just a hollow "shell" of the object without any volume inside. This is mostly [good enough](good_enough.md) for programs such as games -- with opaque objects we only ever see their surface anyway (with transparent objects we get into a bit of trouble but can still manage to "fake" some convincing look).
- **smooth [spline](spline.md) surfaces**: Model the boundary with smooth mathematical function, poplar are e.g. [NURBS](nurbs.md). This gives very nice models that even up close look completely smooth. Disadvantage is that it's not so easy to render these models directly in real time, so the models are typically converted to polygonal models during rendering anyway, sometimes using things like adaptive subdivision to still keep the model as smooth as possible.
- **[polygonal](polygon.md)**: The surface is represented with polygons such as triangles or quads that are connected to each other by their edges. These models have sharp edges and to look smooth have to make use of many polygons, but it turns out this representation is convenient, they can be easily edited and most importantly quickly rendered in real time, which is why most game 3D models use this representation. These models are composed of three essential elements: **vertices** (points in space), **edges** (lines connecting the vertices) and **polygons** (flat surfaces between the edges).
- **[triangular](triangle.md)**: Polygonal models that only contain triangles (three sided polygons), oftentimes automatically created from general polygonal models. Models are normally automatically triangulated right before rendering because a GPU can basically just draw triangles.
- ...
- **volume representation**: Explicitly provide information about the whole object's volume, i.e. it is possible to tell if any point is inside the model or outside of it and additionally usually also providing more information e.g. about density, material, index of refraction and so on. Such models naturally allow more precise simulations, they may fit better into physics engines and can also naturally be nicely rendered with [raytracting](raytracing.md) and similar image order rendering methods. For real time entertainment graphics this is mostly [overkill](overkill.md) and the model would have to be converted to boundary representation anyway, so volumetric models are rather used in science and engineering industry.
- **[voxel](voxel.md)**: Analogy of 2D bitmap images extended to 3D, i.e. the model exists in a 3D grind and is represented with small cubes called voxels (3D analog to 2D [pixel](pixel.md)). The model is therefore rough with "staircases" -- this is very famously seen in the game [Minecraft](minecraft.md), but is very common also e.g. in medical devices like MRI which scan human body as a series of layers, each one captured essentially as a 2D image. Voxel models are convenient for various dynamic simulations, [cellular automata](cellular_automaton.md), [procedural generation](procgen.md) and so on. Voxel models can be converted to other types of model, e.g. to polygonal ones (see the Marching Cubes algorithm).
- **[constructive solid geometry](csg.md)** (CSG): Represent the model as a [tree](tree.md) (or a more general hierarchical graph) of basic geometric shapes combined together with so called boolean operations -- basically [set](set.md) operations like union, subtraction and so on. This is widely used in [CAD](cad.md) applications for variety of reasons, e.g. the models are quite precise and smooth, easily parametrized, their description is similar to their physical manufacturing by machines (e.g. "make a sphere, dig hole in it", ...) and so on.
- **[implicit surfaces](implicit_surface.md), [signed distance function](sdf.md)**: Describe the model by a [distance](distance.md) function, i.e. function *f(x,y,z)* which for any point in space says the distance to the object's boundary, with this distance being negative inside the object. This has some nice advanced use cases.
- **[heightmaps](heightmap.md)**: Typically used for modeling terrain, represent terrain height at each 2D coordinate, normally with a grayscale bitmap image. Advantages include simplicity of representation and the ability to edit the heightmap with image editing tools, among disadvantages are limited resolution of the heightmap and inability to represent e.g. overhangs.
- ...
- **[point cloud](point_cloud.md)**: Captures only individual points, sometimes with additional attributes such as color of each point, something akin its size, orientation and so on. This is typically what we get as raw data from some 3D scanners (see [photogrammetry](photogrammetry.md)). The advantage of point clouds is simplicity, they can be relatively easily rendered (just by drawing points on the screen), disadvantage is that the model has no surface and volume, there are "holes" in it: point cloud therefore has to be very dense to really be useful and for that it can take a lot of storage space. Point clouds may be converted to a more desirable format with special algorithms.
- **[wireframe](wireframe.md)**: Records only edges, again potentially with attributes like their color etc. Just as with point clouds wireframe model has no surface or volume, but it at least has some information about which points are interconnected. Nowadays wireframe is not so much used as a model representation but rather as one of viewing modes.
- by **features**:
- **UV mapped**: Having UV map, i.e. being ready to be textured.
- **[textured](texture.md)**: Having one or more textures.
- **[rigged](rig.md)**: Having bone rig set up for skeletal animation.
- **animated**: Having predefined animation (e.g. idle, running, attacking, ...).
- with **materials**: Having one or more materials defined and assigned to parts of the model. Materials define properties such as texture, metalicity, transparency and so on.
- with smoothing groups: Having information important for correct [shading](shading.md) (so that sharp edges look sharp and smooth edges look smooth).
- with subdivision weights: Having information that's important for correct automatic subdivision (geometrical smoothing).
- ...
- by detail, [resolution](resolution.md) and fidelity:
- **[low poly](low_poly.md)**: Relatively low total count of polygons.
- **mid poly**: Polygon count somewhere between low and high poly.
- **high poly**: Relatively high total count of polygons.
- ...
- by artistic style:
- **realistic**
- **stylized**
- **abstract**
- ...
- by intended use:
- **[real time](real_time.md)**: Made for real time graphic, i.e. optimized for speed.
- **offline**: Made for offline rendering, optimized for detail and visual quality.
- for animation: Made with animation in mind -- this requires extra effort on correct topology so that the model deforms well.
- ...
**Animation**: the main approaches to animation are these (again, just the important ones, you may encounter other ways too):
- **model made of separate parts**: Here we make a bigger model out of smaller models (i.e. body is head plus torso plus arms plus legs etc.) and then animate the big model by transforming the small models. This is very natural e.g. for animating machines, for example the wheels of a car, but characters were animated this way too (see e.g. Morrowind). The advantage is that you don't need any sophisticated subsystem for deforming models or anything, you just move models around (though it's useful to at least have parenting of models so that you can attach models to stick together). But it can look bad and there may be some ugliness like models intersecting etc.
- **keyframe [morphing](morphing.md)**: The mostly sufficient [KISS](kiss.md) way based on having a few model "poses" and just [interpolating](interpolation.md) between them -- i.e. for example a running character may have 4 keyframes: legs together, right leg in front, legs together, left leg in front; now to make smooth animation we just gradually deform one keyframe into the next. Now let's stress that this is a single model, each keyframe is just differently shaped, i.e. its vertices are at different positions, so the model is animating by really being deformed into different shapes. This was used in old games like [Quake](quake.md), it looks good and works well -- use it if you can.
- **skeletal animation**: The [mainstream](mainstream.md), gigantically [bloated](bloat.md) way, used in practically all 3D games since about 2005. Here we firstly make a *skeleton* for the model, i.e. an additional "model made of sticks (so called *bones*)" and then we have to painstakingly rig (or *skin*) the model, i.e. we attach the skeleton to the model (more technically assign weights to the model's vertices so as to make them deform correctly). Now we have basically a puppet we can move quite easily: if we move the arm bone, the whole arm moves and so on. Now animations are still made with keyframes (i.e. making poses in certain moments in time between which we interpolate), the advantage against morphing is just that we don't have to manually reshape the model on the level of individual vertices, we only manipulate the bones and the model deforms itself, so it's a bit more comfortable but this requires firstly much more work and secondly there needs to be a hugely bloated skeletal system programmed in (complex math, complex model format, skinning GUI, ...). Bones have more advantages, you can e.g. make procedural animations, ragdoll physics, you can attach things like weapon to the bones etc., but it's mostly not worth it. Even if you have a rigged skeletal model, you can still export its animation in the simple *keyframe morphing* format so as to at least keep your engine simple. Though skeletal animation was mostly intended for characters, nowadays it's just used for animating everything (like book pages have their own bones etc.) because many engines don't even support anything simpler.
Let us also briefly mention **texturing**, an important part of making traditional 3D models. In the common, narrower sense texture is a 2D images that is stretched onto the model surface to give the model more detail, just like we put wallpaper on a wall -- without textures our models have flat looking surfaces with just a constant color (at best we may assign each polygon a different color, but that won't make for a very realistic model). Putting texture on the model is called *texture mapping* -- you may also hear the term *UV mapping* because texturing is essential about making what we call a *UV map*. This just means we assign each model vertex 2D coordinates inside the texture; we traditionally call these two coordinates *U* and *V*, hence the term *UV mapping*. *UV* coordinates are just coordinates within the texture image; they are not in pixels but are typically [normalized](normalization.md) to a [float](float.md) in range <0,1> (i.e. 0.5 meaning middle of the image etc.) -- this is so as to stay independent of the texture [resolution](resolution.md) (you can later swap the texture for a different resolution one and it will still work). By assigning each vertex its UV texture coordinates we basically achieve the "stretching", i.e. we say which part of the texture will show on what's the character's face etc. (Advanced note: if you want to allow "tears" in the texture, you have to assign UV coordinates per triangle, not per vertex.) Now let's also mention a model can have multiple textures at once -- the most basic one (usually called *diffuse*) specifies the surface color, but additional textures may be used for things like transparency, normals (see [normal mapping](normal_mapping.md)), displacement, material properties like metalicity and so on (see also [PBR](pbr.md)). The model may even have multiple UV maps, the UV coordinates may be animated and so on and so forth. Finally we'll also say that there exists 3D texturing that doesn't use images, 3D textures are mostly [procedurally generated](procgen.md), but this is beyond our scope now.
We may do many, many more things with 3D models, for example **[subdivide](subdivision.md)** them (automatically break polygons down into more polygons to smooth them out), apply boolean operations to them (see above), **sculpt** them (make them from virtual clay), **[optimize](optimization.md)** them (reduce their polygon count, make better topology, ...), apply various modifiers, 3D print them, make them out of paper (see [origami](origami.md)) etcetc.
{ Holy crab, there is a lot to say about 3D models. ~drummyfish }
## Example
@ -163,7 +216,7 @@ TODO: other types of models, texturing etcetc.
**Do you want to start 3D modeling?** Or do you already know a bit about it and **just want some advice to get better?** Then let us share a few words of advice here.
Let us preface with mentioning the **[hacker](hacking.md) chad way of making 3D models**, i.e. the [LRS](lrs.md) way 3D models should ideally be made. Remeber, **you don't need any program to create 3D models**, you can make 3D models perfectly fine without Blender or any similar program, and even without computers. Sure, a certain kind of highly artistic, animated, very high poly models will be very hard or impossible to make without an interactive tool like Blender, but you can still make very complex 3D models, such as e.g. that of a whole city, without any fancy tools. Of course people were making statues and similar kinds of "physical 3D models" for thousands of years -- sometimes it's actually simpler to make the model by hand out of clay and later scan it into the computer -- you may also make easily make a polygonal model out of paper, BUT even virtual 3D models can simply be made with pen and paper, it's just numbers, verices and triangles, very manageable if you keep it simple and well organized. You can directly write the models in text formats like obj or collada. First computer 3D models were actually made by hand, just with pen and paper, because there were simply no computers fast enough to even allow real time manipulation of 3D models; back then the modellers simply measured positions of someone object's "key points" (verices) in 3D space which can simply be done with tools like rulers and strings, no need for complex 3D scanners (but if you have a digital camera, you have a quite advanced 3D scanner already). They then fed the manually made models to the computer to visualize them, but again, you don't even need a computer to draw a 3D model, in fact there is a whole area called [descriptive geometry](descriptive_geometry.md) that's all about drawing 3D models on paper and which was used by engineers before computers came. Anyway, you don't have to go as far as avoiding computers of course -- if you have a programmable computer, you already have the luxury which the first 3D artists didn't have, a whole new world opens up to you, you can now make very complex 3D models just with your programming language of choice. Imagine you want to make the said 3D model of a city just using the [C](c.md) programming language. You can first define the terrain as [heightmap](heightmap.md) simply as a 2D array of numbers, then you write a simple code that will iterate over this array and converts it to the obj format (a very simple plain text 3D format, it will be like 20 lines of code) -- now you have the basic terrain, you can render it with any tool that can load 3D models in obj format (basically every 3D tool), AND you may of course write your own 3D visualizer, there is nothing difficult about it, you don't even have to use perspective, just draw it in orthographic projection (again, that will be probably like 20 lines of code). Now you may start adding houses to your terrain -- make a C array of vertices and another array of triangle indices, manually make a simple 3D model of a house (a basic shape will have fewer than 20 vertices, you can cut it out of paper to see what it will look like). That's your house geometry, now just keep making instances of this house and placing them on the terrain, i.e. you make some kind of struct that will keep the house transformation (its position, rotation and scale) and each such struct will represent one house having the geometry you created (if you later improve the house model, all houses will be updates like this). You don't have to worry about placing the houses vertically, their height will be computed automatically so they sit right on the terrain. Now you can update your model exporter to take into account the houses, it will output the obj model along with them and again, you can view this whole model in any 3D software or with your own tools. You can continue by adding trees, roads, simple materials (maybe just something like per triangle colors) and so on. This approach may actually even be superior for some projects just as scripting is superior to many GUI programs, you can collaborate on this model just like you can collaborate on any other text program, you can automatize things greatly, you'll be independent of proprietary formats and platforms etcetc. This is how 3D models would ideally be made.
Let us preface with mentioning the **[hacker](hacking.md) chad way of making 3D models**, i.e. the [LRS](lrs.md) way 3D models should ideally be made. Remeber, **you don't need any program to create 3D models**, you don't have to be a Blender whore, you can make 3D models perfectly fine without Blender or any similar program, and even without computers. Sure, a certain kind of highly artistic, animated, very high poly models will be very hard or impossible to make without an interactive tool like Blender, but you can still make very complex 3D models, such as that of a whole city, without any fancy tools. Of course people were making statues and similar kinds of "physical 3D models" for thousands of years -- sometimes it's actually simpler to make the model by hand out of clay and later scan it into the computer, you can just make a physical wireframe model, measure the positions of vertices, hand type them into a file and you have a perfectly valid 3d model -- you may also easily make a polygonal model out of paper, BUT even virtual 3D models can simply be made with pen and paper, it's just numbers, vertices and [triangles](triangle.md), very manageable if you keep it simple and well organized. You can directly write the models in text formats like obj or collada. First computer 3D models were actually made by hand, just with pen and paper, because there were simply no computers fast enough to even allow real time manipulation of 3D models; back then the modelers simply measured positions of someone object's "key points" (vertices) in 3D space which can simply be done with tools like rulers and strings, no need for complex 3D scanners (but if you have a digital camera, you have a quite advanced 3D scanner already). They then fed the manually made models to the computer to visualize them, but again, you don't even need a computer to draw a 3D model, in fact there is a whole area called [descriptive geometry](descriptive_geometry.md) that's all about drawing 3D models on paper and which was used by engineers before computers came. Anyway, you don't have to go as far as avoiding computers of course -- if you have a programmable computer, you already have the luxury which the first 3D artists didn't have, a whole new world opens up to you, you can now make very complex 3D models just with your programming language of choice. Imagine you want to make the said 3D model of a city just using the [C](c.md) programming language. You can first define the terrain as [heightmap](heightmap.md) simply as a 2D array of numbers, then you write a simple code that will iterate over this array and converts it to the obj format (a very simple plain text 3D format, it will be like 20 lines of code) -- now you have the basic terrain, you can render it with any tool that can load 3D models in obj format (basically every 3D tool), AND you may of course write your own 3D visualizer, there is nothing difficult about it, you don't even have to use perspective, just draw it in orthographic projection (again, that will be probably like 20 lines of code). Now you may start adding houses to your terrain -- make a C array of vertices and another array of triangle indices, manually make a simple 3D model of a house (a basic shape will have fewer than 20 vertices, you can cut it out of paper to see what it will look like). That's your house geometry, now just keep making instances of this house and placing them on the terrain, i.e. you make some kind of struct that will keep the house transformation (its position, rotation and scale) and each such struct will represent one house having the geometry you created (if you later improve the house model, all houses will be updates like this). You don't have to worry about placing the houses vertically, their height will be computed automatically so they sit right on the terrain. Now you can update your model exporter to take into account the houses, it will output the obj model along with them and again, you can view this whole model in any 3D software or with your own tools. You can continue by adding trees, roads, simple materials (maybe just something like per triangle colors) and so on. This approach may actually even be superior for some projects just as scripting is superior to many GUI programs, you can collaborate on this model just like you can collaborate on any other text program, you can automatize things greatly, you'll be independent of proprietary formats and platforms etcetc. This is how 3D models would ideally be made.
OK, back to the mainstream now. Nowadays as a [FOSS](foss.md) user you will most likely do 3D modeling with [Blender](blender.md) -- we recommended it to start learning 3D modeling as it is powerful, [free](free_software.md), gratis, has many tutorials etc. Do NOT use anything [proprietary](proprietary.md) no matter what anyone tells you! Once you know a bit about the art, you may play around with alternative programs or approaches (such as writing programs that generate 3D models etc.). However **as a beginner just start with Blender**, which is from now on in this article the software we'll suppose you're using.
Anarch is a [LRS](lrs.md)/[suckless](suckless.md), [free as in freedom](free_software.md) first person shooter [game](game.md) similar to [Doom](doom.md), written by [drummyfish](drummyfish.md). It has been designed to follow the LRS principles very closely and set an example of how games, and software in general, should be written. It also tries to be compatible with principles of [less retarded society](less_retarded_society.md), i.e. it promotes [anarchism](anarchism.md), anti-[capitalism](capitalism.md), pacifism etc.
Anarch is a [LRS](lrs.md)/[suckless](suckless.md), [free as in freedom](free_software.md) first man shooter [game](game.md) similar to [Doom](doom.md), written by [drummyfish](drummyfish.md). It has been designed to follow the LRS principles very closely and set an example of how games, and software in general, should be written. It also tries to be compatible with principles of [less retarded society](less_retarded_society.md), i.e. it promotes [anarchism](anarchism.md), anti-[capitalism](capitalism.md), pacifism etc.
The repo is available at https://codeberg.org/drummyfish/Anarch
or https://gitlab.com/drummyfish/anarch. Some info about the game can also be found at the [libregamewiki](lgw.md): https://libregamewiki.org/Anarch.
@ -22,7 +22,7 @@ Bootstrapping as a general principle can aid us in creation of extremely free te
## Booting: Computer Starting Up
Booting as in "staring computer up" is also a kind of setting up a system from the ground up -- we take it from granted but remember it takes some [work](work.md) to get a computer from being powered off and having all RAM empty to having an operating system loaded, hardware checked and initialized, devices mounted etc.
Booting as in "staring computer up" is also a kind of setting up a system from the ground up -- we take it for granted but remember it takes some [work](work.md) to get a computer from being powered off and having all RAM empty to having an operating system loaded, hardware checked and initialized, devices mounted etc.
Starting up a **simple computer** -- such as some [MCU](mcu.md)-based [embedded](embedded.md) [open console](open_console.md) that runs [bare metal](bare_metal.md) programs -- isn't as complicated as booting up a mainstream [PC](pc.md) with an [operating system](operating_system.md).
Duke Nukem 3D (often just *duke 3D*) is a legendary first person shooter video [game](game.md) released in January 1996 (as [shareware](shareware.md)), one of the best known such games and possibly the second greatest 90s FPS right after [Doom](doom.md). It was made by 3D realms, a company competing with Id software (creators of Doom), in engine made by [Ken Silverman](key_silverman.md). Duke 3D is a big sequel to two previous games which were just 2D platformers; when this 3rd installment came out, it became a hit. It is remembered not only for being very technologically advanced, further pushing advanced fully textured 3D graphics that Doom introduced, but also for its great gameplay and above all for its humor and excellent parody of the prototypical 80s overtestosteroned [alpha male](chad.md) hero, the protagonist Duke himself -- it showed a serious game didn't have to take itself too seriously and became loved exactly for things like weird alien enemies or correct portrayal of [women](woman.md) as mere sexual objects which nowadays makes [feminists](feminism.md) screech in furious rage of thousand suns. Only idiots criticised it. Duke was later ported to other platforms (there was even a quite impressive 3D port for [GBA](gba.md)) and received a lot of additional "content".
Duke Nukem 3D (often just *duke 3D*) is a legendary first man shooter video [game](game.md) released in January 1996 (as [shareware](shareware.md)), one of the best known such games and possibly the second greatest 90s FPS right after [Doom](doom.md). It was made by 3D realms, a company competing with Id software (creators of Doom), in engine made by [Ken Silverman](key_silverman.md). Duke 3D is a big sequel to two previous games which were just 2D platformers; when this 3rd installment came out, it became a hit. It is remembered not only for being very technologically advanced, further pushing advanced fully textured 3D graphics that Doom introduced, but also for its great gameplay and above all for its humor and excellent parody of the prototypical 80s overtestosteroned [alpha male](chad.md) hero, the protagonist Duke himself -- it showed a serious game didn't have to take itself too seriously and became loved exactly for things like weird alien enemies or correct portrayal of [women](woman.md) as mere sexual objects which nowadays makes [feminists](feminism.md) screech in furious rage of thousand suns. Only idiots criticised it. Duke was later ported to other platforms (there was even a quite impressive 3D port for [GBA](gba.md)) and received a lot of additional "content".
Of course, Duke is sadly [proprietary](proprietary.md), as most gaymes, though the source code was later released as [FOSS](foss.md) under [GPL](gpl.md) (excluding the game data and proprietary engine, which is only [source available](source_available.md)). A self-proclaimed [FOSS](foss.md) engine for Duke with GPU accelerated graphics exists: [EDuke32](eduke32.md) -- the repository is kind of a mess though and it's hard to tell if it is legally legit as there are parts of the engine's proprietary code (which may be actually excluded from the compiled binary), so... not sure.
@ -10,7 +10,7 @@ The codebase (including Build engine) is roughly 100000 [LOC](loc.md) of [C](c.m
The original system requirements were roughly following: 66 MHz [CPU](cpu.md), 16 MB [RAM](ram.md) and 30 MB storage space.
Duke ran on **[Build](build.md) engine**, a legendary [software rendering](sw_rendering.md) [primitive 3D](pseudo_3d.md) engine that had limitations similar to those of [Doom](doom.md) engine, i.e. the camera could not genuinely rotate up or down (though it could fake this with kind of a "tilting") and things like rooms above other rooms in a level were allowed only in limited ways ([hacks](hacking.md) such as extra rendering passes or invisible teleports were used to allow this). The engine was not unsimilar to that of Doom, enemies and other objects were represented with 2D [sprites](sprite.md) and levels were based on the concept of sectors (a level was really made as a 2D map in which walls were assigned different heights and textures), however it had new features -- most notably [dynamic](dynamic.md) environment, meaning that levels could change on the fly without the need for [precomputation](precomputation.md), allowing e.g. destructible environments. How the fuck did they achieve this? Instead of [BSP](bsp.md) rendering (used by Doom) Build engine used **[portal rendering](portal_rendering.md)**: basically (put in a quite simplified way) there was just a set of sectors, some of which shared walls ("portals") -- rendering would first draw the sector the player stood in (from the inside of course) and whenever it encountered a portal wall (i.e. a wall that sees into another sector), it would simply [recursively](recursion.md) render that too in the same way -- turns out this was just fine. Other extra features of the engine included tilted floors and ceilings, fake looking up/down, 3rd person view etc. The Build engine was also used in many other games (most notably [Shadow Warrior](shadow_warrior.md) and [Blood](blood.md)) and later incorporated even more advanced stuff, such as [voxel](voxel.md) models, though these weren't yet present in Duke. Just like Doom, Build engine **only used [fixed point](fixed_point.md)**, no [float](float.md)! { Hmm, actually maybe there was a small exception, see the link below. ~drummyfish }
Duke ran on **[Build](build.md) engine**, a legendary [software rendering](sw_rendering.md) [primitive 3D](pseudo_3d.md) engine that had limitations similar to those of [Doom](doom.md) engine, i.e. the camera could not genuinely rotate up or down (though it could fake this with kind of a "tilting") and things like rooms above other rooms in a level were allowed only in limited ways ([hacks](hacking.md) such as extra rendering passes or invisible teleports were used to allow this). The engine was not unsimilar to that of Doom, enemies and other objects were represented with 2D [sprites](sprite.md) and levels were based on the concept of sectors (a level was really made as a 2D map in which walls were assigned different heights and textures), however it had new features -- most notably [dynamic](dynamic.md) environment, meaning that levels could change on the fly without the need for [precomputation](precomputation.md), allowing e.g. destructible environments. How the fuck did they achieve this? Instead of [BSP](bsp.md) rendering (used by Doom) Build engine used **[portal rendering](portal_rendering.md)**: basically (put in a quite simplified way) there was just a set of sectors, some of which shared walls ("portals") -- rendering would first draw the sector the player stood in (from the inside of course) and whenever it encountered a portal wall (i.e. a wall that sees into another sector), it would simply [recursively](recursion.md) render that too in the same way -- turns out this was just fine. Other extra features of the engine included tilted floors and ceilings, fake looking up/down, 3rd man view etc. The Build engine was also used in many other games (most notably [Shadow Warrior](shadow_warrior.md) and [Blood](blood.md)) and later incorporated even more advanced stuff, such as [voxel](voxel.md) models, though these weren't yet present in Duke. Just like Doom, Build engine **only used [fixed point](fixed_point.md)**, no [float](float.md)! { Hmm, actually maybe there was a small exception, see the link below. ~drummyfish }
{ Here are some details on the engine internals from a guy who specializes on this stuff: https://fabiensanglard.net/duke3d/build_engine_internals.php. ~drummyfish }
*Not to be [confused](often_confused.md) with [emoji](emoji.md).*
Emoticon (emotion icon) is a short group of [text](text.md) characters that together by their look resemble a simple picture, very often a facial expression (but also other common symbols). Emoticons are used to communicate feelings and emotions in text-only communication, such as internet chat, where body language is missing to provide this function.
TODO: more
Using [Unicode](unicode.md) in emoticons is considered cheap [cheating](cheating.md), so we won't do that here.
OpenArena (OA) is a first person pew pew arena shooter [game](game.md), a [free as in freedom](free_software.md) [clone](clone.md) of the famous game Quake 3. It runs on [GNU](gnu.md)/[Linux](linux.md), [Winshit](windows.md), [BSD](bsd.md) and other systems, it is quite light on system resources but does require a [GPU](gpu.md) acceleration (no [software rendering](sw_rendering.md)). Quake 3 engine ([Id tech 3](id_tech3.md)) has retroactively been made free software: OpenArena [forked](fork.md) it and additionally replaced the proprietary Quake assets, such as 3D models, sounds and maps, with community-created Japanese/nerd/[waifu](waifu.md)-themed [free culture](free_culture.md) assets, so as to create a completely free game. OpenArena plays almost exactly the same as Quake 3, it basically just looks different and has different maps. It has an official [wiki](wiki.md) at https://openarena.fandom.com and a forum at http://www.openarena.ws/board/. OpenArena has also been used as a research tool.
OpenArena (OA) is a first man pew pew arena shooter [game](game.md), a [free as in freedom](free_software.md) [clone](clone.md) of the famous game Quake 3. It runs on [GNU](gnu.md)/[Linux](linux.md), [Winshit](windows.md), [BSD](bsd.md) and other systems, it is quite light on system resources but does require a [GPU](gpu.md) acceleration (no [software rendering](sw_rendering.md)). Quake 3 engine ([Id tech 3](id_tech3.md)) has retroactively been made free software: OpenArena [forked](fork.md) it and additionally replaced the proprietary Quake assets, such as 3D models, sounds and maps, with community-created Japanese/nerd/[waifu](waifu.md)-themed [free culture](free_culture.md) assets, so as to create a completely free game. OpenArena plays almost exactly the same as Quake 3, it basically just looks different and has different maps. It has an official [wiki](wiki.md) at https://openarena.fandom.com and a forum at http://www.openarena.ws/board/. OpenArena has also been used as a research tool.
As of 2023 most players you encounter in OA are [cheating](cheating.md) (many [americans](usa.md) play it), but if you don't mind that, it's a pretty comfy game.
@ -20,7 +20,7 @@ Physics engine is a wide term even though one usually imagines the traditional 3
A typical physics engine will work something like this: we create a so called **physics world**, a [data structure](data_structure.md) that represents the space in which the simulation takes place (it is similar to a [scene](scene.md) in rendering engines). We then populate this world with physics elements such as rigid bodies (which can have attributes such as mass, elasticity etc.). These bodies are normally basic geometric shapes such as spheres, cylinders, boxes or capsules, or objects composed of several such basic shapes. This is unlike with rendering engines in which we normally have triangle meshes -- in physics engines triangle meshes are extremely slow to process, so for the sake of a physics engine we approximate this mesh with some of the above basic shapes (for example a creature in a game that's rendered as a hi-poly 3D model may in the physics engine be represented just as a simple sphere). Furthermore the bodies can be **[static](static.md)** (cannot move, this is sometimes done by setting their mass to infinity) or **[dynamic](dynamic.md)** (can move); static bodies normally represent the environment (e.g. the game level), dynamic ones the entities in it (player, NPCs, projectiles, ...). Making a body static has performance benefits as its movement doesn't have to be calculated and the engine can also precalculate some things for it that will make e.g. collision detections faster. We then simulate the physics of the world in so called *ticks* (similar to [frames](frame.md) in rendering); in simple cases one tick can be equivalent to one rendering frame, but properly it shouldn't be so (physics shouldn't be affected by the rendering speed, and also for the physics simulation we can usually get away with smaller "[FPS](fps.md)" than for rendering, saving some performance). Usually one tick has set some constant time length (e.g. 1/60th of a second). In each tick the engine performs a **[collision detection](collision.md)**, i.e. it finds out which bodies are touching or penetrating other bodies (this is accelerated with things such as [bounding spheres](bounding_volume.md)). Then it performs so called **collision resolution**, i.e. updating the positions, velocities and forces so that the bodies no longer collide and react to these collisions as they would in the real world (e.g. a ball will bounce after hitting the floor). There can be many more things, for example **constraints**: we may e.g. say that one body must never get further away from another body than 10 meters (imagine it's tied to it by a rope) and the engine will try to make it so that this always holds. The engine will also offer a number of other functions such as casting rays and calculating where it hits (obviously useful for shooter games).
**Integrating physics with graphics**: you will most likely use some kind of graphics engine along with physics engine, even if just for [debugging](debugging.md). As said above, keep in mind a graphics and physics engines should be **strictly separated** ([decoupled](coupling.md), for a number of reasons such as [reusability](reusability.md), easier debugging, being able to switch graphics and physics engines etc.), even though they closely interact and may affect each other in their design, e.g. by the data structures you choose for your program (voxel graphics will imply voxel physics etc.). In your program you will have a **physics world and a graphics scene**, both contain their own elements: the scene has graphics elements such as 3D models or particle systems, the physics world has elements such as rigid bodies and force fields. Some of the graphical and physics entities are connected, for example a 3D model of a tree may be connected to a physics rigid body of a cone shape. NOT ALL graphics elements have counterparts in the physics simulation (e.g. a smoke effect or light aren't present in the physics simulation) and vice versa (e.g. player in a first-person game has no 3D model but still has some physics shape). The connection between graphics and physics elements should be done **above** both engines (i.e. do NOT add pointers to physics object to graphics elements etc.). This means that e.g. in a game you create a higher abstract environment -- for example a level -- which stands above the graphics scene and physics world and has its own game elements, each game element may be connected to a graphics or physics element. These game elements have attributes such as a position which gets updated according to the physics engine and which is transferred to the graphics elements for rendering. Furthermore remember that **graphics and physics should often run on different "FPS"**: graphics engines normally try to render as fast as they can, i.e. reach the highest [FPS](fps.md), while physics engines often have a time step, called a **tick**, of fixed time length (e.g. 1/30th of a second) -- this is so that they stay [deterministic](determinism.md), accurate and also because physics may also run on much lower FPS without the user noticing ([interpolation](interpolation.md) can be used in the graphics engine to smooth out the physics animation for rendering). "[Modern](modern.md)" engines often implement graphics and physics in separate [threads](thread.md), however this is not [suckless](suckless.md), in most cases we recommend the [KISS](kiss.md) approach of a single thread (in the main loop keep a timer for when the next physics tick should be simulated).
**Integrating physics with graphics**: you will most likely use some kind of graphics engine along with physics engine, even if just for [debugging](debugging.md). As said above, keep in mind a graphics and physics engines should be **strictly separated** ([decoupled](coupling.md), for a number of reasons such as [reusability](reusability.md), easier debugging, being able to switch graphics and physics engines etc.), even though they closely interact and may affect each other in their design, e.g. by the data structures you choose for your program (voxel graphics will imply voxel physics etc.). In your program you will have a **physics world and a graphics scene**, both contain their own elements: the scene has graphics elements such as 3D models or particle systems, the physics world has elements such as rigid bodies and force fields. Some of the graphical and physics entities are connected, for example a 3D model of a tree may be connected to a physics rigid body of a cone shape. NOT ALL graphics elements have counterparts in the physics simulation (e.g. a smoke effect or light aren't present in the physics simulation) and vice versa (e.g. player in a first man game has no 3D model but still has some physics shape). The connection between graphics and physics elements should be done **above** both engines (i.e. do NOT add pointers to physics object to graphics elements etc.). This means that e.g. in a game you create a higher abstract environment -- for example a level -- which stands above the graphics scene and physics world and has its own game elements, each game element may be connected to a graphics or physics element. These game elements have attributes such as a position which gets updated according to the physics engine and which is transferred to the graphics elements for rendering. Furthermore remember that **graphics and physics should often run on different "FPS"**: graphics engines normally try to render as fast as they can, i.e. reach the highest [FPS](fps.md), while physics engines often have a time step, called a **tick**, of fixed time length (e.g. 1/30th of a second) -- this is so that they stay [deterministic](determinism.md), accurate and also because physics may also run on much lower FPS without the user noticing ([interpolation](interpolation.md) can be used in the graphics engine to smooth out the physics animation for rendering). "[Modern](modern.md)" engines often implement graphics and physics in separate [threads](thread.md), however this is not [suckless](suckless.md), in most cases we recommend the [KISS](kiss.md) approach of a single thread (in the main loop keep a timer for when the next physics tick should be simulated).
Suckless, software that [sucks](suck.md) less, is a type of [free](free_software.md) [software](software.md), programming philosophy as well as an organization (http://suckless.org/), that tries to adhere to a high technological [minimalism](minimalism.md), [freedom](freedom.md) and [hackability](hacking.md), and opposes so called [bloat](bloat.md) and unnecessary complexity which has been creeping into most "[modern](modern.md)" software and by which technology has started to become less useful and more burdening. It is related to [Unix philosophy](unix_philosophy.md) and [KISS](kiss.md) but brings some new ideas onto the table. It became somewhat known and highly influenced some newly formed groups, e.g. [Bitreich](bitreich.md) and our own [less retarded software](lrs.md). Suckless seems to share many followers with [cat-v.org](cat_v.md).
Suckless, software that [sucks](suck.md) less, is a type of [free](free_software.md) [software](software.md), programming philosophy as well as an organization (http://suckless.org/), that tries to adhere to a high technological [minimalism](minimalism.md), [freedom](freedom.md) and [hackability](hacking.md), and opposes so called [bloat](bloat.md) and unnecessary complexity which has been creeping into most "[modern](modern.md)" software and by which technology has started to become less useful and more burdening. It is related to [Unix philosophy](unix_philosophy.md) and [KISS](kiss.md) but brings some new ideas onto the table. It became somewhat known and highly influenced some newly formed groups, e.g. [Bitreich](bitreich.md) and our own [less retarded software](lrs.md). Suckless seems to share many followers with [cat-v.org](cat_v.md). Suckless has a very minimalist logo that's just a super simple letter *S*.
The community used to be relatively a small underground niche, however after a rise in popularity sometime in 2010s, thanks to tech youtubers such as [Luke Smith](luke_smith.md), [Distro Tube](distro_tube.md) and [Mental Outlaw](mental_outlaw.md), the awareness about the group spread a lot wider, even mainstream programmers now usually know what *suckless* stands for. It has also gained traction on [4chan](4chan.md)'s technology board which again boosted suckless popularity but also inevitably brought some retardism in. While the group core consisting a lot of expert programmers and [hackers](hacker.md) mostly interested in systems like [GNU](gnu.md)/[Linux](linux.md), [BSDs](bsd.md) and [Plan 9](plan9.md), a lot of less skilled "[Linux](linux.md)" users and even complete non-programmers now hang around suckless to various degrees -- especially the [dwm](dwm.md) window manager has seen a great success among "Unix porn" lovers and chronic [ricers](ricing.md). While most of the true suckless followers are hardcore minimalists and apply their principles to everything, many of the noobs around suckless just cherry pick programs they find nice to look at and integrate them in their otherwise bloated systems.
@ -48,4 +48,9 @@ Here is a comparison of average European country before and after infestation wi
| wanted to commit suicide | no | yes |
| society worked | kinda | no |
In [Europe](europe.md), or maybe just anywhere else in the world, you are afraid of getting hit by a car because you might die, in America you afraid of it because you couldn't afford the ambulance bill and would get into unpayable debt (yes, even if you pay "health insurance"). You can literally find footage of half dead people running away from ambulances so that they don't have to go to debt for being kept alive. In Europe you are afraid to hit someone with a car because you might kill him, in America you are afraid of it because he might sue you. This is not an exaggeration or [joke](jokes.md), it's literally how it is -- it's incredible how people can believe the country is somehow "more advanced", it is quite literally the least developed country in history.
In [Europe](europe.md), or maybe just anywhere else in the world, you are afraid of getting hit by a car because you might die, in America you afraid of it because you couldn't afford the ambulance bill and would get into unpayable debt (yes, even if you pay "health insurance"). You can literally find footage of half dead people running away from ambulances so that they don't have to go to debt for being kept alive. In Europe you are afraid to hit someone with a car because you might kill him, in America you are afraid of it because he might sue you. This is not an exaggeration or [joke](jokes.md), it's literally how it is -- it's incredible how people can believe the country is somehow "more advanced", it is quite literally the least developed country in history.
@ -4,6 +4,6 @@ World of Warcraft (WoW) is an AAA [proprietary](proprietary.md) [game](game.md)
There is a [FOSS](foss.md) implementation of WoW server called [MaNGOS](mangos.md) (now having some [forks](fork.md)) that's used to make private servers. The client is of course proprietary and if you dare make a popular server Blizzard (or whatever it's called now, it's probably merged with [Micro$oft](microfost.md) or something now) will just rape you.
The classic WoW (mostly the vanilla but we can possibly extend this to the end of WOTLK) lied somewhere in the middle between good old and shitty [modern](modern.md) games, it had many great things like the iconic awesome [low poly](low_poly.md) hand painted stylized graphics, big open world, amazing PvP and PvE, but the modern poison was already creeping in. The WoW of today is of course 100% pure [shit](shit.md), it's [bloated](blot.md) beyond any imagination, the graphics is absolutely ruined (semi realistic style, everything looks like a cheap plastic toy, with the retarded shit like character outlines, it looks much worse and is also 10000x heavier on the GPU), it's extremely [censored](censorship.md) and [politically correct](political_correctness.md) (you can literally change gender of your character at barbershop lol, they did this out of fear of [LGBT](lgbt.md), they also removed the *spit* emote because it was "offensive" -- yes, a game that's all about [war](war.md) and killing and literally has war in its name must restrain you from hurting someone's feelings by spitting on the ground). You can also make any weapon or armor make look like any other weapon or armor ("transmog"), that just kills the whole point of an RPG, some players also see a different world than others ("phasing") and so on. Also basically every race can now be any class, even if it doesn't make any sense, like Tauren rogue (in the past this used to be a [joke](joke.md) but today jokes are made into reality) -- otherwise it would be [racism](racism.md) or something. The game has about 1 billion expansions while the lore writers had already ran out of any ideas after like 5 of them, so they now just started to mess around with time travel and alternative timelines (resorting to time rape is always that desperate last resort move which signifies the work has been dead for a long time by then). The game is so bad Blizzard even started running official vanilla, no expansion servers ("classic WoW"), which is the only thing holding it above the water now. Of course before this they nuked all the popular unofficial private vanilla servers with legal threats so they could force a [monopoly](monopoly.md) -- this destroyed great many communities but Blizzard is a corporation so they could do anything they want.
The classic WoW (mostly the vanilla but we can possibly extend this to the end of WOTLK) lied somewhere in the middle between good old and shitty [modern](modern.md) games, it had many great things like the iconic awesome [low poly](low_poly.md) hand painted stylized graphics, big open world, amazing PvP and PvE, but the modern poison was already creeping in. The WoW of today is of course 100% pure [shit](shit.md), it's [bloated](blot.md) beyond any imagination, the graphics is absolutely ruined (semi realistic style, everything looks like a cheap plastic toy, with the retarded shit like character outlines, it looks much worse and is also 10000x heavier on the GPU), it's extremely [censored](censorship.md) and [politically correct](political_correctness.md) (you can literally change gender of your character at barbershop lol, they did this out of fear of [LGBT](lgbt.md), they also removed the *spit* emote because it was "offensive" -- yes, a game that's all about [war](war.md) and killing and literally has war in its name must restrain you from hurting someone's feelings by spitting on the ground). You can also make any weapon or armor make look like any other weapon or armor ("transmog"), that just kills the whole point of an RPG, some players also see a different world than others ("phasing") and so on. Also basically every race can now be any class, even if it doesn't make any sense, like Tauren rogue (in the past this used to be a [joke](joke.md) but today jokes are made into reality) -- otherwise it would be [racism](racism.md) or something. A rat in level 80-90 area is 1000 times stronger than a bear in level 1-10 area, that's just fucked up. The game has about 1 billion expansions while the lore writers had already ran out of any ideas after like 5 of them, so they now just started to mess around with time travel and alternative timelines (resorting to time rape is always that desperate last resort move which signifies the work has been dead for a long time by then). The game is so bad Blizzard even started running official vanilla, no expansion servers ("classic WoW"), which is the only thing holding it above the water now. Of course before this they nuked all the popular unofficial private vanilla servers with legal threats so they could force a [monopoly](monopoly.md) -- this destroyed great many communities but Blizzard is a corporation so they could do anything they want.
{ For me the peak of Warcraft was [Warcraft III:TFT](warcraft.md), it was perfect in every way (except for being proprietary and bloated of course). As a great fan of Warcraft III, seeing WoW in screenshots my fantasy made it the best game possible to be created. When I actually got to playing it it was really good -- some of my best memories come from that time -- nevertheless I also remember being disappointed in many ways. Especially with limitation of freedom (soulbound items, forced grinding, effective linearity of leveling, GMs preventing hacking the game in fun ways etc.) and here and there a lack of polish (there were literally visible unfinished parts of the map, also visual transitions between zones too fast and ugly and the overall world design felt kind of bad), laziness and repetitiveness of the design. I knew how the game could be fixed, however I also knew it would never be fixed as it was in hands of a corporation that had other plans with it. That was the time I slowly started to see things not being ideal and the possibility of a great thing going to shit. ~drummyfish }
