Table of Contents

Glossary

Terms used by the toolkit's manual, examples and release notes. Each entry links to the page that says more: a toolkit page where the toolkit owns the idea, the Stride manual where the engine does. Terms are grouped by topic, as in the Stride glossary, and sorted alphabetically within each group.

Getting around

  • Code-only: An approach to building a Stride game in C# without using Game Studio. Scenes are created in code, and content can be generated or loaded from files; the toolkit's extensions keep that code short. See Code-Only.
  • Example: A small runnable project that teaches one idea, such as moving a camera or adding physics. Each has its own folder under examples/code-only and appears in the docs gallery and the launchers. See the examples gallery and contributing examples.
  • Extension method: A C# static method called as if it belonged to another type, such as game.AddGround(). Nearly every toolkit feature is one, so the engine's own types stay as they are. See Extensions.
  • File-based app: A single .cs file run with dotnet run app.cs, with its packages declared in #:package lines at the top instead of a project file. See Create a file-based app.
  • Game Studio: Stride's editor for scenes, assets and settings. The toolkit works without it, and its components also work inside it. See Using the Toolkit in Game Studio and the Stride manual.
  • Launcher: The two toolkit programs that list and start every example, one in a console and one with a window, both reading the same generated manifest. See Building the toolkit.
  • Manual: These pages. The Stride manual covers the engine; this one covers what the toolkit adds, and explains engine behaviour that is easy to trip over when working from code.
  • NuGet package: How the toolkit reaches a game: each library, such as Stride.CommunityToolkit.Bepu, is a package a project references. See Create project.
  • Playground: A scratch project in the examples folder for trying things out, kept small on purpose. It is not an example: the docs and the launchers do not list it. See contributing examples.
  • Stride: The open-source C# game engine the toolkit extends. See stride3d.net and Key concepts.
  • Stride Community Toolkit: A set of libraries, examples and documentation, maintained by the community, that make Stride easier to use from code. See Getting started.

Engine building blocks

  • Component: A piece of data or behaviour attached to an entity: a model, a camera, a physics body, a script. See Components and scripts and Entity-component system.
  • Delta time: The game time that passed since the previous update, read from GameTime.Elapsed (a TimeSpan; .TotalSeconds gives it in seconds). Multiply a speed by it to get how far to move in this update, so movement does not depend on frame rate. See Delta time and GameTime.
  • Deterministic mode: A fixed timestep with exactly one update per draw, so frame N is the same simulated instant every run; game.SetDeterministic() turns it on. Captures and golden images depend on it. See Game extensions.
  • Entity: The basic object in a scene: a name, a transform, and a list of components. On its own it does nothing. See Entity extensions and the Stride manual.
  • Entity-component system (ECS): The pattern Stride is built on: entities hold components, and processors handle the behaviour that components of one kind share. See Components and scripts.
  • Fixed timestep: Updating the simulation in equal time slices regardless of how fast frames arrive. Physics runs this way; deterministic mode makes the whole game do so.
  • Game loop: The engine's repeating cycle: read input, update the world, draw a frame. game.Run(start:, update:) hands you the two moments that matter. See Game extensions.
  • GameTime: The clock object passed to every update: total time, time since the previous update, frame count. See the API.
  • Local space / world space: Local coordinates are relative to an entity's parent; world coordinates are absolute. An entity's Transform.WorldMatrix converts one to the other. See Engine patterns.
  • Processor: An engine system that tracks matching components and handles shared behaviour, such as updating them or preparing them for rendering. The right home for behaviour shared by many entities. See Components and scripts and Components in Game Studio.
  • Scene: The tree of entities the game shows and updates. Code-only games build it in start; Game Studio saves it as an asset. See Scenes.
  • Script: A component with code the engine calls: a StartupScript once, a SyncScript every frame, an AsyncScript as a long-running task. See Script extensions and Types of script.
  • Script system: The engine service that schedules scripts, and what game.Script.AddTask(...) and the toolkit's script-system extensions talk to. See Script system extensions.
  • Transform: The component every entity has: position, rotation and scale, plus the parent link. Moving an entity means writing to it. See Engine patterns.
  • World units: Stride's distances are metres by convention; a cube of size 1 is one metre across. See World units.

