Dropbox Paper, or simply Paper, is a collaborative document-editing service developed by Dropbox. Originating from the company's acquisition of document collaboration company Hackpad in April 2014, Dropbox Paper was officially announced in October 2015, and launched in January 2017. It offers a web application, as well as mobile apps for Android and iOS. Dropbox Paper was described in the official announcement post as "a flexible workspace that brings people and ideas together. With Paper, teams can create, review, revise, manage, and organize — all in shared documents". Reception of Dropbox Paper has been mixed. Critics praised collaboration functionality, including content available immediately, the ability to mention specific collaborators, assign tasks, write comments, as well as editing attribution, and revision history. It received particular praise for its support for rich media from a variety of sources, with one reviewer noting that the Paper's support for rich media exceeds the capabilities of most of its competitors. However, it was criticized for a lack of formatting options and editing features. While the user interface was liked for being minimal, reviewers cited the lack of a fixed formatting bar and missing features present in competitors' products as making Dropbox Paper seem like a "light" tool. == History == Dropbox acquired document collaboration company Hackpad in April 2014. A year later, Dropbox launched a Dropbox Notes note-taking product in beta testing phase. Dropbox Paper was officially announced on October 15, 2015, followed by an open beta and release of mobile Android and iOS apps in August 2016. Dropbox Paper was officially released on January 30, 2017. == Reception == In a comparison between Dropbox Paper and Evernote, PC World's Michael Ansaldo wrote that "With its emphasis on document creation, you might expect formatting to be front and center in Dropbox Paper. That's not the case." Ansaldo noted the lack of a "fixed formatting toolbar as you'd find in Evernote or a word processor like Google Docs or Microsoft Word. Instead, the text editor appears as a floating ribbon only when you highlight selected text." The only formatting options available for emphasis were bolding, strikethrough, bulleted and numbered lists, and H1 and H2 tags. Users can also add links, convert text to checklists, and add comments. Ansaldo wrote that "Both Evernote and Dropbox Paper make it easy to add images to a document", but also noted that "Dropbox Paper doesn't support any image editing". Paper supports rich media, and users can "add rich content to your document just by pasting a link to the file. In addition to Dropbox, Paper supports media from a variety of popular services including YouTube, Spotify, Vimeo, SoundCloud, Facebook, and Google's productivity suite. Once the file appears, you can delete the link for a cleaner display." To start working with other people, Paper "allows you to invite people via email from within a document", with sharing options for who can view the link (anyone with the link or just the invited person), and action permissions (edit or only comment). Regarding collaboration, Ansaldo wrote that "Creative collaboration is Paper’s marquee feature, and it provides a variety of ways to work effectively with others in real time". Users can "make any content immediately visible and accessible to a specific collaborator with "@mentions"", and "You can also use @mentions to create and assign task lists within a document." Paper also "boasts essential collaboration tools including comments, editing attribution, and revision history." Writing for TechRadar, John Brandon wrote that Dropbox Paper "might be a 'light' tool for now without the extensive templates of Microsoft Office or the integration with other apps in the Zoho suite, but it does work well with the Dropbox storage service that's so popular with office workers these days." Kyle Wiggers of Digital Trends wrote that Paper is "all about minimizing distractions. Its interface is quite literally a big, blank canvas on which you tap out your agenda. You can organize notes by title and create to-do lists, but even basic formatting tools are obscured from view", noting Paper's "floating box above words and phrases highlighted by your cursor". Wiggers stated that "Paper is not a to-do organizer", but that it's "well suited to the purpose thanks to a bevy of labor-saving conveniences", highlighting that Paper "supports more media than most of its to-do and note-taking counterparts". He praised the collaboration tools, writing that they "are as extensive as you'd hope, and then some", citing its invitation system with permission controls, lists of changes and revision history, comment and chat support, and "perhaps best of all", the ability to assign tasks with a "@" mention. Business Insider's Alex Heath praised that "Paper's interface is spotless and friendly to write in. You don't feel overwhelmed with formatting options", but criticized the available features, writing that "Google Docs is much more full-featured in the formatting department, so Paper has some catching up to do if it wants to be on par with the competition". Writing for The Verge, Casey Newton praised Paper's handling of rich media, complimenting it for being "great", and added that "I imagine that creative types who work on teams will appreciate having rich media embedded in the documents they're working on rather than in a series of infinite tabs".
Morphobank
MorphoBank is a web application for collaborative evolutionary research, specifically phylogenetic systematics or cladistics, on the phenotype. Historically, scientists conducting research on phylogenetic systematics have worked individually or in small groups employing traditional single-user software applications such as MacClade, Mesquite and Nexus Data Editor. As the hypotheses under study have grown more complex, large research teams have assembled to tackle the problem of discovering the Tree of Life for the estimated 4-100 million living species(Wilson 2003, pp. 77–80) and the many thousands more extinct species known from fossils. Because the phenotype is fundamentally visual, and as phenotype-based phylogenetic studies have continued to increase in size, it becomes important that observations be backed up by labeled images. Traditional desktop software applications currently in wide use do not provide robust support for team-based research or for image manipulation and storage. MorphoBank is a particularly important tool for the growing scientific field of phenomics. The development of MorphoBank, which began in 2001, has been funded by the National Science Foundation's Directorates for Geosciences, Biological Sciences and Computer and Information Science and Engineering. The significance of the scientific work on MorphoBank has been featured in the New York Times(here and here), among other publications. == Advantages == Teams of scientists studying phylogenetics to build the Tree of Life assemble large spreadsheets of observations about species (referred to as "matrices"). These teams require simultaneous access by each team member to a single and secure copy of the team's data during a scientific research project. This single copy of the data also changes with great frequency during the data collection phase. Images that can be very helpful for documenting homology statements must be displayed, labeled and shared as homology statements develop. This cannot be accomplished elegantly with a desktop software package alone because in a desktop environment each collaborator is working on his own private copy of project data. Changes made by one participant cannot automatically propagate to others, preventing collaborators from seeing each other's data edits until they are manually (and due to the effort involved, often only periodically) merged into a single "true" dataset. In all but the smallest and most disciplined of teams, file version control and the reconciliation of changes made on multiple copies of the data emerge quickly as significant drags on productivity. MorphoBank is an attempt to address these issues by leveraging the ubiquity of the web and modern web-based application techniques, including Ajax, web service layers, and rich web applications to provide a full-featured, net-accessible collaborative workspace for phylogenetic research. In particular, MorphoBank makes it easy to: Share all kinds of data with geographically separated team members, including taxonomy, character and specimen data, media (including images, video and audio), phylogenetic matrices (including data in the widely used NEXUS and TNT format) and other data such as documents and genetic sequences. Label high-resolution images using a web-based image annotation application. Collaboratively edit project data such as phylogenetic matrices using a built-in web-based matrix editor. The editor allows the linking of labeled images to individual cells of a matrix. Manage access to project data. Access ranges from full-access for team members to anonymous read-only access for potential reviewers. Publish completed project data on the web in support of a published paper with a persistent URL. Search The Encyclopedia of Life for taxon exemplar images. Store high resolution CT data Create ontologies for updating and populating matrix cells. These tasks are difficult or impossible in most existing software applications. == History == In 2001 the National Science Foundation (NSF) sponsored a workshop, at the American Museum of Natural History in New York to develop the outlines of a web-based system for a collaborative, media-rich research tool for morphological phylogenetics. An application prototype presented at the workshop was later refined with feedback from the workshop and became MorphoBank version 1.0. A grant from the US National Oceanic and Atmospheric Administration funded further revisions resulting in version 2.0, released in 2005. Current support from the NSF is funding current feature enhancements to MorphoBank. MorphoBank was hosted by Stony Brook University until late October 2021 and received back up support from the American Museum of Natural History. The current version is 3.0. Rationale for the software was described in the journal Cladistics. MorphoBank has also received support from NESCENT and the San Diego Supercomputer Center. Since 2018, MorphoBank has been supported in part by Phoenix Bioinformatics, a non-profit company founded to sustain databases for the basic sciences. A permanent move of MorphoBank from Stony Brook University to Phoenix Bioinformatics was complete in late October 2021. The San Diego Supercomputer Center has previously provided technical and hosting resources to the MorphoBank project. == Usage == MorphoBank hosts the products of peer-reviewed scientific research on phenotypes. An increasing volume of systematics data is "born digital" and MorphoBank is well suited to handle this type of material. On August 24, 2007, 62 active research projects were hosted by MorphoBank, as well as 6 completed (and published) projects. By 2017 over 2000 scientists and their students were registered content builders (users are not required to register and are even more numerous) and has more than 500 publicly available projects with approximately 80,000 images that are the products of scientific research. Over 1,500 active research projects are hosted by MorphoBank. The software has been used to assemble phylogenetic research on such groups as mammals, from bats to whales, bivalve molluscs, arachnids, fossil plants and living and extinct amniotes. It has also been used more broadly in evolutionary and paleontological research to host curated images associated with published research on lacewing insects geckos, raptor birds, dinosaurs, frogs and nematodes. MorphoBank is increasingly used in conjunction with the Paleobiology Database. Example published projects: Project 1097: Blank CE, 2013 Origin and early evolution of photosynthetic eukaryotes in freshwater environments – reinterpreting proterozoic paleobiology and biogeochemical processes in light of trait evolution Project 2520: Carvalho, T. P., R. E. Reis, and J. P. Friel, 2017 A new species of Hoplomyzon (Siluriformes: Aspredinidae) from Maracaibo Basin, Venezuela: osteological description using high-resolution Project 2651: Baron, M. G., Norman, D. B., Barrett, P. M., 2017 A new hypothesis of dinosaur relationships and early dinosaur evolution MorphoBank has been particularly important to the Assembling the Tree of Life initiative sponsored by the National Science Foundation. MorphoBank is well-suited to such projects because of its tools for merging taxonomic, character and matrix-based data, as well as its collaborative features. Highlights of this research include a collaborative matrix on mammal evolution published in Science that included over 4,000 phenomic characters scored for over 80 species, a matrix on extant baleen whales featuring nearly 600 images, and more.
Madhan Karky
Madhan Karky Vairamuthu is an Indian lyricist, screenwriter, research associate, software engineer, and entrepreneur. A holder of a doctorate in computer science from the University of Queensland, Karky began his professional career as an assistant professor at the College of Engineering, Guindy, and soon after ventured into the Tamil cinema, working as a lyricist and dialogue writer. He resigned from his teaching profession in early 2013 and began working full-time in the film industry, while also launching the Karky Research Foundation (KaReFo), an educational research organization which primarily focuses on language computing and language literacy. He also founded the Mellinam Education, which develops educational games and story books designed to propagate learning among children, and DooPaaDoo, an online music platform which promotes independent music and serves a distributor for film soundtracks. == Early life == Karky is the eldest son of seven-time National Award winning lyricist Vairamuthu and Ponmani, a Tamil scholar and veteran professor at the Meenakshi College for Women. He has a younger brother, Kabilan, who is a novelist and also works as a lyricist and dialogue writer for Tamil films. === Education === He grew up in Chennai and was educated at the Loyala Matriculation School in Kodambakkam. By his own admission, he was not a good student, excelling primarily only in Tamil and English. During his time in high school, he gained an interest in computer science He got admission in College of Engineering, Guindy which is affiliated with the Anna University. He began his undergraduate education in the field of Computer engineering in the year 1997. While in CEG, as part of his final year project, Karky developed a program called the Tamil Voice Engine, under the supervision of Professor T.V. Geetha. The goal of the project was construction of a text to speech engine for the Tamil language. The research paper on the project was officially selected at the Tamil Internet Conference in Kuala Lumpur, Malaysia. Other projects during his tenure include the Name Generator, which was part of his course on Creativity, Innovation and New Product Development (the objective being to generate random names that are pronounceable with respect to Indian phonetics) and Compiler Design, for which a high level programming language was conceived, with the goal of proper specification and interpretation of lexical rules and grammar rules. For Chennai Kavigal, he created a Spell Checker for a Tamil Word Processor. The project involved a lot of Natural Language Processing elements, based on a root dictionary built as a part of the morphological analyzer for the Tamil Language. The endgame being determining the correctness of words. Following the completion of his bachelor's degree in 2001, Karky began his master's degree at the University of Queensland in the year 2003. In that particular stint, he developed a project based on the theory of computation and strong mathematics (under the supervision of Dr. George Havas). It aimed at analyzing an existing algorithm of reducing any kind of matrix format to a standard format called 'Hermite Normal form', which is a unit upper triangular matrix. Some of his other projects during this course include the Disciplined Software Process Project (whose objective was to introduce and practice the software development process for individuals called Personal Software Process), the On-Line Art Store Website (which involved the creation of a website that trades paintings through the Internet) and the Text Based Voice Chat (for which a Proxy Voice Chat system was designed and developed in Visual Basic that incorporated the predominant computing aspects). In addition to his academics, Karky also served as Academic tutor at the university. He conducted class room tutorials and laboratory sessions on subjects such as Relational Database Systems and Programming Languages. As part of his PhD program on information technology, he developed a Java-based simulation platform called SENSE (Simulated Environment of Networked Sensor Experiments), to test different heuristics. This project was done under the guidance of Dr. Maria Orlowska and Dr. Shazia Sadiq. His thesis is titled "Design considerations for query dissemination in wireless sensor networks". === Teaching career === Upon his return to India following the completion of his post-graduation, Karky returned to CEG Anna University in December 2007. He was a Senior Research Fellow for the next six months, managing research projects as well as multiple student projects at an undergrad and postgrad levels. In addition to those, he handled courses and labs for students who pursued their master's degrees. He also served as a Project Scientist between July 2008 and July 2009, managing projects of research groups as well as ME & MBA students. Starting from August 2009, he began his role as an assistant professor. He lectured Computer Science students who were pursuing their Bachelors and master's degrees as well as coordinated the Tamil Computing Lab at the university. He also served as counsellor for NRI and foreign national students, as well as the Staff treasurer of Computer Science Engineering Association. Some of the subjects he taught include Advanced Databases, Ethics for Engineers, Principles of Programming Languages, Environmental Science and Tamil Computing (for PhD students). === Family and personal life === Karky's been married to Nandini Eswaramoorthy, a fellow alum at Anna University, since June 22, 2008. Nandini Karky now works in the Tamil film industry as a subtitler for feature films and documentaries. They have a son named Haiku Karky, who was born in 2009. == Film career == === Debut === During his teaching stint at Anna University, Karky also began his career in the Tamil film industry with the science-fiction film Enthiran (2010), the magnum opus of director Shankar. Karky had approached the director in 2008 with some of the songs he had written, and was brought him on board to help with the dialogues of the film, especially assisting with technical terminology. He stated that there were three sets of dialogues written for almost every scene of the film; one by Shankar, one by Karky, and the other by the late Sujatha, a frequent collaborator with the director who had died during the early stages of the film's pre-production. Shankar would go through all the three drafts and implement those that fit best. The climax was the only portion that didn't have multiple hands, as it was written solely by Karky. In addition to the dialogue, Karky wrote 2 songs for the film, as well: "Irumbile oru Irudhaiyam" (the first song of his career, which was partially crooned by A.R. Rahman) and "Boom Boom Robo Da". However, Kanden Kadhalai (2009), in which he had written the song "Ododi Poren" (composed by Vidyasagar), became his first release. For his work on Enthiran, Karky was named Best Find of the Year at the 2011 Vijay Awards. === Lyric writer === Following his work on Enthiran, Karky became one of the most sought after lyricists in the Tamil film industry, having multiple collaborations with A.R. Rahman, Harris Jayaraj, G. V. Prakash Kumar, D. Imman, M.M. Keeravani, Yuvan Shankar Raja, S. Thaman, Sanjay Leela Bhansali, Anirudh Ravichander and Sam CS. In addition to his native Tamil, he is known for penning songs in multiple languages; some of which include "Asku Laska" from Nanban (which features 16 different languages), "The Rise of Damo" from 7 Aum Arivu (written in Mandarin) and "Continua" from Nootrenbadhu (in Portuguese). His work is also characterized by infusing uncommon Tamil words that aren't normally used in everyday lexicon, as part of lyrics (like "Kuviyamillaa Kaatchi Paezhai" from Ko and "Panikoozh" from I). He also wrote the first palindrome song in Tamil cinema for the film Vinodhan. As of the end of 2025, he has over one thousand songs to his credit. Some of Karky's most popular songs include "Irumbile oru Irudhaiyam" (Enthiran), "Enamo Edho" (Ko), "Nee Koorinal" (Nootrenbadhu), "Asku Laska" (Nanban), "Google Google" (Thuppakki), "Elay Keechaan" (Kadal), "Osakka" (Vanakkam Chennai), "Selfie Pulla" (Kaththi), "Pookkalae Sattru Oyivedungal" (I), "Mei Nigara" (24), "Azhagiye" (Kaatru Veliyidai), "Endhira Logathu Sundariye" (2.0) and "Kurumba" (Tik Tik Tik). === Dialogue writer === On the heels of the success with Enthiran, Karky once again collaborated as a dialogue writer with director Shankar for Nanban. An adaptation of the Hindi blockbuster 3 Idiots, he infused a twang to the dialogue that aimed to showcase college life in a different manner. He also collaborated as a technical advisor with Shankar with 2.0 (the sequel to Enthiran). Karky's also known for his successful collaboration with Telugu director S.S. Rajamouli, on his two-part magnum opus Baahubali; the second part being the most profitable South Indian film of all time, and RRR. His o
Trie
In computer science, a trie (, ), also known as a digital tree or prefix tree, is a specialized search tree data structure used to store and retrieve strings from a dictionary or set. Unlike a binary search tree, nodes in a trie do not store their associated key. Instead, each node's position within the trie determines its associated key, with the connections between nodes defined by individual characters rather than the entire key. Tries are particularly effective for tasks such as autocomplete, spell checking, and IP routing, offering advantages over hash tables due to their prefix-based organization and lack of hash collisions. Every child node shares a common prefix with its parent node, and the root node represents the empty string. While basic trie implementations can be memory-intensive, various optimization techniques such as compression and bitwise representations have been developed to improve their efficiency. A notable optimization is the radix tree, which provides more efficient prefix-based storage. While tries store character strings, they can be adapted to work with any ordered sequence of elements, such as permutations of digits or shapes. A notable variant is the bitwise trie, which uses individual bits from fixed-length binary data (such as integers or memory addresses) as keys. == History, etymology, and pronunciation == The idea of a trie for representing a set of strings was first abstractly described by Axel Thue in 1912. Tries were first described in a computer context by René de la Briandais in 1959. The idea was independently described in 1960 by Edward Fredkin, who coined the term trie, pronouncing it (as "tree"), after the middle syllable of retrieval. However, other authors pronounce it (as "try"), in an attempt to distinguish it verbally from "tree". == Overview == Tries are a form of string-indexed look-up data structure, which is used to store a dictionary list of words that can be searched on in a manner that allows for efficient generation of completion lists. A prefix trie is an ordered tree data structure used in the representation of a set of strings over a finite alphabet set, which allows efficient storage of words with common prefixes. Tries can be efficacious on string-searching algorithms such as predictive text, approximate string matching, and spell checking in comparison to binary search trees. A trie can be seen as a tree-shaped deterministic finite automaton. == Operations == Tries support various operations: insertion, deletion, and lookup of a string key. Tries are composed of nodes that contain links, which either point to other suffix child nodes or null. As for every tree, each node except the root is pointed to by only one other node, called its parent. Each node contains as many links as the number of characters in the applicable alphabet (although tries tend to have a substantial number of null links). In some cases, the alphabet used is simply that of the character encoding—resulting in, for example, a size of 128 in the case of ASCII. The null links within the children of a node emphasize the following characteristics: Characters and string keys are implicitly stored in the trie, and include a character sentinel value indicating string termination. Each node contains one possible link to a prefix of strong keys of the set. A basic structure type of nodes in the trie is as follows: Node {\displaystyle {\text{Node}}} may contain an optional Value {\displaystyle {\text{Value}}} , which is associated with the key that corresponds to the node. === Searching === Searching for a value in a trie is guided by the characters in the search string key, as each node in the trie contains a corresponding link to each possible character in the given string. Thus, following the string within the trie yields the associated value for the given string key. A null link during the search indicates the inexistence of the key. The following pseudocode implements the search procedure for a given string key in a rooted trie x. In the above pseudocode, x and key correspond to the pointer of the trie's root node and the string key, respectively. The search operation takes O ( m ) {\displaystyle O(m)} time, where m {\displaystyle m} is the size of the string parameter key. In a balanced binary search tree, on the other hand, it takes O ( m log n ) {\displaystyle O(m\log n)} time, in the worst case, since key needs to be compared with O ( log n ) {\displaystyle O(\log n)} other keys and each comparison takes O ( m ) {\displaystyle O(m)} time, in the worst case. The trie occupies less space, in comparison with a binary search tree, in the case of a large number of short strings, since nodes share common initial string subsequences and store the keys implicitly. === Insertion === Insertion into a trie is guided by using the character sets as indexes to the children array until the last character of the string key is reached. Each node in the trie corresponds to one call of the radix sorting routine, as the trie structure reflects the execution pattern of the top-down radix sort. If null links are encountered before reaching the last character of the string key, new nodes are created. The input value is assigned to the value of the last node traversed, which is the node that corresponds to the key. === Deletion === Deletion of a key–value pair from a trie involves finding the node corresponding to the key, setting its value to null, and recursively removing nodes that have no children. The procedure begins by examining key; an empty string indicates arrival at the node corresponding to the (original) key, in which case its value is set to null. If the node, then, has null value and no children, it is removed from the trie by returning null; otherwise, the node is kept by returning the node itself. == Replacing other data structures == === Replacement for hash tables === A trie can be used to replace a hash table, over which it has the following advantages: Searching for a node with an associated key of size m {\displaystyle m} has the complexity of O ( m ) {\displaystyle O(m)} , whereas an imperfect hash function may have numerous colliding keys, and the worst-case lookup speed of such a table would be O ( N ) {\displaystyle O(N)} , where N {\displaystyle N} denotes the total number of nodes within the table. Tries do not need a hash function for the operation, unlike a hash table; there are also no collisions of different keys in a trie. Within a trie, keys can be efficiently sorted lexicographically. However, tries are less efficient than a hash table when the data is directly accessed on a secondary storage device such as a hard disk drive that has higher random access time than the main memory. == Implementation strategies == Tries can be represented in several ways, corresponding to different trade-offs between memory use and speed of the operations. Using a vector of pointers for representing a trie consumes enormous space; however, memory space can be reduced at the expense of running time if a singly linked list is used for each node vector, as most entries of the vector contains nil {\displaystyle {\text{nil}}} . Techniques such as alphabet reduction may reduce the large space requirements by reinterpreting the original string as a longer string over a smaller alphabet. For example, a string of n bytes can alternatively be regarded as a string of 2n four-bit units. This can reduce memory usage by a factor of eight; but lookups need to visit twice as many nodes in the worst case. Another technique includes storing a vector of 256 ASCII pointers as a bitmap of 256 bits representing ASCII alphabet, which reduces the size of individual nodes dramatically. === Bitwise tries === Bitwise tries are used to address the enormous space requirement for the trie nodes in a naive simple pointer vector implementations. Each character in the string key set is represented via individual bits, which are used to traverse the trie over a string key. The implementations for these types of trie use vectorized CPU instructions to find the first set bit in a fixed-length key input (e.g. GCC's __builtin_clz() intrinsic function). Accordingly, the set bit is used to index the first item, or child node, in the 32- or 64-entry based bitwise tree. Search then proceeds by testing each subsequent bit in the key. This procedure is also cache-local and highly parallelizable due to register independency, and thus performant on out-of-order execution CPUs. === Compressed tries === Radix tree, also known as a compressed trie, is a space-optimized variant of a trie in which any node with only one child gets merged with its parent; elimination of branches of the nodes with a single child results in better metrics in both space and time. This works best when the trie remains static and set of keys stored are very sparse within their representation space. One more approach for static tries is to "pack" the trie by storing disjoint
Lillian Lee (computer scientist)
Lillian Lee is a computer scientist whose research involves natural language processing, sentiment analysis, and computational social science. She is a professor of computer science and information science at Cornell University, and co-editor-in-chief of the journal Transactions of the Association for Computational Linguistics. == Education == Lee graduated from Cornell University in 1993 with an undergraduate degree in math and science. She completed her Ph.D. at Harvard University in 1997. Her dissertation, Similarity-Based Approaches to Natural Language Processing, was supervised by Stuart M. Shieber. == Career == Lee has been a member of the Cornell faculty since 1997. == Recognition == Lee has been a fellow of the Association for the Advancement of Artificial Intelligence since 2013, and of the Association for Computational Linguistics since 2017. Lee was elected as an ACM Fellow in 2018 for "contributions to natural language processing, sentiment analysis, and computational social science".
Stencil buffer
A stencil buffer is an extra data buffer, in addition to the color buffer and Z-buffer, found on modern graphics hardware. The buffer is per pixel and works on integer values, usually with a depth of one byte per pixel. The Z-buffer and stencil buffer often share the same area in the RAM of the graphics hardware. In the simplest case, the stencil buffer is used to limit the area of rendering (stenciling). More advanced usage of the stencil buffer makes use of the strong connection between the Z-buffer and the stencil buffer in the rendering pipeline. For example, stencil values can be automatically increased/decreased for every pixel that fails or passes the depth test. The simple combination of depth test and stencil modifiers make a vast number of effects possible (such as stencil shadow volumes, Two-Sided Stencil, compositing, decaling, dissolves, fades, swipes, silhouettes, outline drawing, or highlighting of intersections between complex primitives) though they often require several rendering passes and, therefore, can put a heavy load on the graphics hardware. The most typical application is still to add shadows to 3D applications. It is also used for planar reflections. Other rendering techniques, such as portal rendering, use the stencil buffer in other ways; for example, it can be used to find the area of the screen obscured by a portal and re-render those pixels correctly. The stencil buffer and its modifiers can be accessed in computer graphics by using APIs like OpenGL, Direct3D, Vulkan or Metal. == Architecture == The stencil buffer typically shares the same memory space as the Z-buffer, and typically the ratio is 24 bits for Z-buffer + 8 bits for stencil buffer or, in the past, 15 bits for Z-buffer + 1 bit for stencil buffer. Another variant is 4 + 24, where 28 of the 32 bits are used and 4 ignored. Stencil and Z-buffers are part of the frame buffer, coupled to the color buffer. The first chip available to a wider market was 3Dlabs' Permedia II, which supported a one-bit stencil buffer. The bits allocated to the stencil buffer can be used to represent numerical values in the range [0, 2n-1], and also as a Boolean matrix (n is the number of allocated bits), each of which may be used to control the particular part of the scene. Any combination of these two ways of using the available memory is also possible. == Stencil test == Stencil test or stenciling is among the operations on the pixels/fragments (Per-pixel operations), located after the alpha test, and before the depth test. The stencil test ensures undesired pixels do not reach the depth test. This saves processing time for the scene. Similarly, the alpha test can prevent corresponding pixels to reach the stencil test. The test itself is carried out over the stencil buffer to some value in it, or altered or used it, and carried out through the so-called stencil function and stencil operations. The stencil function is a function by which the stencil value of a certain pixel is compared to a given reference value. If this comparison is logically true, the stencil test passes. Otherwise not. In doing so, the possible reaction caused by the result of comparing three different state-depth and stencil buffer: Stencil test is not passed Stencil test is passed but not the depth test Both tests are passed (or stencil test is passed, and the depth is not enabled) For each of these cases, different operations can be set over the examined pixel. In the OpenGL stencil functions, the reference value and mask, respectively, define the function glStencilFunc. In Direct3D each of these components is adjusted individually using methods SetRenderState devices currently in control. This method expects two parameters, the first of which is a condition that is set and the other its value. In the order that was used above, these conditions are called D3DRS_STENCILFUNC, D3DRS_STENCILREF, and D3DRS_STENCILMASK. Stencil operations in OpenGL adjust glStencilOp function that expects three values. In Direct3D, again, each state sets a specific method SetRenderState. The three states that can be assigned to surgery are called D3DRS_STENCILFAIL, D3DRENDERSTATE_STENCILZFAIL, and D3DRENDERSTATE_STENCILPASS. == Z-fighting == Due to the lack of precision in the Z-buffer, coplanar polygons that are short-range, or overlapping, can be portrayed as a single plane with a multitude of irregular cross-sections. These sections can vary depending on the camera position and other parameters and are rapidly changing. This is called Z-fighting. There exist multiple solutions to this issue: - Bring the far plane closer to restrict the scene's depth, thus increasing the accuracy of the Z-buffer, or reducing the distance at which objects are visible in the scene. - Increase the number of bits allocated to the Z-buffer, which is possible at the expense of memory for the stencil buffer. - Move polygons farther apart from one another, which restricts the possibilities for the artist to create an elaborate scene. All of these approaches to the problem can only reduce the likelihood that the polygons will experience Z-fighting, and do not guarantee a definitive solution in the general case. A solution that includes the stencil buffer is based on the knowledge of which polygon should be in front of the others. The silhouette of the front polygon is drawn into the stencil buffer. After that, the rest of the scene can be rendered only where the silhouette is negative, and so will not clash with the front polygon. == Shadow volume == Shadow volume is a technique used in 3D computer graphics to add shadows to a rendered scene. They were first proposed by Frank Crow in 1977 as the geometry describing the 3D shape of the region occluded from a light source. A shadow volume divides the virtual world in two: areas that are in shadow and areas that are not. The stencil buffer implementation of shadow volumes is generally considered among the most practical general-purpose real-time shadowing techniques for use on modern 3D graphics hardware. It has been popularised by the video game Doom 3, and a particular variation of the technique used in this game has become known as Carmack's Reverse. == Reflections == Reflection of a scene is drawn as the scene itself transformed and reflected relative to the "mirror" plane, which requires multiple render passes and using of stencil buffer to restrict areas where the current render pass works: Draw the scene excluding mirror areas – for each mirror lock the Z-buffer and color buffer Render visible part of the mirror Depth test is set up so that each pixel is passed to enter the maximum value and always passes for each mirror: Depth test is set so that it passes only if the distance of a pixel is less than the current (default behavior) The matrix transformation is changed to reflect the scene relative to the mirror plane Unlock the Z-buffer and color buffer Draw the scene, but only the part of it that lies between the mirror plane and the camera. In other words, a mirror plane is also a clipping plane Again locks color buffer, depth test is set so that it always passes, reset stencil for the next mirror. == Planar Shadows == While drawing a plane of shadows, there are two dominant problems: The first concerns the problem of deep struggle in case the flat geometry is not awarded on the part covered with the shadow of shadows and outside. See the section that relates to this. Another problem relates to the extent of the shadows outside the area where the plane there. Another problem, which may or may not appear, depending on the technique, the design of more polygons in one part of the shadow, resulting in darker and lighter parts of the same shade. All three problems can be solved geometrically, but because of the possibility that hardware acceleration is directly used, it is a far more elegant implementation using the stencil buffer: 1. Enable lights and the lights 2. Draw a scene without any polygon that should be projected shadows 3. Draw all polygons which should be projected shadows, but without lights. In doing so, the stencil buffer, the pixel of each polygon to be assigned to a specific value for the ground to which they belong. The distance between these values should be at least two, because for each plane to be used two values for two states: in the shadows and bright. 4. Disable any global illumination (to ensure that the next steps will affect only individual selected light) For each plane: For each light: 1. Edit a stencil buffer and only the pixels that carry a specific value for the selected level. Increase the value of all the pixels that are projected objects between the date of a given level and bright. 2. Allow only selected light for him to draw level at which part of her specific value was not changed. == Spatial shadows == Stencil buffer implementation of spatial drawing shadows is any shadow of a geometric body that its volume includes part of the scene that is
Büchi automaton
In computer science and automata theory, a deterministic Büchi automaton is a theoretical machine which either accepts or rejects infinite inputs. Such a machine has a set of states and a transition function, which determines which state the machine should move to from its current state when it reads the next input character. Some states are accepting states and one state is the start state. The machine accepts an input if and only if it will pass through an accepting state infinitely many times as it reads the input. A non-deterministic Büchi automaton, later referred to just as a Büchi automaton, has a transition function which may have multiple outputs, leading to many possible paths for the same input; it accepts an infinite input if and only if some possible path is accepting. Deterministic and non-deterministic Büchi automata generalize deterministic finite automata and nondeterministic finite automata to infinite inputs. Each are types of ω-automata. Büchi automata recognize the ω-regular languages, the infinite word version of regular languages. They are named after the Swiss mathematician Julius Richard Büchi, who invented them in 1962. Büchi automata are often used in model checking as an automata-theoretic version of a formula in linear temporal logic. == Formal definition == Formally, a deterministic Büchi automaton is a tuple A = ( Q , Σ , δ , q 0 , F ) {\textstyle A=(Q,\Sigma ,\delta ,q_{0},\mathbf {F} )} that consists of the following components: Q {\textstyle Q} is a finite set. The elements of Q {\textstyle Q} are called the states of A {\textstyle A} . Σ {\textstyle \Sigma } is a finite set called the alphabet of A {\textstyle A} . δ : Q × Σ → Q {\textstyle \delta \colon Q\times \Sigma \to Q} is a function, called the transition function of A {\textstyle A} . q 0 {\textstyle q_{0}} is an element of Q {\textstyle Q} , called the initial state of A {\textstyle A} . F ⊆ Q {\textstyle \mathbf {F} \subseteq Q} is the acceptance condition. A run i _ = i 0 i 1 i 2 ⋯ ∈ Σ ω {\displaystyle {\underline {i}}=i_{0}i_{1}i_{2}\cdots \in \Sigma ^{\omega }} is an infinite string of inputs of A {\displaystyle A} . By calling δ {\displaystyle \delta } recursively, we can extend it to a function δ ω : Σ ω → Q ω {\displaystyle \delta ^{\omega }:\Sigma ^{\omega }\to Q^{\omega }} . A state q ∈ Q {\displaystyle q\in Q} is said to occur infinitely often for a run i _ {\displaystyle {\underline {i}}} when the set { n ∈ N ∣ δ ω ( i _ ) n = q } {\displaystyle \{n\in \mathbb {N} \mid \delta ^{\omega }({\underline {i}})_{n}=q\}} is infinite. Let I n f ( i _ ) {\displaystyle \mathrm {Inf} ({\underline {i}})} be the set of states occurring infinitely often for i _ {\displaystyle {\underline {i}}} . The language of A {\displaystyle A} is then the set of runs of A {\displaystyle A} in which at least one of the infinitely-often occurring states is in F {\textstyle \mathbf {F} } ; in symbols: L ( A ) = { i _ ∈ Σ ω ∣ I n f ( i _ ) ∩ F ≠ ∅ } . {\displaystyle L(A)=\{{\underline {i}}\in \Sigma ^{\omega }\mid \mathrm {Inf} ({\underline {i}})\cap \mathbf {F} \neq \varnothing \}.} In a (non-deterministic) Büchi automaton, the transition function δ {\textstyle \delta } is replaced with a transition relation Δ {\textstyle \Delta } that returns a set of states, and the single initial state q 0 {\textstyle q_{0}} is replaced by a set I {\textstyle I} of initial states. Generally, the term Büchi automaton without qualifier refers to non-deterministic Büchi automata. For more comprehensive formalism see also ω-automaton. == Closure properties == The set of Büchi automata is closed under the following operations. Let A = ( Q A , Σ , Δ A , I A , F A ) {\displaystyle A=(Q_{A},\Sigma ,\Delta _{A},I_{A},{F}_{A})} and B = ( Q B , Σ , Δ B , I B , F B ) {\displaystyle B=(Q_{B},\Sigma ,\Delta _{B},I_{B},{F}_{B})} be Büchi automata and C = ( Q C , Σ , Δ C , I C , F C ) {\displaystyle C=(Q_{C},\Sigma ,\Delta _{C},I_{C},{F}_{C})} be a finite automaton. Union: There is a Büchi automaton that recognizes the language L ( A ) ∪ L ( B ) . {\displaystyle L(A)\cup L(B).} Proof: If we assume, w.l.o.g., Q A ∩ Q B {\displaystyle Q_{A}\cap Q_{B}} is empty then L ( A ) ∪ L ( B ) {\displaystyle L(A)\cup L(B)} is recognized by the Büchi automaton ( Q A ∪ Q B , Σ ∪ Σ , Δ A ∪ Δ B , I A ∪ I B , F A ∪ F B ) . {\displaystyle (Q_{A}\cup Q_{B},\Sigma \cup \Sigma ,\Delta _{A}\cup \Delta _{B},I_{A}\cup I_{B},{F}_{A}\cup {F}_{B}).} Intersection: There is a Büchi automaton that recognizes the language L ( A ) ∩ L ( B ) . {\displaystyle L(A)\cap L(B).} Proof: The Büchi automaton A ′ = ( Q ′ , Σ , Δ ′ , I ′ , F ′ ) {\displaystyle A'=(Q',\Sigma ,\Delta ',I',F')} recognizes L ( A ) ∩ L ( B ) , {\displaystyle L(A)\cap L(B),} where Q ′ = Q A × Q B × { 1 , 2 } {\displaystyle Q'=Q_{A}\times Q_{B}\times \{1,2\}} Δ ′ = Δ 1 ∪ Δ 2 {\displaystyle \Delta '=\Delta _{1}\cup \Delta _{2}} Δ 1 = { ( ( q A , q B , 1 ) , a , ( q A ′ , q B ′ , i ) ) | ( q A , a , q A ′ ) ∈ Δ A and ( q B , a , q B ′ ) ∈ Δ B and if q A ∈ F A then i = 2 else i = 1 } {\displaystyle \Delta _{1}=\{((q_{A},q_{B},1),a,(q'_{A},q'_{B},i))|(q_{A},a,q'_{A})\in \Delta _{A}{\text{ and }}(q_{B},a,q'_{B})\in \Delta _{B}{\text{ and if }}q_{A}\in F_{A}{\text{ then }}i=2{\text{ else }}i=1\}} Δ 2 = { ( ( q A , q B , 2 ) , a , ( q A ′ , q B ′ , i ) ) | ( q A , a , q A ′ ) ∈ Δ A and ( q B , a , q B ′ ) ∈ Δ B and if q B ∈ F B then i = 1 else i = 2 } {\displaystyle \Delta _{2}=\{((q_{A},q_{B},2),a,(q'_{A},q'_{B},i))|(q_{A},a,q'_{A})\in \Delta _{A}{\text{ and }}(q_{B},a,q'_{B})\in \Delta _{B}{\text{ and if }}q_{B}\in F_{B}{\text{ then }}i=1{\text{ else }}i=2\}} I ′ = I A × I B × { 1 } {\displaystyle I'=I_{A}\times I_{B}\times \{1\}} F ′ = { ( q A , q B , 2 ) | q B ∈ F B } {\displaystyle F'=\{(q_{A},q_{B},2)|q_{B}\in F_{B}\}} By construction, r ′ = ( q A 0 , q B 0 , i 0 ) , ( q A 1 , q B 1 , i 1 ) , … {\displaystyle r'=(q_{A}^{0},q_{B}^{0},i^{0}),(q_{A}^{1},q_{B}^{1},i^{1}),\dots } is a run of automaton A' on input word w {\textstyle w} if r A = q A 0 , q A 1 , … {\displaystyle r_{A}=q_{A}^{0},q_{A}^{1},\dots } is run of A {\textstyle A} on w {\textstyle w} and r B = q B 0 , q B 1 , … {\displaystyle r_{B}=q_{B}^{0},q_{B}^{1},\dots } is run of B {\textstyle B} on w {\textstyle w} . r A {\textstyle r_{A}} is accepting and r B {\textstyle r_{B}} is accepting if r ′ {\textstyle r'} is concatenation of an infinite series of finite segments of 1-states (states with third component 1) and 2-states (states with third component 2) alternatively. There is such a series of segments of r ′ {\textstyle r'} if r ′ {\textstyle r'} is accepted by A ′ {\textstyle A'} . Concatenation: There is a Büchi automaton that recognizes the language L ( C ) ⋅ L ( A ) . {\displaystyle L(C)\cdot L(A).} Proof: If we assume, w.l.o.g., Q C ∩ Q A {\displaystyle Q_{C}\cap Q_{A}} is empty then the Büchi automaton A ′ = ( Q C ∪ Q A , Σ , Δ ′ , I ′ , F A ) {\displaystyle A'=(Q_{C}\cup Q_{A},\Sigma ,\Delta ',I',F_{A})} recognizes L ( C ) ⋅ L ( A ) {\displaystyle L(C)\cdot L(A)} , where Δ ′ = Δ A ∪ Δ C ∪ { ( q , a , q ′ ) | q ′ ∈ I A and ∃ f ∈ F C . ( q , a , f ) ∈ Δ C } {\displaystyle \Delta '=\Delta _{A}\cup \Delta _{C}\cup \{(q,a,q')|q'\in I_{A}{\text{ and }}\exists f\in F_{C}.(q,a,f)\in \Delta _{C}\}} if I C ∩ F C is empty then I ′ = I C otherwise I ′ = I C ∪ I A {\displaystyle {\text{ if }}I_{C}\cap F_{C}{\text{ is empty then }}I'=I_{C}{\text{ otherwise }}I'=I_{C}\cup I_{A}} ω-closure: If L ( C ) {\displaystyle L(C)} does not contain the empty word then there is a Büchi automaton that recognizes the language L ( C ) ω . {\displaystyle L(C)^{\omega }.} Proof: The Büchi automaton that recognizes L ( C ) ω {\displaystyle L(C)^{\omega }} is constructed in two stages. First, we construct a finite automaton A ′ {\textstyle A'} such that A ′ {\textstyle A'} also recognizes L ( C ) {\displaystyle L(C)} but there are no incoming transitions to initial states of A ′ {\textstyle A'} . So, A ′ = ( Q C ∪ { q new } , Σ , Δ ′ , { q new } , F C ) , {\displaystyle A'=(Q_{C}\cup \{q_{\text{new}}\},\Sigma ,\Delta ',\{q_{\text{new}}\},F_{C}),} where Δ ′ = Δ C ∪ { ( q new , a , q ′ ) | ∃ q ∈ I C . ( q , a , q ′ ) ∈ Δ C } . {\displaystyle \Delta '=\Delta _{C}\cup \{(q_{\text{new}},a,q')|\exists q\in I_{C}.(q,a,q')\in \Delta _{C}\}.} Note that L ( C ) = L ( A ′ ) {\displaystyle L(C)=L(A')} because L ( C ) {\displaystyle L(C)} does not contain the empty string. Second, we will construct the Büchi automaton A ″ {\textstyle A''} that recognize L ( C ) ω {\displaystyle L(C)^{\omega }} by adding a loop back to the initial state of A ′ {\textstyle A'} . So, A ″ = ( Q C ∪ { q new } , Σ , Δ ″ , { q new } , { q new } ) {\displaystyle A''=(Q_{C}\cup \{q_{\text{new}}\},\Sigma ,\Delta '',\{q_{\text{new}}\},\{q_{\text{new}}\})} , where Δ ″ = Δ ′ ∪ { ( q , a , q new ) | ∃ q ′ ∈ F C . ( q , a , q ′ ) ∈ Δ ′ } . {\displaystyle \Delta ''=\Delta '\cup \{(q,a,q_{\text{new}})|\exists q'\in F_{C}.(q,a,q')\in \Delta '\}.} Complementation: