Update
Miloslav Ciz
2 years ago
parent
f7e0fb4b27
commit
556653d6e4
@ -0,0 +1,3 @@
|
||||
# Apple
|
||||
|
||||
Apple is a [terrorist](terrorism.md) organization and one of the biggest [American](usa.md) computer fashion [corporations](corporation.md), infamously founded by [Steve Jobs](steve_jobs.md), it creates and sells overpriced, abusive, highly consumerist electronic devices.
|
||||
@ -0,0 +1,7 @@
|
||||
# Collision
|
||||
|
||||
Collision happens when two or more things want to occupy the same spot. This situation usually needs to be addressed somehow; then we talk about **collision resolution**. In [programming](programming.md) there are different types of collisions, for example:
|
||||
|
||||
- **[hash](hash.md) collision**: When two items produce the same hash, they will map to the same index in a [hash table](hash_table.md). Typical solution is to have a [list](list.md) at each table index so that multiple items can fit there.
|
||||
- **collision of bodies in a [physics engine](physics_engine.md)**: See [collision_detection](collision_detection.md). These collision are resolved by separating the bodies and updating their velocities so that they "bounce off" as in [real life](irl.md).
|
||||
- **request collision**: General situation in which multiple clients request access to something that can be used only by one client at a time, e.g. a communication [bus](bus.md). Resolution is usually done by some kind of [arbiter](arbiter.md) who decides, by whatever algorithm, who to grant the access to.
|
||||
@ -0,0 +1,21 @@
|
||||
# Collision Detection
|
||||
|
||||
Collision detection is an essential problem e.g. of simulating physics of mechanical bodies in [physics engines](physics_engine.md) (but also elsewhere), it tries to detect whether (and also how) geometric shapes overlap. Here we'll be talking about the collision detection in physics engine, but the problem appear in other contexts too (e.g. [frustum culling](frustum_culling.md) in [computer graphics](graphics.md)). Collision detection potentially leads to so called *collision resolution*, a different stage that tries to deal with the detected collision (separate the bodies, update their velocities, make them "bounce off"). Physics engines are mostly divided into 2D and 3D ones so we also normally either talk about 2D or 3D collision detection (3D being, of course, a bit more complex).
|
||||
|
||||
There are two main types of collision detection:
|
||||
|
||||
- **[discrete](discrete.md)**: Detecting collisions only at discrete points in time (each engine tick or "frame") -- this is easier but can result in detecting the collisions in wrong ways or missing them completely (imagine a fast flying object that in one moment is wholly in front of a wall and at the next instant wholly behind it). Nevertheless this is completely usable, one just has to be careful enough about the extreme cases.
|
||||
- **[continuous](continuous.md)**: Detecting collisions considering the continuous motion of the bodies (still done at discrete ticks but [analytically](analytical.md) considering the whole motion since the last tick) -- this is more difficult to program and more costly to compute, but also correctly detects collisions even in extreme cases. Sometimes engines perform discrete detection by default and use continuous detection in special cases (e.g. when speeds become very high or in other error-prone situations). Continuous detection can be imagined as a collision detection of a higher dimensional bodies where the added dimension is time -- e.g. detecting collisions of 2D spheres becomes detecting collisions of "tubes" in 3D space. If you don't want to go all the way to implementing continuous collisions, you may consider an in-between solution by detecting collisions in smaller steps (which may also be done only sometimes, e.g. only for high speed bodies or only when an actual discrete collision is detected).
|
||||
|
||||
Collision detection is non-trivial because we need to detect not only the presence of the collision but also its parameters which are typically the exact **point of collision, collision depth and collision [normal](normal.md)** -- these are needed for subsequently resolving the collision (typically the bodies will be shifted along the normal by the collision depth to become separated and [impulses](impulse.md) will be applied at the collision point to update their velocities). We also need to detect **general cases**, i.e. collisions of whole volumes (imagine e.g. a tiny cuboid inside an arbitrarily rotated bigger cone). This is very hard and/or expensive for some complex shapes such as general 3D triangle meshes (which is why we approximate them with simpler shapes). We also want the detection algorithm to be at least reasonably **fast** -- for this reason collision detection mostly happens in two phases:
|
||||
|
||||
- **broad phase**: Quickly estimates which bodies MAY collide, usually with [bounding volumes](bounding_volume.md) (such as spheres or [axis aligned bounding boxes](aabb.md)) or space indexing and algorithms such as *[sweep and prune](sweep_and_prune.md)*. This phase quickly opts-out of checking collision of objects that definitely CANNOT collide because they're e.g. too far away.
|
||||
- **narrow phase**: Applying the precise, expensive collision detection on the potentially colliding pairs of bodies determined in the broad phase. This yields the real collisions.
|
||||
|
||||
In many cases it is also important to correctly detect the **order of collisions** -- it may well happen a body collides not with one but with multiple bodies at the time of collision detection and the computed behavior may vary widely depending on the order in which we consider them. Imagine that body *A* is colliding with body *B* and body *C* at the same time; in [real life](real_life.md) *A* may have first collided with *B* and be deflected so that it never hits *C*, or the other way around, or it might have collided with both. In continuous collision detection we know the order as we also have exact time coordinate of each collision (even though the detection itself is still computed at discrete time steps), i.e. we know which one happened first. With discrete collisions we may use [heuristics](heuristic.md) such as the direction in which the bodies are moving, but this may fail in certain cases (considering e.g. rotations).
|
||||
|
||||
**On shapes**: general rule is that **mathematically simpler shapes are better for collision detection**. Spheres (or circles in 2D) are the best, they are stupidly simple -- a collision of two spheres is simply decided by their [distance](distance.md) (i.e. whether the distance of their center points is less that the sum of the radia of the spheres), which also determines the collision depth, and the collision normal is always aligned with the vector pointing from one sphere center to the other. So **if you can, use spheres** -- it is even worth using multiple spheres to approximate more complex shapes if possible. [Capsules](capsule.md) ("extruded spheres"), infinite planes, half-planes, infinite cylinders (distance from a line) and axis-aligned boxes are also pretty simple. Cylinders and cuboids with arbitrary rotation are bit harder. Triangle meshes (the shape most commonly used for real-time 3D models) are very difficult but may be [approximated](approximation.md) e.g. by a [convex hull](convex_hull.md) which is manageable (a convex hull is an intersection of a number of half-spaces) -- if we really want to precisely collide full 3D meshes, we may split each one into several convex hulls (but we need to write the non-trivial splitting algorithm of course). Also note that you need to write a detection algorithm for any possible pair of shape types you want to support, so for *N* supported shapes you'll need *N * (N + 1) / 2* detection algorithms.
|
||||
|
||||
{ In theory we may in some cases also think about using iterative/numerical methods to find collisions, i.e. starting at some point between the bodies and somehow stepping towards their intersection until we're close enough. Another ideas I had was to use [signed distance functions](sdf.md) for representing static environments, it could have some nice advantages. But I'm really not sure how well or whether it would really work. ~drummyfish }
|
||||
|
||||
TODO: some actual algorithms
|
||||
@ -1,3 +1,3 @@
|
||||
# Firmware
|
||||
|
||||
Firmware is a type of very basic [software](software.md) that's usually preinstalled on a device from factory and serves to provide the most essential functionality of the device. On simple devices, like mp3 players or remote controls, firmware may be all that's ever needed for the devices functioning, while on more complex ones, such as [personal computers](pc.md), firmware (e.g. [BIOS](bios.md) or [UEFI](uefi.md)) allows basic configuration, allows installation of more complex software (such as an [operating system](os.md)) and possibly provides functions that the installed software can use. Firmware is typically not meant to be rewritten by the user and is installed in some kind of memory that's not very easy to rewrite, it may even be hard-wired in which case it becomes something on the very boundary of software and [hardware](hardware.md).
|
||||
Firmware is a type of very basic [software](software.md) that's usually preinstalled on a device from factory and serves to provide the most essential functionality of the device. On simple devices, like mp3 players or remote controls, firmware may be all that's ever needed for the device's functioning, while on more complex ones, such as [personal computers](pc.md), firmware (e.g. [BIOS](bios.md) or [UEFI](uefi.md)) allows basic configuration and installation of more complex software (such as an [operating system](os.md)) and possibly provides functions that the installed software can use. Firmware is normally not meant to be rewritten by the user and is installed in some kind of memory that's not very easy to rewrite, it may even be hard-wired in which case it becomes something on the very boundary of software and [hardware](hardware.md).
|
||||
|
||||
@ -0,0 +1,5 @@
|
||||
# Gatekeeping
|
||||
|
||||
|
||||
|
||||
[Soyence](soyence.md) practices gatekeeping, they
|
||||
@ -0,0 +1,7 @@
|
||||
# Micro$oft
|
||||
|
||||
Micro$soft (officially Microsoft, MS) is a terrorist organization, [software](software.md) [corporation](corporation.md) named after it's founder's dick -- it is, along with [Google](google.md), [Apple](apple.md) [et al](et_al.md) one of the biggest organized crime groups in history, best known for holding the world captive with its highly abusive "[operating system](os.md)" called [Windows](windows.md), as well as for leading an aggressive war on [free software](free_software.md) and utilizing many unethical and/or illegal business practices such as destroying any potential competition with the [*Embrace Extend Extinguish*](eee.md) strategy.
|
||||
|
||||
Microsoft is unfortunately among the absolutely most powerful entities in the world (that sucks given they're also among the most hostile ones) -- likely more powerful than any government and most other corporations, it is in their power to **immediately destroy any country** with the push of a button, it's just a question of when this also becomes their interest. This power is due to them having **complete control over almost absolute majority of personal computers in the world** (and therefore by extension over all devices, infrastructure, organization etc.), through their [proprietary](proprietary.md) ([malware](malware.md)) "[operating system](os.md)" [Windows](windows.md) that has built-in [backdoor](backdoor.md), allowing Microsoft immediate access and control over practically any computer in the world. The backdoor "feature" isn't even hidden, it is officially and openly admitted (it is euphemistically called [auto updates](autoupdate.md)). Microsoft prohibits studying and modification of Windows under threats including physical violence (tinkering with Windows violates its [EULA](eula.md) which is a lawfully binding license, and law can potentially be enforced by police using physical force). Besides legal restrictions Microsoft applies high [obfuscation](obfuscation.md), [bloat](bloat.md), [SAASS](saass.md) and other techniques preventing user freedom and defense against terrorism, and forces its system to be installed in schools, governments, power plants, hospitals and basically on every computer anyone buys. Microsoft can basically (for most people) turn off the [Internet](internet.md), electricity, traffic control system etc. Therefore every hospital, school, government and any other institution has to bow to Microsoft.
|
||||
|
||||
TODO: it would take thousands of books to write just a fraction of all the bad things, let's just add the most important ones
|
||||
@ -1,21 +1,23 @@
|
||||
# Physics Engine
|
||||
|
||||
Physics engine is a [software](software.md) (usually a [library](library.md)) whose purpose is to simulate physical laws of mechanics, i.e. things such as forces, [rigid](rigid_body.md) and [soft](soft_body.md) body collisions, particle motion, fluid dynamics etc.
|
||||
Physics engine is a [software](software.md) (usually a [library](library.md)) whose purpose is to simulate physics laws of mechanics, i.e. things such as forces, [rigid](rigid_body.md) and [soft](soft_body.md) body collisions, [particle](particle.md) motion, fluid dynamics etc.
|
||||
|
||||
{ When it comes to classic 3D rigid body physics engines, they're extremely hard to make, much more than for example an advanced 3D rendering engine, especially when you want to make them [LRS](lrs.md) (without floating point, ...) and/or general and somewhat physically correct (being able to simulate e.g. the Dzhanibekov effect, satisfying all the conservation laws, continuous collision detection etc.). Good knowledge of mechanics and things like [quaternions](quaternion.md) and 3D rotations is just the beginning, difficulties arise in every aspect of the engine, and of those there are many. As I've found, 32 bit fixed point is not enough for a general engine (even though it is enough for a rendering engine), you'll run into precision problems as you need to represent both relatively high and low energies. You'll also run into stability issues such as stable contacts, situations with multiple objects stacked on top of each other starting to bounce on their own etc. Even things such as deciding in what order to resolve collisions are very difficult, they can lead to many bugs such as a car not being able to drive on a straight road made of several segments. Collision detection alone for all combinations of basic shapes (sphere, cuboid, cylinder, capsule, ... let alone general triangle mesh) are hard as you want to detect general cases (not only e.g. surface collisions) and you want to extract all the parameters of the collisions (collision point, normal etc.) AND you want to make it fast. And of course you'll want to add acceleration structures and many other thing on top. So think twice before deciding to write your own physics engine.
|
||||
{ When it comes to classic 3D rigid body physics engines, they're extremely hard to make, much harder than for example an advanced 3D rendering engine, especially when you want to make them [LRS](lrs.md) (without floating point, ...) and/or general and somewhat physically correct (being able to simulate e.g. the Dzhanibekov effect, satisfying all the conservation laws, continuous collision detection etc.). Good knowledge of mechanics and things like [quaternions](quaternion.md) and 3D rotations is just the beginning, difficulties arise in every aspect of the engine, and of those there are many. As I've found, 32 bit fixed point is not enough for a general engine (even though it is enough for a rendering engine), you'll run into precision problems as you need to represent both relatively high and low energies. You'll also run into stability issues such as stable contacts, situations with multiple objects stacked on top of each other starting to bounce on their own etc. Even things such as deciding in what order to resolve collisions are very difficult, they can lead to many bugs such as a car not being able to drive on a straight road made of several segments. Collision detection alone for all combinations of basic shapes (sphere, cuboid, cylinder, capsule, ... let alone general triangle mesh) are hard as you want to detect general cases (not only e.g. surface collisions) and you want to extract all the parameters of the collisions (collision location, depth, normal etc.) AND you want to make it fast. And of course you'll want to add acceleration structures and many other thing on top. So think twice before deciding to write your own physics engine.
|
||||
|
||||
A sane approach may be to write a simplified engine specifically for your program, e.g. many times you get away with creating an engine that doesn't work with rigid bodies but some simple meshes made of spheres connected by springs. That's super simple, doable and probably [good enough](good_enough.md). ~drummyfish }
|
||||
A sane approach may be to write a simplified engine specifically for your program, for example a Minecraft-like game may just need non-rotating capsules in a voxel environment, that's not that hard. You may perhaps get away with a bit of cheating, e.g. simulating rigid bodies as really stiff soft bodies, it may not be as efficient and precise but it's simpler to program. It may be [good enough](good_enough.md). ~drummyfish }
|
||||
|
||||
Physics engine is a wide term even though one usually imagines the traditional 3D rigid body engine used in games such as [GTA](gta.md). These engines may nevertheless have different purposes, features and even basic paradigms, some may e.g. be specialized just for computing precise ballistic trajectories for the army, some may serve for simulating weather etc. Some common classifications and possible characteristics of physics engines follow:
|
||||
|
||||
- **[2D](2d.md) vs [3D](3d.md)**: 2D engines are generally much more simple to implement than 3D, for example because of much more simple math for rotations and collision detections.
|
||||
- **[2D](2d.md) vs [3D](3d.md)**: 2D engines are generally much more simple to implement than 3D, for example because of much more simple math for rotations and collision detection. Graphics and physics are usually loosely interconnected (though they should be [decoupled](coupling.md)) in that the way in which we represent graphics (2D, general 3D, [BSP](bsp.md), [voxels](voxel.md), ...) usually also determines how we compute physics, so that there may also exist e.g. "[pseudo 3D](pseudo_3d.md)" physics engines as part of "pseudo 3D" renderers, e.g. the one used in [Doom](doom.md) etc.
|
||||
- **[real time](real_time.md) vs [offline](offline.md)**: Real-time ones are mostly intended to be used in the entertainment industry, i.e. [games](game.md), movies etc. as they can compute somewhat realistic looking results quickly but for the price of dropping high accuracy (they use many [approximations](approximation.md)). Scientific engines may prefer to be offline and taking longer time to compute more precise results.
|
||||
- **[rigid body](rigid_body.md) vs [soft body](soft_body.md)**: Rigid body engines don't allow bodies to deform while soft body ones do -- in real life all bodies are soft, but neglecting this detail and considering shapes rigid can have benefits (such as being able to consider the body as a whole and not having to simulate all its individual points). Of course, a complex engine may implement both rigid and soft body physics.
|
||||
- **paradigm**: The basic approach to implementing the simulation, e.g. being [impulse](impulse.md)-based (applying impulses to correct errors), constraint-based (solving equations to satisfy imposed constraints), penalty-based (trying to find equilibriums of forces) etc.
|
||||
- **[discrete](discrete.md) vs [continuous](continuous.md) collision detection**: Discrete collision detection only detects collisions at single points in time (at each engine tick) and are simple than those implementing continuous collision detection. Discrete engine are less accurate, consider e.g. that a very fast moving object can pass through a wall because at one instant it is in front of it while at the next tick it is behind it. Continuous collisions won't allow this to happen, but are more difficult to program, may be slower etc. For games discrete collisions are usually [good enough](good_enough.md).
|
||||
- **features: fluid, cloth, particles, [ragdoll](ragdoll.md), [inverse kinematics](inverse_kinematics.md), [GPU](gpu.md) acceleration, [determinism](determinism.md), [voxels](voxel.md), ...**: These are a number of additional features the engine can have such as the ability to simulate fluids (which itself is a huge field of its own) or cloths.
|
||||
- **features: fluid, cloth, particles, [ragdoll](ragdoll.md), [inverse kinematics](inverse_kinematics.md), [GPU](gpu.md) acceleration, [determinism](determinism.md), [voxels](voxel.md), [acceleration](acceleration.md) [data structures](data_structure.md) ...**: These are a number of additional features the engine can have such as the ability to simulate fluids (which itself is a huge field of its own) or cloths, some go as far as e.g. integrating motion-captured animations of humans with physics to create smooth realistic animations e.g. of running over walking pedestrians with a car and so on.
|
||||
|
||||
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 something as simple as a plain sphere). Furthermore the bodies can be **[static](static.md)** (cannot move, this is sometimes done by setting the 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**, i.e. it finds out which bodies are touching or penetrating other bodies (this is accelerated with things such as [bounding spheres](bounding_sphere.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).
|
||||
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).
|
||||
|
||||
## Existing Engines
|
||||
|
||||
|
||||
@ -0,0 +1,26 @@
|
||||
# Signed Distance Function
|
||||
|
||||
Signed distance function (SDF, also signed distance field) is a [function](function.md) that for any point in space returns its distance to the closest point of some geometric shape, and also the information whether that point is outside or inside that shape (if inside, the distance is negative, outside it's positive and exactly on the surface it is zero -- hence *signed* distance function). SDFs find use in elegantly representing some surfaces and solving some problems, most notably in computer [graphics](graphics.md), e.g. for smoothly rendering upscaled [fonts](font.md), in [raymarching](raymarching.md), implementing [global illumination](gi.md), as a 3D model storage representation, for [collision detection](collision_detection.md) etc. SDFs can exist anywhere where [distances](distance.md) exist, i.e. in 2D, 3D, even non-[Euclidean](euclidean.md) spaces etc. (and also note the distance doesn't always have to be Euclidean distance, it can be anything satisfying the [axioms](axiom.md) of a distance metric, e.g. [taxicab distance](taxicab.md)).
|
||||
|
||||
Sometimes SDF is extended to also return additional information, e.g. the whole [vector](vector.md) to the closest surface point (i.e. not only the distance but also a direction towards it) which may be useful for specific algorithms.
|
||||
|
||||
**What is it all good for?** We can for example implement quite fast [raytracing](raytracing.md)-like rendering of environments for which we have a fast SDF. While traditional raytracing has to somehow test each ray for potential intersection against all 3D elements in the scene, which can be slow (and complicated), with SDF we can performs so called [raymarching](raymarching.md), i.e. iteratively stepping along the ray according to the distance function (which hints us on how big of a step we can make so that we can potentially quickly jump over big empty areas) until we get close enough to a surface which we interpret as an intersection -- if the SDF is fast, this approach may be pretty efficient ([Godot](godot.md) implemented this algorithm to render real-time global illumination and reflections even in GPUs that don't support accelerated raytracing). Programs for rendering 3D [fractals](fractal.md) (such as Mandelbulber) work on this principle as well. SDFs can also be used as a format for representing shapes such as [fonts](font.md) -- there exists a method (called multi-channel SDF) that stores font glyphs in bitmaps of quite low-resolution that can be rendered at arbitrary scale in a quality almost matching that of the traditional vector font representation -- the advantage over the traditional vector format is obviously greater simplicity and better compatibility with GPU hardware that's optimized for storing and handling bitmaps. Furthermore we can trivially increase or decrease weight (boldness) of a font represented by SDFs simply by adjusting the rendering distance threshold. SDFs can also be used for [collision detection](collision_detection.md) and many other things. One advantage of using SDFs is their **generality** -- if we have an SDF raymarching algorithm, we can plug in any shape and environment just by constructing its SDF, while with traditional raytracing we normally have to write many specialized algorithms for detecting intersections of rays with different kinds of shapes, i.e. we have many special cases to handle.
|
||||
|
||||
**How is an SDF implemented?** Well, it's a [function](function.md), it can be implemented however we wish and need, it depends on the use case, but we probably want it to be **fast** because algorithms that work with SDFs commonly call it often. SDF of simple mathematical shapes (and their possible combinations such as unions, see. e.g. [CSG](csg.md)), e.g. spheres, can be implemented very easily (SDF of a sphere = distance to the sphere center minus its radius); even the already mentioned 3D [fractals](fractal.md) have functions that can be used to quickly estimate the distance towards their surface. Other times -- e.g. where arbitrary shapes may appear -- the function may be [precomputed](precomputing.md) into some kind of N dimensional [array](array.md), we might say we use a precomputed [look up table](LUT.md). This can be done in a number of ways, but as a simple example we can imagine raymarching mirror reflections with which we can subdivide the 3D scene into a grid and into each cell we store the SDF value at its center point (which here may be computed by even a relatively slow algorithm), which will allow for relatively fast search of intersections of rays with the surface (at any point along the ray we may check the SDF value of the current cell which will likely provide information for how big a step we can make next).
|
||||
|
||||
```
|
||||
. . . . . . . . 3 2 2 2 2 2 2 2
|
||||
. . . . . . . . 3 2 1 1 1 1 1 1
|
||||
. . . X X X X X 2 2 1 0 0 0 0 0
|
||||
. . . X X X X X 2 1 1 0-1-1-1 0
|
||||
. . X X X X X X 2 1 0 0-1-2-1 0
|
||||
. . X X X X X X 2 1 0-1-1-2-1 0
|
||||
. . X X X X X X 2 1 0-1-1-1-1 0
|
||||
. . X X X X X X 2 1 0 0 0-1-1 0
|
||||
. . . . X X X X 2 1 1 1 0 0 0 0
|
||||
. . . . . . . . 2 2 2 1 1 1 1 1
|
||||
```
|
||||
|
||||
*Shape (left) and its SDF (right, distances rounded to integers).*
|
||||
|
||||
SDFs in computer graphics were being explored a long time ago but seem to have start to become popular since around the year 2000 when Frisken [et al](et_al.md) used adaptive SDFs as an efficient representation for 3D models preserving fine details. In 2007 [Valve](valve.md) published a paper at [SIGGRAPH](siggraph.md) showing the bitmap representation of SDF shapes that they integrated into their [Source](source_engine.md) engine.
|
||||
@ -1,3 +1,5 @@
|
||||
# Soyence
|
||||
|
||||
Soyence is a mainstream propaganda and [business](business.md) claiming itself to be [science](science.md). It's what typical reddit atheists believe is science. It's what Neil De Grass Tyson tells you is science.
|
||||
Soyence is a mainstream propaganda and [business](business.md) claiming itself to be [science](science.md). It is what the typical reddit [atheist](atheism.md) believes is science or what Neil De Grass Tyson tells you is science. Soyence calls itself science and [gatekeeps](gatekeeping.md) itself by calling unpopular science -- such as that regarding human [race](race.md) or questioning big pharma [vaccines](vaccine.md) -- [pseudoscience](pseudoscience.md).
|
||||
|
||||
Soyence relies on low [IQ](iq.md) and shallow education of its followers while making them believe they are smart, it produces propaganda such as "documentaries" with Morgan Freeman, series like The Big Bang Theory and [YouTube](youtube.md) videos with titles like "Debunking Flat Earth with FACTS AND LOGIC", so there's a huge mass of [NPCs](npc.md) thinking they are Einsteins who blindly support this cult. Soyence tries to ridicule and punish thinking outside the box and asking specific questions, i.e. it is not dissimilar to a mass [religion](religion.md).
|
||||
Loading…
Reference in New Issue