Content: models, materials, textures

  • Asset: A file the engine compiles and loads: a model, texture, sound, scene. Code-only games make most content at runtime instead. See Assets.
  • Asset compiler: The tool that turns assets into runtime data; even a code-only game runs it once, to copy the engine's shader sources into its data/db folder. See Troubleshooting.
  • Content manager: game.Content, the loader for compiled assets by URL. Code-only games rarely need it. See Asset URL.
  • EM: A font's own unit of size: the design grid every glyph is drawn on, which maps to the font size when text is set. The toolkit's outlines and TextMeshOptions.Size are in EM units, so a capital letter is about 0.7 EM tall whatever the font. See 3D Text.
  • Glyph: The shape a font draws for a character: one or more closed curves (contours), some of them holes, with an advance that says how far the pen moves after it. MeshFont reads glyph outlines from a font file, and TextMesh extrudes them. See 3D Text.
  • Index buffer: The list of vertex indices that says which vertices form each triangle, so a vertex shared by six triangles is stored once. See MeshBuilder.
  • PBR (physically based rendering): Describing a surface by what it is made of - a colour, how metallic it is, how rough - and computing the light from those claims, instead of tuning highlights by eye. Stride's materials are PBR; the toolkit's CreateMaterial takes the three numbers. See Materials from code.
  • Material: How a surface reacts to light: colour, roughness, metalness, emission, transparency. In code it is built from a MaterialDescriptor; game.CreateMaterial(...) wraps the common case. See Engine patterns and Materials.
  • Mesh: Geometry the GPU draws: a vertex buffer, an index buffer and a layout. A model is one or more meshes with materials. See MeshBuilder.
  • Model: The renderable asset an entity shows through its ModelComponent: meshes plus the materials they use. See Model extensions.
  • Prefab: A saved entity tree instantiated many times, in the editor or from code. See Entity extensions and Prefabs.
  • Primitive: A built-in shape such as a cube, sphere, capsule, cone or torus, generated from a few numbers. game.CreatePrimitive(Primitive3D.Sphere(0.5f)) builds one with a material; the overloads in the physics packages can also add a collider. See Engine patterns.
  • Procedural model: A model computed from parameters at runtime, with no file behind it; every primitive is one, and the toolkit adds 2D and lettering variants. See Engine patterns.
  • Runtime font: A font whose character images are drawn as they are needed, from a system or embedded TTF file, with no font asset prepared beforehand. Several of the toolkit's text features use one, so a code-only game needs no font file of its own. See Engine patterns.
  • Skybox: The picture of the surroundings, drawn behind everything and used to light reflective surfaces. Stride.CommunityToolkit.Skyboxes carries a ready one. See Skyboxes.
  • Sprite font: Draws text using character images or distance-field data stored in textures. Characters can be prepared before the game runs or generated as needed. See Sprite fonts.
  • Texture: An image on the GPU: a picture on a surface, a data table for a shader, or a target to draw into. See TextureCanvas and Textures.
  • Vertex: One corner of a triangle, carrying a position and whatever else the shader needs: a normal, a colour, texture coordinates. See MeshBuilder.
  • Vertex buffer: The GPU array of vertices a mesh draws from, laid out by its vertex declaration. See MeshBuilder.

