Mountain Car, a standard testing domain in Reinforcement learning, is a problem in which an under-powered car must drive up a steep hill. Since gravity is stronger than the car's engine, even at full throttle, the car cannot simply accelerate up the steep slope. The car is situated in a valley and must learn to leverage potential energy by driving up the opposite hill before the car is able to make it to the goal at the top of the rightmost hill. The domain has been used as a test bed in various reinforcement learning papers. == Introduction == The mountain car problem, although fairly simple, is commonly applied because it requires a reinforcement learning agent to learn on two continuous variables: position and velocity. For any given state (position and velocity) of the car, the agent is given the possibility of driving left, driving right, or not using the engine at all. In the standard version of the problem, the agent receives a negative reward at every time step when the goal is not reached; the agent has no information about the goal until an initial success. == History == The mountain car problem appeared first in Andrew Moore's PhD thesis (1990). It was later more strictly defined in Singh and Sutton's reinforcement learning paper with eligibility traces. The problem became more widely studied when Sutton and Barto added it to their book Reinforcement Learning: An Introduction (1998). Throughout the years many versions of the problem have been used, such as those which modify the reward function, termination condition, and the start state. == Techniques used to solve mountain car == Q-learning and similar techniques for mapping discrete states to discrete actions need to be extended to be able to deal with the continuous state space of the problem. Approaches often fall into one of two categories, state space discretization or function approximation. === Discretization === In this approach, two continuous state variables are pushed into discrete states by bucketing each continuous variable into multiple discrete states. This approach works with properly tuned parameters but a disadvantage is information gathered from one state is not used to evaluate another state. Tile coding can be used to improve discretization and involves continuous variables mapping into sets of buckets offset from one another. Each step of training has a wider impact on the value function approximation because when the offset grids are summed, the information is diffused. === Function approximation === Function approximation is another way to solve the mountain car. By choosing a set of basis functions beforehand, or by generating them as the car drives, the agent can approximate the value function at each state. Unlike the step-wise version of the value function created with discretization, function approximation can more cleanly estimate the true smooth function of the mountain car domain. === Eligibility traces === One aspect of the problem involves the delay of actual reward. The agent is not able to learn about the goal until a successful completion. Given a naive approach for each trial the car can only backup the reward of the goal slightly. This is a problem for naive discretization because each discrete state will only be backed up once, taking a larger number of episodes to learn the problem. This problem can be alleviated via the mechanism of eligibility traces, which will automatically backup the reward given to states before, dramatically increasing the speed of learning. Eligibility traces can be viewed as a bridge from temporal difference learning methods to Monte Carlo methods. == Technical details == The mountain car problem has undergone many iterations. This section focuses on the standard well-defined version from Sutton (2008). === State variables === Two-dimensional continuous state space. V e l o c i t y = ( − 0.07 , 0.07 ) {\displaystyle Velocity=(-0.07,0.07)} P o s i t i o n = ( − 1.2 , 0.6 ) {\displaystyle Position=(-1.2,0.6)} === Actions === One-dimensional discrete action space. m o t o r = ( l e f t , n e u t r a l , r i g h t ) {\displaystyle motor=(left,neutral,right)} === Reward === For every time step: r e w a r d = − 1 {\displaystyle reward=-1} === Update function === For every time step: A c t i o n = [ − 1 , 0 , 1 ] {\displaystyle Action=[-1,0,1]} V e l o c i t y = V e l o c i t y + ( A c t i o n ) ∗ 0.001 + cos ( 3 ∗ P o s i t i o n ) ∗ ( − 0.0025 ) {\displaystyle Velocity=Velocity+(Action)0.001+\cos(3Position)(-0.0025)} P o s i t i o n = P o s i t i o n + V e l o c i t y {\displaystyle Position=Position+Velocity} === Starting condition === Optionally, many implementations include randomness in both parameters to show better generalized learning. P o s i t i o n = − 0.5 {\displaystyle Position=-0.5} V e l o c i t y = 0.0 {\displaystyle Velocity=0.0} === Termination condition === End the simulation when: P o s i t i o n ≥ 0.6 {\displaystyle Position\geq 0.6} == Variations == There are many versions of the mountain car which deviate in different ways from the standard model. Variables that vary include but are not limited to changing the constants (gravity and steepness) of the problem so specific tuning for specific policies become irrelevant and altering the reward function to affect the agent's ability to learn in a different manner. An example is changing the reward to be equal to the distance from the goal, or changing the reward to zero everywhere and one at the goal. Additionally, a 3D mountain car can be used, with a 4D continuous state space.
New York Institute of Technology Computer Graphics Lab
The New York Institute of Technology Computer Graphics Lab is a computer lab located at the New York Institute of Technology (NYIT), founded by Alexander Schure. It was originally located at the "pink building" on the NYIT campus. It has played an important role in the history of computer graphics and animation, as founders of Pixar and Lucasfilm Limited, including Turing Award winners Edwin Catmull and Patrick Hanrahan, began their research there. It is the birthplace of entirely 3D CGI films. The lab was initially founded to produce a short high-quality feature film with the project name of The Works. The feature, which was never completed, was a 90-minute feature that was to be the first entirely computer-generated CGI movie. Production mainly focused around DEC PDP and VAX machines. Many of the original CGL team now form the elite of the CG and computer world with members going on to Silicon Graphics, Microsoft, Cisco, NVIDIA and others, including Pixar president, co-founder and Turing laureate Ed Catmull, Pixar co-founder and Microsoft graphics fellow Alvy Ray Smith, Pixar co-founder Ralph Guggenheim, Walt Disney Animation Studios chief scientist Lance Williams, Netscape and Silicon Graphics founder Jim Clark, Tableau co-founder and Turing laureate Pat Hanrahan, Microsoft graphics fellow Jim Blinn, Thad Beier, Oscar and Bafta nominee Jacques Stroweis, Andrew Glassner, and Tom Brigham. Systems programmer Bruce Perens went on to co-found the Open Source Initiative. Researchers at the New York Institute of Technology Computer Graphics Lab created the tools that made entirely 3D CGI films possible. Among NYIT CG Lab's many innovations was an eight-bit paint system to ease computer animation. NYIT CG Lab was regarded as the top computer animation research and development group in the world during the late 70s and early 80s. == The 21st century == The lab is presently located at NYIT's Long Island campus, and NYIT currently offers a Ph.D. program in Computer Science.
UCSD Pascal
UCSD Pascal is a Pascal programming language system that runs on the UCSD p-System, a portable, highly machine-independent operating system. UCSD Pascal was first released in 1977. It was developed at the University of California, San Diego (UCSD). == The p-System == In 1977, the University of California, San Diego (UCSD) Institute for Information Systems developed UCSD Pascal to provide students with a common environment that could run on any of the then available microcomputers as well as campus DEC PDP-11 minicomputers. The operating system became known as UCSD p-System. There were three operating systems that IBM offered for its original IBM PC: the UCSD p-System, CP/M-86, and IBM PC DOS. Vendor SofTech Microsystems emphasized p-System's application portability, with virtual machines for 20 CPUs as of the IBM PC's release. It predicted that users would be able to use applications they purchased on future computers running p-System; advertisements called it "the Universal Operating System". PC Magazine denounced UCSD p-System on the IBM PC, stating in a review of Context MBA, written in the language, that it "simply does not produce good code". The p-System did not sell very well for the IBM PC, because of a lack of applications and because it was more expensive than the other choices. Previously, IBM had offered the UCSD p-System as an option for IBM Displaywriter, an 8086-based dedicated word processing machine. (The Displaywriter's native operating system had been developed completely internally and was not opened for end-user programming.) Notable extensions to standard Pascal include separately compilable Units and a String type. Some intrinsics were provided to accelerate string processing (e.g. scanning in an array for a particular search pattern); other language extensions were provided to allow the UCSD p-System to be self-compiling and self-hosted. UCSD Pascal was based on a p-code machine architecture. Its contribution to these early virtual machines was to extend p-code away from its roots as a compiler intermediate language into a full execution environment. The UCSD Pascal p-Machine was optimized for the new small microcomputers with addressing restricted to 16-bit (only 64 KB of memory). James Gosling cites UCSD Pascal as a key influence (along with the Smalltalk virtual machine) on the design of the Java virtual machine. UCSD p-System achieved machine independence by defining a virtual machine, called the p-Machine (or pseudo-machine, which many users began to call the "Pascal-machine" like the OS—although UCSD documentation always used "pseudo-machine") with its own instruction set called p-code (or pseudo-code). Urs Ammann, a student of Niklaus Wirth, originally presented a p-code in his PhD thesis, from which the UCSD implementation was derived, the Zurich Pascal-P implementation. The UCSD implementation changed the Zurich implementation to be "byte oriented". The UCSD p-code was optimized for execution of the Pascal programming language. Each hardware platform then only needed a p-code interpreter program written for it to port the entire p-System and all the tools to run on it. Later versions also included additional languages that compiled to the p-code base. For example, Apple Computer offered a Fortran Compiler (written by Silicon Valley Software, Sunnyvale California) producing p-code that ran on the Apple version of the p-system. Later, TeleSoft (also located in San Diego) offered an early Ada development environment that used p-code and was therefore able to run on a number of hardware platforms including the Motorola 68000, the System/370, and the Pascal MicroEngine. UCSD p-System shares some concepts with the later Java platform. Both use a virtual machine to hide operating system and hardware differences, and both use programs written to that virtual machine to provide cross-platform support. Likewise both systems allow the virtual machine to be used either as the complete operating system of the target computer or to run in a "box" under another operating system. The UCSD Pascal compiler was distributed as part of a portable operating system, the p-System. == History == UCSD p-System began around 1974 as the idea of UCSD's Kenneth Bowles, who believed that the number of new computing platforms coming out at the time would make it difficult for new programming languages to gain acceptance. He based UCSD Pascal on the Pascal-P2 release of the portable compiler from Zurich. He was particularly interested in Pascal as a language to teach programming. UCSD introduced two features that were important improvements on the original Pascal: variable length strings, and "units" of independently compiled code (an idea included into the then-evolving Ada (programming language)). Niklaus Wirth credits the p-System, and UCSD Pascal in particular, with popularizing Pascal. It was not until the release of Turbo Pascal that UCSD's version started to slip from first place among Pascal users. The Pascal dialect of UCSD Pascal came from the subset of Pascal implemented in Pascal-P2, which was not designed to be a full implementation of the language, but rather "the minimum subset that would self-compile", to fit its function as a bootstrap kit for Pascal compilers. UCSD added strings from BASIC, and several other implementation dependent features. Although UCSD Pascal later obtained many of the other features of the full Pascal language, the Pascal-P2 subset persisted in other dialects, notably Borland Pascal, which copied much of the UCSD dialect. == Versions == There were four versions of UCSD p-code engine, each with several revisions of the p-System and UCSD Pascal. A revision of the p-code engine (i.e., the p-Machine) meant a change to the p-code language, and therefore compiled code is not portable between different p-Machine versions. Each revision was represented with a leading Roman Numeral, while operating system revisions were enumerated as the "dot" number following the p-code Roman Numeral. For example, II.3 represented the third revision of the p-System running on the second revision of the p-Machine. === Version I === Original version, never officially distributed outside of the University of California, San Diego. However, the Pascal sources for both Versions I.3 and I.5 were freely exchanged between interested users. Specifically, the patch revision I.5a was known to be one of the most stable. === Version II === Widely distributed, available on many early microcomputers. Numerous versions included Apple II ultimately Apple Pascal, DEC PDP-11, Intel 8080, Zilog Z80, and MOS 6502 based machines, Motorola 68000 and the IBM PC (Version II on the PC was restricted to one 64K code segment and one 64K stack/heap data segment; Version IV removed the code segment limit but cost a lot more). Project members from this era include Dr Kenneth L Bowles, Mark Allen, Richard Gleaves, Richard Kaufmann, Pete Lawrence, Joel McCormack, Mark Overgaard, Keith Shillington, Roger Sumner, and John Van Zandt. === Version III === Custom version written for Western Digital to run on their Pascal MicroEngine microcomputer. Included support for parallel processes for the first time. === Version IV === Commercial version, developed and sold by SofTech. Based on Version II; did not include changes from Version III. Did not sell well due to combination of their pricing structure, performance problems due to p-code interpreter, and competition with native operating systems (on top of which it often ran). After SofTech dropped the product, it was picked up by Pecan Systems, a relatively small company formed of p-System users and fans. Sales revived somewhat, due mostly to Pecan's reasonable pricing structure, but the p-System and UCSD Pascal gradually lost the market to native operating systems and compilers. Available for the TI-99/4A equipped with p-code card, Commodore CBM 8096, Sage II/IV, HP 9000, and BBC Micro with 6502 second processor. == Further use == The Corvus Systems computer used UCSD Pascal for all its user software. The "innovative concept" of the Constellation OS was to run Pascal (interpretively or compiled) and include all common software in the manual, so users could modify as needed.
Vacuum tube characteristics
Vacuum tube characteristics (also called tube curves, valve characteristics or valve curves) describes the electrical relationships between electrode voltages and currents in a vacuum tube. These relationships are commonly presented as characteristic curves in tube manuals and engineering references. The curves typically show plate current versus plate voltage for several fixed control-grid voltages, showing how current varies with electrode potentials under controlled conditions. Designers use them to select operating points, determine voltage gain, estimate output power, and construct graphical load-line analyses. The use of characteristic curves as an engineering tool for analyzing vacuum-tube operation was established in the 1910s, notably in work by Edwin Howard Armstrong. Examples of such curves appear in early tube manuals and textbooks and form the basis of classical vacuum-tube circuit design. Different types of vacuum tubes are characterized using plots appropriate to their electrode structure and intended use. Two-electrode devices such as diodes are described primarily by the relation between plate voltage and plate current. Amplifying tubes containing control grids, such as triodes, tetrodes, pentodes, and beam tetrodes, are represented by families of curves measured for different grid voltages. From these families additional parameters such as amplification factor (μ), transconductance (gm), and plate resistance (rp) may be obtained. Although these plots are used primarily for circuit design, their shapes arise from the underlying physics of electron flow in vacuum tubes. The physical principles responsible for the observed characteristics are discussed in later sections. == 3/2 power law == In high-vacuum thermionic diodes operating under normal conditions, plate current increases nonlinearly with plate voltage. Over the space-charge-limited region, the current is well approximated by the three-halves power relation I p = P ⋅ V p 3 / 2 {\displaystyle I_{p}=P\cdot V_{p}^{3/2}} where P {\displaystyle P} is the perveance of the tube. Perveance is determined primarily by electrode geometry, including cathode area and cathode-to-plate spacing. It provides a practical measure of current-producing capability and is often used in tube manuals in place of a complete family of plate-characteristic curves. == Signal diode characterization == For small-signal diodes, tube manuals typically publish a single static anode characteristic showing anode current (Ia) as a function of anode voltage (Va), measured with the heater operating at its rated voltage. Because the diode contains no control grid, only one such I–V curve is required. The low-voltage portion of the curve is particularly important in detector service, where the nonlinear curvature of the current–voltage relation allows a small alternating signal to produce a net direct-current output, resulting in rectification. In addition to the static characteristic, tube manuals specify heater ratings, maximum plate voltage, permissible average current, and interelectrode capacitance. These parameters define the allowable operating region and high-frequency behavior. Another typical data sheet for a diode is for the Philips EB91 double diode. This book includes curves of the diode response in use as a detector. The output voltage is non-zero for an input voltage of 0 due to the Edison effect. == Rectifier characterization == Vacuum-tube rectifiers intended for power-supply service are specified differently from signal diodes. Their data emphasize heater requirements, peak inverse voltage, maximum peak plate current, permissible DC output current for various filter configurations, and regulation characteristics. Rectifier tubes exhibit nonlinear voltage drop that increases with current. For limited operating ranges this behavior may be represented by an equivalent or effective series resistance corresponding to the local slope of the plate characteristic (dynamic plate resistance, dV/dI). Diode voltages can be determied by use of a graphical aide. In capacitor-input supplies, conduction occurs in pulses near the peaks of the AC waveform, producing peak currents substantially greater than the average DC load current. Data sheets therefore specify maximum peak plate current and permissible filter capacitance in addition to average DC ratings. Under varying load conditions, the supply voltage changes in accordance with the rectifier's nonlinear characteristic and effective impedance. == Triode characterization == === Early use === The systematic use of characteristic curves to explain and quantify vacuum-tube amplification was introduced by Edwin Howard Armstrong in 1914. Using measured plate voltage-current curves, Armstrong demonstrated the mechanism of triode amplification and clarified the operation of grid-leak detection. ==== Plate and transfer characteristics ==== Triode data sheets present families of plate characteristics showing plate current I p {\displaystyle I_{p}} as a function of plate voltage E p {\displaystyle E_{p}} for several fixed grid voltages E g {\displaystyle E_{g}} . From these curves the operating point, voltage gain, and load-line behavior may be determined graphically. In normal operation, plate current depends on both grid and plate voltage. Classical analysis shows that the characteristics for different grid voltages are similar in form and differ primarily by horizontal displacement. In triodes, plate current may be approximated by I p = k ( E g + E p μ ) 3 / 2 {\displaystyle I_{p}=k\left(E_{g}+{\frac {E_{p}}{\mu }}\right)^{3/2}} where E g {\displaystyle E_{g}} is the grid voltage, E p {\displaystyle E_{p}} the plate voltage, μ {\displaystyle \mu } the amplification factor, and k {\displaystyle k} a constant determined by the tube geometry.. The amplification factor μ represents the relative effectiveness of grid voltage compared with plate voltage in controlling current. It is fundamentally determined by structural dimensions, particularly grid-to-cathode spacing relative to plate-to-cathode spacing. ==== Small-signal parameters ==== Triodes are commonly characterized by three interrelated small-signal parameters: Amplification factor ( μ {\displaystyle \mu } ) — the change in plate voltage divided by the change in grid voltage at constant plate current: μ = ( ∂ E p ∂ E g ) I p {\displaystyle \mu =\left({\frac {\partial E_{p}}{\partial E_{g}}}\right)_{I_{p}}} Transconductance ( g m {\displaystyle g_{m}} ) — the change in plate current divided by the change in grid voltage at constant plate voltage: g m = ( ∂ I p ∂ E g ) E p {\displaystyle g_{m}=\left({\frac {\partial I_{p}}{\partial E_{g}}}\right)_{E_{p}}} Plate resistance ( r p {\displaystyle r_{p}} ) — the change in plate voltage divided by the change in plate current at constant grid voltage: r p = ( ∂ E p ∂ I p ) E g {\displaystyle r_{p}=\left({\frac {\partial E_{p}}{\partial I_{p}}}\right)_{E_{g}}} These parameters are related by μ = g m r p {\displaystyle \mu =g_{m}r_{p}} as shown in classical tube theory treatments. These parameters are obtained either from slopes of the characteristic curves or from tabulated operating-point data. ==== Comparison of ECC81, ECC82, and ECC83 ==== The ECC81, ECC82, and ECC83 (also known respectively as 12AT7, 12AU7, and 12AX7) are closely related dual triodes widely used in small-signal amplifier stages. Although similar in construction and envelope size, they differ significantly in electrical parameters due to differences in electrode spacing and grid structure. (Data representative of manufacturer specifications.) The ECC83 exhibits high μ {\displaystyle \mu } and high plate resistance, producing large voltage gain but relatively low current drive capability. The ECC82 has lower μ {\displaystyle \mu } and lower plate resistance, allowing greater current delivery and reduced voltage gain. The ECC81 occupies an intermediate position with comparatively high transconductance and moderate amplification factor. These differences arise primarily from variations in grid pitch, cathode area, and electrode spacing, which determine perveance and amplification factor. Although the external envelope is similar, the internal geometry governs the characteristic curves and small-signal parameters. == Tetrode (screen-grid) characterization == The screen-grid tube (tetrode) was developed primarily to reduce the electrostatic coupling between plate and control grid that limited gain and stability in radio-frequency triode amplifiers. In triodes, the grid–plate capacitance provides feedback from plate to grid, restricting obtainable gain and often requiring neutralization circuits such as those used in neutrodyne receivers. By inserting a positively biased screen grid between control grid and plate, this capacitive coupling is greatly reduced, permitting higher stable gain at radio frequencies. The screen grid, also known as the shield grid or grid 2 (to distinguish it from t
GlTF
glTF (Graphics Library Transmission Format or GL Transmission Format and formerly known as WebGL Transmissions Format or WebGL TF) is a standard file format for three-dimensional scenes and models. A glTF file uses one of two possible file extensions: .gltf (JSON/ASCII) or .glb (binary). Both .gltf and .glb files may reference external binary and texture resources. Alternatively, both formats may be self-contained by directly embedding binary data buffers (as base64-encoded strings in .gltf files or as raw byte arrays in .glb files). An open standard developed and maintained by the Khronos Group, it supports 3D model geometry, appearance, scene graph hierarchy, and animation. It is intended to be a streamlined, interoperable format for the delivery of 3D assets, while minimizing file size and runtime processing by apps. As such, its creators have described it as the "JPEG of 3D". == Overview == The glTF format stores data primarily in JSON. The JSON may also contain blobs of binary data known as buffers, and refer to external files, for storing mesh data, images, etc. The binary .glb format also contains JSON text, but serialized with binary chunk headers to allow blobs to be directly appended to the file. The fundamental building blocks of a glTF scene are nodes. Nodes are organized into a hierarchy, such that a node may have other nodes defined as children. Nodes may have transforms relative to their parent. Nodes may refer to resources, such as meshes, skins, and cameras. Meshes may refer to materials, which refer to textures, which refer to images. Scenes are defined using an array of root nodes. Most of the top-level glTF properties use a flat hierarchy for storage. Nodes are saved in an array and are referred to by index, including by other nodes. A glTF scene refers to its root nodes by index. Furthermore, nodes refer to meshes by index, which refer to materials by index, which refer to textures by index, which refer to images by index. All glTF data structures support being extended using a JSON property, allowing arbitrary JSON data to be added. == Releases == === glTF 1.0 === Members of the COLLADA working group conceived the file format in 2012. At SIGGRAPH 2012, Khronos presented a demo of glTF, which was then called WebGL Transmissions Format (WebGL TF). On October 19, 2015, Khronos released the glTF 1.0 specification. ==== Adoption of glTF 1.0 ==== At SIGGRAPH 2016, Oculus announced their adoption of glTF citing the similarities to their ovrscene format. In October 2016, Microsoft joined the 3D Formats working group at Khronos to collaborate on glTF. === glTF 2.0 === The second version, glTF 2.0, was released in June 2017, and is a complete overhaul of the file format from version 1.0, with most tools adopting the 2.0 version. Based on a proposal by Fraunhofer originally presented at SIGGRAPH 2016, physically based rendering (PBR) was added, replacing WebGL shaders used in glTF 1.0. glTF 2.0 added the GLB binary format into the base specification. Other upgrades include sparse accessors and morph targets for techniques such as facial animation, and schema tweaks and breaking changes for corner cases or performance such as replacing top-level glTF object properties with arrays for faster index-based access. There is ongoing work towards import and export in Unity and an integrated multi-engine viewer and validator. ==== Adoption of glTF 2.0 ==== On March 3, 2017, Microsoft announced that they would be using glTF 2.0 as the 3D asset format across their product line, including Paint 3D, 3D Viewer, Remix 3D, Babylon.js, and Microsoft Office. Sketchfab also announced support for glTF 2.0. The glTF and GLB formats are used on and supported by companies including DGG, UX3D, Sketchfab, Facebook, Microsoft, Meta, Google, Adobe, Box, TurboSquid, Unreal Engine, Unity, and Qt Quick 3D. The format has been noted as an important standard for augmented reality, integrating with modeling software such as Autodesk Maya, Autodesk 3ds Max, and Poly. In February 2020, the Smithsonian Institution launched their Open Access Initiative, releasing approximately 2.8 million 2D images and 3D models into the public domain, using glTF for the 3D models. In July 2022, glTF 2.0 was released as the ISO/IEC 12113:2022 International Standard. Khronos stated they would make regular submissions to bring updates and new widely adopted glTF functionality into refreshed versions of ISO/IEC 12113 to ensure that there is no long-term divergence between the ISO/IEC and Khronos specifications. The open-source game engine Godot supports importing glTF 2.0 files since version 3.0 and export since version 4.0. === Extensions === The glTF format can be extended with arbitrary JSON to add new data and functionality. Extensions can be placed on any part of a glTF, including nodes, animations, materials, textures, and on the entire document. Khronos keeps a non-comprehensive registry of glTF extensions on GitHub, including all official Khronos extensions and a few third-party extensions. PBR extensions model the physical appearance of real-world objects, allowing developers to create realistic 3D assets that have the correct appearance. As new PBR extensions are released, they continue to expand PBR capabilities within the glTF framework, allowing a wider range of scenes and objects to be realistically rendered as 3D assets. The KTX 2.0 extension for universal texture compression enables 3D models in the glTF format to be highly compressed and to use natively supported texture formats, reducing file size and boosting rendering speed. Draco is a glTF extension for mesh compression, to compress and decompress 3D meshes, to help reduce the size of 3D files. It compresses vertex attributes, normals, colors, and texture coordinates. Various glTF extensions for game engine interoperability have been developed by OMI group. This includes extensions for physics shapes, physics bodies, physics joints, audio playback, seats, spawn points, and more. The VRM consortium has developed glTF extensions for advanced humanoid 3D avatars including dynamic spring bones and toon materials. == Derivative formats == 3D Tiles, an OGC Community Standard, builds on glTF to add a spatial data structure, metadata, and declarative styling for streaming massive heterogeneous 3D geospatial datasets. VRM, a model format for VR, is built on the .glb format. It is a 3D humanoid avatar specification and file format. == Software ecosystem == Khronos maintains the glTF Sample Viewer for viewing glTF assets. Khronos also maintains the glTF Validator for validating if 3D models conform to the glTF specification. Khronos maintains a glTF Compressor tool to interactively optimize and fine-tune compression settings for glTF assets using KTX 2.0 textures. glTF loaders are in open-source WebGL engines including PlayCanvas, Three.js, Babylon.js, Cesium, PEX, xeogl, and A-Frame. The Godot game engine supports and recommends the glTF format, with both import and export support. Open-source glTF converters are available from COLLADA, FBX, and OBJ. Assimp can import and export glTF. glTF files can also be directly exported from a variety of 3D editors, such as Blender, Unity (using the glTFast importer/exporter), Freecad, Vectary, Autodesk 3ds Max (natively or using Verge3D exporter), Autodesk Maya (using babylon.js exporter), Autodesk Inventor, Modo, Houdini, Paint 3D, Godot, and Substance Painter. Open-source glTF utility libraries are available for programming languages including JavaScript, Node.js, C++, C#, Python, Haskell, Java, Go, Rust, Haxe, Ada, and TypeScript. Khronos keeps a list of these libraries and other related applications on their ecosystem site. The Khronos 3D Commerce Working Group released Asset Creation Guidelines in 2020 outlining best practices for use of the glTF file format in 3D Commerce. In 2025, the Working Group launched Asset Creation Guidelines 2.0, a continuously updated resource with additional guidance for geometry, mesh optimization, UV maps, textures, materials/PBR performance, and web optimization. The Khronos PBR Neutral Tone Mappers specification is a tone mapper designed to faithfully reproduce an object's base color, hue, and saturation when using PBR rendering under grayscale lighting, supporting brand- and product-accurate color representation. Khronos maintains the glTF Asset Auditor to allow retailers and advertising technology platforms to validate 3D assets against either a default Audit Profile modelled on the 2020 3D Commerce Asset Creation Guidelines or a custom profile defined by the target application.
Web development
Web development is the process of designing, developing and maintaining websites and web apps. Web development encompasses several different fields, most commonly referring to the programming of websites. Front-end development is the act of developing the user interface and client-side code, while back-end development focuses on the infrastructure behind a website, mainly server-side code. Since the World Wide Web was released publicly in 1993, web development has evolved greatly, with websites changing from a collection of static HTML pages to complex projects using frameworks, servers, and databases. == Overview == Web development includes many individual tasks, including web design, web content development, networking, and coding. Among web professionals, "web development" usually refers to the main non-design aspects of building websites: writing markup and coding. Web development is generally split into two fields: front-end development and back-end development. Front-end developers create the user interface of websites, turning web designs into HTML, CSS, and JavaScript code. Front-end developers must also make sure that websites work consistently across different browsers and devices. Back-end development, also known as server-side development, focuses on the infrastructure behind a website, including APIs, database management, and security. Some choose to be full-stack developers, meaning they work on both the front-end and back-end. == History == The World Wide Web is often categorised into three generations: Web 1.0, Web 2.0, and Web 3.0 (or Web3). It was invented in 1989, and released to the public in 1993. In the early years of the web, restrospecitvely referred to as Web 1.0, websites were simply a collection of static HTML files, and had limited interactivity. After the introduction of JavaScript in 1995, websites could contain logic, allowing for interactivity. The following year CSS was released, allowing greater control over the styling of web pages. In 1999, the term Web 2.0 was coined by Darcy DiNucci. The term later resurfaced in the early 2000s, as websites started to increase in complexity, requiring server-side services in addition to JavaScript. This led to the emergence of various new programming languages and frameworks designed for backend services, such as PHP, Active Server Pages, and Jakarta Server Pages. This enabled websites to do additional server-side processing, such as accessing databases. Another shift in web development was the release of the iPhone in 2007. This created a new medium for accessing the web, requiring a new approach to web development, and resulting in responsive web design, which allows a single website to appear different depending on the device running it. Later, progressive web apps were introduced, allowing websites to be installed on a device as an independent application. In the 2010s, JavaScript frameworks began to emerge, creating new ways to manipulate web pages, and increasing compatibility between web browsers. JQuery was popular in the early 2010s, but was later surpassed by other frameworks such as React and Vue.js. In the mid 2020s, use of AI became prevalent among web developers, with the 2025 Stack Overflow survey showing over 80% of developers saying the use AI at least monthly in their development process.
Digital Cinema Package
A Digital Cinema Package (DCP) is a collection of digital files used to store and convey digital cinema (DC) audio, image, and data streams. The term was popularized by Digital Cinema Initiatives, LLC in its original recommendation for packaging DC contents. However, the industry tends to apply the term to the structure more formally known as the composition. A DCP is a container format for compositions, a hierarchical file structure that represents a title version. The DCP may carry a partial composition (e.g. not a complete set of files), a single complete composition, or multiple and complete compositions. The composition consists of a Composition Playlist (in XML format) that defines the playback sequence of a set of Track Files. Track Files carry the essence (audio, image, subtitles), which is wrapped using Material eXchange Format (MXF). Track Files must contain only one essence type. Two track files at a minimum must be present in every composition (see SMPTE ST429-2 D-Cinema Packaging – DCP Constraints, or Cinepedia): a track file carrying picture essence, and a track file carrying audio essence. The composition, consisting of a Composition Playlist (CPL) and associated track files, are distributed as a Digital Cinema Package (DCP). A composition is a complete representation of a title version, while the DCP need not carry a full composition. However, as already noted, it is commonplace in the industry to discuss the title in terms of a DCP, as that is the deliverable to the cinema. The Picture Track File essence is compressed using JPEG 2000 and the Audio Track File carries a 24-bit linear PCM uncompressed multichannel WAV file. Encryption may optionally be applied to the essence of a track file to protect it from unauthorized use. The encryption used is AES 128-bit in CBC mode. In practice, there are two versions of composition in use. The original version is called Interop DCP. In 2009, a specification was published by SMPTE (SMPTE ST 429-2 Digital Cinema Packaging – DCP Constraints) for what is commonly referred to as SMPTE DCP. SMPTE DCP is similar but not backwards compatible with Interop DCP, resulting in an uphill effort to transition the industry from Interop DCP to SMPTE DCP. SMPTE DCP requires significant constraints to ensure success in the field, as shown by ISDCF. While legacy support for Interop DCP is necessary for commercial products, new productions are encouraged to be distributed in SMPTE DCP. == Technical specifications == The DCP root folder (in the storage medium) contains a number of files, some used to store the image and audio contents, and some other used to organize and manage the whole playlist. === Picture MXF files === Picture contents may be stored in one or more reels corresponding to one or more MXF files. Each reel contains pictures as MPEG-2 or JPEG 2000 essence, depending on the adopted codec. MPEG-2 is no longer compliant with the DCI specification. JPEG 2000 is the only accepted compression format. Supported frame rates are: SMPTE (JPEG 2000) 24, 25, 30, 48, 50, and 60 fps @ 2K 24, 25, and 30 fps @ 4K 24 and 48 fps @ 2K stereoscopic MXF Interop (JPEG 2000) – Deprecated 24 and 48 fps @ 2K (MXF Interop can be encoded at 25 frame/s but support is not guaranteed) 24 fps @ 4K 24 fps @ 2K stereoscopic MXF Interop (MPEG-2) – Deprecated 23.976 and 24 fps @ 1920 × 1080 Maximum frame sizes are 2048 × 1080 for 2K DC, and 4096 × 2160 for 4K DC. Common formats are: SMPTE (JPEG 2000) Flat (1998 × 1080 or 3996 × 2160), = 1.85:1 aspect ratio Scope (2048 × 858 or 4096 × 1716), ~2.39:1 aspect ratio HDTV (1920 × 1080 or 3840 × 2160), 16:9 aspect ratio (~1.78:1) (although not specifically defined in the DCI specification, this resolution is DCI compliant per section 8.4.3.2). Full (2048 × 1080 or 4096 × 2160) (~1.9:1 aspect ratio, official name by DCI is Full Container. Not widely accepted in cinemas.) MXF Interop (MPEG-2) – Deprecated Full Frame (1920 × 1080) 12 bits per component precision (36 bits total per pixel) XYZ' colorspace; the prime mark indicates gamma encoding (gamma=2.6) Maximum bit rate is 250 Mbit/s (1.3 MBytes per frame at 24 frame per second) === Sound MXF files === Sound contents are also stored in reels corresponding to picture reels in number and duration. In case of multilingual features, separate reels are required to convey different languages. Each file contains linear PCM essence. Sampling rate is 48,000 or 96,000 samples per second Sample precision of 24 bits Linear mapping (no companding) Up to 16 independent channels === Asset map file === List of all files included in the DCP, in XML format. === Composition playlist file === Defines the playback order during presentation. The order is saved in XML format in this file; each picture and sound reel is identified by its UUID. In the following example, a reel is composed by picture and sound: === Packing list file or package key list (PKL) === All files in the composition are hashed and their hash is stored here, in XML format. This file is generally used during ingestion in a digital cinema server to verify if data have been corrupted or tampered with in some way. For example, an MXF picture reel is identified by the following