Rendering

  • Billboard: A flat shape that always turns to face the camera, so a sprite or a glow never shows its edge. Used by particles, ShapeBatch and world text. See ShapeBatch.
  • Charts: The toolkit's line, scatter and 3D charts, drawn through ShapeBatch and updated live. See Charts.
  • Compositor (graphics compositor): The description of how a frame is rendered: which cameras, in which order, through which renderers, into which targets. The toolkit's Add* calls edit it for you. See Graphics compositor.
  • CPU / GPU: The CPU (central processing unit) is the computer's main processor, which runs your C# code. The GPU (graphics processing unit) is the graphics card's processor, which runs shaders and draws the picture by doing many simple calculations at once.
  • Debug overlay: The toolkit's block of text lines in a screen corner, for keys and readouts; every example's on-screen help uses it. See Debug overlay.
  • Debug shapes: Immediate-mode lines, boxes, spheres and arrows drawn for a frame or a duration, for seeing what the code thinks. See Debug shapes.
  • Depth buffer: The per-pixel record of how far the nearest drawn surface is, which is how a near object hides a far one. Soft particles and the depth fade read it. See Rendering pipeline.
  • Depth fade (soft edge): Fading a transparent shape where it meets solid geometry, so a glow or a puff of smoke does not cut the floor with a hard line. See ShapeBatch.
  • Display scale (DPI): The operating system's zoom, such as 150%, that the toolkit's text and pixel sizes follow so a HUD reads the same on every monitor. See Debug overlay.
  • Draw call: One command to the GPU to draw a mesh. Thousands per frame are expensive; instancing and batching cut them. See Instancing.
  • Entity text: A screen-space label pinned to an entity, readable at any distance; the gallery's numbered labels. See Entity text.
  • Forward renderer: Stride's default way to draw a frame: each mesh is shaded with its lights as it is drawn. See Rendering pipeline.
  • GPU picking: Answering "what is under this screen point" by drawing entity ids into a hidden image and reading one pixel back, so it works without colliders. See GPU picking.
  • Gizmo: A helper drawn in the world to show something that has no look of its own: the axes at the origin, a light's direction, the outline of a collider. An editor draws them to grab and drag; the toolkit draws them to see. game.AddGroundGizmo() adds the axes at the ground, game.AddOrientationGizmo() a screen-corner axis indicator, and game.AddPhysicsDebug() the collider outlines (P) and debug meshes (F11). See Entity extensions and Physics extensions.
  • Glow: In ShapeBatch and charts, a soft halo of a given pixel width outside a shape's edge; not the engine's bloom. See ShapeBatch.
  • HDR: High dynamic range: rendering with colour values above 1, so a bright light or an emissive (glowing) material can be brighter than white, then tone-mapped down for the screen. Stride's default pipeline is HDR. See Post effects.
  • HUD: Heads-up display: text and shapes drawn on the screen rather than in the world, such as a score, a health bar or a crosshair. Screen-space ShapeBatch and the debug overlay draw one. See ShapeBatch.
  • Instancing: Drawing many copies of one mesh in a single draw call, each with its own transform. See Instancing and Engine patterns.
  • MeshBuilder: The toolkit's helper for building meshes from code with chained calls: choose a layout, add vertices and indices, get a mesh. See MeshBuilder.
  • Outline (constant-pixel): An edge that stays the same width on screen whether the shape is near or far, which ShapeBatch gets from measuring the shape per pixel. See ShapeBatch.
  • Picking: Finding what is under the cursor. Raycast picking asks the physics engine; GPU picking asks the rendered frame. See Engine patterns and GPU picking.
  • Post effect (post-processing): An effect applied to the finished frame: bloom, fog, vignette, tone mapping, or a custom colour transform such as the toolkit's night vision. See Post effects and the post effects example.
  • Reference grid: The toolkit's grid of numbered lines that shows where things are, in world coordinates or in screen pixels. game.AddGrid() adds one; G steps through off, world and screen. See Reference grid.
  • Render feature: The engine class that draws one kind of thing (meshes, sprites, particles, ShapeBatch shapes) in phases: collect, prepare, draw. See Shaders in a package and Render features.
  • Render group: A tag on a component that a render stage's selector filters on; how one camera draws some things and not others. See Render groups and masks.
  • Render stage: A named slot in the frame (opaque, transparent, shadow casters, the toolkit's picking stage) that meshes are routed to. See Render stages.
  • Render target (render texture): A texture the GPU draws into instead of the screen, later shown on a surface or read back. See Render to texture.
  • Render to texture: A second camera drawn into a texture, for monitors, minimaps or picture-in-picture. See Render to texture.
  • Render view: One camera's worth of a frame in the render system: the objects it can see, sorted, with everything outside its view skipped (culled). A scene renderer owns one. See Custom scene renderers.
  • Scene renderer: A step in the compositor that draws something: the forward renderer, a debug renderer, the toolkit's text and picking renderers. See Custom scene renderers.
  • Screen space: Positions in pixels or fractions of the window rather than in the world. ShapeBatch.Screen draws there. See ShapeBatch.
  • SDF (signed distance field): For every pixel, how far it is from a shape's edge, negative inside. ShapeBatch draws its shapes from one, which is what makes outlines and glows exact at any distance. See ShapeBatch.
  • ShapeBatch: The toolkit's renderer for discs, rings, polygons, lines, arcs and panels with constant-pixel outlines, in the world or on the screen. See ShapeBatch.
  • TextureCanvas: The toolkit's CPU-side image editor: load, blur, resample, combine and draw into a texture from code. See TextureCanvas.
  • Tone mapping: Squeezing HDR colours into the 0-1 range the screen can show. See Post effects.
  • Wireframe: Drawing only the edges of triangles. Stride has a render setting for it; the toolkit's mesh examples show it. See Mesh outline.
  • World text: Text placed in the world with a height in world units, facing where you tell it; the gallery's index board. See World text.

Shaders

  • Compute shader: A GPU program that runs over data rather than pixels, for simulations and heavy maths. See the compute boids example.
  • Effect (.sdfx): Stride's file that assembles a shader from mixins, with switches for the variants a material or feature needs. The engine generates a ShaderMixins class from it. See Effect language and Shaders in a package.
  • Effects package: Stride.CommunityToolkit.Effects, the toolkit package containing effects such as post-processing colour transforms and GPU picking. See GPU picking.
  • HLSL: Microsoft's shader language; SDSL is HLSL with classes and mixins added. See Shading language.
  • Mixin: A shader class that composes into another, Stride's way of building one shader from reusable pieces instead of copy-paste. See Shader classes, mixins and inheritance.
  • Parameter key: The typed name a C# side uses to set a shader value, such as a colour or a texture. See Custom shaders.
  • Shader: A small program the GPU runs per vertex or per pixel to decide where geometry lands and what colour it gets. See Effects and shaders.
  • SDSL (.sdsl): Stride's shading language and file extension: HLSL with classes, inheritance and mixins. A shader in a package must be an embedded resource so the engine can find its source. See Shaders in a package.
  • Shader compilation: Turning SDSL into a program the graphics driver can run. Stride can do it when the game is built or while it runs, and caches the result; when a shader it needs has not been compiled yet, the first frame that uses it pauses briefly, which is why captures wait a few frames. See Compile shaders.

Particles

  • Additive blending: Adding a particle's colour to what is behind it, so overlapping particles get brighter: fire, sparks, lasers. Alpha blending covers instead: smoke. See the particle gallery and Particle materials.
  • Child emitter: An emitter that spawns from another emitter's particles, on their death, along their path or when they hit something; how a firework rocket bursts. See Spawners.
  • Emitter: One stream of particles with its own lifetime, spawner, initializers, updaters, shape and material. A particle system holds several. See Emitters.
  • Flipbook: A texture cut into a grid of frames played through over a particle's life, so one smoke puff forms and thins. See Particle materials.
  • Force field: An updater that pushes particles with a vortex, a repulsor or a directed wind inside a volume. See Updaters.
  • Initializer: Sets a particle's starting values as it is born: position, velocity, size, colour, rotation. See Initializers.
  • Particle system: A ParticleSystemComponent on an entity, simulated on the CPU and drawn by the GPU; Stride's is not a compute-shader system. See Particles.
  • Ribbon / trail: Particles joined into one strip behind a moving emitter: a sword swing, a laser, a comet. See Ribbons and trails.
  • Shape builder: Turns each particle into geometry: a billboard, a flat quad, an oriented quad stretched along its velocity, a hexagon, a ribbon. See Shapes.
  • Simulation space: Whether particles, once born, move independently of the emitter (world space), so a moving emitter leaves them behind, or are carried along with it (local space). See Emitters.
  • Soft particles: Particles with a depth fade, so a smoke sprite fades where it meets the ground instead of cutting it. See Particle materials.
  • Spawner: Decides when particles are born: so many per second, per frame, in a burst, per unit of distance travelled. See Spawners.
  • Updater: Runs over every living particle each frame: gravity, force fields, colliders, size and colour over life. You can write your own in C#. See Updaters.

Physics

  • Bepu (BepuPhysics 2): The C# physics engine Stride 4.4 uses by default; the toolkit's Stride.CommunityToolkit.Bepu builds bodies and colliders for it. See Physics extensions and Physics.
  • Body (rigid body): A physics object with mass that gravity and collisions move. See Rigid bodies.
  • Body interpolation: Drawing a body part of the way between its last two physics poses, so that it moves smoothly when frames come faster than physics steps. Off by default in Bepu; set BodyComponent.InterpolationMode. See the Cube Fountain example.
  • Box2D: A 2D physics engine; Stride.CommunityToolkit.Box2D wraps Box2D.NET for 2D games. See Physics extensions.
  • Bullet: Stride's previous physics engine, still available; Stride.CommunityToolkit.Bullet has the same helpers for it. See Bullet physics.
  • Character controller: A body that walks, jumps and stands on slopes without tipping over, driven by input. See Characters.
  • Collider: The shape physics uses for an entity, often simpler than the mesh you see: a box, sphere, capsule, or a convex hull. See Colliders.
  • Compound collider: Several collider shapes under one body; every toolkit helper builds one. See Collider shapes.
  • Constraint (joint): A rule linking two bodies: a hinge, a rope, a motor. See Why isn't my constraint doing anything? and Constraints.
  • Contact events: Callbacks when two colliders start or stop touching, for damage, sounds or triggers. See Triggers.
  • Contact spring: How Bepu models two things touching: as a spring with a frequency (stiffness) and a damping ratio (how much of a hit it absorbs). The pair decides whether a body bounces; with the defaults nothing does. See Bounce and friction.
  • Convex hull: The smallest shape with no inward dents that encloses a set of points, like shrink-wrap around a mesh. Used as a collider for shapes that are not primitives; hulls are expensive to build, so the toolkit shares one between bodies of the same shape. See Who owns the transform?.
  • Kinematic body: A body that moves only where you put it, pushes others, and is not pushed back: platforms, doors. See Kinematic rigid bodies.
  • Mesh collider: A collider that is the model's own triangles, so a ring keeps its hole where a convex hull would fill it. Built from any model, loaded or procedural, and usually static: a mesh is a surface with no inside, and two meshes meeting costs triangle against triangle. See Physics extensions and E05_3D_MeshColliders.
  • Motor / servo: A constraint that drives towards a target velocity (motor) or a target position (servo). See Why isn't my constraint doing anything?.
  • NaN: Not a Number: a special floating-point value produced by an undefined calculation, such as 0f / 0f. NaN values spread through every calculation they touch and can disrupt a physics simulation; a body whose position becomes NaN is lost. See Single.NaN and Who owns the transform?.
  • Overlap / sweep query: Asking which bodies a shape touches (overlap) or what a shape would hit if moved along a line (sweep). See Physics queries.
  • Raycast: Shooting a line into the world and asking the physics engine what it hits first; the usual way to click on things. See Raycasts.
  • Restitution / friction: Bounciness and grip of a surface, set per body or collider. Bepu has no restitution number: bounce comes from the contact spring, and a pair's friction is the two coefficients multiplied. See Bounce and friction and Rigid bodies.
  • Simulation update: The physics engine's own tick, on a fixed timestep; ISimulationUpdate runs code in step with it. See Physics update.
  • Sleeping: A body that has been still for a while is put to sleep and left out of the simulation until something wakes it. Setting a velocity does not wake it; set Awake = true as well. See Who owns the transform?.
  • Static body: A collider that never moves: floors, walls. See Static colliders.
  • Substeps: Splitting one physics step into several smaller ones for stability, at a cost. See Simulation.
  • Transform ownership: Once a body exists, the physics engine writes the entity's transform; moving the entity yourself does nothing or fights it. See Who owns the transform?.
  • Trigger (sensor): A collider that reports overlaps but does not push: a door zone, a checkpoint. See Triggers.
  • 2D physics: Bodies confined to the XY plane so a 3D engine behaves like a 2D one; Bepu does it with a 2D body component, Box2D natively. See Physics extensions.

Maths

  • AABB (axis-aligned bounding box): The smallest box with sides parallel to the X, Y and Z axes that encloses an object; cheap to test, so engines use it before anything precise. See BoundingBox.
  • Easing: A curve that shapes how a value moves from start to end over time, so motion accelerates, decelerates or overshoots instead of moving linearly. See the Easing Cheat Sheet and the easing tutorial.
  • Interpolation: Blending from one value to another by a fraction between 0 and 1. Lerp, short for linear interpolation, is the simplest kind: the blend moves at a constant rate. The toolkit's Interpolate extension on EasingFunction blends along an easing curve instead. See MathUtil.
  • Matrix: A 4x4 grid of numbers that stores a position, rotation and scale together; WorldMatrix is an entity's place in the world as one. See Matrix.
  • Normal: A direction perpendicular to a surface, used by lighting to know which way a face points. See MeshBuilder.
  • Plane: A flat surface without edges, given by a point and a normal or by four numbers; ShapeBatch draws on one. See Plane.
  • Quaternion: The four-number form of a rotation the engine uses; build one with Quaternion.RotationYawPitchRoll rather than reading its fields. See Quaternion.
  • Radians: An angle unit used by many rotation and maths functions. A full turn is 2π radians, equivalent to 360°, and MathUtil.DegreesToRadians converts. Check each API's expected unit: a camera's field of view, for one, is in degrees. See MathUtil.
  • Tween: Changes a value smoothly over a chosen duration, such as moving an object or fading its colour. An easing function controls how the change progresses. The toolkit's Tween keeps the time for you: start it, pass it the frame time each update, and read the current value. See Easing Basics and Easing in a 3D Game.
  • Vector2 / Vector3 / Vector4: A pair, triple or quadruple of floats: a point, a direction, a size, or a colour. See Vector3.

Input, UI and audio

  • Camera controller: A script that flies or orbits the camera from keyboard and mouse; the toolkit ships several. See Camera controllers.
  • Dear ImGui: An immediate-mode UI library for tools and debug panels; the toolkit wraps it twice, through Hexa.NET.ImGui (Stride.CommunityToolkit.ImGui) and through ImGui.NET (Stride.CommunityToolkit.ImGuiNet). See the ImGui example.
  • Immediate mode: Drawing or building UI by calling functions every frame, with nothing kept between frames: stop calling and it disappears. ImGui, debug shapes and ShapeBatch all work this way.
  • Myra: A UI library for Stride with windows, buttons and layouts. It is retained mode, the opposite of immediate mode: you build the controls once and they stay until you remove them. See the Myra example.
  • Spatial audio: Sound with a position, so it gets quieter with distance and pans left and right. See Audio extensions and Spatialized audio.
  • Stride UI: The engine's own UI system: pages, panels, buttons, laid out in code or the editor. See UI.
  • Virtual buttons: Named actions ("jump", "fire") bound to keys, gamepad buttons or axes, so the game reads the action, not the key. See Virtual buttons.

Tooling and quality

  • DocFX: The tool that builds this site from Markdown and XML comments. See Contribute to the documentation.
  • Golden image (gold scene): A reference screenshot committed to the repository; a test scene is drawn again and compared pixel by pixel, so a change to a renderer or shader that alters the picture fails a check instead of going unnoticed. See Shaders in a package.
  • Metadata block: The YAML comment at the end of an example's Program.cs that names, classifies and describes it for the docs and launchers. See Metadata schema.
  • NDepend: The static-analysis tool the maintainers run over the whole solution to catch design problems; its rules and suppressions live beside the solution. See Contribute code.
  • Release notes: The running list of what changed in each version, kept current as work lands. See Release notes.
  • Roslyn analyzer: A compiler plug-in that reports code issues as warnings; Stride ships some of its own for serialization rules. See Contribute code.
  • Screenshot capture: A toolkit feature that makes any example save one frame as an image and exit, switched on by an environment variable. The docs gallery pictures and the golden images are made with it. See Contribute examples.
  • WARP: Windows Advanced Rasterization Platform: a software renderer that runs Direct3D rendering on the CPU. The toolkit uses it to reduce graphics-hardware differences in screenshot tests. See Microsoft's WARP guide and Shaders in a package.