# Assistant conversation A6BPZL - Canonical URL: - Resource IRI: - Type: assistant conversation - Mode: chat ## Transcript ### 1. User can you read the ontology.md from the repo? ### 2. Assistant tool calls #### Tool call: `list_documents` ```json {} ``` ### 3. Tool result: list_documents FOLDERS - Accounting Algebra & Property Theory - Living Structure, Wholeness & Beauty - Living Structure, Wholeness & Beauty - ontology - Procedural Generation & Co-Creation - Roads, Trails & Movement - Scenario-Based & Behavioral Programming - Technology, Scale & Conviviality - Terrain, Hydrology & Erosion - Water Simulation & Rendering Accounting Algebra & Property Theory (4) - #GANFP9 A Fundamental Duality in the Mathematical and Natural Sciences: From Logic to Biology - 2024 | David Ellerman | 53 pp. Micro abstract: Traces an overlooked subset–partition duality—from logic and category theory through entropy and quantum indefiniteness to selectionist and generative mechanisms in biology. - #NBH3BE Algebraic Models for Accounting Systems - 2010 | Derek J. S. Robinson, José García Pérez, Robert A. Nehmer, Salvador Cruz Rambaud | World Scientific | 255 pp. Micro abstract: Develops accounting theory algebraically: balance vectors as modules, transactions as a group, and whole accounting systems as automata with quotients, homomorphisms, and decision algorithms for audit and control. - #7ESDBJ Economics, Accounting, and Property Theory - 1982 | David P. Ellerman | Lexington Books | 110 pp. Micro abstract: Ellerman's vector-accounting monograph: double entry generalized to property vectors ("accounting without valuation"), grounding a property-theoretic account of appropriation, the firm, and goodwill. - #C8FHDZ On implication and negation in partition logic - 2025 | , David Ellerman | Open Journal of Mathematical Sciences | 9 pp. | doi:10.30538/oms2025.0250 Micro abstract: Develops implication as a refinement-sensitive operation on set partitions, showing how relative negation yields local Boolean cores within the non-distributive algebra of partitions. Living Structure, Wholeness & Beauty (9) - #MH5J8D Beautimeter: Harnessing GPT for Assessing Architectural and Urban Beauty Based on the 15 Properties of Living Structure - 2025 | Bin Jiang | AI | 12 pp. | doi:10.3390/ai6040074 Micro abstract: Presents Beautimeter, a GPT-based tool that scores buildings and urban scenes against Christopher Alexander’s 15 properties of living structure to assess their coherence and beauty. - #XW22YY Generative Codes: The Path to Building Welcoming, Beautiful, Sustainable Neighborhoods - 2005 | Brian Hanson, Christopher Alexander, Maggie Moore Alexander, Michael Mehaffy, Randall Schmidt | Center for Environmental Structure | 21 pp. Micro abstract: Argues that living neighborhoods arise from generative codes: ordered, participatory steps that let buildings and public spaces unfold from local people, land, and context. - #SKRF4C Geography as a Science of the Earth’s Surface Founded on the Third View of Space - 2022 | Bin Jiang | Annals of GIS | 14 pp. | doi:10.1080/19475683.2021.1966502 Micro abstract: Recasts geography around an organismic view of space, using scaling and spatial dependence to understand—and deliberately create—places with greater living structure. - #PXG56P Harmony-Seeking Computations: A Science of Non-Classical Dynamics Based on the Progressive Evolution of the Larger Whole - 2009 | Christopher Alexander | Unpublished manuscript | 66 pp. Micro abstract: Proposes harmony-seeking computation as a creative process that repeatedly strengthens latent centers in a configuration while preserving and deepening the larger whole. - #MJKTBB Living Images: A Recursive Approach to Computing the Structural Beauty of Images or the Livingness of Space - 2023 | Bin Jiang, Chris de Rijke | Annals of the American Association of Geographers | 19 pp. | doi:10.1080/24694452.2023.2178376 Micro abstract: Measures an image’s structural beauty by recursively extracting its nested substructures, revealing a compact hierarchy that also captures visual saliency. - #3XSLTA Structural Beauty: A Structure-Based Computational Approach to Quantifying the Beauty of an Image - 2021 | Bin Jiang, Chris de Rijke | Journal of Imaging | 15 pp. | doi:10.3390/jimaging7050078 Micro abstract: Proposes a quantitative measure of structural beauty based on how many substructures an image contains and how strongly they form a hierarchy across scales. - #ZU8GZV Structure-Preserving Transformations - 2002 | Christopher Alexander | The Nature of Order, Book Two: The Process of Creating Life | 4 pp. | doi:10.2307/j.ctv27ftw6c.5 Micro abstract: Explains structure-preserving transformations: incremental changes that extend the centers and relationships already present in a place rather than weakening its wholeness. - #AULNWD The Nature of Poetic Order - 1998 | Richard P. Gabriel | Warren Wilson Alumni Conference, Mount Holyoke | 99 pp. Micro abstract: Gabriel's slide essay relating poetry's formal order to Christopher Alexander's ideas of generative structure, exploring how constraint and pattern produce living order in creative work. - #BYG3BQ Wholeness as a Hierarchical Graph to Capture the Nature of Space - 2015 | Bin Jiang | International Journal of Geographical Information Science | 14 pp. | doi:10.1080/13658816.2015.1038542 Micro abstract: Models spatial wholeness as a hierarchical graph of mutually reinforcing centers, using PageRank and scaling depth to quantify the life of parts and wholes. ontology (30) - #FQCWKV A Theory of Granular Partitions - 2003 | Barry Smith, Thomas Bittner | Foundations of Geographic Information Science | 33 pp. Micro abstract: Formalizes granular partitions as hierarchical cell systems projected onto reality, combining cognitive selectivity with mereological structure for naming, classifying, mapping, and representation. - #SF7KYZ About the Unreal - 2025 | Barry Smith, Jim Logan, John Beverley | Proceedings of the Joint Ontology Workshops (JOWO), Episode XI | 14 pp. Micro abstract: Models fiction, blueprints, simulations, and other information about unreal entities through logical combinations of actual classes, avoiding commitments to nonexistent dummy instances. - #CGE2NC Against Fantology - 2005 | Barry Smith | Experience and Analysis | 22 pp. Micro abstract: Critiques the idea that first-order logic reveals reality’s ontology, tracing its atomism, timelessness, Booleanism, and reductionism before proposing a six-category ontology and an enhanced Davidsonian formal language. - #JZG4PM Against Fantology Again - 2016 | Ingvar Johansson | The Theory and Practice of Ontology | 12 pp. Micro abstract: Extends the critique of fantology through default ontologization, arguing that Quine’s canonical notation is incoherent about classes and excludes intentional phenomena and distinct modes of existence. - #E5CLFY Agglomerations - 1999 | Barry Smith | Spatial Information Theory: Cognitive and Computational Foundations of Geographic Information Science | 16 pp. | doi:10.1007/3-540-48384-5_18 Micro abstract: Defines agglomerations as geographically dispersed yet unified aggregates—populations, cultures, organizations, and diasporas—and develops a realist mereotopology for their boundaries, identity, and change. - #3CCZ4A Bodily Systems and the Spatial-Functional Structure of the Human Body - 2004 | Barry Smith, Igor Papakin, Katherine Munn | Ontologies in Medicine | 26 pp. | doi:10.3233/978-1-60750-945-5-39 Micro abstract: Integrates anatomy and physiology by modeling the body as a nested spatial-functional hierarchy whose parts are demarcated as system elements through the functions they bear and realize. - #7YZU95 Boundaries: An Essay in Mereotopology - 1997 | Barry Smith | The Philosophy of Roderick Chisholm | 32 pp. Micro abstract: Reconstructs and extends the Brentano–Chisholm mereotopology in which dependent, coincident boundaries account for contact and the continuum across points, lines, surfaces, and bodies. - #3TZK66 Capabilities: An Ontology - 2024 | Barry Smith, David Limbaugh, Eric Merrell, John Beverley, Peter M. Koch | Proceedings of the Joint Ontology Workshops (JOWO), Episode X | 14 pp. Micro abstract: Defines a capability as a disposition in whose realization an organism or group has or had an interest, placing capabilities between dispositions and functions in Basic Formal Ontology. - #XYERFR Carving Up Reality - 2004 | Barry Smith | Categories: Historical and Systematic Essays | 14 pp. Micro abstract: Explains how context-sensitive, coarse-grained partitions guide reference and perception while preserving transitive parthood and distinguishing fiat demarcations from boundaries grounded in reality. - #88BVY3 Categories in Top-Level Ontologies: Revisiting the Aristotelian Background - Barry Smith, Ludger Jansen | 31 pp. Micro abstract: Reconstructs Aristotle’s categories as the philosophical basis of BFO, extending the ontological square with processes into a six-category framework for continuants, occurrents, dependence, and multiple scientific granularities. - #9G4F42 CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY - 2012 | Barry Smith | Ratio | 21 pp. | doi:10.1111/j.1467-9329.2012.00557.x Micro abstract: Extends Basic Formal Ontology to scientific process data through process profiles—quality, rate, and cyclical aspects that ground measurements, time-series graphs, and representations of dynamic systems. - #GSLMP8 Diagrams, Documents, and the Meshing of Plans - 2013 | Barry Smith | Visual Learning, vol. 3: How to Do Things with Pictures: Skill, Practice, Performance | 14 pp. Micro abstract: Shows how diagrams and evolving networks of documents mesh plans, obligations, and specialized labor to enable coordinated collective action beyond the limits of linear text. - #M8BQ3S Do Mountains Exist? Towards an Ontology of Landforms - 2003 | Barry Smith, David M. Mark | Environment and Planning B: Planning and Design | 22 pp. Micro abstract: Argues that mountains are object-like in everyday thought but elevation fields in environmental science, motivating a geospatial ontology that supports both perspectives. - #KSESR8 Drawing Boundaries - 2019 | Barry Smith | The Philosophy of GIS | 26 pp. | doi:10.1007/978-3-030-16829-2_7 Micro abstract: Updates the distinction between human-demarcated fiat boundaries and physically grounded bona fide boundaries, tracing its uses in geography, property, ecology, and Basic Formal Ontology. - #56MWAA Environmental Metaphysics - 2001 | Achille C. Varzi, Barry Smith | Metaphysics in the Post-Metaphysical Age: Proceedings of the 22nd International Wittgenstein Symposium | 12 pp. Micro abstract: Develops an ontology of token niches as tenant–medium–retainer structures, using physical and fiat boundaries to explain environmental fit, protection, movement, and niche construction. - #KG5TBB Making space: the natural, cultural, cognitive and social niches of human activity - 2021 | Barry Smith | Cognitive Processing | 11 pp. | doi:10.1007/s10339-021-01049-y Micro abstract: Shows how legal decisions, plans, historical reasoning, and language create fiat spatial and spatiotemporal entities, then draws limits and practical lessons for ontology-supported AI. - #FJ5KCA More Things in Heaven and Earth - 1995 | Barry Smith | Grazer Philosophische Studien | 15 pp. Micro abstract: Develops an ontology of spatial regions and boundaries, arguing that political territories are historically created fiat objects through performative maps while also recognizing vague, overlapping, and incomplete geographic objects. - #KY3Y9U Naïve Physics: An Essay in Ontology - 1994 | Barry Smith, Roberto Casati | Philosophical Psychology | 22 pp. | doi:10.1080/09515089408573121 Micro abstract: Reconstructs naïve physics as a realist ontology of the common-sense world—objects, processes, stuffs, boundaries, media, and values—drawing on Gestalt psychology and phenomenology to broaden AI’s set-theoretic models. - #TQPVBD New Foundations for Qualitative Physics - 1990 | Barry Smith, Jean Petitot | Evolving Knowledge in Natural Science and Artificial Intelligence | 13 pp. Micro abstract: Argues for a scientific ontology of the qualitative common-sense world, using morphological discontinuities to connect physical substrates, sensible qualities, Aristotelian categories, and ecologically constrained cognition. - #B98HVX Objects and Their Environments: From Aristotle to Ecological Ontology - 2001 | Barry Smith | The Life and Motion of Socio-Economic Units | 26 pp. | doi:10.1201/9781482268096-14 Micro abstract: Extends Aristotelian substance–accident ontology into a realist theory of behavioral settings and ecological niches as nested, bounded wholes in which organisms, objects, and activities mutually fit. - #KYQGNH On Credentials - 2020 | Barry Smith, Giuseppe Lorini, Olimpia Giuliana Loddo | Journal of Social Ontology | 21 pp. | doi:10.1515/jso-2019-0034 Micro abstract: Provides a social ontology of credentials as portable, inspectable institutional documents that certify identity or status and give bearers the practical deontic power to exercise rights, with a typology of their forms and functions. - #BV47YZ On Drawing Lines on a Map - 1995 | Barry Smith | Spatial Information Theory: A Theoretical Basis for GIS | 10 pp. | doi:10.1007/3-540-60392-1_31 Micro abstract: Builds a typology of spatial boundaries around the fiat–bona fide distinction, applying it to maps, political and property divisions, scattered objects, linguistic framing, and truthmakers. - #D8LRQM Ontological Foundations for Geographic Information Science - 2004 | Barry Smith, David M. Mark, Max J. Egenhofer, Stephen C. Hirtle | A Research Agenda for Geographic Information Science | 8 pp. | doi:10.1201/9781420038330.ch12 Micro abstract: Sets a research agenda for geospatial ontology, linking formal accounts of geographic objects, processes, scale, and vagueness to human concepts, interoperable data, and ontology-driven GIS. - #GN66WW Ontologies of Common Sense, Physics and Mathematics - 2023 | Barry Smith, Jobst Landgrebe | arXiv | 32 pp. | doi:10.48550/arXiv.2305.01560 Micro abstract: Proposes linked upper ontologies for common sense, physics, and mathematics, arguing that classical models connect real magnitudes to mathematics whereas modern physics relates measurements to entities lacking commonsense universals. - #WYP3G6 Ontology and Geographic Kinds - 1998 | Barry Smith, David M. Mark | Proceedings of the 8th International Symposium on Spatial Data Handling (SDH ’98) | 7 pp. Micro abstract: Argues that geographic kinds are intrinsically spatial and boundary-centered, requiring mereology and topology to connect physical reality, cultural categorization, cognition, and GIS representation. - #9YMD2E SNAP and SPAN: Towards Dynamic Spatial Ontology - 2004 | Barry Smith, Pierre Grenon | Spatial Cognition & Computation | 35 pp. | doi:10.1207/S15427633SCC0401_5 Micro abstract: BFO's bicategorial framework: SNAP snapshot ontologies of continuants and a SPAN ontology of processes in spacetime, linked by trans-ontological relations to capture change — demonstrated on the ontology of geodynamics. - #2F8T3H Toward a Realistic Science of Environments - 2009 | Barry Smith | Ecological Psychology | 11 pp. Micro abstract: Defends Gibsonian ecological realism: organisms directly perceive affordances in physically real niches, while granular partitions show how different species inhabit perspectives on one world, not separate constructed worlds. - #DT9Y7X True Grid - 2002 | Barry Smith | Spatial Information Theory: Foundations of Geographic Information Science | 17 pp. Micro abstract: Generalizes Alberti’s perspectival grid into a realist theory of projection: pictures, maps, names, concepts, and databases are “true grids” when their cells preserve relevant structure and refer transparently to reality. - #PHAFYA Truth and the Visual Field - 1997 | Barry Smith | Naturalizing Phenomenology: Issues in Contemporary Phenomenology and Cognitive Science | 8 pp. Micro abstract: Uses mereotopology and Gibsonian ecology to treat perception and language as carving transient fiat boundaries in reality, defining a judgment field as the truth-making portion of the world selected by a true sentence. - #XZX6PE Vague Reference and Approximating Judgments - 2003 | Barry Smith, Thomas Bittner | Spatial Cognition and Computation | 20 pp. Micro abstract: Formalizes vague reference as multiple crisp candidate referents within granular partitions, then explains approximation as using familiar spatial or temporal reference grids to constrain vagueness without truth-value indeterminacy. Procedural Generation & Co-Creation (14) - #ABD2B8 Between Tech and Art: The Vegetation of Horizon Zero Dawn - 2018 | Gilbert Sanders, Guerrilla Games | Game Developers Conference (GDC) 2018 | 87 pp. Micro abstract: A production breakdown of Horizon Zero Dawn’s vegetation pipeline, covering global wind simulation, layered foliage motion, coverage-preserving alpha mipmaps, shading, asset LODs, placement, and cascaded shadows. - #4TH488 Explainable AI for Designers: A Human-Centered Perspective on Mixed-Initiative Co-Creation - 2018 | Antonios Liapis, G. Michael Youngblood, Jichen Zhu, Rafael Bidarra, Sebastian Risi | 2018 IEEE Conference on Computational Intelligence and Games (CIG) | 8 pp. | doi:10.1109/CIG.2018.8490433 Micro abstract: Defines explainable AI for game designers, mapping co-creative systems by their explainability, initiative, and domain overlap so explanations serve concrete design tasks. - #9NQ94D Extracting Physics from Blended Platformer Game Levels - 2020 | Adam Summerville, Anurag Sarkar, Joseph C. Osborn, Sam Snodgrass | Joint Proceedings of the AIIDE 2020 Workshops (CEUR Workshop Proceedings, Vol. 2862) | 7 pp. Micro abstract: Infers playable jump physics from generated platformer levels, including hybrid physics models for levels that blend the geometry and style of multiple games. - #66Q3W3 Ghost of Tsushima: Procedural Grass - 2021 | Eric Wohllaib, Sucker Punch Productions | Game Developers Conference (GDC) 2021 | 55 pp. Micro abstract: Explains Ghost of Tsushima’s compute-driven grass pipeline, from tiled placement and culling to indirect drawing, cubic Bézier blade geometry, variable LOD, wind animation, and material shading. - #QHMFH2 Improved Alpha Testing Using Hashed Sampling - 2019 | Chris Wyman, Morgan McGuire | IEEE Transactions on Visualization and Computer Graphics | 12 pp. | doi:10.1109/TVCG.2017.2739149 Micro abstract: Develops hashed alpha testing, a stable quasi-random thresholding method that preserves distant alpha-mapped foliage and hair while controlling flicker, anisotropy, and interactions with TAA and alpha-to-coverage. - #7GR3AQ Procedural Content Generation through Quality Diversity - 2019 | Ahmed Khalifa, Antonios Liapis, Daniele Gravina, Georgios N. Yannakakis, Julian Togelius | 2019 IEEE Conference on Games (CoG) | 8 pp. | doi:10.1109/CIG.2019.8848053 Micro abstract: Argues for quality-diversity algorithms in procedural generation, producing broad collections of varied, playable content while exposing the design space for exploration and co-creation. - #CQBDX4 Procedural Content Generation via Machine Learning (PCGML) - 2018 | Aaron Isaksen, Adam Summerville, Amy K. Hoover, Andy Nealen, Christoffer Holmgård, Julian Togelius, Matthew Guzdial, Sam Snodgrass | IEEE Transactions on Games | 15 pp. | doi:10.1109/TG.2018.2846639 Micro abstract: Defines and surveys PCGML: generating functional game content directly from models trained on existing examples, with uses spanning creation, completion, repair, critique, and compression. - #EARFEK Procedural Generation of Villages on Arbitrary Terrains - 2012 | Adrien Bernhardt, Adrien Peytavie, Arnaud Emilien, Eric Galin, Marie-Paule Cani | The Visual Computer | 10 pp. | doi:10.1007/s00371-012-0699-7 Micro abstract: Presents a three-stage procedural model that grows terrain-responsive village roads and settlements, partitions land into plausible parcels, and generates slope-adapted buildings with open shape grammars. - #EDURTK Real-Time GPU Tree Generation - 2025 | Bastian Kuth, Carsten Faber, Dominik Baumeister, Max Oberberger, Pirmin Pfeifer, Quirin Meyer, Seyedmasih Tabaei | High-Performance Graphics – Symposium Papers | 10 pp. | doi:10.2312/hpg.20251168 Micro abstract: Introduces a GPU work-graph pipeline that generates, animates, edits, and continuously LODs detailed seasonal trees every frame, replacing gigabytes of baked geometry with kilobytes of parameters. - #GBXEP3 Realistic Modeling and Rendering of Plant Ecosystems - 1998 | Bernd Lintermann, Matt Pharr, Oliver Deussen, Pat Hanrahan, Przemyslaw Prusinkiewicz, Radomír Měch | Proceedings of SIGGRAPH ’98 | 12 pp. | doi:10.1145/280814.280898 Micro abstract: Presents a foundational pipeline for authoring plant ecosystems through terrain design, ecological simulation, procedural plant models, approximate instancing, and efficient rendering of billion-primitive scenes. - #BDBBL6 Real‐time Realistic Rendering and Lighting of Forests - 2012 | Eric Bruneton, Fabrice Neyret | Computer Graphics Forum | 11 pp. | doi:10.1111/j.1467-8659.2012.03016.x Micro abstract: Combines detailed z-field trees with terrain shader-maps to render immense forests in real time, preserving sun, sky, canopy, and ground-lighting effects through seamless, scale-consistent transitions. - #PQ68ZH Responsive Real-Time Grass Rendering for General 3D Scenes - 2017 | Klemens Jahrmann, Michael Wimmer | Proceedings of the 2017 Symposium on Interactive 3D Graphics and Games (I3D ’17) | 10 pp. | doi:10.1145/3023368.3023380 Micro abstract: Renders every grass blade as responsive tessellated geometry on arbitrary 3D surfaces, with per-blade wind, gravity, and collision physics plus aggressive culling that retains dense fields in real time. - #WZ8DHP Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents - 2026 | Rishabh Kar | arXiv | 25 pp. | doi:10.48550/arXiv.2605.01783 Micro abstract: Integrates procedural generation and validation in an endless runner, using aerial and ground agents to detect blocked or unnavigable content before the player reaches it. - #NRBMD5 Towards Friendly Mixed Initiative Procedural Content Generation: Three Pillars of Industry - 2020 | Frederic Fol Leymarie, Gorm Lai, William Latham | Proceedings of the International Conference on the Foundations of Digital Games (FDG '20) | 4 pp. | doi:10.1145/3402942.3402946 Micro abstract: Distills three requirements for industry-friendly co-creative PCG tools: preserve designer control, keep feedback loops short, and fit into existing production pipelines. Roads, Trails & Movement (8) - #G3TBNG A Sequential Two-Step Algorithm for Fast Generation of Vehicle Racing Trajectories - 2016 | J. Christian Gerdes, John Subosits, Nitin R. Kapania | Journal of Dynamic Systems, Measurement, and Control | 12 pp. | doi:10.1115/1.4033311 Micro abstract: Generates near-optimal racing trajectories quickly by alternating between a minimum-time speed profile and a convex path update that reduces curvature. - #B6P8L4 Active walker model for the formation of human and animal trail systems - 1997 | Dirk Helbing, Frank Schweitzer, Joachim Keltsch, Péter Molnár | Physical Review E | 34 pp. | doi:10.1103/physreve.56.2527 Micro abstract: Models trail systems as self-organization: walkers reinforce attractive routes while unused traces fade, producing dendritic ant trails and low-detour pedestrian networks. - #V4TQYB Interactive procedural street modeling - 2008 | Eugene Zhang, Gregory Esch, Guoning Chen, Pascal Müller, Peter Wonka | ACM Transactions on Graphics | 10 pp. | doi:10.1145/1360612.1360702 Micro abstract: Lets designers generate and edit large street networks through tensor fields, combining procedural speed with brush-like global and local control over street patterns. - #UYLTYJ Modelling the Evolution of Human Trail Systems - 1997 | Dirk Helbing, Joachim Keltsch, Péter Molnár | Nature | 11 pp. | doi:10.1038/40353 Micro abstract: Shows how pedestrian trails emerge through feedback between destination-seeking walkers, existing paths, and vegetation recovery, yielding a compromise between directness and shared infrastructure. - #GY93FG Mountain Trail Formation and the Active Walker Model - 2009 | J. P. Hague, S. J. Gilks | International Journal of Modern Physics C | 22 pp. | doi:10.1142/S0129183109014059 Micro abstract: Extends the active-walker model to steep terrain, explaining zigzag mountain trails through slope avoidance, directional persistence, and mutual reinforcement by ascending and descending walkers. - #LXV9AT Principles of Trail Layout and Design - 2019 | California State Parks | California State Parks Trails Handbook | 64 pp. Micro abstract: A field-oriented guide to durable trail design, emphasizing curvilinear alignment, natural drainage, sustainable grades, control points, and close reading of landform and soils. - #XDEFZS Procedural Generation of Roads - 2010 | A. Peytavie, E. Galin, E. Guérin, N. Maréchal | Computer Graphics Forum | 10 pp. | doi:10.1111/j.1467-8659.2009.01612.x Micro abstract: Automatically routes and constructs roads with an anisotropic shortest-path method that weighs slope and obstacles while treating surface segments, bridges, and tunnels consistently. - #ARP5U7 The Topography of Minoan Peak Sanctuaries - 1983 | A. A. D. Peatfield | The Annual of the British School at Athens | 8 pp. | doi:10.1017/s0068245400019729 Micro abstract: Argues that Minoan peak sanctuaries were chosen for visibility and proximity to local settlements, forming a beacon-like sacred network whose contraction tracked settlement abandonment rather than cultic collapse. Scenario-Based & Behavioral Programming (8) - #P2W4J5 Adaptive Behavioral Programming - 2011 | David Harel, Nir Eitan | 8 pp. | doi:10.1109/ictai.2011.109 Micro abstract: Adds reinforcements to live sequence charts and BPJ so scenario-based programs can learn from their environment, specifying goals to pursue and scenarios to avoid, with modular learning decompositions. - #XQ5NKX Challenges in Modeling and Unmodeling Emergence, Rule Composition, and Networked Interactions in Complex Reactive Systems - 2023 | Assaf Marron, David Harel, Guy Frankel, Irun Cohen, Smadar Szekely | 8 pp. | doi:10.5220/0011728900003402 Micro abstract: Position paper on modeling emergence, rule composition, and networked interactions in complex reactive systems, introducing "unmodeling"—explicitly excluding entities and behaviors from model execution. - #D4VB7S Distributing Scenario-Based Models: A Replicate-and-Project Approach - 2017 | Assaf Marron, Daniel Gritzner, David Harel, Guy Katz, Joel Greenyer, Shlomi Steinberg | MODELSWARD 2017 | 16 pp. | doi:10.5220/0006271301820195 Micro abstract: Distributes scenario-based models by replicating the full specification on every component and projecting it per component, mimicking centralized behavior while sharply reducing synchronization. - #CSJARA Enhancing Scenario-Based Modeling Using Large Language Models - 2026 | Assaf Marron, David Harel, Guy Katz, Smadar Szekely | Communications in Computer and Information Science | Springer Nature Switzerland | pp. 43-68 | 26 pp. | doi:10.1007/978-3-031-96841-9_3 Micro abstract: Extended methodology for combining LLM chatbots with scenario-based modeling: iterative generation of stand-alone scenarios checked by analysis and human review, framed as a step toward Wise Computing. - #3JCRAD On Augmenting Scenario-Based Modeling with Generative AI - 2024 | Assaf Marron, David Harel, Guy Katz, Smadar Szekely | MODELSWARD 2024 | 12 pp. | doi:10.5220/0012427100003645 Micro abstract: Outlines a structured method for using generative-AI chatbots in modeling: iteratively generate scenario-based model fragments, then analyze and inspect them to converge on an accurate system model. - #QV3BWZ On tracing reactive systems - 2011 | David Harel, Shahar Maoz | Software & Systems Modeling | 22 pp. | doi:10.1007/s10270-010-0151-2 Micro abstract: Introduces model-based trace visualization and exploration for reactive systems, using scenario-based (LSC) abstractions and the Tracer prototype, demonstrated on a PacMan game. - #TDS4H2 Relaxing Synchronization Constraints in Behavioral Programs - 2013 | Amir Kantor, David Harel, Guy Katz | LPAR 2013 (Logic for Programming, Artificial Intelligence, and Reasoning) | 17 pp. | doi:10.1007/978-3-642-45221-5_25 Micro abstract: Proposes eager execution for behavioral programs: fast b-threads run ahead when synchronization outcomes are predictable, improving performance, modularity, and distributability, shown in a C++ BP framework. - #M5788P Towards Behavioral Programming in Distributed Architectures - 2015 | Amir Kantor, Assaf Marron, David Harel, Gera Weiss, Guy Katz, Guy Wiener | Science of Computer Programming | 58 pp. | doi:10.1016/j.scico.2014.03.003 Micro abstract: Extends behavioral programming to distributed architectures: b-threads as Erlang processes, eager execution to relax synchronization, and modular distributed execution, demonstrated on simulations and a quadrotor. Technology, Scale & Conviviality (2) - #WYH36B The City as Convivial Centre - 1974 | Leopold Kohr | Tract, no. 12 (Gryphon Press) | 18 pp. Micro abstract: Kohr's essay arguing that cities exist for convivial life rather than economic function, and that human-scale size is what lets a city serve as a centre of leisure, culture, and encounter. - #67REFX The Question Concerning Technology - 1977 | Martin Heidegger | The Question Concerning Technology and Other Essays (Harper & Row) | 23 pp. Micro abstract: Heidegger's essay on the essence of technology as Enframing (Gestell), a mode of revealing that reduces the world to standing-reserve, and on art as a possible saving power. Terrain, Hydrology & Erosion (8) - #NV2YRW FastFlow: GPU Acceleration of Flow and Depression Routing for Landscape Simulation - 2024 | Aryamaan Jain, Bernhard Kerbl, Brandon Finley, Guillaume Cordonnier, James Gain | Computer Graphics Forum | 13 pp. | doi:10.1111/cgf.15243 Micro abstract: A GPU framework for routing surface flow through terrain and its depressions fast enough to make erosion, river, lake, and ecosystem simulations interactive. - #2284QZ From features to fingerprints: A general diagnostic framework for anthropogenic geomorphology - 2019 | Damian Evans, Erle C Ellis, Giulia Sofia, Paolo Tarolli, Wenfang Cao | Progress in Physical Geography: Earth and Environment | 34 pp. | doi:10.1177/0309133318825284 Micro abstract: Integrates geomorphology, archaeology, and high-resolution remote sensing into a framework for reading anthropogenic landforms as landscape-scale sociocultural fingerprints. - #96ZMGK Large Scale Terrain Generation from Tectonic Uplift and Fluvial Erosion - 2016 | Adrien Peytavie, Bedrich Benes, Guillaume Cordonnier, Jean Braun, Marie-Paule Cani, Éric Galin, Éric Guérin | Computer Graphics Forum | 11 pp. | doi:10.1111/cgf.12820 Micro abstract: Generates large, controllable mountain terrains by coupling user-painted tectonic uplift with fluvial erosion, then turning the resulting stream graph into detailed landforms. - #K82AS7 Legacy sediment: Definitions and processes of episodically produced anthropogenic sediment - 2013 | L. Allan James | Anthropocene | 11 pp. | doi:10.1016/j.ancene.2013.04.001 Micro abstract: Broadens legacy sediment to episodically produced anthropogenic alluvium and colluvium, and explains its deposition, storage, and remobilization through sediment delivery–transport capacity dynamics. - #DWXKYQ Physically-based analytical erosion for fast terrain generation - 2024 | Boris Gailleton, Guillaume Cordonnier, Petros Tzathas, Philippe Steer | Computer Graphics Forum | 14 pp. | doi:10.1111/cgf.15033 Micro abstract: Turns the stream power law into an interactive terrain tool, replacing thousands of erosion time steps with analytical solutions and a direct control for landscape age. - #MTDKDE Priority-Flood: An Optimal Depression-Filling and Watershed-Labeling Algorithm for Digital Elevation Models - 2014 | Clarence Lehman, David Mulla, Richard Barnes | Computers & Geosciences | 17 pp. | doi:10.1016/j.cageo.2013.04.024 Micro abstract: Introduces Priority-Flood, a simple, optimal algorithm that removes drainage-blocking depressions from elevation models and can also derive watersheds and flow directions. - #AK7NGE Procedural Riverscapes - 2019 | A. Peytavie, B. Benes, E. Galin, E. Guérin, J. Gain, T. Dupont, Y. Cortial | Computer Graphics Forum | 12 pp. | doi:10.1111/cgf.13814 Micro abstract: Builds editable, animated riverscapes from bare terrain by carving hydrologically plausible channels and blending real-time procedural water primitives instead of simulating fluids. - #DMTA8Y Terrain Generation Using Procedural Models Based on Hydrology - 2013 | Adrien Peytavie, Bedřich Beneš, Jean-David Génevaux, Éric Galin, Éric Guérin | ACM Transactions on Graphics | 10 pp. | doi:10.1145/2461912.2461996 Micro abstract: Generates controllable, multiscale terrain from a sketched drainage network, representing rivers and landforms as an editable hierarchy of continuous procedural primitives. Water Simulation & Rendering (12) - #RBS5K6 A Layered Particle-Based Fluid Model for Real-Time Rendering of Water - 2010 | Daniel Scherzer, Florian Bagar, Michael Wimmer | Computer Graphics Forum | 7 pp. | doi:10.1111/j.1467-8659.2010.01734.x Micro abstract: Renders particle-based water and volumetric foam in real time using perspective-aware surface smoothing, physically guided foam formation, and layered depth compositing. - #C4AY2M A Survey of Ocean Simulation and Rendering Techniques in Computer Graphics - 2011 | B. Crespin, D. Ghazanfarpour, E. Darles, J.-C. Gonzato | Computer Graphics Forum | 17 pp. | doi:10.1111/j.1467-8659.2010.01828.x Micro abstract: Surveys ocean graphics from spectral deep-water models to near-shore fluid simulation, then covers the foam, spray, and light transport needed for convincing rendering. - #WZMZGY Advected river textures - 2009 | Dirk Arnold, Stephen Brooks, Tim Burrell | Computer Animation and Virtual Worlds | 11 pp. | doi:10.1002/cav.288 Micro abstract: Combines a 2D Navier–Stokes solver, hydrostatic pressure columns, and advected procedural textures to render detailed, terrain-responsive rivers at real-time frame rates. - #92XRH7 Lagrangian Texture Advection: Preserving both Spectrum and Velocity Field - 2011 | Qizhi Yu, E. Bruneton, F. Neyret, N. Holzschuch | IEEE Transactions on Visualization and Computer Graphics | 13 pp. | doi:10.1109/tvcg.2010.263 Micro abstract: Advects fluid textures with deformable particle grids, preserving both the input texture’s visual spectrum and exact motion along the velocity field without cumulative stretching. - #8SERGP Real-time Breaking Waves for Shallow Water Simulations - 2007 | Markus Gross, Matthias Müller-Fischer, Nils Thürey, Simon Schirm | 15th Pacific Conference on Computer Graphics and Applications (Pacific Graphics 2007) | 8 pp. | doi:10.1109/PG.2007.33 Micro abstract: Adds real-time overturning waves to shallow-water heightfields by detecting steep fronts and spawning connected particle sheets that collapse into splashes and foam. - #CWC7H9 Real-time Rendering of Enhanced Shallow Water Fluid Simulations - 2013 | Antonio Susín, Jesús Ojeda | Computers & Graphics | 9 pp. Micro abstract: Builds a real-time rendering pipeline for shallow-water simulations, adding fine surface detail, advected foam, photon-based caustics, and screen-space reflection and refraction. - #MVUJ8Z Real-time Rendering of River Networks - 2010 | Quintijn Hendrickx, Rafael Bidarra, Ruben M. Smelik | Proceedings of the ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games | 1 pp. Micro abstract: Renders branching river networks efficiently with quadratic Bézier curves, GPU distance fields, and streaming normal maps instead of dense geometry or particle simulation. - #5MGCZ5 Real-time River Representation by Dynamic Control of Data on Waves - 2008 | Makoto Kosugi, Nobuhiko Mukai, Yasuhiro Kato | 4 pp. | doi:10.3169/itej.62.2063 Micro abstract: Dynamically switches river-wave models by viewing distance, preserving nearby reflection and wave detail while retaining wind-driven motion across the full landscape. - #XDESU9 Scalable real‐time animation of rivers - 2009 | Eric Bruneton, Fabrice Neyret, Nicolas Holzschuch, Qizhi Yu | Computer Graphics Forum | 11 pp. | doi:10.1111/j.1467-8659.2009.01363.x Micro abstract: Animates rivers across vast terrains by computing steady flow locally and advecting fine surface detail only where visible, at a screen-space sampling density. - #869NHK Very Fast Real-Time Ocean Wave Foam Rendering Using Halftoning - 2011 | Ian Parberry, Jennifer R. Alford, Mary Yingst | Proceedings of the 6th International North American Conference on Intelligent Games and Simulation (GAMEON-NA) | 7 pp. Micro abstract: Uses a spectrally controlled halftone mask to make texture-based ocean foam dissipate as clumped bubbles that pop, rather than merely fading transparently. - #A2QB8L Water Flow in Portal 2 - 2010 | Alex Vlachos | ACM SIGGRAPH 2010 Course: Advances in Real-Time Rendering in 3D Graphics and Games | 54 pp. Micro abstract: Explains Portal 2’s production-friendly water shader: artist-painted flow maps advect layered normal maps, while offsets and noise suppress repetition and pulsing on limited hardware. - #PBM2TC Water surface wavelets - 2018 | Chris Wojtan, Matthias Müller-Fischer, Miles Macklin, Nuttapong Chentanez, Stefan Jeschke, Tomáš Skřivan | ACM Transactions on Graphics | 13 pp. | doi:10.1145/3197517.3201336 Micro abstract: Represents water waves as spatially varying directional amplitudes, enabling vast interactive simulations with fine detail, moving obstacles, solid coupling, and direct artistic control. Unfiled (1) - #3CV92Z moppe ### 4. Assistant tool calls #### Tool call: `get_document` ```json { "id": "3CV92Z" } ``` ### 5. Tool result: get_document GIT REPOSITORY #3CV92Z Title: moppe Outline: - /3CV92Z/source-directories/YXRlbGllcg atelier - /3CV92Z/source-directories/Y21ha2U cmake - /3CV92Z/source-directories/ZG9jcw docs - /3CV92Z/source-directories/aWRlYXM ideas - /3CV92Z/source-directories/bW9wcGU moppe - /3CV92Z/source-directories/cGxhbg plan - /3CV92Z/source-directories/cGxhbm5pbmc planning - /3CV92Z/source-directories/cmVzZWFyY2g research - /3CV92Z/source-directories/dGVzdHM tests - /3CV92Z/source-directories/dG9vbHM tools - /3CV92Z/source-files/LmNsYW5nLWZvcm1hdA .clang-format - /3CV92Z/source-files/LmNsYW5nZA .clangd - /3CV92Z/source-files/LmdpdGF0dHJpYnV0ZXM .gitattributes - /3CV92Z/source-files/LmdpdGlnbm9yZQ .gitignore - /3CV92Z/source-files/QUdFTlRTLm1k AGENTS.md - /3CV92Z/source-files/Q0xBVURFLm1k CLAUDE.md - /3CV92Z/source-files/Q01ha2VMaXN0cy50eHQ CMakeLists.txt - /3CV92Z/source-files/Q01ha2VQcmVzZXRzLmpzb24 CMakePresets.json - /3CV92Z/source-files/TWFrZWZpbGU Makefile - /3CV92Z/source-files/UkVBRE1FLm1k README.md ### 6. Assistant tool calls #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 20, "query": "ontology.md" } ``` ### 7. Tool result: search_text Exact matches 1. Source file: docs/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9SRUFETUUubWQ#content Size: 1906 bytes, 33 lines Matching excerpt: ... ion checkpoint, frame reading, and replay boundary. - `renderer-design.md` — Metal/backend implementation detail and retained port-design record. - `surface-atlas.md` — current surface domains, typed sections, and renderer presentation bridge. - `refactoring-seams.md` — characterization contracts for surface, replay, completed-world loading, and target ownership. - `terrain-expressions.md` — direct terrain generation and analysis design. - `trails.md` — leisure-circuit planning, grading, materials, and consumers. - `units.md` — scientific quantities, unit conventions, and simulation scale. - `ontology.md` — what kinds of things the game world contains: fields and fiat objects, substances and qualities, processes, populations, and what makes a representation faithful. A vocabulary, not a specification. - `working-practices.md` — development and verification practices. Repository-native RFCs and their executable work-item graphs live in `../planning/`. They describe accepted intended work and its dependencies; they are more concrete than the speculative essays in `../ideas/`, but do not claim that an item is implemented until its work item says so. The Atelier charters (`atelier-earth.md` and ` ... Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9SRUFETUUubWQ#content"] 2. Source file: docs/surface-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content Size: 6695 bytes, 107 lines Matching excerpt: # The current-engine surface atlas This is the small atlas for Moppe's adopted Atelier earth vocabulary. It describes the current engine, not the proposed second engine. The purpose is to make its topology, intrinsic readings, and rendering bridge enumerable. For the wider ownership, state, presentation, and target map, start with the [engine atlas](engine-atlas.md). ## Storeys | Storey | Current object | Responsibility | | --- | --- | --- | | Combinatorial | `map::SurfaceDomain` | The finite toroidal vertex lattice, index/offset correspondence, horizontal spacing, and bilinear reconstruction stencil. | | Intrinsic | `map::SurfaceAtlas`, `map::WaterSurfaceSections` | Typed 0-cochains sharing the lattice but kept in named ground groups and a distinct water bundle. `map::Surface` owns the authoritative ground geometry and its later analyses. | | Extrinsic | `game::SurfacePresentation`, `game::WaterPresentation` | Convert typed columns to plain scalar texture payloads and upload them through `render::Renderer`. These are the quantity-to-number bridges. | Terrain generation writes the mandatory geometry bundle directly. Hydrology, geology, ecology, and use add readings at later, named Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content"] 3. Source file: docs/atelier-earth.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content Size: 15763 bytes, 318 lines Matching excerpt: # The Atelier earth A proposal to widen the atelier's scope: from a studio of small organisms (the tree, the carpet, the cellular sheet) to a second implementation of the engine itself, begun again from the foundations of the earth. This is not a refactor of moppe and not a port. Moppe continues to run, generate, and play. The atelier grows a world beside it, small and whole at every stage, made of the semantic material we have learned to want: typed quantities, affine frames, rank-graded domains, sections, and a discrete calculus — with Metal as the prime instance substrate. Where moppe discovered these ideas mid-flight and carries them partially, the atelier bakes them in from the first line. The two meet later by adoption, organ by organ, never by conversion. ## What "engine" means here Not "motorcycle game." The engine is a simulation of a world: - a **combinatorial storey** — finite topologies: lattices, trees, sheets; vertices, edges, faces; incidence and orientation. No positions live here. - an **intrinsic storey** — typed sections over those topologies: bundles whose columns are labelled by mp-units quantity specifications. Elevation is a point-valued 0-cochain; a flow is Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content"] 4. Source file: docs/ontology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines Matching excerpt: # What Exists in Moppe Moppe keeps careful accounts of *how much*: heights in meters, thrust in newtons, sink rates in meters per second. The type system refuses to add an airspeed to an altitude, and the codebase is better for it. This document starts a parallel set of accounts about *what kinds of things there are*. It is not a specification and it proposes no work. It is a vocabulary — a way of talking about the game world that stays truthful about the structure of what the code simulates, the way `units.md` stays truthful about magnitudes. The vocabulary is borrowed, mostly from the ontologist Barry Smith and his collaborators, whose papers live in `research/` (readable in sections at `https://m.sheaf.less.rest/` with `Accept: text/markdown`). Their subject is ordinary reality — mountains, headaches, county borders, orchestras — but a game world turns out to be built from the same kinds of things, and it is clarifying to call them by their proper names. ## Fields and things Ask what the terrain *is* and two honest answers come back. To the simulation, the terrain is a field: elevation as a value at every position, and alongside it moisture, forest cover, snow support, channel f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content"] 5. Source file: ideas/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvUkVBRE1FLm1k#content Size: 1788 bytes, 34 lines Matching excerpt: # Ideas This directory holds design essays and speculative directions for Moppe. They are useful context, not descriptions of implemented behavior or a committed roadmap. - `orientation.md` gives one interpretation of the project's character. - `theory-of-the-world.md` develops a conceptual vocabulary for generated terrain and water. - `second-author.md` imagines a future layer of centers, paths, roads, and settlements above the geological world. - `tending-the-world.md` proposes that riding, reading, and changing the landscape become one continuous form of play rather than a game/editor split. - `world-as-lab.md` imagines the resulting open-world experience: riding as a way to reach places where observation, experiment, care, making, and memory become the larger game. - `structure-of-space.md` develops the irregular cellular tissue through which continuous terrain can become places, construction, and persistent history. - `geometry-from-fields.md` proposes grass, debris, gravel, living water, and weather effects as GPU-evaluated functions over the generator's field data — solid wins and speculative ideas, with a suggested order. - `terrain-lab-spectacles.md` collects playful hydro Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvUkVBRE1FLm1k#content"] 6. Source file: plan/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9SRUFETUUubWQ#content Size: 4050 bytes, 77 lines Matching excerpt: # Plan: RFCs for the landscape, the simulation, and the semantics Design RFCs distilled from a full-codebase review and design conversation (July 2026). Each file states a problem, the current situation with code references, a proposal, consequences, risks, and an implementation sketch. Most remain drafts; an RFC records an implementation date when its acceptance path lands. Current architecture stays documented in `docs/`; speculative essays stay in `ideas/` -- this directory is the bridge between them: concrete enough to start, honest about cost. ## Landscape process (simulation) - [RFC-001](done/rfc-001-uplift-stream-power.md) — Uplift fields + implicit stream power run to quasi-equilibrium: mountains as the residue of uplift under erosion. Implemented and selected for ordinary world generation on 2026-07-13. - [RFC-002](done/rfc-002-hillslope-diffusion.md) — Hillslope diffusion (soil creep): smooth convex crests against sharp valley cuts. Small, standalone, also RFC-001's D term. - [RFC-003](done/rfc-003-sediment-ledger-rasters.md) — Keep the per-cell sediment ledger as eroded/deposited rasters; feed materials, detail, and Lab overlays. Cheapest coherence win available. - [RFC- Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9SRUFETUUubWQ#content"] 7. Source file: README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/UkVBRE1FLm1k#content Size: 3693 bytes, 104 lines Matching excerpt: # Moppe **A motorcycle game in generated worlds.** ![A forested generated landscape beside a lake](screenshots/forest-and-lake.png) Moppe grows landscapes from geological recipes, lets water find its routes, settles forests into the resulting habitats, and puts a motorcycle into the world. The aim is to make places with a readable history: mountains, rivers, lakes, and trails that arise from the land instead of being scattered on top of it. Moppe is an active experimental project, not a packaged release. The current game runs on a custom Metal renderer across macOS, iOS, and tvOS. ## Generated landscapes

Mountain ranges fading into atmospheric haze A dark mountain ridge above a distant lake

Sunlight spilling through a high mountain valley Closely framed alpine ridges in warm evening light

A broad panorama of layered ge Read the complete file with read blocks=[ build["direct world construction"] build --> world["GeneratedWorld"] world --> session["GameSession"] world --> view["FrameView"] session --> view view --> scene["world, actor, water, effect, HUD presentation"] scene --> renderer["render::Renderer"] renderer --> metal["Metal backend"] renderer --> webgpu["WebGPU backend"] app["application: loading, input, mode selection"] --> build app --> session app --> view ``` `GeneratedWorld` is the stable owner of one completed landscape. `GameSession` is the mutable life played on that landscape. `FrameView` is a new immutable reading composed for Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9lbmdpbmUtYXRsYXMubWQ#content"] 11. Source file: planning/tracks/current-engine-refactoring/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL1JFQURNRS5tZA#content Size: 2639 bytes, 63 lines Matching excerpt: # Current-engine refactoring (completed) This is the completed executable track for [RFC-0001](../../rfcs/0001-current-engine-refactoring.md). It was a dependency graph, not a release calendar: work could happen in parallel when nodes were independent, and an item became `ready` only when its declared dependencies were `done`. All 19 work items are now `done`; the graph is preserved as the decision and validation history behind the current [engine atlas] (../../../docs/engine-atlas.md). The first item intentionally repairs the complexity instrument. The earlier report showed real cyclomatic concentration, but unity builds currently make its cognitive column and scan scope unreliable. We should not steer a large refactor with a crooked compass. ```mermaid flowchart LR ENG001["ENG-001: trustworthy complexity report"] ENG002["ENG-002: characterize seams"] ENG010["ENG-010: one Bundle"] ENG011["ENG-011: SurfaceAtlas"] ENG012["ENG-012: presentation bridge"] ENG020["ENG-020: local transform validation"] ENG021["ENG-021: WorldRecipe"] ENG022["ENG-022: GeneratedWorld"] ENG023["ENG-023: async world handoff"] ENG030["ENG-030: InputFrame"] ENG031["ENG-031: GameSession"] ENG032["ENG-032: public Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL1JFQURNRS5tZA#content"] 12. Source file: plan/done/rfc-004-erosion-performance.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9kb25lL3JmYy0wMDQtZXJvc2lvbi1wZXJmb3JtYW5jZS5tZA#content Size: 5693 bytes, 114 lines Matching excerpt: # RFC-004: The erosion performance path - Status: Superseded on 2026-07-16 - Area: terrain simulation, performance - Interacts with: RFC-001 (reduces droplet load), RFC-003 (ledger on GPU) ## Problem This proposal is retained as a historical design record. RFC-001's orogeny model replaced droplet erosion in ordinary world generation, and the unused droplet implementation was removed. None of the droplet GPU work below is on the active roadmap; source-field acceleration remains independently useful. World generation time is dominated by terrain work that the codebase has already architected for acceleration but not yet wired up. The pointwise source field runs on the CPU interpreter during the loading screen even though a Metal evaluator exists and is ~10x faster; droplet erosion runs serially inside its lockstep batches even though the batch structure was explicitly designed as a GPU work boundary (`docs/terrain-expressions.md`: "lower a whole lockstep batch to a GPU compute kernel"). ## Current situation Three distinct tiers, smallest first: 1. **Wiring gap.** Terrain Lab injects the accelerated evaluator (`moppe/game/terrain_lab.cc:508` calls `platform::create_field_evaluator()`) Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9kb25lL3JmYy0wMDQtZXJvc2lvbi1wZXJmb3JtYW5jZS5tZA#content"] 13. Source file: planning/tracks/current-engine-refactoring/items/ENG-051-publish-resulting-engine-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wNTEtcHVibGlzaC1yZXN1bHRpbmctZW5naW5lLWF0bGFzLm1k#content Size: 1650 bytes, 42 lines Matching excerpt: +++ id = "ENG-051" title = "Publish the resulting engine atlas and retire the migration track" rfc = "RFC-0001" track = "current-engine-refactoring" status = "done" depends_on = ["ENG-050"] order = 190 areas = ["docs", "architecture"] +++ # Publish the resulting engine atlas and retire the migration track ## Outcome Architecture documentation enumerates the actual domains, intrinsic sections, world/session state boundaries, presentations, and target dependencies; this track records what was completed, deferred, or dropped. ## Scope Update living architecture documents and RFC status. Do not erase the history of decisions that explains the resulting shape. ## Acceptance - A new reader can map the engine without reading this execution history. - The track has no ambiguous active or ready work items at closure. ## Evidence `docs/engine-atlas.md` is the current reader entry: it maps source domains, all named surface/water intrinsic sections, completed-world/session/frame boundaries, presentation bridges, lifecycle handoff, and CMake dependencies. The documentation index now leads to it and to the generated-world and game-state details. `renderer-design.md` is explicitly a Metal impleme Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wNTEtcHVibGlzaC1yZXN1bHRpbmctZW5naW5lLWF0bGFzLm1k#content"] 14. Source file: research/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvUkVBRE1FLm1k#content Size: 8279 bytes, 143 lines Matching excerpt: # Moppe research shelf This directory keeps a selective local shelf of primary papers and practical manuals that bear directly on Moppe. It is intentionally smaller than `ideas/reading-map.md`: the reading map is a broad annotated bibliography, while this shelf favors open copies worth returning to during implementation and design. The PDFs were fetched and checked in July 2026. Each file was verified as a parseable PDF with plausible page count and extractable title text. A sample from every subject group was also rendered for visual inspection. Source links below point to the copy archived here or to its stable landing page. ## Suggested first handful For the strongest short route through the shelf: 1. `routes/helbing-1998-active-walker-trail-systems.pdf` 2. `terrain/genevaux-2013-hydrology-based-terrain.pdf` 3. `pcg/kapania-2019-racing-trajectories.pdf` 4. `pcg/gravina-2019-pcg-quality-diversity.pdf` 5. `alexander/alexander-2009-harmony-seeking-computations.pdf` 6. `alexander/jiang-2015-wholeness-hierarchical-graph.pdf` 7. `space/jakob-2015-instant-field-aligned-meshes.pdf` 8. `vegetation/wohllaib-2021-ghost-grass.pdf` 9. `vegetation/kuth-2025-gpu-tree-generation.pdf` ## Routes Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvUkVBRE1FLm1k#content"] 15. Source file: plan/rfc-008-geology-conditioned-tessellation.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9yZmMtMDA4LWdlb2xvZ3ktY29uZGl0aW9uZWQtdGVzc2VsbGF0aW9uLm1k#content Size: 4632 bytes, 98 lines Matching excerpt: # RFC-008: Near-field tessellation with geology-conditioned detail - Status: Draft - Area: rendering (terrain geometry) - Interacts with: RFC-003 (its amplitude inputs), RFC-006 (channel banks), RFC-007 (waterline snap); extends item 5 of `ideas/geometry-from-fields.md` ## Problem Within arm's reach of the bike the terrain is still the quarter-cell Catmull-Rom reconstruction of 2.44 m samples: smooth, but featureless below the lattice scale. Banks, channel lips, ridgelines, and slopes have no metre-scale relief of their own, and the splat textures carry all close-range character alone. Generic detail noise would add bumps, but bumps that ignore the simulation read as texture, not terrain. ## Current situation - The near field renders through the Subdivided LOD: bounded Catmull-Rom heights and surface-derived normals in `terrain.metal`, morphing back to the authoritative lattice by `LOD_MORPH_START[0]` (64 cells, `moppe/game/terrain.cc`). - Physics stays on the authoritative bilinear surface; the render surface is already allowed to differ within each source cell's corner range -- there is precedent for a bounded divergence envelope. - Sub-metre shading detail exists only as pebble- Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9yZmMtMDA4LWdlb2xvZ3ktY29uZGl0aW9uZWQtdGVzc2VsbGF0aW9uLm1k#content"] 16. Source file: planning/rfcs/0001-current-engine-refactoring.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvcmZjcy8wMDAxLWN1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nLm1k#content Size: 2525 bytes, 60 lines Matching excerpt: # RFC-0001: Evolve the current engine toward the Atelier architecture Status: realized (decision accepted) ## Decision Moppe will not be replaced by a second engine. It will adopt the Atelier's architecture organ by organ, preserving a working game at every stage. The desired shape is: ```text topological domain -> typed intrinsic sections -> focused laws and simulation -> explicit extrinsic presentation ``` The current `Surface`/`WaterSurface` atlas and the Atelier tree are proofs of this shape. The completed execution track is [`current-engine-refactoring`](../tracks/current-engine-refactoring/README.md). The reader-facing result is the [engine atlas](../../docs/engine-atlas.md). ## Constraints - Prefer concrete domain values over generic manager frameworks. - Preserve the current game and its deterministic checks while boundaries move. - Keep quantities and their semantic kinds until the explicit renderer bridge. - Treat generation, mutable simulation, and presentation as different kinds of state. - Let the source and target graph follow the proven dependencies, rather than moving files first. ## Result The RFC is realized. `spatial::Bundle` is the shared finite-section abstract Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvcmZjcy8wMDAxLWN1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nLm1k#content"] 17. Source file: docs/renderer-design.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZW5kZXJlci1kZXNpZ24ubWQ#content Size: 31751 bytes, 526 lines Matching excerpt: # Moppe rendering & platform architecture Status: current Metal/backend implementation record. This document preserves the port's technical decisions and implementation detail; the [engine atlas](engine-atlas.md) is the current map of source ownership, state, and CMake targets. A playable browser backend now implements the same renderer contract through WebGPU; see [WebAssembly and WebGPU](web.md). Android remains a future possibility. ## Port goals and retained constraints 1. Render through Metal on macOS and iOS with one shared game codebase. 2. Keep the game's look and feel: same pass order, same haze/lighting math, same HUD, same physics. 3. Abstract the renderer and platform behind small, game-shaped interfaces so a WebGPU (or other) backend is an additive job, not a rewrite. 4. Refactor as we go: split the 4000-line main.cc into modules, remove dead code, de-boost, kill hidden global state where cheap. 5. Modernize where it pays: vertex-pulled terrain from a height texture (replaces ~100 MB of CPU-built triangle-strip soup), an explicit post chain, background-thread world generation with a loading screen (required on iOS anyway). ## Review amendments (adopted) A three-lens ad Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZW5kZXJlci1kZXNpZ24ubWQ#content"] 18. Source file: research/terrain/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvdGVycmFpbi9SRUFETUUubWQ#content Size: 6437 bytes, 114 lines Matching excerpt: # Terrain generation research This folder keeps the primary papers guiding Moppe's terrain laboratory. The PDFs are archived locally so implementation work can refer to stable copies rather than depending on browser bookmarks. ## Papers - `barnes-2016-priority-flood.pdf` — Richard Barnes, Clarence Lehman, and David Mulla, “Priority-Flood: An Optimal Depression-Filling and Watershed-Labeling Algorithm,” *Computers & Geosciences* 62, 2014. The archived arXiv version includes filling, watershed, and flow-direction variants. [arXiv](https://arxiv.org/abs/1511.04463) - `genevaux-2013-hydrology-based-terrain.pdf` — Jean-David Genevaux et al., “Terrain Generation Using Procedural Models Based on Hydrology,” *ACM Transactions on Graphics* 32(4), 2013. River networks are primary modeling features from which the surrounding terrain is constructed. [author copy](https://www.cs.purdue.edu/cgvlab/www/resources/papers/Genevaux-ACM_Trans_Graph-2013-Terrain_Generation_Using_Procedural_Models_Based_on_Hydrology.pdf) - `cordonnier-2016-uplift-fluvial-erosion.pdf` — Guillaume Cordonnier et al., “Large Scale Terrain Generation from Tectonic Uplift and Fluvial Erosion,” *Computer Graphics Forum* 35(2), Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvdGVycmFpbi9SRUFETUUubWQ#content"] 19. Source file: AGENTS.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/QUdFTlRTLm1k#content Size: 7069 bytes, 125 lines Matching excerpt: # Moppe Development Guidelines ## Build Commands - Configure: `cmake -B build -G Ninja` - Build everything: `cmake --build build` - Unit tests: `ctest --test-dir build --output-on-failure` - WebAssembly/WebGPU: `make web-serve`, then open `http://localhost:8080` (renderer testbed: `/moppe-web-testbed.html`) - Run the game: `./build/moppe.app/Contents/MacOS/moppe` (or `open build/moppe.app`) - Game controller: left stick drives and steers; right trigger boosts; `A` deploys the glider or restarts; `B` mounts/dismounts; `X` cycles the camera; and `Y` boosts, flares, or skips the cinematic. The D-pad navigates Terrain Lab. Xbox, PlayStation, and compatible MFi controllers use this layout. - Hang glider: boost the bike into the air and press `E` once the deploy prompt appears. `A`/`D` bank, `W`/`S` select airspeed, and `Space` flares; the motocross stays tethered beneath the wing. Press `E` again to drop it and reduce wing loading; otherwise touching down folds the wing and continues on the bike. On iOS, the mount/dismount corner deploys the wing while airborne and drops the attached bike while gliding. - Modes: `--fullscreen`, `--windowed`, `--graphics-quality low|balanced|high` - Over Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/QUdFTlRTLm1k#content"] 20. Source file: docs/project.org Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9wcm9qZWN0Lm9yZw#content Size: 39327 bytes, 737 lines Matching excerpt: #+title: Moppe project #+startup: overview * Purpose Moppe is currently a motorcycle game and a laboratory for generated worlds. It has several inherited or experimental modes, but the main line of work is the random world: generate a landscape, understand how it formed, render it convincingly, and ride through it. The immediate goal is not yet to build a large game around that world. It is to make the world coherent enough that riding it produces places worth noticing: waterways that make sense, terrain with a readable history, and routes and obstacles that arise from the land rather than being scattered on top of it. The more speculative ambition is an inhabited procedural world. The [[file:../ideas/second-author.md][second-author notes]] explore how geology might eventually support paths, roads, centers, and settlements. The [[file:../ideas/tending-the-world.md][tending-the-world essay]] develops the related possibility that riding, interpreting, and changing the landscape could become one continuous form of play instead of a game/editor split. The [[file:../ideas/structure-of-space.md][structure-of-space notes]] explore an irregular cellular tissue between smooth terrain fields Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9wcm9qZWN0Lm9yZw#content"] Approximate matches 1. Source file: docs/ontology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines Score: 0.016 Related excerpt: describes an organism as a nested spatial-functional hierarchy whose subsystems are fiat demarcations. The walker's limbs, a tree's branching, a river's confluence tree — one directed-tree vocabulary, as the Atelier notes already observe about drainage and organisms. ## Multitudes Some things come in populations: the pickup stars, the grove of trees, the dust emissions, someday traffic. A population is not an arbitrary set — Smith is scornful of set theory's willingness to collect numbers and popes together — but a collection *of a kind, in a context*: many instances of one universal sharing one setting. That is why a fleet can be total, every member having every quality of its kind, with none of the spreadsheet's empty cells. Members of a population are born and die, and identity across that churn — being *the same star* between one snapshot and the next — is what the philosophers call **genidentity**. A handle with a generation counter is genidentity implemented; a recycled slot resurrecting the wrong star is a genidentity bug. ## Systems, magnitudes, models Landgrebe and Smith's ontology of physics adds the top floor. A **system** is a portion of reality delimited *by fiat*: you Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content"] 2. Source file: docs/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9SRUFETUUubWQ#content Size: 1906 bytes, 33 lines Score: 0.016 Related excerpt: ... ion checkpoint, frame reading, and replay boundary. - `renderer-design.md` — Metal/backend implementation detail and retained port-design record. - `surface-atlas.md` — current surface domains, typed sections, and renderer presentation bridge. - `refactoring-seams.md` — characterization contracts for surface, replay, completed-world loading, and target ownership. - `terrain-expressions.md` — direct terrain generation and analysis design. - `trails.md` — leisure-circuit planning, grading, materials, and consumers. - `units.md` — scientific quantities, unit conventions, and simulation scale. - `ontology.md` — what kinds of things the game world contains: fields and fiat objects, substances and qualities, processes, populations, and what makes a representation faithful. A vocabulary, not a specification. - `working-practices.md` — development and verification practices. Repository-native RFCs and their executable work-item graphs live in `../planning/`. They describe accepted intended work and its dependencies; they are more concrete than the speculative essays in `../ideas/`, but do not claim that an item is implemented until its work item says so. The Atelier charters (`atelier-earth.md` and ` ... Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9SRUFETUUubWQ#content"] ### 8. Assistant tool calls #### Tool call: `read` ```json { "blocks": [ "https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content" ] } ``` ### 9. Tool result: read SOURCE FILE Path: docs/ontology.md Resource: /3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines # What Exists in Moppe Moppe keeps careful accounts of *how much*: heights in meters, thrust in newtons, sink rates in meters per second. The type system refuses to add an airspeed to an altitude, and the codebase is better for it. This document starts a parallel set of accounts about *what kinds of things there are*. It is not a specification and it proposes no work. It is a vocabulary — a way of talking about the game world that stays truthful about the structure of what the code simulates, the way `units.md` stays truthful about magnitudes. The vocabulary is borrowed, mostly from the ontologist Barry Smith and his collaborators, whose papers live in `research/` (readable in sections at `https://m.sheaf.less.rest/` with `Accept: text/markdown`). Their subject is ordinary reality — mountains, headaches, county borders, orchestras — but a game world turns out to be built from the same kinds of things, and it is clarifying to call them by their proper names. ## Fields and things Ask what the terrain *is* and two honest answers come back. To the simulation, the terrain is a field: elevation as a value at every position, and alongside it moisture, forest cover, snow support, channel flux — each a quantity distributed over the same ground. This is the scientist's answer. Hydrology and erosion are computed this way because they are field phenomena; nothing in a drainage calculation ever needs to know where one mountain ends and the next begins. To the player, the terrain is things: a mountain, a valley, a river with a mouth, a waterfall worth flying past. This is not a lesser answer. People — and cameras, and quest designers — deal in objects, because objects are what you can name, visit, and point at. Smith and Mark, in *Do Mountains Exist?*, show how both answers hold at once. The mountain is real, but it is a **fiat object**: a portion of the elevation field set into relief and named, the way Mount Everest is a demarcation drawn on geophysical reality rather than a self-bounding thing like a planet. Fiat objects have graded, vague boundaries — nobody can say exactly where a mountain stops, and nobody needs to. The water-feature namer (stream, river, confluence, mouth, waterfall, lake) and the cinematic landmark planner are the game performing exactly this projection: carving nameable things out of fields so that the camera can tour them and the player can be somewhere. Trail influence and home-base influence do the same job with honest gradedness — membership that fades instead of ending. The rule of thumb this yields: **simulate in fields, experience in objects**, and treat the projection from one to the other as real work with a real name. ## Six kinds of entity Aristotle sorted what exists into a small table; Smith's *Against Fantology* extends it to six cells, and the game fills every one of them. There are **substances**: things that exist on their own and persist — this bike, this glider, this cedar, the walker. A substance has an essence: being a bike is not a state the bike is in, it is what the thing *is*, and it is true the whole time the bike exists. There are **qualities**: things that exist only *in* something else — this bike's boost charge, the moisture of this patch of ground, the bank of this glider right now. A quality cannot float free; there is no boost charge without a bike to have it. The bundle types make this dependence structural: a moisture value exists only at a site of a domain, and the compiler will not let you write one down otherwise. And there are **processes**: things that happen — this jump, this landing, this cinematic flight, the afternoon's slow clouding-over. A process is not a thing that changes; a process *is* a change, stretched over time, with the bike as its participant. Each of the three comes in particular and universal. *This* jump is a particular; *jump* is the universal it instantiates. The quantity specs are exactly the universals of the quality column: `airspeed` and `rate_of_climb` are both measured in meters per second, but they are different universals, which is why they are different specs. Keeping the spec vocabulary curated — one spec per genuine quality, none for arbitrary combinations — is the ontological discipline that Smith calls resisting *Booleanism*: reality does not contain a quality for every expression you can form, and neither should the game. The reason to keep all six cells distinct is what Smith's paper is about. Flatten them — treat "is a bike" and "is airborne" as the same sort of runtime fact, or reduce every entity to a bare id with property cells, as an entity-component spreadsheet does — and you get a world of unknowable particulars inspected through null checks. The six-fold structure is what the null checks were compensating for. ## What persists and what happens Smith's SNAP/SPAN framework says a changing world needs two linked books of account. One book inventories **continuants**: everything that exists wholly at an instant and endures — the bike, its boost charge, the trail network. The other inventories **occurrents**: everything that unfolds — rides, jumps, landings, a session's whole history. Neither book reduces to the other, and each continuant appears in the second book once, as its **life**. The game already keeps both books; it just never said so. `GameState` is a SNAP inventory: the copyable value of everything that exists at this tick. The fixed-step input tape and the replay machinery are SPAN: a session's history as a first-class thing you can store and re-run. The philosophical footnote that earns its keep here is that *processes cannot change* — a process is timelessly whatever it turns out to be — which is why a replay tape is immutable by nature and not merely by implementation choice. Where a process crosses a threshold there is an **event**: an instantaneous boundary. Touchdown. Star collected. Glider deployed. The scattered airtime floats and pop-on-read impact values in the current code are events and processes recorded without their proper category; the vocabulary at least lets us see them as such. ## Parts, attachments, places The word "hierarchy" hides three different relations, and scene graphs earn their bad reputation by melting them into one pointer. **Parthood** is definitional. The wheel is part of the bike the way the heart is part of the body: a bike without a wheel is not a sparser bike but a damaged one. Parthood belongs in the type: a bike *is* frame and wheels and steering, the way a product type says. **Attachment** is circumstantial but grammatical. The rider mounts the bike; the bike hangs tethered beneath the glider; the glider is dropped. These are configurations drawn from a small closed set, with rules about which transitions are possible when. The mode flag and the `bike_attached` boolean are this grammar written in shorthand. **Location** is neither. The bike is not part of the terrain and not attached to it; it is *on* it, which is a relation you query — sample the field under the wheels — not a link you store. Keeping location out of the structural relations is what keeps them small, and it is the mistake scene graphs make when the player gets reparented under the boat. A body, incidentally, has the same shape all the way down: Smith's paper on bodily systems describes an organism as a nested spatial-functional hierarchy whose subsystems are fiat demarcations. The walker's limbs, a tree's branching, a river's confluence tree — one directed-tree vocabulary, as the Atelier notes already observe about drainage and organisms. ## Multitudes Some things come in populations: the pickup stars, the grove of trees, the dust emissions, someday traffic. A population is not an arbitrary set — Smith is scornful of set theory's willingness to collect numbers and popes together — but a collection *of a kind, in a context*: many instances of one universal sharing one setting. That is why a fleet can be total, every member having every quality of its kind, with none of the spreadsheet's empty cells. Members of a population are born and die, and identity across that churn — being *the same star* between one snapshot and the next — is what the philosophers call **genidentity**. A handle with a generation counter is genidentity implemented; a recycled slot resurrecting the wrong star is a genidentity bug. ## Systems, magnitudes, models Landgrebe and Smith's ontology of physics adds the top floor. A **system** is a portion of reality delimited *by fiat*: you choose a granularity and a boundary — the planets, or the planets with their moons — because you choose which interactions you are modeling. The vehicle system, the soaring model, the drainage network: none of these carve the game world at pre-given joints, and none need apologize for it. Delimiting a system is a modeling act, and it is done well or badly, not truly or falsely. A **magnitude** is a measurable phenomenon — mass, sink rate, boost energy — and each magnitude is a dimension of the system's **phase space**. This gives the right way to see a state value: not a struct that accumulated fields, but a phase space that should be able to say what its dimensions are. A bag like the current logic-state struct is a phase space with unlabeled axes. A **model**, finally, is a human-made representation of a system — equations, drawings, code — and models approximate by nature. Their worked example of an idealized model is, delightfully, a weight on a spring: the harmonic oscillator, template for every refinement. The game is full of these honest small models — the comment in `glider.hh` calls its physics "a deliberately compact soaring model," which is exactly the right register. The code is the model stratum of the game: laws written as update rules, idealization as license rather than lapse. ## Pictures of the world The engine is full of representations: the height texture, the trail-map HUD, the frame snapshot handed to the renderer, the benchmark CSV, a saved checkpoint. Smith's *True Grid* and the granular-partition papers give a single account of what all of these are: a **grid** of cells stands in a **projection** relation to reality, and when projection succeeds each object is **located** at its cell. A grid whose projection and location agree — where the map says what is there, and what is there is what the map says — is **transparent**: you look through it at the things themselves. Transparency is the correctness condition of every bridge in the codebase, from bundle columns packed into texture lanes to poses frozen into a frame. The two classic ways a representation goes wrong are exactly the two familiar bugs: cells projecting onto nothing (a dangling handle) and cell structure disagreeing with object structure (a mirror that drifted out of sync). Three details of the theory pay immediate rent. Grids may hold **empty cells** without being false — the periodic table kept labeled boxes for undiscovered elements — so spare fleet capacity and absent optional poses are respectable. A fixed grid may be **re-projected over time** — their example is a territorial grid sampling birds from moment to moment — which is precisely what a frame is: the same cells every frame, aimed anew sixty times a second. And every grid has a **direction of fit**. Most of the engine's grids fit world-to-map: the render, the HUD, the CSV must conform to the world, and their virtue is fidelity. The trail system fits both ways at once, like a cadastre: walkers wear the trail, the trail steers the walkers, and its virtue is stable convergence. And one grid fits map-to-world: the recipe. ## The unreal, made real on demand A game world is, in the terms of Smith's paper on the unreal, fiction: its representations are about things that do not exist. Fiction's cells project into thin air — his older example is a catalogue of Aztec gods. But procedural generation is fiction with a private amendment: the recipe is a plan whose execution *manufactures its referents*. A seed names a world the way "Mount Everest" names a mountain — rigidly — except that uttering the name is what brings the mountain into being. Generation is a performative map, and determinism is simply the demand that the performance be repeatable: same seed, same world, so that the name never dangles. This is why the game can hold itself to a standard that ordinary fiction cannot: within a generated world, every well-formed representation can be transparent, because the world and its pictures issue from the same act. ## The vocabulary, briefly - **field** — a quantity everywhere over a domain (elevation, moisture) - **fiat object** — a named, vaguely-bounded demarcation of a field (a mountain, a river mouth, a trail) - **substance** — an independent persisting thing (the bike, this tree) - **quality** — a dependent thing, existing only in its bearer (this bike's boost charge); its universal is a quantity spec - **process / event** — what happens / its instantaneous boundary (this jump / touchdown) - **continuant / occurrent (SNAP / SPAN)** — what persists at an instant / what unfolds over time; checkpoint / replay - **parthood, attachment, location** — is made of / is configured with / is at; type structure / closed grammar / field query - **population, genidentity** — many of a kind in a context; identity through birth, death, and reuse of slots - **system, magnitude, model** — fiat-delimited subject matter; a dimension of its phase space; the code that approximates it - **grid, projection, location, transparency, direction of fit** — what a representation is, and when it is faithful - **performative map** — a representation that creates its target; a recipe with its seed None of this obliges any refactoring. It is here so that when we discuss whether something deserves a struct, a spec, an event, or a query, the discussion can be about what the thing *is* — and so that the answer, once found, has a name. ## Sources Barry Smith and collaborators; all in `research/`, browsable at `m.sheaf.less.rest`: - *Against Fantology* (2005) — the six-category table; against bare particulars and Booleanism. - *Do Mountains Exist?* (Smith & Mark, 2003) — fields, objects, and fiat landforms. - *SNAP and SPAN* (Grenon & Smith, 2004) — continuants, occurrents, lives, and change. - *Classifying Processes* (2012) — process profiles; determinable and determinate. - *True Grid* (2002) — projection, transparency, directions of fit. - *A Theory of Granular Partitions* (Bittner & Smith, 2003) — cells, location, empty cells, granularity. - *Ontologies of Common Sense, Physics and Mathematics* (Landgrebe & Smith, 2023) — systems, magnitudes, models, phase space. - *About the Unreal* (Beverley, Logan & Smith, 2025) — fiction, blueprints, and simulation. - *Bodily Systems and the Spatial-Functional Structure of the Human Body* (2004) — organisms as nested fiat systems. ### 10. Assistant Yes—I’ve read `docs/ontology.md` in the Moppe repository. Its central rule is **“simulate in fields, experience in objects.”** It establishes a Barry Smith–inspired vocabulary for discussing the game world, including: - fields and fiat objects - substances, qualities, and processes - continuants and occurrents (SNAP/SPAN) - parthood, attachment, and location - populations and genidentity - systems, magnitudes, models, and phase spaces - grids, projection, transparency, and direction of fit - procedural generation as a **performative map** It is explicitly a vocabulary rather than a specification or refactoring proposal. ### 11. User What I find really interesting and intriguing is the possibility of using the Barry Smith way of thinking to do something like have a nicer kind of a typed and semantically meaningful representation of the world in the game. In a way that is based on nested containment, like Mario topology, Mariology, and these ontological relations and the ideas like dependent continuant and this kind of stuff. ### 12. Assistant tool calls #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 10, "query": "mereology mereotopology dependent continuant containment ontology world representation" } ``` #### Tool call: `search_text` ```json { "document_id": "7YZU95", "limit": 8, "query": "boundaries parts whole dependence coincidence contact" } ``` #### Tool call: `search_text` ```json { "document_id": "3CCZ4A", "limit": 8, "query": "nested spatial functional hierarchy fiat parts systems function" } ``` #### Tool call: `search_text` ```json { "document_id": "9YMD2E", "limit": 8, "query": "dependent continuant continuant occurrent participation spatial location" } ``` ### 13. Tool result: search_text Exact matches 1. Source file: docs/ontology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines Matching excerpt: # What Exists in Moppe Moppe keeps careful accounts of *how much*: heights in meters, thrust in newtons, sink rates in meters per second. The type system refuses to add an airspeed to an altitude, and the codebase is better for it. This document starts a parallel set of accounts about *what kinds of things there are*. It is not a specification and it proposes no work. It is a vocabulary — a way of talking about the game world that stays truthful about the structure of what the code simulates, the way `units.md` stays truthful about magnitudes. The vocabulary is borrowed, mostly from the ontologist Barry Smith and his collaborators, whose papers live in `research/` (readable in sections at `https://m.sheaf.less.rest/` with `Accept: text/markdown`). Their subject is ordinary reality — mountains, headaches, county borders, orchestras — but a game world turns out to be built from the same kinds of things, and it is clarifying to call them by their proper names. ## Fields and things Ask what the terrain *is* and two honest answers come back. To the simulation, the terrain is a field: elevation as a value at every position, and alongside it moisture, forest cover, snow support, channel f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content"] 2. Source file: docs/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9SRUFETUUubWQ#content Size: 1906 bytes, 33 lines Matching excerpt: # Documentation - `engine-atlas.md` — current engine map: domains, world/session/frame boundaries, presentation, and target dependencies. - `project.org` — living status, priorities, and dated progress notes. - `generated-world.md` — completed-world construction, ownership, and activation lifetime. - `game-state.md` — session checkpoint, frame reading, and replay boundary. - `renderer-design.md` — Metal/backend implementation detail and retained port-design record. - `surface-atlas.md` — current surface domains, typed sections, and renderer presentation bridge. - `refactoring-seams.md` — characterization contracts for surface, replay, completed-world loading, and target ownership. - `terrain-expressions.md` — direct terrain generation and analysis design. - `trails.md` — leisure-circuit planning, grading, materials, and consumers. - `units.md` — scientific quantities, unit conventions, and simulation scale. - `ontology.md` — what kinds of things the game world contains: fields and fiat objects, substances and qualities, processes, populations, and what makes a representation faithful. A vocabulary, not a specification. - `working-practices.md` — development and verification practic Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9SRUFETUUubWQ#content"] 3. Source file: ideas/structure-of-space.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content Size: 24239 bytes, 620 lines Matching excerpt: # The structure of space *Notes toward a cellular tissue for places, construction, and memory.* ## The proposition Moppe's landscape is currently represented with great success as fields: height at a position, water over rock, slope, drainage, material, and the successive results of terrain transformations. This is the right language for geology at landscape scale. It is not by itself the right language for everything that may later inhabit the land. Paths, crossings, rooms, courtyards, bridges, property, construction stages, names, and remembered events want discrete identity. They want adjacency, containment, boundaries, and persistence. They want to say *this place*, *this edge*, and *these neighbors*, even while their physical realization remains smooth and irregular. The proposed middle layer is a **draped cellular tissue**: a mostly quadrilateral, locally rhythmic, irregular two-dimensional cell complex embedded in the smooth terrain. It exists lightly across the world and grows sparse three-dimensional cellular structure where construction takes hold. The terrain remains continuous where continuity matters. The tissue becomes discrete where composition matters. This is not t Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content"] 4. Source file: docs/refactoring-seams.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZWZhY3RvcmluZy1zZWFtcy5tZA#content Size: 9975 bytes, 187 lines Matching excerpt: # Refactoring seams RFC-0001 established these boundaries one at a time. This page preserves the observable contracts that survived those moves; it is a characterization baseline, not a second architecture proposal or a current work plan. The [engine atlas](engine-atlas.md) is the reader-facing map of the resulting ownership and target shape. ## Surface `map::Surface` is the materialized ground reading over one `SurfaceDomain`. Its `SurfaceAtlas` owns geometry plus named optional hydrology, geology, ecology, and use sections; `game::SurfacePresentation` is the only bridge that turns them into renderer lanes. | Contract | Characterization owner | | --- | --- | | Continuous elevation and normal reads reconstruct the authoritative geometry bundle, including across the torus boundary. | `surface_reconstruction_matches_authoritative_geometry` and `surface_reconstruction_wraps_the_torus` in `tests/map/surface_test.cc` | | Mutating the elevation column changes surface reads immediately; rebuilding geometry readings clears dependent materialized sections. | `surface_geometry_is_authoritative_without_a_refresh_barrier` and `surface_presentation_is_the_numeric_bridge_for_typed_sections` in ` Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZWZhY3RvcmluZy1zZWFtcy5tZA#content"] 5. Source file: research/vegetation/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvdmVnZXRhdGlvbi9SRUFETUUubWQ#content Size: 14261 bytes, 225 lines Matching excerpt: # Vegetation rendering research This shelf collects papers and production material for dense vegetation that looks alive without making the renderer revolve around it. It is deliberately matched to Moppe's current split: - the terrain has a filtered grass material; the former per-blade mesh-shader experiment remains useful history but is not in the current game; - trees have a global habitat-driven canopy field and cheap chunked population, while distinct Atelier organisms form the detailed mixed-age stand; - moisture, elevation, slope, shore clearance, and tree line already provide ecological placement fields; - grass and tree vertices already share a continuous wind vocabulary. The most useful conclusion is not one representation for every distance. Keep individual geometry where its silhouette, parallax, interaction, or identity is visible; progressively turn it into filtered coverage and canopy appearance as it becomes subpixel. ## Start here 1. `wohllaib-2021-ghost-grass.pdf` is the closest production analogue to the current grass renderer: tile-local GPU generation, field sampling, culling, per-blade variation, animation, and LOD. 2. `kuth-2025-gpu-tree-generation.pdf` is the Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvdmVnZXRhdGlvbi9SRUFETUUubWQ#content"] 6. Source file: tests/game/generated_world_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nZW5lcmF0ZWRfd29ybGRfdGVzdC5jYw#content Size: 3708 bytes, 99 lines Matching excerpt: #include #include #include #include #include namespace { moppe::terrain::WorldRecipe test_world_recipe (moppe::spatial_extent_t extent, int resolution, moppe::terrain::Seed seed) { using namespace moppe; using namespace moppe::terrain; return make_world_recipe ( extent, resolution, seed, 50.0f * u::m, TerrainGenerationProfile::Fast); } void fill_test_terrain (moppe::map::Surface& map) { for (int y = 0; y < map.height (); ++y) for (int x = 0; x < map.width (); ++x) map.set_elevation ( x, y, moppe::terrain::surface_elevation_point ( (0.25f + 0.01f * static_cast ((x + y) % 7)) * 650.0f * mp_units::si::metre)); } } MOPPE_TEST (generated_world_owns_a_complete_named_world) { using namespace moppe; using namespace moppe::terrain; const spatial_extent_t extent = spatial_extent_in_metres (Vec3 (640, 650, 640)); game::WorldParams params; params.map_size = extent; params.resolution = 17; params.water_level = 50.0f * u::m; const WorldRecipe recipe = test_world_recipe (extent, 17, Seed { 42 }); game::GeneratedWorld world (params, recipe); fill_test_terrain (world.surface ()); world.rebuild_surface (); std::ve Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nZW5lcmF0ZWRfd29ybGRfdGVzdC5jYw#content"] 7. Source file: docs/engine-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9lbmdpbmUtYXRsYXMubWQ#content Size: 12439 bytes, 222 lines Matching excerpt: # Moppe engine atlas This is the reader's map of the current engine after RFC-0001. It names the values that make up a world, the mutable state that rides it, the immutable reading that presents a frame, and the CMake targets that carry those boundaries. Read it before the detailed subsystem documents; the `current-engine-refactoring` track is retained as the history of how this shape was reached, not as the architecture reference. ## One world, one frame The main flow is data and borrows, not a generic scene graph or an ownership diagram for CMake: ```mermaid flowchart LR recipe["WorldRecipe"] --> build["direct world construction"] build --> world["GeneratedWorld"] world --> session["GameSession"] world --> view["FrameView"] session --> view view --> scene["world, actor, water, effect, HUD presentation"] scene --> renderer["render::Renderer"] renderer --> metal["Metal backend"] renderer --> webgpu["WebGPU backend"] app["application: loading, input, mode selection"] --> build app --> session app --> view ``` `GeneratedWorld` is the stable owner of one completed landscape. `GameSession` is the mutable life played on that landscape. `FrameView` is a new immutable reading composed for Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9lbmdpbmUtYXRsYXMubWQ#content"] 8. Source file: moppe/game/forest.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mb3Jlc3QuaGg#content Size: 1826 bytes, 66 lines Matching excerpt: #ifndef MOPPE_GAME_FOREST_HH #define MOPPE_GAME_FOREST_HH #include #include #include #include #include namespace moppe::game { enum class ForestForm { broadleaf, conifer }; struct ForestSite { Vec3 position; Vec3 normal; float cover = 0.0f; float scale = 1.0f; std::uint32_t seed = 0; ForestForm form = ForestForm::broadleaf; }; struct ForestPlan { std::vector sites; Vec3 period; }; // Convert the continuous canopy field into stable individuals on a // jittered grid. Positions and identities depend only on world seed and // lattice cell, so revisiting an area never produces a different forest. [[nodiscard]] ForestPlan plan_global_forest (const map::Surface& surface, std::uint32_t seed, float spacing = 12.0f); // Terrain-scale presentation of the population. Each retained mesh owns a // cullable world chunk of deliberately cheap trunks and crown volumes; the // detailed Atelier stand remains a separate near/hero representation. class ForestLandscape { public: void rebuild (render::Renderer& renderer, const map::Surface& surface, std::uint32_t seed); void draw (render::Renderer& renderer, const V Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mb3Jlc3QuaGg#content"] 9. Source file: ideas/theory-of-the-world.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvdGhlb3J5LW9mLXRoZS13b3JsZC5tZA#content Size: 6242 bytes, 115 lines Matching excerpt: # Theory of the world This document is the conceptual model underneath the terrain code. Nothing here is required to compile; all of it is required to make good decisions. ## The world is a torus The generated random landscape is a flat torus: finite, unbounded, locally ordinary Euclidean space with gravity pointing down, closed by identifying opposite edges. City and Pico modes remain explicitly bounded exceptions. Nothing bends; only neighborliness changed. Consequences recur everywhere: noise must be periodic (integer wave counts — wavelengths must divide the world); there are no boundary cells, so nothing may be seeded, clamped, or special-cased "at the edge"; periodic position differences should use minimum-image deltas (`topology.hh`); physics keeps *unwrapped* coordinates (the universal cover) and wraps at terrain lookup—the ring-buffer discipline. This makes winding numbers possible, although the game does not yet expose a general circumnavigation reading. A useful law: on a torus, every operator should commute with translation. Symmetry violations are how residual edge-thinking announces itself. ## Two authors, and a referee Terrain is the current score in an argument betw Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvdGhlb3J5LW9mLXRoZS13b3JsZC5tZA#content"] 10. Source file: atelier/atelier.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content Size: 4395 bytes, 117 lines Matching excerpt: #include "atelier/atelier.hh" #include #include namespace atelier { using namespace si::unit_symbols; namespace { simd_float4 material_parameters (const EmbeddedTile& tile) { constexpr simd_float3 ivory { 0.74f, 0.66f, 0.56f }; constexpr simd_float3 compressed { 0.64f, 0.54f, 0.50f }; constexpr simd_float3 new_growth { 0.64f, 0.70f, 0.62f }; const Real deformation = tile.deformation.numerical_value_in (mp_units::one); const simd_float3 mature = simd_mix (ivory, compressed, simd_float3 (deformation)); const simd_float3 colour = simd_mix (mature, new_growth, simd_float3 (tile.generation)); return simd_make_float4 (colour, tile.material_seed); } } bool Viewport::is_empty () const { return width == 0 || height == 0; } Real Viewport::aspect_ratio () const { if (is_empty ()) throw std::invalid_argument ("An empty viewport has no aspect ratio"); return Real (width) / Real (height); } Frame compose_frame (const HexSheet& sheet, EmbeddingKind embedding, Duration elapsed, Viewport viewport) { const EmbeddedHexSheet world = embed_hex_sheet (sheet, embedding, elapsed, viewport.aspect_ratio ()); Frame frame { .uniforms = Uniforms { .world_to_clip = world.world_to_clip, . Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content"] Approximate matches 1. Source file: docs/ontology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines Score: 0.016 Related excerpt: # What Exists in Moppe Moppe keeps careful accounts of *how much*: heights in meters, thrust in newtons, sink rates in meters per second. The type system refuses to add an airspeed to an altitude, and the codebase is better for it. This document starts a parallel set of accounts about *what kinds of things there are*. It is not a specification and it proposes no work. It is a vocabulary — a way of talking about the game world that stays truthful about the structure of what the code simulates, the way `units.md` stays truthful about magnitudes. The vocabulary is borrowed, mostly from the ontologist Barry Smith and his collaborators, whose papers live in `research/` (readable in sections at `https://m.sheaf.less.rest/` with `Accept: text/markdown`). Their subject is ordinary reality — mountains, headaches, county borders, orchestras — but a game world turns out to be built from the same kinds of things, and it is clarifying to call them by their proper names. ## Fields and things Ask what the terrain *is* and two honest answers come back. To the simulation, the terrain is a field: elevation as a value at every position, and alongside it moisture, forest cover, snow support, channel f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content"] ### 14. Tool result: search_text Exact matches 1. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 16 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #P8BRYH Boundaries Matching excerpt #2YHFG9: We now have two (in the end equivalent) alternatives in regard to the definition of boundary : on the one hand we might exploit in Chisholmian fashion the use of de re modalities and define boundaries as entities that are necessarily such as to exist as parts of bodies; on the other hand we might exploit the notion of coincidence and define boundaries as coincident entities. Here we follow Chisholm in taking the former course. We shall then lay down the interrelation between boundaries and coincidence by means of an axiom. 2. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 20 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness Matching excerpt #FH7DGQ: A pair of spatial entities are in contact each other directly when their respective boundaries, in whole or in part, coincide. Chisholm defines direct contact as follows (1992/93, p. 16): 3. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 29 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #X4V2VT Points, Lines and Surfaces Matching excerpt #Q6MSTK: Even when this is done, much will have been left unsaid. Thus we have not specified that points are parts of lines, that lines are parts of surfaces. Thus a fortiori we have not said either that lines are not mere sums of points and that surfaces are not mere sums of lines. Nor have we said that lines and surfaces have boundaries. We have not defined the single dimensions, nor ruled out fractional dimensions, and nor have we said that points, lines and surfaces are entities of zero, one and two dimensions, respectively. All of these things need to be proved, or stipulated axiomatically on the basis of intuitively reasonable, sound and satisfactory mereotopological considerations. Only then will we have more than the beginnings of a theory of boundaries and coincidence. 4. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 26 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness #5T4RSH Dimensions Matching excerpt #TJM63V: is to be designated as one-dimensional if it has no other boundaries than such as are not themselves continuous. ... The spatial line, too, has no boundaries other than non-extended ones, namely the spatial points, and it is for this reason that Euclid defined the point as that which has no parts. The surface, in contrast, belongs with the two-dimensional continua since its boundaries comprehend not only points but also lines. And a body is to be designated as a three-dimensional continuum since not only is the whole body bounded by a surface but so also each one of its parts is separated from the remainder by a surface that is a two-dimensional boundary. (1988, p. 10) 5. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 21 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness Matching excerpt #Y2BVSN: A pliable rod, it seems clear, can be turned back upon itself in some special sense (the two ends can be brought into contact with each other). But surely the sense in which a doughnut is in contact with itself applies to all connected bodies (consider v in \text{DDCOK} as the right boundary of the left hemisphere of a sphere, w as the left boundary of the right hemisphere of the same sphere). Indeed it follows from our considerations on internal boundaries above that x\text{DCOK}x holds for every body x , since every body is large or thick enough to contain at least two coincident entities as parts. 6. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 21 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness #ZQP35X Touching Matching excerpt #6SNMDD: In fact, to do justice to what Chisholm has in mind, we must therefore distinguish touching as a special case of direct contact which applies only to coincident parts of external boundaries of mutually discrete bodies: an entity x touches an entity y if each is such that it can exist without detriment even should the other be destroyed. We might, accordingly, introduce a new primitive ‘exists’ (symbolized by ‘ E! ’) and formulate a definition along the lines of: 7. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 2 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #DKMEJR The Brentano-Chisholm Theory of the Continuum Matching excerpt #9SHYRP: It is the theory of coincidence, and the account of boundaries and the continuum which this dictates, which will occupy us in what follows. We shall concentrate especially on four papers in which Chisholm treats the theory of coincidence of boundaries in space (1983, 1989, 1992/93 and 1994). As will already be clear, analogous reasoning can be applied also to the coincidence of boundaries in time (to beginnings and endings, for example: see Chisholm 1982, 1992), though we shall here leave these, temporal, matters out of account. 2 8. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 23 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness #CC4MY2 Contact Matching excerpt #45FYR5: ( x is in total contact with y iff x and y are in contact and all parts of x and y are in contact with corresponding parts of y and x ). Approximate matches 1. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 20 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness Score: 0.03 Related excerpt #FH7DGQ: A pair of spatial entities are in contact each other directly when their respective boundaries, in whole or in part, coincide. Chisholm defines direct contact as follows (1992/93, p. 16): 2. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 11 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #A5EDZ6 The Formalization of the Brentano-Chisholm Theory #2ZAUBH Coincidence Score: 0.028 Related excerpt #HWJSAQ: Coincidence, as we shall here understand the notion, is exclusively the sort of thing that pertains to boundaries. 16 Bodies do not coincide (not even with themselves); nor do they coincide with the spatial regions they occupy. Other sorts of coincidence may be 3. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 24 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness #E4UVCT Connectedness for Boundaries Score: 0.027 Related excerpt #E8PW3Q: (a boundary is connected iff any partition into y and z is such that if y is a boundary of body u and z is a boundary of body v then u and v are in direct contact) 4. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 17 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #P8BRYH Boundaries Score: 0.026 Related excerpt #LZYKS3: (a boundary is an entity which is as a matter of necessity such that it and all its parts are necessary proper parts of bodies). 5. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 23 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #836SUT Varieties of Connectedness #4MYQQ8 Boundary Of Score: 0.026 Related excerpt #DSKWQ4: ( x is a boundary of a body y iff x is a boundary and a part of y and y is possibly such as to touch some z with part of which x is coincident). 6. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 28 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #X4V2VT Points, Lines and Surfaces Score: 0.025 Related excerpt #J2EW9V: We can also define, by analogy with the case for bodies, what it is for two boundaries to be in direct contact: 7. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 7 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #5FAE8D Plerosis Score: 0.024 Related excerpt #XPVR43: Boundaries, accordingly, may be boundaries only in certain directions and not in others. Imagine a line that is tangent to a circle, and meets the circle at a certain point. Strictly speaking we need here to recognize two points, a point on the line and a point on the circle, which coincide , the one with the other. The two points are not identical since they serve as boundaries in different directions. The point on the line is a boundary in two rectilinear directions, the point on the circle is a boundary in two directions of a certain determinate curvature. 12 8. Source: Boundaries: An Essay in Mereotopology (#7YZU95), Barry Smith, p. 6 Context: #RBUH86 Boundaries: An Essay in Mereotopology1 #S83P9V Mereology Score: 0.021 Related excerpt #7LSF8Y: All the mentioned types of entities share further the fact that they license certain sorts of ontological inference ( if there is a boundary/structure/hole/soul having these and those properties, then there is a host having these and those properties). We cannot infer to any specific host, however. Thus it cannot be said of any definite continuum that a boundary is dependent on it : that which a boundary is dependent on can be designated rather only via a general term: what is required by a boundary is, Brentano says, ‘not this or that particular continuum, but any continuum of the appropriate kind.’ 10 For while no boundary can exist without being connected with a continuum, ‘there is no specifiable part, however small, of the continuum, and no point, however near it may be to the boundary, which is such that we may say that it is the existence of that part or of that point which conditions the boundary.’ (Brentano 1981, p. 56) ### 15. Tool result: search_text Exact matches 1. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 5 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #CVF4S5 2. Bodily Systems in the Medical Domain #9UT3KZ 2.3 A Brief Summary Matching excerpt #5KJ64T: It is top-level systems like the circulatory, digestive, urinary, and endocrine systems to which we refer in what follows with the term bodily system . One feature that is shared in common by all bodily systems unique among all the parts involved in the body's spatial-functional hierarchy is that their ceasing to function is sufficient for the body to die. 2. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 15 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #YN2YMY 4. 'Element' Defined Matching excerpt #446F78: In the context of the digestive system, the blood's function is to transport nutrients and allow for nutrient and waste exchange at the cellular level, and to nourish the components of the digestive system; in the context of the respiratory system, its function is to transport gases and allow for gas exchange at the cellular level. Blood, therefore, like most elements, can be located simultaneously at different horizontal levels of the spatial-functional hierarchy, for it has different functions within the context of different systems, and blood is an element of each. More precisely, we might want to say that at any given time different potentially overlapping parts of the blood in the body are parceled out as elements of different systems. Which these parts are will then vary from one moment to the next. 3. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 20 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #EU2W22 5. Elements, Functions, and Criticality #P8ECVR 5.4 Critical Functions and the Spatial-Functional Hierarchy Matching excerpt #FQ4V8B: There are clearly many types of criticality. Is the heart more critical than the stomach because the body will die sooner in virtue of a malfunctioning of the heart? An expansion of this account can break down criticality into its different types. For now, however, since we have explored how the criticality of a function goes hand in hand with its placement on the spatial-functional hierarchy, we have what we need to explain the reasoning behind a division of the body into its major systems. 4. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 19 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #EU2W22 5. Elements, Functions, and Criticality #P8ECVR 5.4 Critical Functions and the Spatial-Functional Hierarchy Matching excerpt #K99UR3: We can now see that a correlation emerges between criticality and spatial-functional level. Elements with functions at higher spatial-functional levels are also more critical. In other words (and as a rule of thumb only) the fewer systems you have to count upward from a function before you reach the function of the body as a whole, the more critical the function is to the whole organism. For example, the brain exists on a high spatial-functional level: there is only one brain in the whole body, and it has a critical function. Each single neuron, on the other hand, exists on a low spatial-functional level and does not have a critical function because it stands in a relation of redundancy to other neurons. 5. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 15 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #YN2YMY 4. 'Element' Defined Matching excerpt #ZCKB2J: Just as systems can be divided into elements, so functions can be divided into sub-functions (corresponding to the elements which perform them). Functions located at lower levels of the spatial-functional hierarchy interact in complex ways to enable functions at higher levels. For example, the function of a particular neuron (to provide a path for electric impulses), is realized in a composite process that consists of smaller interrelated processes, such as the exchange of potassium and sodium ions through the cellular membrane. One of the kidney's functions is to excrete urine. This function is realized by a composite process that consists of smaller interrelated processes that occur on lower levels of granularity: the excretion of urea and creatinine, absorption of necessary ions and excretion of redundant ions and water. So the realization of a function in a process often entails the realization of sub-functions in sub-processes. 6. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 16 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #EU2W22 5. Elements, Functions, and Criticality #986L3N 5.1 Evaluating Functionings Matching excerpt #5BZ36Q: The spatial-functional hierarchy gives us a means by which we can effect an evaluation of functionings. In a spatial-functional hierarchy built in reflection of constituent functions on successive levels, an element succeeds in performing its function when that performance contributes to the functioning of each overarching whole on each successive level, until we reach the processes relevant to the survival of the whole human body. The body's survival then becomes the benchmark for the evaluation of the functionings of its respective elements. 7. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 22 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #YHJXXN 6. How the Body is Demarcated into Bodily Systems #WGQZDU 6.2 Critical Systems Matching excerpt #T7R9D2: Of course it is possible that, if an element several levels below the body as a whole ceases to function, then the life of the body itself could be brought to an end. Does this undercut our conception of the spatial-functional hierarchy? No; rather it forces us to take into account causal processes that relate one spatial-functional level to another. The heart is a critical element of the circulatory system; the circulatory system is a critical element of the whole body. If the heart stops, the body dies. But it is not the heart's stopping that directly causes the body to die; rather, the heart's stopping causes the circulatory system to stop functioning, which in turn is what causes the body to die. So an element on a lower spatial-functional level, separated from the body as a whole by several other levels, does not directly cause the body to stop working. It does so only by means of intermediate causal links. A spatial-functional hierarchy accounts for these links. 8. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 14 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #W88WGC 3. Defining 'System' #JHMTY4 3.8 The Body as Spatial-Functional Hierarchy Matching excerpt #77LY9W: We also take over from [25] the idea of a spatial-functional hierarchy, which, in contrast to the FMA, supports an assay of the body's anatomical structures in tandem with an assay of the corresponding functions. The spatial side of this hierarchy taxonomizes the body's anatomy according to a modular structure (i.e. in terms of what is element of what). The functional side of the hierarchy taxonomizes the body according to which functional processes cause, or enable, which other functional processes to occur. Fusing a spatial taxonomy with a functional taxonomy yields a spatial-functional hierarchy. Approximate matches 1. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 12 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #W88WGC 3. Defining 'System' #LWLW7G 3.7 Functions in Bodily Systems #J4EPE3 SPAN Score: 0.03 Related excerpt #PWEAM4: This bipartite formula can be applied iteratively as well as recursively. It can be applied iteratively to all the parts of a functional unit that belong to the same spatial-functional level, and it can be repeated recursively, as the element on level (b) is in the next cycle turned into the overarching whole on level (a). Examples are: 2. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 25 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #JPXCVX References Score: 0.028 Related excerpt #XKW6N3: [27] Smith B, Varzi A. Fiat Objects. N Guarino, L Vieu and S Pribbenow (eds.), Parts and Wholes: Conceptual Part-Whole Relations and Formal Mereology , 11th European Conference on Artificial Intelligence, Amsterdam, 8 August 1994, Amsterdam: European Coordinating Committee for Artificial Intelligence, 1994, 15-23. 3. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 14 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #W88WGC 3. Defining 'System' #JHMTY4 3.8 The Body as Spatial-Functional Hierarchy Score: 0.028 Related excerpt #77LY9W: We also take over from [25] the idea of a spatial-functional hierarchy, which, in contrast to the FMA, supports an assay of the body's anatomical structures in tandem with an assay of the corresponding functions. The spatial side of this hierarchy taxonomizes the body's anatomy according to a modular structure (i.e. in terms of what is element of what). The functional side of the hierarchy taxonomizes the body according to which functional processes cause, or enable, which other functional processes to occur. Fusing a spatial taxonomy with a functional taxonomy yields a spatial-functional hierarchy. 4. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 19 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #EU2W22 5. Elements, Functions, and Criticality #P8ECVR 5.4 Critical Functions and the Spatial-Functional Hierarchy Score: 0.027 Related excerpt #8R4VKG: Recall that the spatial-functional hierarchy is organized on the basis of two features of the body: its complex anatomical structure, and the functions that are realized through the processes that this structure allows for. Elements on lower levels are parts of elements on higher levels, and, correspondingly, their functioning contributes to the functioning of the elements on these higher levels. 5. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 11 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #W88WGC 3. Defining 'System' #LWLW7G 3.7 Functions in Bodily Systems Score: 0.026 Related excerpt #QGJKCL: A multi-leveled hierarchy of granular partitions is needed if we are to highlight the human body’s systems and their elements on successive levels. Each element is distinguished by a specific structure that allows for it to engender specific physiological processes. In the everyday language of the life sciences, this element is said to have a function . A function, like an element, is a SNAP entity or endurant. 6. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 13 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #W88WGC 3. Defining 'System' #JHMTY4 3.8 The Body as Spatial-Functional Hierarchy Score: 0.025 Related excerpt #L7X8QD: We have now arrived at a picture of the body as a complex modular hierarchy that is at once spatial and functional. The heart, for example, is at once a part of the circulatory system and an element in that system. As a part, it is a mereological component of a physical structure visible exclusively in a SNAP ontology such as the FMA. As an element, it has a function that is realized in processes, and therefore it requires for its demarcation also reference to a SPAN ontology. 7. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 13 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #W88WGC 3. Defining 'System' #JHMTY4 3.8 The Body as Spatial-Functional Hierarchy Score: 0.025 Related excerpt #XYK3M5: On the spatial-functional hierarchy here defended, the circulatory system is at the top level, the heart is located at the next level down, and its elements – ventricles, atria, valves, and so on – at the next level thereafter. Each of the latter bears a function in relation to the higher-level functioning of the heart. The circulatory system itself is an element of the human body taken as a whole. 8. Source: Bodily Systems and the Spatial-Functional Structure of the Human Body (#3CCZ4A), Barry Smith, Igor Papakin, Katherine Munn, p. 11 Context: #XDQMN2 Bodily Systems and the Spatial-Functional Structure of the Human Body #W88WGC 3. Defining 'System' #LWLW7G 3.7 Functions in Bodily Systems Score: 0.023 Related excerpt #SRYLVT: A system is characterized simultaneously by a complex modular structure , which is a SNAP entity, and by a multi-leveled family of associated processes , which are SPAN entities. The processes occur as they do because the body is structured in such a way as to sustain a complex modular hierarchy of functions . ### 16. Tool result: search_text Exact matches 1. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 23 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #4NQATC 5 Trans-Ontology in BFO #854NA2 SNAP-SPAN Trans-ontology Matching excerpt #MKLFMV: There is finally a crucial form of trans-ontological relation between spatial and spatiotemporal regions. Instants of time delineate a cross-section of space-time which is super-imposable on space as apprehended by the corresponding SNAP ontology. The relation between the two is then not one of identity – no continuant is identical with any occurrent – but rather a sui generis relation of superposition. Space in other words is not a mere temporal slice of spacetime . We will come back to this in the following section. 2. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 25 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #BS2RJT 6.1 Georegions and Geo-Ontologies #PKYEV9 Geospatial Regions. Matching excerpt #YEMULU: Since the relation between a substance and its (maximal, and therefore unique) surface is functional, we use the functional expression surface in order to denote a substance's surface. The entity surface(earth) is a SNAP substantial entity existentially dependent upon earth , and it has a specific spatial location at any given time. We may now define surface geospatial regions as spatial locations of parts of the surface of the Earth: 3. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 14 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #CAHEN5 3.3 SNAP Dependent Entities Matching excerpt #LQQKR6: The redness of the ball inheres in the ball; the elevation of a summit inheres in the summit; the shape of a landform inheres in the landform. Inherence is a form of existential dependence (Husserl, 1913/21; Simons, 1987; Smith, 1997). The latter is such that the first of its relata (in the case of inherence , the SNAP dependent entity) exists only in virtue of the existence of the second (the bearer). There are other forms of dependence relations (e.g., between processes and their participants). Thus dependence alone does not suffice for the relation of inherence to obtain, though we will not pursue this matter here. Inherence is also a form of spatial subsumption, i.e., the spatial location of the inhering entity is a part of its bearer's: 4. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 29 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #DUUBT3 6.5 The SNAP Geographical Fields Ontology Matching excerpt #3N894U: Work on the ontology of geography has recognized two distinct perspectives, called the object and field perspectives, respectively (Couclelis, 1992; Peuquet et al. , 1999; Galton, 2001; Smith and Mark, 2003). The object-perspective is precisely the SNAP geographical framework presented here. The field-perspective involves apprehending reality in terms of distributions of attributes such as temperature, population density or tree-coverage over a given spatial location. SNAP Fields are enduring entities which are located at or defined in terms of geospatial regions with which they coincide spatially. Field attributes are dependent SNAP entities which are associated with given locations at given times. 5. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 30 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #DUUBT3 6.5 The SNAP Geographical Fields Ontology #UMMP8H Relations in SNAP Field Ontologies. Matching excerpt #W2G9QC: Fields are related to their attributes in a way that is analogous to the inference relation between SNAP dependent entities and the substantial entities which are their bearers. Attributes in a field are necessarily bound to a given part of the field, and thus to a given spatial location. We use the relation of attribution between an attribute in a field and the corresponding field location, abbreviated in the symbol ‘AttributedTo’. The SNAP field and object perspectives are then linked as follows. Whenever a is attributed to b in a SNAP field ontology and b is located at the position c , there is, in some SNAP object ontology (SnapObj \Omega ), a substance located at c in which a' , a proxy of a , inheres. For instance, there is a portion of the elevation field of the Earth corresponding to Mont Blanc. 6. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 25 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #BS2RJT 6.1 Georegions and Geo-Ontologies #PKYEV9 Geospatial Regions. Matching excerpt #BVG8VK: This implies that there is a further sort of spatial reasoning in the geographical context, relating to the way geographical entities are located with respect to surface(earth) . This is the type of reasoning we employ when working with two-dimensional maps. The functional relation SurfaceLocation relates a spatial entity to its corresponding surface location. (This is in fact a ternary relation between a SNAP entity, a spatial region and a substance acting as a reference body. Here, however, we can leave the third term out of account, since we assume in all geographical contexts that the relevant reference body is the Earth.) The surface location of a geographical entity is that portion of the location of the Earth's surface onto which the spatial location of the entity projects along the vertical axis at a given time. 7. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 11 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #UQH4XU 3.1 Spatial Regions Matching excerpt #B8QPLB: SpatialLocation is a functional predicate. We can denote the spatial location of an entity a in an ontology \omega via the expression ' spatial-location ( a, \omega )'. 8. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 11 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #UQH4XU 3.1 Spatial Regions Matching excerpt #W3VRVA: Spatial regions can serve as locations for SNAP entities. To this end, we introduce a new primitive relation of spatial location, symbolized: 'SpatialLocation' (it corresponds to the notion of exact location in (Casati and Varzi, 1996)). Approximate matches 1. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 3 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #K6SSVN 1 Philosophical Background #PYHEWY Spatiotemporal Ontologies in BFO Score: 0.03 Related excerpt #FMX8ZQ: Continuants and occurents exist in time in different ways. The challenge is to build a unified framework within which we can do justice to both of these modes of being equally. This framework needs to keep the two corresponding groups of entities clearly separate, since no single inventory can embrace them both. At the same time however we have to find a way of bringing them together: continuants are themselves subject to constant change; occurents depend on continuant objects as their bearers. In particular, there is an important correspondence between continuants and those special types of occurents which are their lives . 2. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 22 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #4NQATC 5 Trans-Ontology in BFO #854NA2 SNAP-SPAN Trans-ontology Score: 0.029 Related excerpt #EG4A6W: A participant in a process exists during a time which overlaps the temporal location of the process. We then have: 3. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 16 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #35MC29 4 SPAN Score: 0.028 Related excerpt #8KKMCY: Occurrences are structured also along the spatial dimension; however, the real substrate for location here is no longer space but rather spacetime , which is itself a SPAN entity. SPAN entities are not located in space – the assumption that they are so located derived from the fact that each region of space may be put in correspondence with a particular portion of an instantaneous slice of spacetime. SPAN ontologies comprehend spatiotemporally extended regions and the occursents (including changes, as entities in their own right) located at such regions. 4. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 3 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #K6SSVN 1 Philosophical Background #DK4RJ9 Temporal Modes of Being Score: 0.027 Related excerpt #JPD4N9: Occurents are all bound in time in the way described by Zemach (1970). This means that each portion of the time during which an occurrent occurs can be associated with a corresponding temporal portion of the occurrent. This is because occurents exist only in their successive temporal parts or phases. Some occurents – for example beginnings and endings (the initial and terminal boundaries of processes) – are instantaneous. 5. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 19 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #35MC29 4 SPAN #WWCQX4 4.4 Spatiotemporal Regions Score: 0.027 Related excerpt #AMXB9Z: As in the spatial and temporal cases, a number of spatiotemporal relations hold between processuals, including those which hold in virtue of the relations between the regions of spacetime at which they are located. Thus there are mereological and mereotopological relations as well as relations of co-incidence or locational overlap which obtain when two entities occupy the same spatiotemporal region or when their respective spatiotemporal regions share a part. 6. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 18 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #35MC29 4 SPAN #QLNXDB 4.3 Temporal Regions Score: 0.026 Related excerpt #22JVJZ: We may thus introduce a temporal-location function analogous to spatial-location introduced earlier, though without an ontology as an argument. Processual entities do not change their locations in time in the way in which substantial entities may change their locations in space. 7. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 22 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #4NQATC 5 Trans-Ontology in BFO #854NA2 SNAP-SPAN Trans-ontology Score: 0.024 Related excerpt #CATCDR: There is a family of other trans-ontological relations between SNAP and SPAN entities, of which not only participation but also initiation , termination , creation , destruction , sustenance , deterioration , facilitation , hindrance are examples (for details, see Grenon, 2003; Smith and Grenon, 2003). Here, we describe the basic intuitions of the framework, taking as prototypical the example of participation . 8. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 13 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #LGE6EY 3.2 Substantial Entities Score: 0.023 Related excerpt #7Z4URQ: As substances are located in space (at spatial regions), so also are the sites associated with them. But substantial entities also occupy sites or parts of sites., so that we have a three-term relation between substantial entities, sites and spatial regions. Occupies itself is a two-term relation between a substantial entity and a site. It is definable in terms of the notions of location and internal part (Smith and Varzi, 1999). For present purposes it is sufficient to point that in any ontology in which a case of the occupies relation obtains, i) the substantial entity and site which are joined by this relation do not overlap and neither do their respective locations; ii) the substantial entity's location is an internal part of the location of the sum of this entity with the site which it occupies. ### 17. Assistant tool calls #### Tool call: `read` ```json { "blocks": [ "https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content", "https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9lbmdpbmUtYXRsYXMubWQ#content" ] } ``` ### 18. Tool result: read SOURCE FILE Path: ideas/structure-of-space.md Resource: /3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content Size: 24239 bytes, 620 lines # The structure of space *Notes toward a cellular tissue for places, construction, and memory.* ## The proposition Moppe's landscape is currently represented with great success as fields: height at a position, water over rock, slope, drainage, material, and the successive results of terrain transformations. This is the right language for geology at landscape scale. It is not by itself the right language for everything that may later inhabit the land. Paths, crossings, rooms, courtyards, bridges, property, construction stages, names, and remembered events want discrete identity. They want adjacency, containment, boundaries, and persistence. They want to say *this place*, *this edge*, and *these neighbors*, even while their physical realization remains smooth and irregular. The proposed middle layer is a **draped cellular tissue**: a mostly quadrilateral, locally rhythmic, irregular two-dimensional cell complex embedded in the smooth terrain. It exists lightly across the world and grows sparse three-dimensional cellular structure where construction takes hold. The terrain remains continuous where continuity matters. The tissue becomes discrete where composition matters. This is not the claim that space is ultimately made of cells. The tissue is a provisional interpretation of differentiated space and a constructive measure laid into it. Its concise constitution is: > Space is not made of cells. The cellular tissue gives making a meter. ## Two views of space Ordinary game geometry begins with a neutral carrier: ```text world space = coordinates object = transform + geometry ``` Every empty location is equivalent until a field or object assigns it a property. This abstraction is indispensable. Rendering, physics, terrain evaluation, distance, erosion, and vehicle trajectories all require a stable metric space. Moppe's periodic heightfield and its universal cover are exact and useful laws of the world. They are not an exhaustive account of inhabited space. An articulated space also contains: - regions with different intensities of coherence; - relations of approach, enclosure, support, and visibility; - thresholds, bottlenecks, crossings, and seams; - larger and smaller centers which overlap and contain one another; - several geometries of movement for several kinds of body; - histories through which use and construction acquire meaning. A saddle is not merely a low point on a ridge. It joins two valleys and separates two summits. A headland helps enclose a harbor. A crest and a descending face can form one flight. A quiet opening among several paths can become a place to wait. These structures are partly metric, but they are not captured by coordinates alone. Moppe can therefore retain two simultaneous truths: ```text carrier space continuous coordinates, terrain, water, distance, velocity articulated space centers, cells, boundaries, support, approach, use, history ``` The cellular tissue mediates between them. It gives articulated space enough discrete form to be inspected, remembered, and changed while staying embedded in continuous land. ## Centers before objects In an object-first world, a bridge object is placed and connectivity is derived from it. In an Alexandrian account, the crossing may be present as a latent center before a bridge exists. Two routes approach opposite banks. The river narrows. Foundations are stable. People can see the far side. Traffic repeatedly converges and perhaps already uses a ford. Several spatial structures support the same relation: ```text place A <- latent crossing -> place B ``` The bridge does not originate this linkage. It recognizes, strengthens, and materializes it. Once built, it differentiates the crossing into further centers: abutments, span, midpoint, space beneath, framed river view, approaches, waiting places, and bridgeheads. An inn, shrine, market, or town may later intensify the same center at other scales. The same account applies elsewhere: - a path makes an already viable line durable; - a temple gives material form to a place of attention; - a monument fixes an event into public memory; - a harbor articulates the seam between land and water movement; - a town condenses where several movement systems repeatedly meet; - a jump develops a latent relation among approach, takeoff, flight, landing, and continuation. Buildings should not create places from nothing. They should give material form to spatial structures which have begun to exist. ## What cells mean The tissue is not merely an efficient construction grid. Its elements are hypotheses about the current structure of space. A face says: > For now, this region behaves coherently enough to be treated as one place. An edge says: > Something changes, separates, joins, or passes here. A vertex says: > Several spatial relations meet here. A subdivision says: > This place has acquired enough internal structure to become several more > definite places. A group of cells says: > These regions participate in a larger center. A vertical sprout says: > This center has become materially articulated and inhabitable. Cells need not be visible. They are stable addresses for relationship and history. A road may flow smoothly through a sequence of cells. A forest may use cells only for ecological state while individual trees remain continuously placed. A river may cross cell boundaries according to its own heightfield law. The tissue is a shared substrate, not a universal visual style. ## Two complementary algebras The terrain system is a field algebra: ```text position -> value ``` It is good at height, uplift, moisture, temperature, material suitability, continuous masks, and gradients. The tissue suggests a place algebra: ```text cell + neighbors + history -> structured possibility ``` It is good at occupancy, adjacency, routes, districts, ownership, construction, typed relationships, and persistent events. Fields inform cells: ```text cell slope <- sample the slope field cell moisture <- integrate the moisture field cell material <- classify geological fields cell buildability <- interpret several local readings ``` Cells can later propose explicit transforms back into fields: ```text road cells -> cut-and-fill corridor canal edges -> incision and water routing foundation cells -> local grading and retaining garden cells -> soil and vegetation change ``` Neither representation should swallow the other. A reading remains a reading; a change to terrain remains an explicit transform. ## Why rough quadrilaterals Perfect square grids make composition tractable but impose a global axis and visible repetition. Regular hexagons distribute neighbors evenly but tend to produce sixty-degree path habits and awkward building footprints. Arbitrary polygons adapt freely but make every conjunction special. Roughly rectangular cells occupy a fruitful middle. Rooms, walls, roofs, and neighboring buildings benefit from approximate right angles. They fit, furnish, subdivide, and extend without leaving thin wedge-shaped remainders. Yet exact orthogonality is unnecessary and often hostile to land, use, and existing centers. A useful tissue would prefer: - mostly four-sided cells; - angles broadly near right angles, not exactly ninety degrees; - moderate local aspect ratios; - variable scale; - no thin slivers or unusable exterior remnants; - no globally privileged north-south axis; - boundaries that may follow landforms and existing centers; - occasional triangles, pentagons, or junction cells where the whole genuinely calls for them. The irregularity is not noise applied to a grid. It is the accommodation by which the measure belongs to its site. ## Meter, not ontology The constructive value of the tissue is analogous to rhythm in typography and music. A typographic baseline grid does not claim that language consists of horizontal lines. It lets headings, paragraphs, captions, lists, and images participate in one vertical rhythm. Musical meter does not require a strict metronome. It creates shared temporal expectations within which phrases can stretch, accents can move, and syncopation can become meaningful. Minecraft succeeds in part because every act inherits a spatial beat. One block, two blocks, and three blocks immediately become comprehensible measures. Openings align. Repetitions can be counted by eye. Several people can extend, repair, or vary one another's work without manipulating splines, control points, or specialist modeling tools. The result may be cubic, but the act of composition is unusually tractable. Terminal interfaces and monospace technical documents gain a related integrity from shared cells, baselines, columns, indentation, and a small vocabulary of separators. Ordinary HTML supplies much more continuous freedom and therefore no automatic rhythm; good web design must reconstruct a spacing scale, type scale, baseline, columns, and component proportions. Moppe can retain the compositional help without retaining literal cubes. The player can perform cell-like acts while contextual rules deform and articulate them into irregular geometry. The lattice makes alignment, repetition, and cooperation easy. Its exceptions then acquire meaning. A larger central bridge arch matters because the other bays establish a rhythm. A ceremonial approach matters because ordinary streets follow the land. A tower matters because normal buildings share a comprehensible height scale. Without expectation, deviation is merely noise. With expectation, roughness becomes life. ## A fluid local tempo The tissue should not repeat one module everywhere. It is better understood as a spatial tempo map with a local scale, direction, and degree of regularity. Conceptually, continuous fields might guide it: ```text target cell size s(x) preferred direction theta(x) directional stretch A(x) desired detail d(x) ``` On a broad plain the rhythm may be slow and calm. Along a valley, cells may stretch with the land. Around a shore or junction, the rhythm may tighten. At a settlement it becomes finer and more articulated. Around a temple it may acquire local symmetry and ceremonial measure. This rhythm should be hierarchical: ```text small unit stone, timber bay, step, opening room unit inhabitable cell building unit group of rooms and courts street unit facades, crossings, public space district unit routes and major centers ``` These are spatial counterparts to subdivisions, beats, bars, and phrases. Their ratios need not be exact, but they should remain perceptibly related. Different regions can develop different meters according to material, terrain, climate, craft, and history. This is vernacular as an inherited constructive rhythm rather than a catalogue of visual styles. ## An induced and adaptive tissue The tissue should not be a neutral overlay generated once and mistaken for the world. It may begin from a coarse periodic seed mesh because computation must begin somewhere, but its meaningful form should be induced by what the world contains. Relaxation and later adaptation can respond to: - ridges and watershed divides; - channels, shores, and flood surfaces; - benches, saddles, and stable construction ground; - movement corridors and repeated traces; - existing centers and construction; - the boundaries of positive outdoor spaces; - local demand for finer articulation. Edges may migrate toward meaningful boundaries. Important crossings may become vertices or short edge chains. Cells may subdivide where a place becomes important and remain coarse where the land is quiet. This makes remeshing a semantic operation. When one cell becomes several, names, traffic, events, ecology, ownership, and center relationships must be transferred deliberately. It should feel like one place becoming several more definite places, not like data being regenerated. The initial mesh is scaffolding. Adaptation gives it meaning. ## Sparse vertical growth A full voxel world would make construction simple but would fight the smooth landscape, burden the terrain scale with empty air cells, and make the visual language unnecessarily cubic. Instead, the two-dimensional tissue exists everywhere and three-dimensional cellular structure sprouts only where required. A surface cell can acquire a vertical stack: ```text surface cell -> foundation -> occupied floor cells -> walls and openings -> roof cells -> attachments and ornament ``` A group of surface cells can seed a building complex containing rooms, courtyards, arcades, stairs, towers, and roofs. A bridge anchors to cells on both banks and grows an elevated chain between them. A retaining wall articulates an edge between differently fitted surface cells. Uninhabited country remains a light surface complex. Occupation causes the world to differentiate vertically. ## Deformed modules The interaction can remain block-like while the result remains irregular. The player or simulation makes simple gestures: - select this cell; - continue from this edge; - raise this group one level; - enclose these cells; - open this wall; - support this span; - strengthen this boundary. The construction system maps a curated vocabulary of components into the irregular cells. At its simplest, a unit-square module can be mapped into a convex quadrilateral by bilinear interpolation among its corners. More careful component rules preserve what should not deform: straight timber, wall thickness, column section, roof pitch, arch thrust, and material size. Different materials absorb irregularity differently. Rough stone tolerates shape variation. Timber imposes straight members and repeated bays. Brick prefers another module. Trim, infill, and craft resolve small mismatches. These constraints create vernacular character from construction rather than from decorative skin. Townscaper demonstrates the humane division of labor: the person controls mass, void, adjacency, height, and color; contextual rules articulate roofs, arches, stairs, supports, gardens, and small life. Moppe's version must also listen to terrain, water, movement, material, and history. The player indicates and judges. The system fits and differentiates. ## A bridge as the complete example A bridge exercises nearly every part of the proposal. 1. Routes and mover geometries reveal demand for a crossing. 2. Hydrology supplies water depth, flood behavior, and channel structure. 3. Banks and geology supply candidate abutments and foundations. 4. Surface cells give stable identities to the approaches and crossing. 5. A smooth macro curve establishes alignment and elevation. 6. The curve is divided into structural bays according to the local meter. 7. Bays become deformed construction cells and select vernacular modules. 8. Piers, arches, beams, rails, stairs, and abutments adapt to local facts. 9. Terrain transforms fit the approaches while preserving the surrounding drainage and landform. 10. Use, repair, flood, and later additions continue the bridge's history. The scales divide responsibility cleanly: ```text spline says where the bridge goes cells say how the span is composed modules articulate local relationships history says what the bridge becomes ``` The bridge may begin as stepping stones, a ferry, or a timber span. Later stonework can retain the old ford, repaired footings, flood marks, a shrine to safe passage, or a desire path beneath an arch. Construction becomes geological in its own way: buildings are strata. ## Positive space and settlement Object placement optimizes buildings and inherits whatever space remains between them. A cellular construction language can shape occupied and unoccupied space together. - a loop of built cells creates a courtyard; - a widened route creates a square; - two offset buildings make a gateway; - an arcade mediates between interior cells and a public route; - a bridgehead leaves a place to wait; - a temple enclosure creates a calm void; - a row of houses strengthens the street they face. The empty cell is not missing content. It may be the strongest center in the composition. Towns should likewise precipitate rather than spawn. A ford becomes a bridge; the crossing acquires a keeper, shelter, stable, workshop, market, houses, shrine, and secondary paths. The main street remembers the trail. The square remembers the widened junction. The temple addresses the center which caused the settlement to exist. The cell tissue gives this incremental history stable units without forcing the final town onto a perfect grid. ## Several effective geometries The continuous carrier supports more than one articulated space. For a pedestrian, a shallow ford may join two banks. For a cart they remain far apart. For a boat the river is a route, not a barrier. For the motorcycle the same gap may be a jump. Visual space, drainage space, and ritual space have still other adjacencies. ```text walking space cart space water space motorcycle space visual space drainage space ``` Infrastructure is powerful because it changes several of these spaces at once. A bridge shortens terrestrial routes, affects water, frames a view, creates shelter, and may become a stunt line. A strong center often condenses several geometries into one place. The tissue should therefore preserve typed relationships rather than reduce every adjacency immediately to one universal distance. ## A world which remembers Cells and edges provide stable addresses for histories which fields alone do not naturally hold: - passages in each direction; - braking, wheelspin, takeoffs, and landings; - dwell time and repeated stopping; - construction, repair, damage, and abandonment; - flooding, erosion, and vegetation succession; - names, ownership, stewardship, and events; - membership in overlapping centers. A desire path can emerge as a flow across edges while its visible trace stays smooth. When the flow stabilizes, the world recognizes a route corridor. When several routes meet repeatedly, their shared cells can become a center. Construction then has somewhere meaningful to take hold. The tissue is interpretive, constructive, and historical at once. ## Interaction as soft measure The player need not see or obey a hard grid. - a wall gently aligns with nearby edges; - a bridge prefers comprehensible bay spacing; - a room settles toward a good rough rectangle; - a path width tends toward the local module; - courtyard boundaries negotiate with their neighbors; - a deliberate gesture can break the suggestion when the exception matters. This is soft spatial quantization. The player supplies gesture, the local meter supplies measure, and the existing whole supplies correction. The tissue can appear when useful as a planning overlay, a temporary construction scaffold, a land-use reading, or a visualization of centers. In ordinary play it should usually disappear into the world it helped make. ## The torus The base tissue must be as honest about topology as the terrain. Opposite boundaries of the fundamental square are the same neighborhood. Initial generation, relaxation, adjacency, pathfinding, centers, and later remeshing must all respect that identification. A periodic irregular tissue would remove the last temptation to treat the world edge as an exceptional construction boundary. Roads, districts, and settlements can cross the seam because the cells themselves do. The flat torus remains the metric law. The articulated tissue grows within it and may acquire winding centers and routes of its own. ## Possible values Names and boundaries remain speculative, but the eventual code might need plain values resembling: ```text SurfaceTissue vertices, edges, cells, topology, embedding SurfaceCell terrain reading, ecology, traffic, construction, history SurfaceEdge boundary kind, route flux, intercepted water, crossing SpatialCenter weighted region, contained centers, typed supports ConstructionComplex foundations, levels, walls, openings, roofs, attachments ``` These should not be forced into `TerrainProgram`. The terrain program says how rock and water were produced. The tissue interprets a materialized world and carries later inhabitation. Explicit transforms mediate whenever construction changes terrain. As always, values should be serializable, diffable, inspectable, and subject to deterministic replay within their declared evaluator. ## First proofs The first implementation should prove the representation before attempting a town generator. 1. Generate one deterministic periodic irregular-quad tissue over a finished terrain. 2. Drape it onto the heightfield and display it faintly in Terrain Lab. 3. Compare a flat topological view with its sloping world embedding. 4. Let cell scale and orientation respond mildly to shores, drainage, ridges, and slope. 5. Select cells and inspect their terrain readings and neighbors. 6. Express a smooth route corridor through a cell sequence without making the route look cellular. 7. Represent one lake, saddle, and approach as overlapping supported centers. 8. Sprout a few simple plaster or clay masses from chosen cells. 9. Generate one terrain-fitted bridge or shrine from a blessed center. 10. Ride the result and judge whether the tissue helped it belong. Before procedural architecture, the first visual proof is simply a beautiful mesh: calm on broad slopes, more articulate around water and crossings, roughly rectangular without a global axis, and continuous across the torus. If a few extruded cells already appear to belong to the landscape, the representation is alive enough to continue. ## Guardrails - The tissue is not the ontology of space; it is a changing interpretation. - Cells are semantic addresses, not compulsory visible tiles. - Metric physics and smooth terrain remain authoritative where appropriate. - Adaptation should follow centers, not add decorative irregularity. - Calm regularity is necessary for meaningful exceptions. - Remeshing must preserve identity and history explicitly. - Readings precede mutations; construction edits terrain only through named transforms. - A global score never replaces pairwise judgment in the actual place. - New architecture should strengthen existing centers and help form larger wholes. - The system must leave room for unbuilt land and inner calm. ## The larger picture The proposal fills a missing middle in Moppe's language: ```text fields make land cells make places actionable construction makes centers visible use and memory make them irreplaceable ``` The smooth heightfield is the world's continuous body. The cellular tissue is the locally adapted rhythm through which the world recognizes places, coordinates acts separated by people and time, and learns how to build. The bridge is not an asset placed into empty coordinates. It is space becoming conscious of its own crossing. ## Further reading and play - Christopher Alexander, *The Nature of Order*, especially Books 1 and 2 on centers, wholeness, and structure-preserving transformations. - Christopher Alexander, [Harmony-Seeking Computations](https://www.cs.york.ac.uk/nature/workshop/papers/Harmony-Seeking_Computation.pdf), for value-aware transformation of an existing whole. - Bin Jiang, [Geography Founded on the Third View of Space](https://arxiv.org/abs/2108.02493), for the contrast among absolute, relational, and organismic space. - Oskar Stalberg, [Organic Towns from Square Tiles](https://compaec.github.io/news/2020/06/29/StalbergTalk.html), and Tommy Thompson, [How Townscaper Works](https://www.gamedeveloper.com/game-platforms/how-townscaper-works-a-story-four-games-in-the-making). - Boris the Brave, [Townscaper Grid](https://www.boristhebrave.com/docs/sylves/1/articles/tutorials/townscaper.html) and [Editable WFC](https://www.boristhebrave.com/2022/04/25/editable-wfc/), for practical irregular grids and local contextual regeneration. SOURCE FILE Path: docs/engine-atlas.md Resource: /3CV92Z/source-files/ZG9jcy9lbmdpbmUtYXRsYXMubWQ#content Size: 12439 bytes, 222 lines # Moppe engine atlas This is the reader's map of the current engine after RFC-0001. It names the values that make up a world, the mutable state that rides it, the immutable reading that presents a frame, and the CMake targets that carry those boundaries. Read it before the detailed subsystem documents; the `current-engine-refactoring` track is retained as the history of how this shape was reached, not as the architecture reference. ## One world, one frame The main flow is data and borrows, not a generic scene graph or an ownership diagram for CMake: ```mermaid flowchart LR recipe["WorldRecipe"] --> build["direct world construction"] build --> world["GeneratedWorld"] world --> session["GameSession"] world --> view["FrameView"] session --> view view --> scene["world, actor, water, effect, HUD presentation"] scene --> renderer["render::Renderer"] renderer --> metal["Metal backend"] renderer --> webgpu["WebGPU backend"] app["application: loading, input, mode selection"] --> build app --> session app --> view ``` `GeneratedWorld` is the stable owner of one completed landscape. `GameSession` is the mutable life played on that landscape. `FrameView` is a new immutable reading composed for each visible frame; it does not own a renderer, a platform object, or mutable actor state. The application selects input and mode, advances the session, composes the view, and invokes the concrete presenters in game-shaped order. ## Domains and ownership | Domain | Owns | Does not own | Main locations | | --- | --- | --- | --- | | Quantity and finite-section vocabulary | `spatial::Bundle`, typed domains, and mp-units-facing section types | A terrain map, a world, or a rendering policy | `moppe/spatial/`, `moppe/quantities.hh` | | Terrain algorithms | Geology, evolution, trails, hydrology, and their typed products | A completed map, scene, platform, or renderer | `moppe/terrain/` | | Completed world | Heightmap, surface, materialized analyses, water surface, and trails | Mutable player state, GPU resources, or an event loop | `moppe/map/`, `moppe/game/generated_world.*` | | Simulation | Mutable rider, vehicle, glider, walker, camera, stars, dust, and checkpoint state | Loading, `GeneratedWorld` ownership, and platform effects | `moppe/mov/`, `moppe/game/game_session.*` | | Frame and scene presentation | Immutable frame readings and focused terrain, water, actor, effect, and HUD presenters | Simulation mutation or an OS event loop | `moppe/game/frame_view.*`, game presentation files | | Application and platform | Loading/activation, input adaptation, mode selection, host services, and terminal `main` | Portable terrain and simulation laws | `moppe/game/world_loading.*`, `moppe/game/game.cc`, `moppe/game/terrain.*`, `moppe/platform/` | | Renderer and backend | Game-shaped draw/resource API, Metal resources, passes, command submission, and capture/timing lifecycle | Terrain policy, session state, or a generic render graph | `moppe/render/`, `moppe/render/metal/`, `moppe/shaders/metal/` | `moppe/game/` is intentionally not one architectural layer. Its source files belong to world construction, simulation, scene presentation, or application composition according to what they own. The CMake targets below make that division executable. ## World and intrinsic readings `terrain::WorldRecipe` binds seed and algorithm values to physical world parameters and water datum. World loading directly initializes, evolves, and forms trails on `map::Surface`, then analyzes hydrology and derives later surface readings. Once active, ordinary gameplay receives const views of the completed world. `map::SurfaceDomain` is the one finite lattice for the ground. It owns the topology, site correspondence, spacing, and reconstruction stencil. Its `SurfaceAtlas` groups typed 0-cochains by the named materialization boundary: | Group | Typed sections | Valid when | | --- | --- | --- | | Geometry | `surface_elevation`, `terrain_normal`, removed/deposited material, `snow_support` | Elevation/history exist at construction; normals/support after `rebuild_geometry_readings()` | | Hydrology | `channel_flux`, `surface_moisture`, `waterline_distance` | World hydrology/materialization | | Geology | `erosion_exposure`, `deposition_cover` | Geological materialization | | Ecology | `tree_habitat`, `forest_cover` | Ecological materialization | | Use | `trail_influence`, `home_base_influence` | Completed trail-use analysis | Geometry is authoritative and always present. Later groups are individually optional: absence means the corresponding world-building barrier has not run, while a present all-zero section is a real reading. `map::WaterSurface` uses the same domain but a distinct water bundle: `surface_elevation`, `wave_amplitude`, and `water_velocity`. It is not a ground-atlas group merely because both surfaces have matching texture dimensions. `GeneratedWorld::Hydrology` is similarly a complete analytical value rather than a collection of app-level optionals. It contains standing water, lake census, drainage, fractional channels, waterways, and the river network. `WaterSurface` and `TrailNetwork` use optional storage to express their construction boundary and to support focused tests. Ordinary completed worlds build both. The detailed vocabulary, validity rules, and quantity-to-texture mappings live in [Surface atlas](surface-atlas.md). ## State, lifetime, and handoff | Value or phase | Owner and rule | Deliberately outside it | | --- | --- | --- | | `WorldRecipe` and `WorldParams` | Immutable construction description for a world | Live player progress and renderer history | | `GeneratedWorld` | Non-copyable, non-movable owner of completed terrain and analyses | Platform, session, and GPU ownership | | Loading candidate | Worker builds a fresh world; the loading screen sees status text only | Mutation of the active world/session | | Activation | Main thread transfers the completed owner once, retires the old session before its old world, then creates a fresh session | A half-built visible world | | `GameSession` | Mutable run against one completed world's terrain and surface borrows | A replacement world or loading lifecycle | | `GameState` | Copyable snapshot of mutable session systems, portable only between sessions on the same world | Terrain, water, renderer history, window state, and asynchronous loading | | `FrameView` | Immutable per-frame snapshot of selected camera, lighting, graphics, poses, HUD, overlays, and visibility | Renderer/platform types and later simulation mutation | The ordinary playable step is `advance_game_session(context, session, input, seconds_t)`. Its context lends only the world-side readings simulation needs. Platform-side speech and other application effects return as a small result for the application to realize. The full checkpoint and replay boundary is described in [Game state and replay](game-state.md); completed-world construction and handoff are described in [Generated worlds](generated-world.md). ## Presentation and renderer boundaries Presentation turns completed-world and frame readings into the renderer's game-shaped API without pushing numeric packing or platform work down into the terrain/simulation layers. | Input | Presentation owner | Renderer-facing result | | --- | --- | --- | | Typed ground atlas and trails | `game::SurfacePresentation` | Terrain material/path texture lanes | | Typed water bundle plus water datum/extent | `game::WaterPresentation` | Numeric ocean setup and water texture lanes | | Completed-world river network | `game::RiverSurface` | Curved river ribbon mesh/data | | `FrameView`, world, and session readings | Focused world, actor, water, effect, and HUD routines | Retained resources and `DrawList` commands in fixed frame order | | Renderer calls | `render::Renderer` | Backend-independent resource/pass requests | | Metal renderer state | `MetalTerrainResources`, `MetalWaterResources`, `MetalFrameTargets`, `MetalFrameEncoding` | Retained world resources, target resources, and one drawable submission | Terrain, Water, and Scene operations share one lazy scene encoder; their separate names do not imply a generic render graph or separate depth histories. The Metal facade owns drawable acquisition, command-buffer lifetime, capture, timing, and benchmark completion. See [Renderer and platform architecture] (renderer-design.md) for resource and pass detail. ## Target graph The source ownership above is reflected by these CMake targets. Arrows point from a consumer to the target it consumes. Dashed Apple edges exist only in Apple configurations; exactly one selected-platform edge is present per build. ```mermaid flowchart LR spatial["moppe_spatial"] --> units["mp-units"] terrain["moppe_terrain"] --> spatial world["moppe_world"] --> terrain simulation["moppe_simulation"] --> world simulation --> render["moppe_render"] scene["moppe_scene"] --> simulation scene --> world scene --> render scene --> botany["atelier_botany"] scene -.-> apple["moppe_apple"] app["moppe_app"] --> scene app -.-> mac["moppe_platform_mac"] app -.-> ios["moppe_platform_ios"] app -.-> web["moppe_platform_web"] metal["moppe_metal"] --> render webgpu["moppe_webgpu"] --> render terrain_metal["moppe_terrain_metal"] --> terrain mac --> metal mac --> terrain_metal mac --> apple ios --> metal ios --> apple web --> webgpu desktop["moppe"] --> app desktop --> mac phone["moppe-ios"] --> app phone --> ios browser["moppe-web"] --> app browser --> web tests["moppe-tests"] --> scene tools["terrain tools"] --> world ``` `moppe_spatial` is deliberately header-only: its types expose mp-units vocabulary but need no translation unit. `moppe_terrain` keeps reusable finite terrain and hydrology algorithms free of world, scene, and platform code. `moppe_world` adds concrete map storage, direct construction, materialization, `GeneratedWorld`, and deterministic water-capture selection. `moppe_simulation` has a real dependency on `moppe_render`: session-owned Stars retain meshes and Stars/Dust expose their presentation operations. This is an explicit current constraint, not a claim that physics needs Metal. `moppe_scene` composes the completed-world and session readings, with Apple-common asset/glyph support where available, but has no OS event loop or renderer backend. `moppe_app` holds the host-service callers (`Terrain` and `WorldLoading`); terminal programs retain `game.cc` because it defines `main` and chooses the macOS, iOS, or browser host. The ordinary desktop game consumes the app/scene path; portable tests begin at the testable scene target and do not link a desktop event loop. Terrain command-line tools consume only `moppe_world`, so they do not pull in the desktop platform merely because unrelated presentation code was compiled into a broad archive. ## Current scope and deliberate gaps This atlas describes the completed RFC-0001 slice. It does not claim that the Atelier proposals have replaced Moppe, that every run is bitwise reproducible, or that every renderer backend has visual feature parity. - Implicit elevation and chart origins remain current-engine facts; registered frame projections remain Atelier-earth work. - `GameState` makes fixed-world session replay practical, but world generation, renderer history, window state, and loading are not checkpoint state. - Metal is the full-fidelity native backend. WebGPU is the supported playable browser backend, with a deliberately lower-cost default presentation; Android remains unimplemented. - Persistent places, routes, and player traces belong to later world work, not to the completed-world/session boundary described here. ## Detailed maps - [Surface atlas](surface-atlas.md) — domains, all typed sections, validity, and presentation lanes. - [Terrain generation and analysis](terrain-expressions.md) — direct finite construction and typed analysis products. - [Generated worlds](generated-world.md) — construction capability and activation lifetime. - [Game state and replay](game-state.md) — session checkpoint and benchmark boundary. - [Refactoring seams](refactoring-seams.md) — preserved characterization and runtime smoke contracts. - [Renderer and platform architecture](renderer-design.md) — Metal resources, frame encoding, and host implementation detail. ### 19. Assistant Yes—this may be the most interesting architectural possibility latent in `ontology.md`. The terms you are reaching for are **mereology** (parts and wholes) and **mereotopology** (parts, boundaries, contact, connectedness). The important move would be to make the world not merely *data with descriptive labels*, but a **typed world whose valid structures follow ontological distinctions**. ## Not one generic containment tree Nested containment can provide the backbone, but Barry Smith’s framework suggests that a world is not adequately represented by a single scene graph: ```text world └── valley └── bridge └── wheel ``` That collapses several fundamentally different relations. Instead: ```text wheel proper_part_of bike rider mounted_on bike bike located_in valley redness inheres_in bike ride has_participant bike touchdown terminates flight bridge realizes_function crossing ``` These relations have different laws. Parthood is transitive; location usually is not. Attachment can change; constitutive parthood cannot change without damaging or transforming the whole. A quality cannot exist without its bearer. A process depends on participants but is not part of their SNAP inventory. Smith’s treatment of inherence explicitly makes a quality existentially dependent on its bearer (#LQQKR6), while SNAP/SPAN keeps continuants and occurrents distinct but connected through participation and related relations (#FMX8ZQ, #CATCDR). So the representation would be less like an ECS spreadsheet and more like a **typed, temporally evolving relation graph**, with nested wholes as one especially important family of edges. ## Dependent continuants are especially promising This gives a much richer account of “properties.” Instead of every property being an interchangeable component: - **quality** — this bridge’s current structural condition; - **disposition** — this slope’s tendency to slide when saturated; - **function** — this bridge’s function of carrying travelers; - **role** — this clearing’s temporary role as a campsite; - **realization process** — an actual crossing, landslide, or night’s occupation. A function or disposition is a *realizable dependent continuant*: it persists in a bearer even when it is not currently being exercised, and is realized through a process. That distinction could become mechanically meaningful: ```text Bridge has_part Abutment, Span, Deck bears_quality StructuralCondition bears_function CarryTraffic bears_disposition CollapseUnderExcessLoad Crossing realizes CarryTraffic has_participant Rider, Bike, Bridge ``` A damaged bridge might continue to bear its crossing function while acquiring a greater collapse disposition. That is much more expressive than toggling `bridge.enabled` or attaching arbitrary components. ## Spatial-functional nesting The bodily-systems paper offers a particularly useful model: combine a **spatial hierarchy**—what is part of what—with a **functional hierarchy**—which lower-level processes enable higher-level processes (#77LY9W). Functions are decomposed into subfunctions, whose realizations are processes composed from subprocesses (#ZCKB2J). For Moppe, this could apply equally to: ```text watershed tributary systems channels channel segments tree crown and root system branches shoots bridge crossing system approaches, supports, span structural members motorcycle propulsion and suspension systems assemblies physical parts ``` But these hierarchies may overlap. The same stream segment can be part of a drainage network, an ecological habitat, and a named river. The bodily-systems paper explicitly allows something to participate in multiple functional systems according to context (#446F78). Therefore the result should be a typed DAG or relation structure, not a rigid ownership tree. ## Moppe already has the beginnings Several existing structures can be reinterpreted as early pieces of this architecture: - `SurfaceDomain` provides locations and topology. - Typed bundle sections are dependent qualities attached to sites. - `GeneratedWorld` is a continuant inventory. - `GameSession` is the mutable life associated with that world. - `FrameView` is a granular projection of the current SNAP inventory. - Replay is a SPAN representation. - `structure-of-space.md` proposes stable cells carrying adjacency, containment, boundaries, identity, and history. - Its “place algebra” is already very close to an applied mereotopological layer. The next conceptual step is therefore not “put everything into an ontology database.” It is to identify a small **world-semantic kernel**: ```text Kinds IndependentContinuant SpecificallyDependentContinuant Quality Role Function Disposition Occurrent Process Event SpatialRegion FiatObject Relations proper_part_of inheres_in located_in occupies attached_to participates_in realizes initiates / terminates boundary_of connected_to / adjacent_to / overlaps ``` Each relation would have its own admissible endpoint kinds, invariants, and temporal behavior. The type system could enforce the static portion; constructors and relation stores would enforce facts discovered dynamically. The key principle would be: > **Containment supplies nested wholes; typed ontological relations explain what the nesting means and connect those wholes to qualities, locations, functions, and histories.** That could give Moppe something substantially better than either a conventional scene graph or a generic ECS: a world representation in which the program can distinguish *what a thing is*, *what it depends on*, *where it is*, *what whole it belongs to*, *what it can do*, and *what has happened through it*. ### 20. User I think one interesting thing to look at as a case study or an example is the motorcycle or the glider. It's a thing in the world that moves, so how do you represent the position of the vehicle? Is that a quality? I don't think so. It's a relation between an object and some spatial region or something, but it's kind of more interesting than that also. That's something to think about. Being an object with a position in the world, being an actual object, a material object, means that it has not just a position but some kind of velocity also. It seems very interesting to think about these things more ontologically. ### 21. Assistant tool calls #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 15, "query": "struct Bike position velocity glider position velocity transform pose" } ``` #### Tool call: `search_text` ```json { "document_id": "9YMD2E", "limit": 10, "query": "velocity motion quality spatial location continuant change position" } ``` #### Tool call: `search_text` ```json { "document_id": "9G4F42", "limit": 10, "query": "velocity rate process profile quality change motion" } ``` #### Tool call: `search_text` ```json { "document_id": "GN66WW", "limit": 10, "query": "position velocity physical object magnitude state phase space" } ``` ### 22. Tool result: search_text Exact matches 1. Source file: moppe/mov/glider.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5oaA#content Size: 3121 bytes, 116 lines Matching excerpt: #ifndef MOPPE_GLIDER_HH #define MOPPE_GLIDER_HH #include #include namespace moppe::mov { using rate_of_climb_t = quantity; using airspeed_t = quantity; using glide_ratio_t = quantity; // A deliberately compact soaring model. The glider is described by a // speed-to-sink polar rather than by generic thrust: the air mass supplies // ridge lift, the wing always sinks through it, and bank trades height for // turn rate. class Glider { public: struct State { position_t position {}; velocity_t velocity {}; Vec3 heading { 0, 0, 1 }; radians_t bank {}; airspeed_t airspeed {}; rate_of_climb_t vertical_speed {}; rate_of_climb_t air_mass_lift {}; control_signal_t turn {}; control_signal_t speed_control {}; bool flare {}; bool bike_attached {}; bool landed {}; }; explicit Glider (const map::Surface& surface); void launch (position_t position, velocity_t inherited_velocity, const Vec3& heading, bool bike_attached = false); bool update (seconds_t dt); State state () const; void restore (const State& state); void set_turn (control_signal_t turn) { m_turn = tur Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5oaA#content"] 2. Source file: moppe/mov/vehicle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content Size: 8839 bytes, 305 lines Matching excerpt: #ifndef MOPPE_VEHICLE_HH #define MOPPE_VEHICLE_HH #include #include #include #include #include namespace moppe { namespace mov { using namespace moppe::map; // An axis-aligned solid block (a building): the vehicle bounces // off its walls, and its top is drivable ground. struct Box { float x0, z0, x1, z1, top; }; class Vehicle { public: struct State { position_t position {}; velocity_t velocity {}; Vec3 heading {}; Vec3 thrust_orientation {}; radians_t yaw {}; radians_t yaw_target {}; float lean {}; Vec3 render_heading {}; Vec3 render_normal {}; float susp {}; float susp_v {}; float wheel_spin {}; bool boost_flight {}; control_signal_t thrust {}; float boost_input {}; float boost_drive {}; float boost_level {}; float boost_charge {}; seconds_t boost_recharge_delay {}; meters_t water_level {}; seconds_t airborne_time {}; speed_t impact {}; meters_t fall_top {}; meters_t fall_drop {}; int body_kind {}; DisplayColor body_color {}; }; // max_thrust caps the wheel force (launch punch); power caps // force * speed, so acceleration tapers like a real engine // instead of shoving at 3 g all the way to the hori Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content"] 3. Source file: moppe/game/frame_view.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3Lmho#content Size: 7224 bytes, 224 lines Matching excerpt: #ifndef MOPPE_GAME_FRAME_VIEW_HH #define MOPPE_GAME_FRAME_VIEW_HH #include #include #include #include #include #include namespace moppe::game { // The one selected presentation mode for a finished world frame. These are // deliberately concrete application modes, not a generic scene hierarchy. enum class FrameSceneMode { Gameplay, Cinematic, WaterInspection, TreeDemo }; // A camera has already been selected by the application before composing a // frame. Keeping its view matrix here preserves cinematics' banked camera // while still letting FrameView apply riding-only shake afterward. struct FrameCameraReading { Vec3 position {}; Vec3 forward { 0, 0, 1 }; Mat4 view {}; float field_of_view = 70.0f; }; // Renderer-facing snapshots of the parts of a vehicle that actually affect // its visible pose. They intentionally omit controls and physical state. struct VehiclePose { Vec3 position {}; Vec3 render_orientation { 0, 0, 1 }; Vec3 render_normal { 0, 1, 0 }; float suspension = 0.0f; float lean_radians = 0.0f; float wheel_spin_radians = 0.0f; float yaw_radians = 0.0f; Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3Lmho#content"] 4. Source file: moppe/game/game_session.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content Size: 22571 bytes, 576 lines Matching excerpt: #include #include #include #include namespace moppe::game { namespace { void sync_attached_bike (GameSession& session) { const mov::Glider& glider = session.glider (); const Vec3 up = Quaternion::rotate (Vec3 (0, 1, 0), glider.heading (), -glider.bank ()); session.bike ().carry (glider.physical_position () - up * 2.4f * u::m, glider.physical_velocity (), glider.heading (), up); } void set_turn (GameSession& session, float value) { GameLogicState& logic = session.logic (); logic.m_turn_input = value; if (logic.m_mode == M_FOOT) session.walker ().set_turn (value); else if (logic.m_mode == M_GLIDER) session.glider ().set_turn (value); else session.active_vehicle ().set_yaw ((90 * value) * u::deg); } void set_go (GameSession& session, float value) { GameLogicState& logic = session.logic (); logic.m_go_input = value; if (logic.m_mode == M_FOOT) session.walker ().set_walk (value > 0 ? value : value * 0.6f); else if (logic.m_mode == M_GLIDER) session.glider ().set_speed_control (value); else { session.active_vehicle ().set_thrust (value); session.active_vehicle ().set_boost (logic.m_boost_input, logic.m_go_input); } } void set_boos Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content"] 5. Source file: tests/game/game_state_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nYW1lX3N0YXRlX3Rlc3QuY2M#content Size: 23339 bytes, 558 lines Matching excerpt: #include #include #include #include #include #include #include #include namespace { void check_vector (const moppe::Vec3& actual, const moppe::Vec3& expected) { MOPPE_CHECK_NEAR (actual[0], expected[0], 1e-6f); MOPPE_CHECK_NEAR (actual[1], expected[1], 1e-6f); MOPPE_CHECK_NEAR (actual[2], expected[2], 1e-6f); } void check_position (const moppe::position_t& actual, const moppe::position_t& expected) { check_vector (moppe::position_value (actual), moppe::position_value (expected)); } void check_velocity (const moppe::velocity_t& actual, const moppe::velocity_t& expected) { check_vector (moppe::velocity_value (actual), moppe::velocity_value (expected)); } void check_color (moppe::DisplayColor actual, moppe::DisplayColor expected) { MOPPE_CHECK_NEAR (actual.red, expected.red, 1e-6f); MOPPE_CHECK_NEAR (actual.green, expected.green, 1e-6f); MOPPE_CHECK_NEAR (actual.blue, expected.blue, 1e-6f); } } MOPPE_TEST (vehicle_state_restores_hidden_simulation_state) { using namespace moppe; map::Surface map (9, 9, Vec3 (100, 20, 100)) Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nYW1lX3N0YXRlX3Rlc3QuY2M#content"] 6. Source file: moppe/mov/glider.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5jYw#content Size: 7491 bytes, 186 lines Matching excerpt: #include #include #include namespace moppe::mov { namespace { constexpr float gravity = 9.82f; constexpr airspeed_t trim_speed = 16.0f * airspeed[u::m / u::s]; constexpr airspeed_t minimum_speed = 10.0f * airspeed[u::m / u::s]; constexpr airspeed_t maximum_speed = 28.0f * airspeed[u::m / u::s]; // Rider and wing are the unloaded reference mass. Carrying the 150 kg // motocross raises total weight to roughly 2.5 times that baseline. constexpr float loaded_weight_ratio = 2.5f; // A persistent, readable prevailing wind. Its horizontal velocity is // included in ground speed and its encounter with windward slopes makes // the first ridge-lift model. const Vec3 wind_velocity (3.2f, 0, 1.4f); const Vec3 wind_direction = normalized (wind_velocity); } Glider::Glider (const map::Surface& surface) : m_surface (surface) {} void Glider::launch (position_t position, velocity_t inherited_velocity, const Vec3& heading, bool bike_attached) { m_position = position; m_bike_attached = bike_attached; const Vec3 inherited = velocity_value (inherited_velocity); Vec3 horizontal (inherited[0], 0, inherited[2]); const float inherited_speed = length (horizontal); m_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5jYw#content"] 7. Source file: tests/game/frame_view_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9mcmFtZV92aWV3X3Rlc3QuY2M#content Size: 14552 bytes, 352 lines Matching excerpt: #include #include #include #include #include #include #include using namespace moppe; namespace { void frame_view_check_vector (const Vec3& actual, const Vec3& expected) { MOPPE_CHECK_NEAR (actual[0], expected[0], 1e-6f); MOPPE_CHECK_NEAR (actual[1], expected[1], 1e-6f); MOPPE_CHECK_NEAR (actual[2], expected[2], 1e-6f); } void frame_view_check_color (DisplayColor actual, DisplayColor expected) { MOPPE_CHECK_NEAR (actual.red, expected.red, 1e-6f); MOPPE_CHECK_NEAR (actual.green, expected.green, 1e-6f); MOPPE_CHECK_NEAR (actual.blue, expected.blue, 1e-6f); } bool frame_view_same_matrix (const Mat4& left, const Mat4& right) { for (int i = 0; i < 16; ++i) if (left.m[i] != right.m[i]) return false; return true; } struct FrameFixture { map::Surface map { 17, 17, Vec3 (160, 40, 160) }; game::WorldParams world; std::unique_ptr session; game::GraphicsSettings graphics = game::high_graphics_settings (); FrameFixture () { map.fill_elevation (moppe::terrain::surface_elevation_point ( (0.25f) * 40.0f * mp_units::si::metre)); map.rebuild_geometry_readings (); world.map_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9mcmFtZV92aWV3X3Rlc3QuY2M#content"] 8. Source file: moppe/game/game_session.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uaGg#content Size: 3635 bytes, 132 lines Matching excerpt: #ifndef MOPPE_GAME_GAME_SESSION_HH #define MOPPE_GAME_GAME_SESSION_HH #include #include #include #include #include namespace moppe::game { // The world-side values consumed by ordinary fixed-step simulation. It is // deliberately a small view rather than GeneratedWorld, so simulation has // no loading, renderer, or platform dependency. Landscape scale belongs // here because it is a live presentation setting which persists across // regenerated sessions rather than checkpoint state. struct GameSessionAdvanceContext { const WorldParams& world; const map::Surface& surface; const std::vector& obstacles; float landscape_scale_x = 1.0f; float landscape_scale_y = 1.0f; }; // Observable application-side effects of an ordinary simulation step. // The application decides how to realize these, keeping platform services // outside the simulation seam. struct GameSessionAdvanceResult { bool say_ouchies = false; }; // The mutable state of one playable session on a completed world. The // world retains the surface; vehicles and the glider borrow it for their // physical readings Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uaGg#content"] 9. Source file: moppe/mov/vehicle.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content Size: 21178 bytes, 538 lines Matching excerpt: #include #include namespace moppe { namespace mov { static const float radius = 1; // metres // How fast full steering input swings the bike itself, in radians // per second per radian of yaw input. Grip then drags the // velocity around after the heading. static const float steering_rate = 1.6; static const float air_steering_rate = 0.9; static const acceleration_component_t boost_acceleration = 26.0f * isq::acceleration[u::m / pow<2> (u::s)]; static const radians_t boost_max_tilt = 60.0f * u::deg; static const seconds_t boost_full_burn_time = seconds (3.0f); static const seconds_t boost_recharge_time = seconds (5.0f); static const seconds_t boost_recharge_pause = seconds (0.65f); static const float boost_reserve_charge = 0.06f; static const float boost_emergency_level = 0.18f; Vehicle::Vehicle (position_t position, degrees_t orientation, const Surface& map, newtons_t max_thrust, watts_t power, kilograms_t mass) : m_position (position), m_velocity (moppe::velocity (Vec3 ())), m_heading (sin (orientation), 0, cos (orientation)), m_thrust_orientation (m_heading), m_yaw (), m_yaw_target (), m_lean (0), m_render_heading (m_heading), m_render_normal (0, 1 Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content"] 10. Source file: moppe/game/frame_view.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3LmNj#content Size: 13431 bytes, 318 lines Matching excerpt: #include #include #include #include namespace moppe::game { namespace { constexpr float SUN_AZIMUTH = 0.8f; // Keep the historical art-direction calculations bit-for-bit aligned // with the game loop while moving them behind the presentation seam. constexpr float ART_PI = 3.14159f; float smooth_curve (float edge0, float edge1, float value) { const float t = std::clamp ((value - edge0) / (edge1 - edge0), 0.0f, 1.0f); return t * t * (3.0f - 2.0f * t); } float sun_elevation_for (float sun_height) { return std::sin ((sun_height - 0.5f) * ART_PI); } float daylight_for (float sun_height) { return smooth_curve (-0.08f, 0.18f, sun_elevation_for (sun_height)); } float golden_light_for (float sun_height) { const float elevation = sun_elevation_for (sun_height); return daylight_for (sun_height) * (1.0f - smooth_curve (0.15f, 0.65f, elevation)); } FrameVisibility visibility_for (const FrameViewInput& input, const FrameView& view) { const bool cinematic = input.scene == FrameSceneMode::Cinematic; const bool water = input.scene == FrameSceneMode::WaterInspection; const bool tree = input.scene == FrameSceneMode::TreeDemo; FrameVisibility vis Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3LmNj#content"] 11. Source file: moppe/game/walker.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXIuaGg#content Size: 2079 bytes, 82 lines Matching excerpt: #ifndef MOPPE_GAME_WALKER_HH #define MOPPE_GAME_WALKER_HH #include #include #include #include namespace moppe { namespace game { // On-foot mode: park the bike, stretch your legs, walk through // doors into buildings. Toggled with the secret 7-5-R combo. // Port of main.cc's Walker; water_level now arrives through // WorldParams and the figure records into a DrawList. class Walker { public: struct State { position_t position {}; Vec3 heading {}; velocity_component_t vertical_velocity {}; control_signal_t turn {}; control_signal_t walk {}; meters_t animation_distance {}; bool grounded {}; }; Walker (); State state () const { return { m_pos, m_heading, m_vy, m_turn, m_walk, m_anim, m_grounded }; } void restore (const State& state) { m_pos = state.position; m_heading = state.heading; m_vy = state.vertical_velocity; m_turn = state.turn; m_walk = state.walk; m_anim = state.animation_distance; m_grounded = state.grounded; } void spawn (position_t pos, const Vec3& heading); void set_turn (control_signal_t t) { m_turn = t; } void set_walk (control_signal_t w) { m_walk = w; } void jump (); void update (seconds_t dt Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXIuaGg#content"] 12. Source file: moppe/game/chase_camera.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaGFzZV9jYW1lcmEuaGg#content Size: 3269 bytes, 107 lines Matching excerpt: #ifndef MOPPE_GAME_CHASE_CAMERA_HH #define MOPPE_GAME_CHASE_CAMERA_HH #include #include #include namespace moppe { namespace game { // The chase camera from gfx::ThirdPersonCamera, GL-free: instead // of realize()-ing onto the GL matrix stack it hands out a view // matrix. Its follow spring and terrain corridor are frame-rate // independent. class ChaseCamera { public: struct State { position_t position {}; position_t target {}; Vec3 avg_orientation {}; displacement_t ahead {}; velocity_t position_velocity {}; velocity_t target_velocity {}; speed_t speed {}; bool is_uninitialized {}; }; ChaseCamera (degrees_t pitch_offset, meters_t distance) : m_pitch_offset (pitch_offset), m_distance (distance), m_speed (0 * u::m / u::s), m_is_uninitialized (true) {} void update (position_t position, const Vec3& orientation, velocity_t velocity, seconds_t dt); void limit (const map::Surface& map); void set_landscape_scale (float horizontal, float vertical) { m_horizontal_scale = horizontal; m_vertical_scale = vertical; } State state () const { return { m_position, m_target, m_avg_orientation, m_ahead, m_position_velocity, m_target_velo Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaGFzZV9jYW1lcmEuaGg#content"] 13. Source file: moppe/game/chase_camera.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaGFzZV9jYW1lcmEuY2M#content Size: 6519 bytes, 159 lines Matching excerpt: #include #include #include namespace moppe { namespace game { namespace { // damping_ratio is the dimensionless zeta of the second-order // system, not a rate: 1 is critical, below rings, above crawls. void spring (position_t& value, velocity_t& velocity, position_t target, frequency_t frequency, float damping_ratio, seconds_t dt) { const frequency_t omega = PI2 * frequency; const displacement_t error = quantity_cast (target - value); const acceleration_t acceleration = quantity_cast ( error * omega * omega - velocity * (2.0f * damping_ratio * omega)); velocity += quantity_cast (acceleration * dt); value += quantity_cast (velocity * dt); } } void ChaseCamera::update (position_t position, const Vec3& orientation, velocity_t velocity, seconds_t dt) { // dt-correct smoothing (3.1/s reproduces the old 0.05 @ 60Hz) float alpha = smoothing_alpha (3.1f / u::s, dt); float fast = smoothing_alpha (12.0f / u::s, dt); const bool reset = m_is_uninitialized; if (reset) { alpha = fast = 1; m_ahead = displacement (Vec3 ()); } m_avg_orientation = linear_vector_interpolate (m_a Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaGFzZV9jYW1lcmEuY2M#content"] 14. Source file: moppe/map/water_surface.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbWFwL3dhdGVyX3N1cmZhY2UuaGg#content Size: 1767 bytes, 58 lines Matching excerpt: #ifndef MOPPE_MAP_WATER_SURFACE_HH #define MOPPE_MAP_WATER_SURFACE_HH #include #include namespace moppe::terrain { struct WaterSheets; } namespace moppe::map { inline constexpr struct wave_amplitude : quantity_spec { } wave_amplitude; inline constexpr struct water_velocity : quantity_spec { } water_velocity; using WaveAmplitude = quantity; using WaterVelocity = quantity; using WaterSurfaceSections = spatial:: Bundle; // Standing and running water sampled over the terrain lattice. Elevation // shares the ground's affine frame; amplitude and velocity describe the // water itself and therefore live in a distinct bundle. class WaterSurface { public: // Painted water sheets and the ground share one lattice. WaterSurface (SurfaceDomain domain, const terrain::WaterSheets& sheets); WaterSurface (SurfaceDomain domain, std::span level_and_amplitude, std::span planar_flow); const WaterSurfaceSections Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbWFwL3dhdGVyX3N1cmZhY2UuaGg#content"] 15. Source file: docs/ontology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines Matching excerpt: # What Exists in Moppe Moppe keeps careful accounts of *how much*: heights in meters, thrust in newtons, sink rates in meters per second. The type system refuses to add an airspeed to an altitude, and the codebase is better for it. This document starts a parallel set of accounts about *what kinds of things there are*. It is not a specification and it proposes no work. It is a vocabulary — a way of talking about the game world that stays truthful about the structure of what the code simulates, the way `units.md` stays truthful about magnitudes. The vocabulary is borrowed, mostly from the ontologist Barry Smith and his collaborators, whose papers live in `research/` (readable in sections at `https://m.sheaf.less.rest/` with `Accept: text/markdown`). Their subject is ordinary reality — mountains, headaches, county borders, orchestras — but a game world turns out to be built from the same kinds of things, and it is clarifying to call them by their proper names. ## Fields and things Ask what the terrain *is* and two honest answers come back. To the simulation, the terrain is a field: elevation as a value at every position, and alongside it moisture, forest cover, snow support, channel f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content"] Approximate matches 1. Source file: moppe/mov/vehicle.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content Size: 21178 bytes, 538 lines Score: 0.044 Related excerpt: w, but pitch the chassis tangent to // the landing surface. The sampled normal supplies the corresponding // roll, so sidehill touchdowns meet both tires instead of one edge. forward = m_heading - up * dot (m_heading, up); if (length2 (forward) < 0.0001f) { const Vec3 impact_velocity = velocity + Vec3 (0, -gravity * t, 0); forward = impact_velocity - up * dot (impact_velocity, up); } if (length2 (forward) < 0.0001f) return false; normalize (forward); time_to_landing = t; return true; } return false; } // The obstacle box whose roof is the effective ground under the // bike -- only counts once the bike is up at roof level, so a // building towering overhead is not "ground". const Box* Vehicle::roof_under () const { if (!m_obstacles) return 0; const Box* found = 0; const Vec3& p = position_value (m_position); float best = m_map.interpolated_height (p[0], p[2]); for (size_t i = 0; i < m_obstacles->size (); ++i) { const Box& b = (*m_obstacles)[i]; if (p[0] >= b.x0 && p[0] <= b.x1 && p[2] >= b.z0 && p[2] <= b.z1 && p[1] > b.top - 2 * radius && b.top > best) { best = b.top; found = &b; } } return found; } void Vehicle::collide_with_walls () { if (!m_obstacles) return; Vec3& p = position_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content"] 2. Source file: moppe/game/vehicle_render.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5jYw#content Size: 19470 bytes, 510 lines Score: 0.04 Related excerpt: Mat4::rotation (steer, y_axis); r.draw_mesh (*bm.steering, steering); // Fork legs run from the clamp down to the front axle. dl.push (); dl.translate (0, 0.05f, 0.55f); dl.rotate (steer, y_axis); dl.color (0.72f, 0.74f, 0.78f); for (int s = -1; s <= 1; s += 2) model::link (dl, Vec3 (s * 0.10f, 0.10f, -0.02f), Vec3 (s * 0.09f, -0.60f + wheel_drop * 0.7f, 0.20f), 0.055f); dl.pop (); r.draw_mesh ( *bm.wheel, steering * Mat4::translation (Vec3 (0, -0.60f + wheel_drop * 0.7f, 0.20f)) * axle); // Gimballed jump-jet nozzles under the frame. for (int s = -1; s <= 1; s += 2) r.draw_mesh (*bm.nozzle, frame * Mat4::translation (Vec3 (s * 0.14f, -0.45f, -0.35f)) * Mat4::rotation (boost_nozzle_angle (vehicle), x_axis)); dl.pop (); } // The additive exhaust lick and jump-jet plumes, replayed as baked // unit cones under breathing scale matrices. Called after the // world draw list plays so the glow blends over the solids, the // same reason the star halos draw last. void render_vehicle_flames (render::Renderer& r, const VehiclePose& vehicle, float time, const Vec3& visual_scale) { const bool bike = (vehicle.body_kind == 0); const float thrust = std::abs (vehicle.thrust); const bool exhaust = bi Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5jYw#content"] 3. Source file: moppe/mov/vehicle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content Size: 8839 bytes, 305 lines Score: 0.031 Related excerpt: #ifndef MOPPE_VEHICLE_HH #define MOPPE_VEHICLE_HH #include #include #include #include #include namespace moppe { namespace mov { using namespace moppe::map; // An axis-aligned solid block (a building): the vehicle bounces // off its walls, and its top is drivable ground. struct Box { float x0, z0, x1, z1, top; }; class Vehicle { public: struct State { position_t position {}; velocity_t velocity {}; Vec3 heading {}; Vec3 thrust_orientation {}; radians_t yaw {}; radians_t yaw_target {}; float lean {}; Vec3 render_heading {}; Vec3 render_normal {}; float susp {}; float susp_v {}; float wheel_spin {}; bool boost_flight {}; control_signal_t thrust {}; float boost_input {}; float boost_drive {}; float boost_level {}; float boost_charge {}; seconds_t boost_recharge_delay {}; meters_t water_level {}; seconds_t airborne_time {}; speed_t impact {}; meters_t fall_top {}; meters_t fall_drop {}; int body_kind {}; DisplayColor body_color {}; }; // max_thrust caps the wheel force (launch punch); power caps // force * speed, so acceleration tapers like a real engine // instead of shoving at 3 g all the way to the hori Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content"] 4. Source file: moppe/game/game_session.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content Size: 22571 bytes, 576 lines Score: 0.027 Related excerpt: ic.m_mode == M_CAR ? m_car : m_bike; } Vec3 GameSession::subject_position () const { if (m_logic.m_mode == M_FOOT) return m_walker.position (); if (m_logic.m_mode == M_GLIDER) return m_glider.position (); return active_vehicle ().position (); } Vec3 GameSession::subject_heading () const { if (m_logic.m_mode == M_FOOT) return m_walker.heading (); if (m_logic.m_mode == M_GLIDER) return m_glider.heading (); return active_vehicle ().orientation (); } float GameSession::subject_speed_kmh () const { if (m_logic.m_mode == M_FOOT) return 0.0f; if (m_logic.m_mode == M_GLIDER) return m_glider.airspeed ().numerical_value_in (u::m / u::s) * 3.6f; return length (active_vehicle ().velocity ()) * 3.6f; } bool GameSession::can_deploy_glider (const map::Surface& terrain) const { if (m_logic.m_mode != M_BIKE || !m_bike.airborne ()) return false; const Vec3 position = m_bike.position (); const float ground = terrain.interpolated_height (position[0], position[2]); return position[1] - ground > 3.0f; } bool GameSession::can_drop_bike () const { return m_logic.m_mode == M_GLIDER && m_glider.bike_attached (); } void GameSession::clear_controls () { set_turn (*this, 0.0f); set_go (*this, 0.0f); set_boost Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content"] 5. Source file: moppe/game/glider_render.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nbGlkZXJfcmVuZGVyLmNj#content Size: 4083 bytes, 120 lines Score: 0.016 Related excerpt: #include #include #include #include namespace moppe::game { namespace { void wing_triangle (render::DrawList& dl, const Vec3& a, const Vec3& b, const Vec3& c) { dl.normal (normalized (cross (b - a, c - a))); dl.vertex (a); dl.vertex (b); dl.vertex (c); } Mat4 glider_frame (const GliderPose& glider, const Vec3& visual_scale) { const Vec3 fwd = normalized (glider.heading); const Vec3 right = normalized (cross (Vec3 (0, 1, 0), fwd)); const Vec3 up = cross (fwd, right); return Mat4::translation (glider.position) * Mat4::basis (right, up, fwd) * Mat4::rotation (-glider.bank_radians * u::rad, Vec3 (0, 0, 1)) * Mat4::scaling (visual_scale); } } void render_glider (render::DrawList& dl, const GliderPose& glider, float time, const Vec3& visual_scale) { const Vec3 nose (0, 0.18f, 1.8f); const Vec3 left (-4.6f, 0, -0.75f); const Vec3 right (4.6f, 0, -0.75f); const Vec3 tail (0, -0.08f, -2.15f); const Vec3 center (0, 0.20f, -0.30f); const Vec3 hang (0, -1.15f, -0.22f); dl.push (); dl.mult (glider_frame (glider, visual_scale)); // A lightly faceted Rogallo wing. The darker underside is explicitly // wound the other Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nbGlkZXJfcmVuZGVyLmNj#content"] 6. Source file: moppe/mov/glider.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5jYw#content Size: 7491 bytes, 186 lines Score: 0.016 Related excerpt: #include #include #include namespace moppe::mov { namespace { constexpr float gravity = 9.82f; constexpr airspeed_t trim_speed = 16.0f * airspeed[u::m / u::s]; constexpr airspeed_t minimum_speed = 10.0f * airspeed[u::m / u::s]; constexpr airspeed_t maximum_speed = 28.0f * airspeed[u::m / u::s]; // Rider and wing are the unloaded reference mass. Carrying the 150 kg // motocross raises total weight to roughly 2.5 times that baseline. constexpr float loaded_weight_ratio = 2.5f; // A persistent, readable prevailing wind. Its horizontal velocity is // included in ground speed and its encounter with windward slopes makes // the first ridge-lift model. const Vec3 wind_velocity (3.2f, 0, 1.4f); const Vec3 wind_direction = normalized (wind_velocity); } Glider::Glider (const map::Surface& surface) : m_surface (surface) {} void Glider::launch (position_t position, velocity_t inherited_velocity, const Vec3& heading, bool bike_attached) { m_position = position; m_bike_attached = bike_attached; const Vec3 inherited = velocity_value (inherited_velocity); Vec3 horizontal (inherited[0], 0, inherited[2]); const float inherited_speed = length (horizontal); m_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5jYw#content"] 7. Source file: moppe/game/walker_render.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXJfcmVuZGVyLmNj#content Size: 4269 bytes, 130 lines Score: 0.015 Related excerpt: #include #include #include #include namespace moppe::game { void render_walker (render::DrawList& draw, const WalkerPose& walker, float time, const Vec3& visual_scale) { draw.set_texture (nullptr); // The rider, dismounted: the same guy in the same gear, with knees and // elbows that actually articulate through the gait. const bool moving = std::abs (walker.walk) > 0.01f; const float phase = walker.animation_distance * 3.6f; const float bob = moving ? 0.025f * std::fabs (std::sin (phase)) : 0.0f; const float breathe = moving ? 0.0f : 0.006f * std::sin (time * 2.0f); draw.push (); draw.translate ( walker.position[0], walker.position[1] + bob, walker.position[2]); draw.rotate ( std::atan2 (walker.heading[0], walker.heading[2]) * u::rad, 0, 1, 0); draw.scale (visual_scale); // Legs: the thigh swings from the hip, the shin lags behind with a knee // bend that folds on the back-swing, and the boot rides along. for (int side = -1; side <= 1; side += 2) { const float leg_phase = phase + (side > 0 ? 0.0f : PI); const float thigh = moving ? -30.0f * std::sin (leg_phase) : 0.0f; const float knee = moving ? 12.0f + 30.0f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXJfcmVuZGVyLmNj#content"] 8. Source file: moppe/mov/glider.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5oaA#content Size: 3121 bytes, 116 lines Score: 0.014 Related excerpt: #ifndef MOPPE_GLIDER_HH #define MOPPE_GLIDER_HH #include #include namespace moppe::mov { using rate_of_climb_t = quantity; using airspeed_t = quantity; using glide_ratio_t = quantity; // A deliberately compact soaring model. The glider is described by a // speed-to-sink polar rather than by generic thrust: the air mass supplies // ridge lift, the wing always sinks through it, and bank trades height for // turn rate. class Glider { public: struct State { position_t position {}; velocity_t velocity {}; Vec3 heading { 0, 0, 1 }; radians_t bank {}; airspeed_t airspeed {}; rate_of_climb_t vertical_speed {}; rate_of_climb_t air_mass_lift {}; control_signal_t turn {}; control_signal_t speed_control {}; bool flare {}; bool bike_attached {}; bool landed {}; }; explicit Glider (const map::Surface& surface); void launch (position_t position, velocity_t inherited_velocity, const Vec3& heading, bool bike_attached = false); bool update (seconds_t dt); State state () const; void restore (const State& state); void set_turn (control_signal_t turn) { m_turn = tur Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L2dsaWRlci5oaA#content"] 9. Source file: tests/game/game_state_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nYW1lX3N0YXRlX3Rlc3QuY2M#content Size: 23339 bytes, 558 lines Score: 0.014 Related excerpt: #include #include #include #include #include #include #include #include namespace { void check_vector (const moppe::Vec3& actual, const moppe::Vec3& expected) { MOPPE_CHECK_NEAR (actual[0], expected[0], 1e-6f); MOPPE_CHECK_NEAR (actual[1], expected[1], 1e-6f); MOPPE_CHECK_NEAR (actual[2], expected[2], 1e-6f); } void check_position (const moppe::position_t& actual, const moppe::position_t& expected) { check_vector (moppe::position_value (actual), moppe::position_value (expected)); } void check_velocity (const moppe::velocity_t& actual, const moppe::velocity_t& expected) { check_vector (moppe::velocity_value (actual), moppe::velocity_value (expected)); } void check_color (moppe::DisplayColor actual, moppe::DisplayColor expected) { MOPPE_CHECK_NEAR (actual.red, expected.red, 1e-6f); MOPPE_CHECK_NEAR (actual.green, expected.green, 1e-6f); MOPPE_CHECK_NEAR (actual.blue, expected.blue, 1e-6f); } } MOPPE_TEST (vehicle_state_restores_hidden_simulation_state) { using namespace moppe; map::Surface map (9, 9, Vec3 (100, 20, 100)) Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nYW1lX3N0YXRlX3Rlc3QuY2M#content"] 10. Source file: moppe/game/glider_render.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nbGlkZXJfcmVuZGVyLmho#content Size: 368 bytes, 14 lines Score: 0.014 Related excerpt: #ifndef MOPPE_GAME_GLIDER_RENDER_HH #define MOPPE_GAME_GLIDER_RENDER_HH #include #include namespace moppe::game { void render_glider (render::DrawList& dl, const GliderPose& glider, float time, const Vec3& visual_scale = Vec3 (1, 1, 1)); } #endif Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nbGlkZXJfcmVuZGVyLmho#content"] 11. Source file: moppe/game/model.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9tb2RlbC5jYw#content Size: 2783 bytes, 95 lines Score: 0.014 Related excerpt: #include #include namespace moppe { namespace game { namespace model { void box (render::DrawList& dl, float width, float height, float depth) { dl.push (); dl.scale (width, height, depth); dl.cube (1.0f); dl.pop (); } void ellipsoid (render::DrawList& dl, float rx, float ry, float rz, int slices, int stacks) { dl.push (); dl.scale (rx, ry, rz); dl.sphere (1.0f, slices, stacks); dl.pop (); } void link (render::DrawList& dl, const Vec3& start, const Vec3& end, float thickness) { const Vec3 midpoint = (start + end) * 0.5f; const Vec3 direction = end - start; const float beam_length = moppe::length (direction); const float flat = std::sqrt (direction[0] * direction[0] + direction[2] * direction[2]); dl.push (); dl.translate (midpoint); dl.rotate (std::atan2 (direction[0], direction[2]) * u::rad, 0, 1, 0); dl.rotate (-std::atan2 (direction[1], flat) * u::rad, 1, 0, 0); box (dl, thickness, thickness, beam_length); dl.pop (); } void rider_material (render::DrawList& dl, RiderMaterial material) { switch (material) { case RiderMaterial::Pants: dl.color (0.13f, 0.14f, 0.19f); break; case RiderMaterial::Jersey: dl.color (0.15f, 0.28f, 0.55f); break; case RiderMa Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9tb2RlbC5jYw#content"] 12. Source file: moppe/game/cinematic_flight.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaW5lbWF0aWNfZmxpZ2h0LmNj#content Size: 39889 bytes, 938 lines Score: 0.013 Related excerpt: + look_near); const RouteState view_far = route_state (m_route_distance + look_far); Vec3 wanted_look = view_far.position - view_near.position; if (length2 (wanted_look) < 1e-5f) wanted_look = path_forward; else normalize (wanted_look); Vec3 framed_subject = current.subject - current.position; if (length2 (framed_subject) > 1e-5f) { normalize (framed_subject); wanted_look = wanted_look * 0.48f + framed_subject * 0.52f; if (length2 (wanted_look) > 1e-5f) normalize (wanted_look); } const float gimbal_alpha = 1.0f - std::exp (-1.9f * dt); m_look_direction += (wanted_look - m_look_direction) * gimbal_alpha; if (length2 (m_look_direction) > 1e-5f) normalize (m_look_direction); const float speed_fov = std::clamp ((m_speed - 70.0f) * 0.055f, 0.0f, 10.0f); const float dive_fov = std::clamp (-path_forward[1] * 9.0f, 0.0f, 5.0f); const float wanted_fov = current.field_of_view + speed_fov + dive_fov; m_field_of_view += (wanted_fov - m_field_of_view) * (1.0f - std::exp (-3.0f * dt)); // Roll from the broad upcoming arc, never from frame-local acceleration. // This keeps a gently banked horizon through a whole turn and eliminates // the left-right rocking caused by tiny corrections in the fligh Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaW5lbWF0aWNfZmxpZ2h0LmNj#content"] 13. Source file: moppe/game/vehicle_render.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5oaA#content Size: 1530 bytes, 36 lines Score: 0.013 Related excerpt: #ifndef MOPPE_GAME_VEHICLE_RENDER_HH #define MOPPE_GAME_VEHICLE_RENDER_HH #include #include #include namespace moppe { namespace game { // The drawing half of the old Vehicle::render, split out so the // simulation stays renderer-free. Reads one immutable vehicle pose; // the bike's rigid assemblies // are baked meshes drawn straight through the renderer, while // shape-changing parts (suspension links) record into the frame's // draw list. Dispatches bike vs. commandeered car/truck on the // body kind. `time` (seconds) replaces the hidden // glutGet(GLUT_ELAPSED_TIME) that drove the flashing light bars. void render_vehicle (render::Renderer& r, render::DrawList& dl, const VehiclePose& vehicle, float time, const Vec3& visual_scale = Vec3 (1, 1, 1)); // The exhaust lick and jump-jet plumes: baked unit cones replayed // with breathing scale matrices. Additive glow must blend over the // already-drawn solids, so the caller invokes this after playing // the world draw list (alongside the star halos), not at vehicle // draw time. void render_vehicle_flames (render::Renderer& r, const VehiclePose& vehicle, float Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5oaA#content"] 14. Source file: moppe/game/hud.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9odWQuY2M#content Size: 24839 bytes, 674 lines Score: 0.013 Related excerpt: 0.62f, 1.0f, 0.9f); // ==================== SPEEDOMETER ==================== // Live speed arc, green through amber to red. if (speed_fraction > 0.003f) { const int segs = (int)(44 * speed_fraction) + 1; dl.begin (Prim::TriangleStrip); for (int i = 0; i <= segs; ++i) { const float f = speed_fraction * i / segs; const float angle = 210.0f - 240.0f * f; const Point outer = layout.speed.at (0.88f, angle); const Point inner = layout.speed.at (0.78f, angle); dl.color (0.2f + 0.8f * f, 0.95f - 0.8f * f, 0.12f, 0.85f); dl.vertex (outer.x, outer.y); dl.vertex (inner.x, inner.y); } dl.end (); } // Large digital speed and a small odometer readout. { const std::string speed = std::to_string ((int)(kmh + 0.5f)); dl.color (0.95f, 0.96f, 0.98f); m_display24->draw (dl, layout.speed.center.x - m_display24->measure (speed) * 0.5f, layout.speed.center.y + 4, speed); char buf[16]; snprintf (buf, sizeof buf, "%07.1f", st.odometer_m / 1000.0); dl.color (0.76f, 0.8f, 0.76f); m_helv10->draw (dl, layout.speed.center.x - m_helv10->measure (buf) * 0.5f, layout.speed.center.y + 35, buf); } if (st.on_foot || st.gliding) { char text[16]; const std::string label = st.gliding ? (snprintf (text, sizeof text, "%+. Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9odWQuY2M#content"] 15. Source file: atelier/matrix.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9tYXRyaXguaGg#content Size: 2995 bytes, 70 lines Score: 0.013 Related excerpt: #pragma once #include "atelier/space.hh" // GPU matrices: where the scene's quantities become the float4x4s a // vertex shader multiplies by. Everything here consumes points, // angles, and lengths, and emits raw clip-space arithmetic. namespace atelier { using Matrix = simd_float4x4; [[nodiscard]] inline Matrix translation (const Point& to) { Matrix matrix = matrix_identity_float4x4; matrix.columns[3] = simd_make_float4 (in_metres (to), 1.0f); return matrix; } [[nodiscard]] inline Matrix rotation (Angle by, const Vec3& about) { return simd_matrix4x4 (simd_quaternion (in_radians (by), as_simd (about))); } // The rotation carrying one unit direction onto another. [[nodiscard]] inline Matrix rotation (const Vec3& from, const Vec3& to) { return simd_matrix4x4 (simd_quaternion (as_simd (from), as_simd (to))); } [[nodiscard]] inline Matrix perspective (Angle vertical_fov, Real aspect_ratio, Length near_plane, Length far_plane) { const Real y = Real (1.0f / angular::tan (vertical_fov / 2)); const Real x = y / aspect_ratio; const Real z = Real (far_plane / (near_plane - far_plane)); return { simd_make_float4 (x, 0, 0, 0), simd_make_float4 (0, y, 0, 0), simd_make_float4 (0, 0, z, -1), simd Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9tYXRyaXguaGg#content"] ### 23. Tool result: search_text Exact matches 1. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 18 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #35MC29 4 SPAN #QLNXDB 4.3 Temporal Regions Matching excerpt #22JVJZ: We may thus introduce a temporal-location function analogous to spatial-location introduced earlier, though without an ontology as an argument. Processual entities do not change their locations in time in the way in which substantial entities may change their locations in space. 2. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 30 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #DUUBT3 6.5 The SNAP Geographical Fields Ontology #UMMP8H Relations in SNAP Field Ontologies. Matching excerpt #W2G9QC: Fields are related to their attributes in a way that is analogous to the inference relation between SNAP dependent entities and the substantial entities which are their bearers. Attributes in a field are necessarily bound to a given part of the field, and thus to a given spatial location. We use the relation of attribution between an attribute in a field and the corresponding field location, abbreviated in the symbol ‘AttributedTo’. The SNAP field and object perspectives are then linked as follows. Whenever a is attributed to b in a SNAP field ontology and b is located at the position c , there is, in some SNAP object ontology (SnapObj \Omega ), a substance located at c in which a' , a proxy of a , inheres. For instance, there is a portion of the elevation field of the Earth corresponding to Mont Blanc. 3. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 11 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #UQH4XU 3.1 Spatial Regions Matching excerpt #B8QPLB: SpatialLocation is a functional predicate. We can denote the spatial location of an entity a in an ontology \omega via the expression ' spatial-location ( a, \omega )'. 4. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 25 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #BS2RJT 6.1 Georegions and Geo-Ontologies #PKYEV9 Geospatial Regions. Matching excerpt #BVG8VK: This implies that there is a further sort of spatial reasoning in the geographical context, relating to the way geographical entities are located with respect to surface(earth) . This is the type of reasoning we employ when working with two-dimensional maps. The functional relation SurfaceLocation relates a spatial entity to its corresponding surface location. (This is in fact a ternary relation between a SNAP entity, a spatial region and a substance acting as a reference body. Here, however, we can leave the third term out of account, since we assume in all geographical contexts that the relevant reference body is the Earth.) The surface location of a geographical entity is that portion of the location of the Earth's surface onto which the spatial location of the entity projects along the vertical axis at a given time. 5. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 11 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #UQH4XU 3.1 Spatial Regions Matching excerpt #W3VRVA: Spatial regions can serve as locations for SNAP entities. To this end, we introduce a new primitive relation of spatial location, symbolized: 'SpatialLocation' (it corresponds to the notion of exact location in (Casati and Varzi, 1996)). 6. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 12 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #UQH4XU 3.1 Spatial Regions Matching excerpt #UK8AFV: (D20) (\text{spatial-location}(x, \omega) = y) \equiv_{\text{def}} \text{SpatialLocation}(x, y, \omega) 7. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 13 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #QZ35CZ 3 SNAP #LGE6EY 3.2 Substantial Entities Matching excerpt #7Z4URQ: As substances are located in space (at spatial regions), so also are the sites associated with them. But substantial entities also occupy sites or parts of sites., so that we have a three-term relation between substantial entities, sites and spatial regions. Occupies itself is a two-term relation between a substantial entity and a site. It is definable in terms of the notions of location and internal part (Smith and Varzi, 1999). For present purposes it is sufficient to point that in any ontology in which a case of the occupies relation obtains, i) the substantial entity and site which are joined by this relation do not overlap and neither do their respective locations; ii) the substantial entity's location is an internal part of the location of the sum of this entity with the site which it occupies. 8. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 20 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #4NQATC 5 Trans-Ontology in BFO #5YQFU8 SNAP-SNAP Trans-Ontology #VZ3SDB Spatial and Locational Change Matching excerpt #YBG49Z: In one SNAP ontology the cup is on the table, in a later SNAP ontology it is on the floor. The cup underwent locational change. In one SNAP ontology Danzig is a part of Germany; in a later SNAP ontology it is part of Poland. Here, Germany and Poland undergo spatial change. 9. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 20 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #4NQATC 5 Trans-Ontology in BFO #5YQFU8 SNAP-SNAP Trans-Ontology #LFHHPS Qualitative Change Matching excerpt #YHMNNV: (i) Change in determinables : In many cases a SNAP dependent entity will instantiate different determinates of the same determinable quality universal at different times. The colour of this table becomes tarnished over time. The colour changes; yet there is still something which remains the same and which is the subject of such change: the token determinable remains the same while transitioning through successive token determinates or values. Some quantitative changes, for example changes in temperature, belong under this heading also. 10. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 25 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #BS2RJT 6.1 Georegions and Geo-Ontologies #PKYEV9 Geospatial Regions. Matching excerpt #YEMULU: Since the relation between a substance and its (maximal, and therefore unique) surface is functional, we use the functional expression surface in order to denote a substance's surface. The entity surface(earth) is a SNAP substantial entity existentially dependent upon earth , and it has a specific spatial location at any given time. We may now define surface geospatial regions as spatial locations of parts of the surface of the Earth: Approximate matches 1. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 29 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #YVHQGW 6.4 The SPAN Geographical Process Ontology #BGCHQQ Patterns and Features of Processes Score: 0.03 Related excerpt #M9HAZK: (i) Changes of intensity or rate of a process which give rise to characteristics such as: accelerating, alternating (e.g. tidal variations), gradual, instantaneous, continuous, discrete, regular, zigzagging, cyclical, seasonal, transient, and so on. 2. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 28 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #YVHQGW 6.4 The SPAN Geographical Process Ontology Score: 0.028 Related excerpt #WUSSZQ: Some geographical objects are tied essentially to their sites; this holds especially of geographical features such as canyons and mountains. However, a number of geographical objects endure through changes of site , either through movement (e.g., thunderstorms) or through shifts over time (e.g., front lines in a war, city limits). Other sorts of geographical changes include qualitative, structural and morphological changes: for example a change in vegetation coverage or in temperature across a given or site. 3. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 18 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #35MC29 4 SPAN #QLNXDB 4.3 Temporal Regions Score: 0.028 Related excerpt #22JVJZ: We may thus introduce a temporal-location function analogous to spatial-location introduced earlier, though without an ontology as an argument. Processual entities do not change their locations in time in the way in which substantial entities may change their locations in space. 4. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 3 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #K6SSVN 1 Philosophical Background #PYHEWY Spatiotemporal Ontologies in BFO Score: 0.026 Related excerpt #FMX8ZQ: Continuants and occurents exist in time in different ways. The challenge is to build a unified framework within which we can do justice to both of these modes of being equally. This framework needs to keep the two corresponding groups of entities clearly separate, since no single inventory can embrace them both. At the same time however we have to find a way of bringing them together: continuants are themselves subject to constant change; occurents depend on continuant objects as their bearers. In particular, there is an important correspondence between continuants and those special types of occurents which are their lives . 5. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 16 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #35MC29 4 SPAN Score: 0.026 Related excerpt #8KKMCY: Occurrences are structured also along the spatial dimension; however, the real substrate for location here is no longer space but rather spacetime , which is itself a SPAN entity. SPAN entities are not located in space – the assumption that they are so located derived from the fact that each region of space may be put in correspondence with a particular portion of an instantaneous slice of spacetime. SPAN ontologies comprehend spatiotemporally extended regions and the occursents (including changes, as entities in their own right) located at such regions. 6. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 28 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #7MRJ7Z 6.3 The SNAP Geographical Object Ontology Score: 0.026 Related excerpt #HYFZ83: (vi) Geographical Qualities . In the geographical realm we are interested in qualities (and other SNAP dependent entities) of geographical substantial entities of geographical scale. These include qualities of features (for example the altitude of a mountain peak) and of agents (an army's morale, a government's level of respect for human rights). 7. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 20 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #4NQATC 5 Trans-Ontology in BFO #5YQFU8 SNAP-SNAP Trans-Ontology Score: 0.026 Related excerpt #2SX25R: It is important to emphasize that changes themselves are not entities according to the SNAP point of view. Rather, they appear, here, as trans-ontological structures or patterns. (Only in the SPAN ontology are changes entities in their own right.) Here we review from the SNAP perspective three main types of change: qualitative, locational, and substantial. We shall focus on changes of the qualitative sort, as these exhibit some of the peculiar features of SNAP-SNAP trans-ontological reasoning. 8. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 26 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #BS2RJT 6.1 Georegions and Geo-Ontologies #PKYEV9 Geospatial Regions. Score: 0.024 Related excerpt #B3QQ2H: Geographical entities are in every case spatially located at, under or above their surface locations. We thus can assume that synchronic spatial relations obtain between entities located at given spatial regions at given times in reflection of the relations which obtain between the regions themselves. Some of these relations have a mereotopological character, some are distance and orientation relations. For example an airplane is above the city of Carlin, NV, Carlin is situated along Interstate 80, Carlin is west of New York. An airplane flying over Carlin, while spatially disconnected from the city, is such that its surface location is part of (or overlaps) that of the city it is flying over. 9. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 29 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #XVCM25 6 Case Study: The Ontology of Geodynamic #YVHQGW 6.4 The SPAN Geographical Process Ontology #BGCHQQ Patterns and Features of Processes Score: 0.014 Related excerpt #XNK3DB: In each case, these features are characterizable in our framework in terms of projections of processes onto the corresponding characteristic shapes of the spatiotemporal regions they occupy. 10. Source: SNAP and SPAN: Towards Dynamic Spatial Ontology (#9YMD2E), Barry Smith, Pierre Grenon, p. 20 Context: #RBL6PZ SNAP and SPAN: Towards Dynamic Spatial Ontology #4NQATC 5 Trans-Ontology in BFO #5YQFU8 SNAP-SNAP Trans-Ontology #LFHHPS Qualitative Change Score: 0.014 Related excerpt #LDCNFD: At any given time certain qualities inhere in each given substance. At any subsequent time a number of different qualities may inhere in the same substance. Pace (Loux, 1979) there need be no inconsistency in ascribing contradictory properties to the same object providing such ascriptions pertain to distinct ontologies and such a way that there is no single perspective within which they conjunctively obtain. There are various modes of qualitative change: ### 24. Tool result: search_text Exact matches 1. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 9 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #5G9USM 4.2 Rate Process Profiles Matching excerpt #YR4NY7: On a somewhat higher level of complexity are what we shall call rate process profiles, which are the targets of selective abstraction focused not on determinate quality magnitudes plotted over successive instants of time, but rather on certain ratios between these magnitudes and associated intervals of elapsed time. A speed process profile, for example, is represented by a graph plotting against time the ratio of distance covered per unit of time. Since rates may change, and since such changes, too, may have rates of change, we have to deal here with a hierarchy of process profile universals at successive levels, including: 2. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #D42PMV 4.3 Cyclical Process Profiles Matching excerpt #9YFYNR: rate process profile cyclical process profile regular cyclical process profile 3 bpm cyclical process profile 4 bpm cyclical process profile irregular cyclical process profile increasing cyclical process profile 3. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #D42PMV 4.3 Cyclical Process Profiles Matching excerpt #DNL3CD: In the case of a regular cyclical process profile, a rate can be assigned in the simplest possible fashion by dividing the number of cycles by the duration of the temporal region occupied by the process profile as a whole. Irregular cyclical process profiles, for example as identified in the clinic, or in a morse code transmission, or in readings on an aircraft instrument panel, may be of specific interest because they are of diagnostic or forensic significance. 4. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 7 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #LVS5LJ 3. Processes in BFO #AD3XPJ 3.4 First Approximation to a Solution of the Problem of Process Measurement Data Matching excerpt #EG9TAW: Our response is, in first approximation, very simple: when we predicate, for instance, 'has speed 3.12 m/s', of a certain process of motion, then we are asserting, not that that the process in question has some special quality which the same process, in another scenario, might conceivably have lacked. Rather, we are asserting that this process is of a certain special type . Thus an assertion to the effect that 5. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 9 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #3522YH 4.1 Quality Process Profiles Matching excerpt #PHCTTF: The simplest example of a process profile is that part of a process which serves as the target of selective abstraction focused on a sequence of instances of determinate qualities such as temperature or height. When we measure, for example, the process of temperature increase in patient John, then there is a sequence of determinate temperature qualities whose values when measured on some scale are recorded on John's temperature chart. Process profiles of this simple sort can very often be represented by means of a graph in which measures of a certain quality are plotted against time. 6. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 8 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles Matching excerpt #HX8P8N: These structural dimensions are, equivalently, different dimensions along which processes can be compared. When comparing two heart beating processes as being for example of the same rate , or when comparing two games of chess as consisting of the same series of moves , then there is something in each of the two processes which is – not numerically but qualitatively – ‘the same’. This something which the two processes share in common we shall refer to in what follows to as a process profile . 7. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 9 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles Matching excerpt #SLU44F: What they share in common more precisely is that each contains an instantiation of the same process profile universal . The figure illustrates multiple instantiations of multiple process profile universals reflecting the fact that we can measure and compare cardiac processes along multiple different axes, each of which corresponds, in our proposed terminology, to a different determinable process profile universal. 8. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #T82MXT 5. Conclusion: Towards an Ontology of Time Series Graphs Matching excerpt #M5A3DM: We have dealt in the foregoing with only a small selection of the ways in which processes can be classified through division into types and subtypes. One important next step will deal with the ways in which such classification is complicated by the fact that processes are embedded within a series of larger process wholes, each nested within yet larger process wholes. Thus when a billiard ball is moving across a table, we can focus on the ball's motion relative to the table, but we can also focus on the larger process which is the motion of the body-table system relative to the motion of the earth; or we can focus on the motion of the body-table-earth system relative to the movement of the sun; and so forth. 9. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 8 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles Matching excerpt #HE3TYR: running process of 30 minute duration 3.12 m/s motion process 9.2 calories per minute energy burning process 30.12 liters per kilometer oxygen utilizing process 10. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #D42PMV 4.3 Cyclical Process Profiles Matching excerpt #GQKSB4: One important sub-family of rate process profiles is illustrated by cyclical processes, for example the 60 beats per minute beating process of John's heart, or the 120 beats per minute of his drumming process, and so on. Approximate matches 1. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 9 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #5G9USM 4.2 Rate Process Profiles Score: 0.03 Related excerpt #YR4NY7: On a somewhat higher level of complexity are what we shall call rate process profiles, which are the targets of selective abstraction focused not on determinate quality magnitudes plotted over successive instants of time, but rather on certain ratios between these magnitudes and associated intervals of elapsed time. A speed process profile, for example, is represented by a graph plotting against time the ratio of distance covered per unit of time. Since rates may change, and since such changes, too, may have rates of change, we have to deal here with a hierarchy of process profile universals at successive levels, including: 2. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #D42PMV 4.3 Cyclical Process Profiles Score: 0.028 Related excerpt #9YFYNR: rate process profile cyclical process profile regular cyclical process profile 3 bpm cyclical process profile 4 bpm cyclical process profile irregular cyclical process profile increasing cyclical process profile 3. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #5G9USM 4.2 Rate Process Profiles Score: 0.027 Related excerpt #LB4HCF: Measurement data representing rates are often expressed in terms not of the process profile instantiated across a temporal interval, but rather of what holds at some specific temporal instant. The latter is then defined in terms of the former in the following way: 4. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #D42PMV 4.3 Cyclical Process Profiles Score: 0.027 Related excerpt #DNL3CD: In the case of a regular cyclical process profile, a rate can be assigned in the simplest possible fashion by dividing the number of cycles by the duration of the temporal region occupied by the process profile as a whole. Irregular cyclical process profiles, for example as identified in the clinic, or in a morse code transmission, or in readings on an aircraft instrument panel, may be of specific interest because they are of diagnostic or forensic significance. 5. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 9 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #5G9USM 4.2 Rate Process Profiles Score: 0.027 Related excerpt #LL4Y5N: speed profile constant speed profile 2 mph constant speed profile 3 mph constant speed profile acceleration profile (increasing speed profile) constant acceleration profile 32ft/s 2 acceleration profile 33 ft/s 2 acceleration profile variable acceleration profile increasing acceleration profile 6. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #D42PMV 4.3 Cyclical Process Profiles Score: 0.026 Related excerpt #GQKSB4: One important sub-family of rate process profiles is illustrated by cyclical processes, for example the 60 beats per minute beating process of John's heart, or the 120 beats per minute of his drumming process, and so on. 7. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #D42PMV 4.3 Cyclical Process Profiles Score: 0.026 Related excerpt #PDREMS: Cyclical process profiles are a subtype of rate process profiles in which the salient ratio is not distance covered but rather number of cycles per unit of time. Here again we find a variety of more specialized universals at lower levels of generality, including for example: 8. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 9 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #3522YH 4.1 Quality Process Profiles Score: 0.025 Related excerpt #PHCTTF: The simplest example of a process profile is that part of a process which serves as the target of selective abstraction focused on a sequence of instances of determinate qualities such as temperature or height. When we measure, for example, the process of temperature increase in patient John, then there is a sequence of determinate temperature qualities whose values when measured on some scale are recorded on John's temperature chart. Process profiles of this simple sort can very often be represented by means of a graph in which measures of a certain quality are plotted against time. 9. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 8 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles Score: 0.024 Related excerpt #HE3TYR: running process of 30 minute duration 3.12 m/s motion process 9.2 calories per minute energy burning process 30.12 liters per kilometer oxygen utilizing process 10. Source: CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY (#9G4F42), Barry Smith, p. 10 Context: #7G5WHM CLASSIFYING PROCESSES: AN ESSAY IN APPLIED ONTOLOGY #WHAR3D 4. Process Profiles #5G9USM 4.2 Rate Process Profiles Score: 0.023 Related excerpt #YLKZ82: asserts, roughly, that there is some temporal interval (t_1, t_2) , including t in its interior, in which the speed v process profile universal is instantiated. More precisely (in order to take account of the fact that John may be moving with a continuously changing speed in the neighborhood of t ), (1) must be formulated in something like the following terms: ### 25. Tool result: search_text Exact matches 1. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 25 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #FJ2UE9 4.2 Entangled photons model #W7M2FJ 4.2.3 The meaning of the model Matching excerpt #PNYW3L: In the notation of Griffiths |z_a^+ z_b^-\rangle = |z^+\rangle_a \otimes |z^-\rangle_b is “an eigenstate of both S_{az} [z-direction spin] for the a particle, eigenvalue +1/2 , and of S_{bz} for the b particle, eigenvalue -1/2 ; the state |z_a^- z_b^+\rangle has a similar interpretation with eigenvalues of the opposite sign.” [13, sect. V A]. 55 That the projectors S_{az} and S_{bz} have the tensor product |z^+\rangle_a \otimes |z^-\rangle_b as eigenstate means that they have a physical interpretation in the model of the spin states of the photons with phase space \mathcal{A}^m \otimes \mathcal{B}^n . One can also show how to add the experimental process of the measurement of the spin to the phase space of the model [13]. 2. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 15 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator Matching excerpt #NHMT4U: With these variables and this solution, we can calculate the idealised position x of the oscillating mass at any time t in an imaginary phase space. A phase space is the algebraic field which is used by the model of the system to obtain the required model entities which are elements of or defined over the field. 3. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 8 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #9BTD4U 2 Physics upper ontology #XLSYCZ 2.2 Magnitudes Matching excerpt #XFKEE3: In physics, magnitudes are also called ‘physical quantities’. Here, however, we distinguish for clarity’s sake between ‘magnitudes’ on the one hand, and ‘quantities’ on the other. We define a magnitude as an entity which can be quantified using measurements. Magnitudes are then of two sorts: (1) qualities of continuants (for example mass , length ), or characteristics of processes (for example velocity , acceleration ). 25 The magnitude is 4. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 20 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #FJ2UE9 4.2 Entangled photons model #2LXWR4 4.2.1 Mathematical ontology of the entangled photon model Matching excerpt #QZRULS: where the m are the base vectors of a finite Hilbert space (see paragraph 4.2.1.1 and [12, ch. 3]). This inner product is used in physics to express the probability amplitude of state |\psi\rangle to move to state |\phi\rangle . It expresses a relationship between the two states as a probabilistic measure in the form of a complex number. 49 The square of its absolute |\langle\phi|\psi\rangle|^2 is the corresponding quantum probability (Born rule). For example, the inner product \mathcal{I}(|\phi\rangle, |\psi\rangle) (eqn. 6) is used to express the amplitude of a particle in state |\psi\rangle with a momentum p to be found at a position x as 5. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 21 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #FJ2UE9 4.2 Entangled photons model #2LXWR4 4.2.1 Mathematical ontology of the entangled photon model Matching excerpt #5SGSZA: Note that in quantum physics the Hilbert space is the phase space of the modelled system. 6. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 6 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #9BTD4U 2 Physics upper ontology #XLSYCZ 2.2 Magnitudes Matching excerpt #8NKC2N: In classical physics, a magnitude is a phenomenon in reality – for example mass, distance, velocity, acceleration or energy – which has the feature that its instances can be measured . 7. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 17 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator #RTGZW9 4.1.2 Magnitudes in the harmonic oscillator model Matching excerpt #ALBL7G: The force F shown in equation (1) is also a process magnitude. It is the effect on a body (mass) which it accelerates, which means that it changes the amount or direction of velocity of the moving mass or deforms its body. ‘Process’ is defined in such a way that all processes have temporal parts. This applies to acceleration also, which is a derivative of velocity with respect to time, 42 and so has temporal parts also from its mathematical definition. When acceleration is measured at an instant, then a measurement result, a continuant magnitude, is obtained. All such results are merely approximations to their real-world counterparts. 8. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 9 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #9BTD4U 2 Physics upper ontology #XLSYCZ 2.2 Magnitudes Matching excerpt #3R8J26: A physical quantity , in contrast, is the count of how many of this or that particular magnitude are found in a specific case of measurement. It is that about which we speak when we collect measurement data and express it in terms of, for example, numbers (quantities) of meters or joules. The term ‘quantity’ thereby captures also how much of or how many of a particular measurement magnitude we have in a system we observe or on which we perform measurements. In physics, the quantity is expressed using a mathematically defined magnitude that can be referenced using a variable in an equation. 9. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 16 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator #J9BHWH 4.1.1 Mathematical ontology of the oscillator model Matching excerpt #UUFWXJ: Because the idealized harmonic oscillator only moves up and down in one direction, vectors are not needed to model its motion. The phase space which is required for the model is just the simple space of real numbers \mathbb{R} , an algebraic field. 10. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 10 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #9BTD4U 2 Physics upper ontology #XLSYCZ 2.2 Magnitudes #KTYY4Y 2.2.2 Quantities and units of measurement Matching excerpt #84X9SK: The act of measuring consists in identifying the quantity of a physical magnitude (in the simplest cases by answering the question: How many ) of a given quality such as length or mass with either its discrete number of instances using natural numbers ( \mathbb{N} ) or using rational numbers ( \mathbb{Q} ) to approximate real numbers \mathbb{R} . Approximate matches 1. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 15 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator Score: 0.029 Related excerpt #NHMT4U: With these variables and this solution, we can calculate the idealised position x of the oscillating mass at any time t in an imaginary phase space. A phase space is the algebraic field which is used by the model of the system to obtain the required model entities which are elements of or defined over the field. 2. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 16 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator #RTGZW9 4.1.2 Magnitudes in the harmonic oscillator model Score: 0.029 Related excerpt #E2ALGQ: The magnitudes are part of the system that is represented by the physics and mathematics entities: mass ( m ), distance ( x ), time ( t ), and acceleration ( \ddot{x} ) and the spring constant (stiffness) k . Mass, distance and the spring constant are continuant magnitudes. Mass is a quality of a body that ‘does not require any further process in order to be realized’ [1]. The distance x is a length, a primitive quality in our common sense understanding of the world that is also a mathematical entity, see the definition of \pi in footnote 34. The 3. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 28 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #VPLR2G 6 Discussion Score: 0.027 Related excerpt #Z598KL: Our approach to physics ontology with the division of physics entities into systems, magnitudes and models reflects our understanding of the physicist's knowledge generation process. In classical physics, systems are selections from reality which are chosen and delimited as objects of scientific inquiry. Here, the magnitudes are universals. They mediate between the reality of the system and the idealised nature of the model. We saw that the harmonic oscillator model illustrates in which way we abstract from reality to create idealised models in physics, but the model can be refined to an extent that it can model reality very closely, for example, to yield the forced oscillator with damping that models a real electric circuit. Because the model uses Euclidean space ( \mathbb{R}^3 ) as phase space, we can easily imagine the relationship of the model to the sensory reality we perceive in our common-sense view of the world as an environment extending in three spatial and one temporal dimension. The magnitudes we use to link the model to reality can not only be imagined quite well, they can also be experienced: we can feel our own mass and the acceleration and force acting on our bodies, and we can feel the retraction of a spring and also the passing of time as our heart beats and as we breathe. 4. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 8 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #9BTD4U 2 Physics upper ontology #XLSYCZ 2.2 Magnitudes Score: 0.027 Related excerpt #PTQCVU: Magnitudes are in every case, in classical as in modern physics, associated with material entities. This means that magnitudes are either (i.) continuant magnitudes 21 (such as mass or density), which are qualities of material bodies; or they are (ii.) process magnitudes , 22 such as velocity or force, where the processes measured involve material bodies as participants and interactions mediated by particles (as for example photons mediate the electromagnetic force). 23 5. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 24 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #FJ2UE9 4.2 Entangled photons model #MDGYDQ 4.2.2 Magnitudes in the entangled photons model Score: 0.026 Related excerpt #KRVWPZ: But where the latter can be imagined using our common sense knowledge of the world, this is not so of the former, which can only be understood as a property that leads to certain indirect measurements results (see above page 19). We model this property mathematically. It is a vector magnitude because it has three spatial components \mathbf{s} = (s_x, s_y, s_z) . It is a vector modelling a conserved quality of the particle and is therefore a continuant quality like mass and not a process characteristic like acceleration. 6. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 16 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator #J9BHWH 4.1.1 Mathematical ontology of the oscillator model Score: 0.026 Related excerpt #UUFWXJ: Because the idealized harmonic oscillator only moves up and down in one direction, vectors are not needed to model its motion. The phase space which is required for the model is just the simple space of real numbers \mathbb{R} , an algebraic field. 7. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 8 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #9BTD4U 2 Physics upper ontology #XLSYCZ 2.2 Magnitudes Score: 0.025 Related excerpt #XFKEE3: In physics, magnitudes are also called ‘physical quantities’. Here, however, we distinguish for clarity’s sake between ‘magnitudes’ on the one hand, and ‘quantities’ on the other. We define a magnitude as an entity which can be quantified using measurements. Magnitudes are then of two sorts: (1) qualities of continuants (for example mass , length ), or characteristics of processes (for example velocity , acceleration ). 25 The magnitude is 8. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 6 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #9BTD4U 2 Physics upper ontology #XLSYCZ 2.2 Magnitudes Score: 0.025 Related excerpt #8NKC2N: In classical physics, a magnitude is a phenomenon in reality – for example mass, distance, velocity, acceleration or energy – which has the feature that its instances can be measured . 9. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 17 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator #RTGZW9 4.1.2 Magnitudes in the harmonic oscillator model Score: 0.023 Related excerpt #C5G8DK: The acceleration referred to on the left hand side of equation (2), \ddot{x} = \frac{d^2x}{dt^2} , is a measurable process profile 41 of a process of motion. It depends on the motion and can exist only if the motion exists. Without motion, there is no acceleration. Acceleration is a process magnitude. 10. Source: Ontologies of Common Sense, Physics and Mathematics (#GN66WW), Barry Smith, Jobst Landgrebe, p. 17 Context: #6KMTK8 Ontologies of common sense, physics and mathematics #KHZPSR 4 Examples from classical and quantum physics #AWHTTL 4.1 The harmonic oscillator #RTGZW9 4.1.2 Magnitudes in the harmonic oscillator model Score: 0.022 Related excerpt #ALBL7G: The force F shown in equation (1) is also a process magnitude. It is the effect on a body (mass) which it accelerates, which means that it changes the amount or direction of velocity of the moving mass or deforms its body. ‘Process’ is defined in such a way that all processes have temporal parts. This applies to acceleration also, which is a derivative of velocity with respect to time, 42 and so has temporal parts also from its mathematical definition. When acceleration is measured at an instant, then a measurement result, a continuant magnitude, is obtained. All such results are merely approximations to their real-world counterparts. ### 26. Assistant Yes. The motorcycle/glider case exposes a useful distinction between **the world**, **the process occurring in it**, and **the numerical state used to model that process**. ## Position is not an intrinsic quality A motorcycle does not possess its position in the way it possesses mass or colour. Its position is relational: ```text motorcycle —exactly_located_in→ spatial region ``` More precisely, a material body **occupies an extended spatial region** at a particular time. Smith and Grenon treat spatial location as a functional relation between an entity and a spatial region (#W3VRVA, #B8QPLB). The object occupies a region, not a coordinate tuple. The stored `position_t` in `Vehicle::State` is something narrower: ```text position_t = coordinates of a selected reference point in a selected world frame at a selected instant ``` That reference point might be the center of mass, chassis origin, or simulation origin. It is not literally the motorcycle’s location; it is a compact **representation from which the occupied region can be reconstructed**. For a rigid vehicle, the more complete relation is its pose: $$ T_{\text{world}\leftarrow\text{body}}(t) $$ This maps points expressed in the vehicle’s body-fixed frame into the world frame. Together with the vehicle’s shape, it determines the spatial region occupied by every part: ```text front wheel —part_of→ motorcycle front wheel —occupies→ transformed wheel region motorcycle —occupies→ union of its parts’ regions ``` Orientation is similarly relational: it is the orientation of the vehicle’s body frame **relative to** a world or terrain frame. A bare `heading` vector hides both relata. ## Coordinates represent a location That gives at least four distinct things: 1. **Material object** — this motorcycle. 2. **Spatial region** — the extended region it occupies now. 3. **Locational relation** — the motorcycle occupies that region. 4. **Coordinate representation** — numbers identifying the region or a reference point in a chosen frame. This distinction matters especially in Moppe because the world is a torus. A single location on the torus has many coordinate representatives in the universal cover: $$ (x,z),\quad (x+nL_x,\ z+mL_z) $$ all project to the same toroidal location. The unwrapped position used by physics therefore contains historical information—how the vehicle arrived there and how many times it crossed the seam—that is not part of its instantaneous location on the torus. In ontological terms: - **wrapped location** belongs to the current SNAP inventory; - **unwrapped displacement and winding** summarize the vehicle’s SPAN history; - the projection from universal-cover coordinates to the torus is part of the model. That is a concrete example of why `position_t` should not be identified with “where the motorcycle really is.” ## Velocity belongs more naturally to motion Velocity is more subtle still. It is not simply another static quality beside mass. Velocity is the rate and direction of change of location relative to a frame: $$ \mathbf v(t)=\frac{d\mathbf x}{dt}. $$ It therefore presupposes: - the enduring material object; - a process of motion or rest in which it participates; - locations across a temporal neighborhood; - a reference frame and temporal scale. Smith’s process account treats speed as a **rate process profile**, abstracted from distance covered over elapsed time (#YR4NY7). Landgrebe and Smith similarly classify mass as a continuant magnitude but velocity and acceleration as characteristics of processes (#XFKEE3, #PTQCVU). An instantaneous velocity stored by the simulation is consequently a model reading of the current motion process, not an intrinsic quality floating inside the vehicle. A useful decomposition would be: ```text motorcycle participates_in → current motion process motion process occurs_in → spatiotemporal region has_profile → velocity relative to world frame has_profile → acceleration relative to world frame snapshot records → motorcycle’s current location records → estimate of motion’s current velocity profile ``` The vehicle can remain the same continuant while participating successively in riding, jumping, falling, landing, skidding, and resting processes. ## “Being airborne” is also relational This analysis improves many current flags: ```text airborne landed bike_attached ``` They are not all qualities of the same kind. - **Airborne**: the motorcycle is spatially disconnected from its support surface and currently participates in a flight/fall process. - **Grounded**: some load-bearing part of the motorcycle is in supporting contact with terrain. - **Landed**: either a current state derived from supporting contact, or an event marking the transition from flight to supported motion. - **Bike attached**: a temporary configuration relation between bike and glider. - **Touchdown**: the instantaneous boundary between airborne and ground-contact processes. The existing `sync_attached_bike()` is revealing. It copies a position and velocity derived from the glider into the bike. Ontologically, while attached, the bike and glider form a temporary **compound moving system**: ```text bike —attached_to→ glider bike —part_of_configuration→ glider–bike system system —participates_in→ flight bike pose —constrained_by→ glider pose + tether geometry ``` The bike does not independently happen to share the glider’s velocity. Its motion is constrained by the attachment relation. The copied state is an implementation of that constraint. ## An ontological reading of the current state The current `Vehicle::State` and `Glider::State` flatten several categories into one snapshot: | Current value | Ontological interpretation | |---|---| | `position` | coordinate representation of a spatial-location relation | | `heading`, `bank` | orientation of a body frame relative to another frame | | `velocity` | instantaneous reading of a motion-process profile | | `airspeed` | motion profile relative to the surrounding air mass | | `vertical_speed` | selected component of a motion profile relative to gravity/world frame | | `boost_charge` | dependent quality of the vehicle | | `bike_attached` | temporary configuration relation | | `landed` | derived contact condition, or shorthand for a process boundary | | `airborne_time` | duration of an ongoing process | | `impact` | magnitude associated with a collision/landing event | | `position` in `VehiclePose` | a renderer-facing projection of the physical relation | A semantically stronger design would not necessarily store less data. It would place the values behind truthful concepts: ```text MaterialBody BodyFrame SpatialOccupancy RigidPose AttachmentConfiguration Motion MotionProfile SupportingContact CollisionEvent ``` The deepest insight is that a moving object does not simply *have position and velocity*. Rather: > A material continuant occupies a spatial region; across time it participates in a motion process; position and velocity vectors are frame-dependent model readings of that occupancy and motion. The motorcycle and glider are excellent case studies because attachment, support, flight, collision, toroidal location, coordinate frames, and process history all become visible in one small part of the game. ### 27. User Right, I feel like it's so cool to have this idea of universals, quality universals or process universals. I really feel like the universals are a very beautiful and powerful thing about this kind of ontology. There's a kind of motion that bodies have when they are in the general right above a planet, so to speak. They have this kind of momentum, and they have the fact that their free fall goes down towards gravity. There's also thrust. Being able to talk about these things, what is it that, let's say, a motorcycle has? What is the motion, what is the process of the motion, or whatever? It's an interesting thing to describe, right? ### 28. Assistant Exactly. Universals let you say not only **what numerical state the motorcycle is in**, but **what kind of happening is occurring**. They turn the physics state into something intelligible. The crucial distinction is: - **universal:** gravitational free fall, rolling, thrust production, gliding; - **particular:** this fall from this ridge, this wheel-driven acceleration, this glider descent. One concrete motion can instantiate several process universals simultaneously. ## The motorcycle does not simply “have motion” There is the motorcycle, an independent continuant, and there is its particular ongoing motion, an occurrent: ```text this motorcycle participates_in → this motion this motion instance_of → terrestrial motion has_profile → current velocity has_profile → current acceleration has_profile → current momentum ``` The motion is part of the motorcycle’s larger life, but it is not a component stored inside the motorcycle in the same sense as its engine or wheel. Then we can classify the motion more specifically: ```text Motion ├── Supported motion │ ├── Rolling │ ├── Skidding │ └── Airborne takeoff ├── Ballistic motion │ └── Gravitational free fall ├── Propelled motion │ ├── Wheel-driven motion │ └── Boost-driven flight ├── Aerodynamic motion │ ├── Gliding │ ├── Turning flight │ └── Flaring └── Collision process └── Landing ``` These need not be exclusive game modes. A particular jump may instantiate: ```text airborne motion gravitationally accelerated motion aerodynamically resisted motion boost-propelled motion ``` all at once. That is one beautiful feature of universals: the same particular can instantiate several genuine kinds without being chopped into unrelated component flags. ## Gravity is part of a larger system “Down” does not inhere in the motorcycle. It arises from the motorcycle’s situation within a gravitational system. For an ordinary planet: ```text motorcycle earth gravitational interaction motion of motorcycle relative to earth ``` The direction called downward is determined by the gravitational field at the motorcycle’s location. The resulting free fall is a process in which the motorcycle participates. Moppe’s actual ontology is slightly different and should remain honest about that. Its world is a flat torus with a privileged vertical direction and approximately uniform gravity, rather than the surface of a spherical planet. So Moppe might have: ```text WorldGravity direction = world down acceleration = 9.82 m/s² this motorcycle located_in → world participates_in→ gravitationally accelerated motion ``` `WorldGravity` might be understood either as part of the game world’s physical structure or as a law of the model. The universal would be something like **motion under Moppe gravity**, instantiated by every unsupported material body. ## Momentum belongs to the moving system Momentum is not quite like mass. - Mass is naturally treated as a quality of the motorcycle. - Velocity characterizes its motion relative to a frame. - Momentum combines the bearer’s mass with that motion: $$ \mathbf p = m\mathbf v. $$ So the current momentum is best understood as a **process magnitude** or model reading associated with the motorcycle’s motion—not an intrinsic quality the stationary motorcycle carries independently of motion. It is also reference-frame dependent. The motorcycle can have one momentum relative to the terrain and another relative to a moving glider or air mass. The ontology should therefore retain the missing argument: ```text momentum_of( this motion, relative_to = world frame ) ``` rather than treating momentum as an unqualified vector. ## Thrust has three ontological levels “Thrust” becomes especially clear when separated into universal, capability, and realization. ### 1. Propulsion function The engine or boost apparatus has a function: ```text boost system bears_function → produce thrust ``` This function persists even when the boost is idle. ### 2. Propulsive disposition or capability The system has a bounded capacity to realize that function: ```text boost system bears_disposition → produce thrust up to some magnitude ``` Charge level, damage, fuel, and temperature can condition this disposition. ### 3. Actual thrust production When activated, a concrete process realizes the function: ```text this boost burn instance_of → thrust-production process realizes → boost system’s propulsion function has_profile → thrust vector over time ``` The motorcycle participates in a resulting acceleration process. Thus “the motorcycle has thrust” can mean three different things: - it has a propulsion system as a part; - that system bears a thrust-producing function or disposition; - a thrust-producing process is occurring now. Those are ontologically distinct and mechanically useful. ## Forces describe concurrent interactions The physics equation can then be read semantically: $$ \frac{d\mathbf p}{dt} = \mathbf F_{\text{gravity}} + \mathbf F_{\text{ground}} + \mathbf F_{\text{thrust}} + \mathbf F_{\text{aerodynamic}}. $$ These are not four independent “motions” stored in the bike. They are model magnitudes associated with several concurrent interactions that jointly shape one particular motion: ```text gravitational interaction ground-contact interaction propulsion process aerodynamic interaction ↓ causally contribute to ↓ this motorcycle’s motion ``` The motion has one trajectory, but that trajectory can be understood through several process universals and causal contributions. ## The universals form a vocabulary of laws A useful universal is not merely a category name. It says what kinds of participants and relations belong to its instances: ```text GravitationalFreeFall participant: material body environment: gravitational field excludes: load-bearing support characteristic profile: downward acceleration Rolling participant: wheeled body contact: wheel–supporting-surface constraint: approximate no-slip contact characteristic profile: translation coupled to wheel rotation Gliding participant: aerodynamic lifting body medium: moving air mass characteristic profiles: airspeed, sink rate, lift, drag ThrustProduction participant: propulsion apparatus realization-of: propulsion function characteristic profile: directed force over time ``` This is more than an inheritance hierarchy. Each universal provides a small grammar for valid particulars. The resulting picture is: ```text motorcycle independent continuant mass dependent quality propulsion function realizable dependent continuant current spatial occupancy relation to spatial region current motion occurrent rolling / falling / gliding process universals velocity / momentum profiles of motion thrust profile of a propulsion process takeoff / touchdown boundaries between processes ``` The beautiful part is that the numbers remain—the simulation still needs $\mathbf x$, $\mathbf v$, $\mathbf p$, and $\mathbf F$—but each number becomes a **reading of something with an ontological kind**. The physics state stops being a bag of variables and becomes a compact measurement of a structured world. ### 29. User Yeah, so here, thinking in these terms makes me feel like, well, yeah, this is kind of like what I want from something like an entity component system. Now I feel like these things can be encoded in C++ in various ways. One way, I feel like, there is something related to, like, what is it called, CPO customization points, stuff like that, you know what I mean? ### 30. Assistant tool calls #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 10, "query": "tag_invoke customization point CPO customization_point" } ``` #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 10, "query": "concept requires template #include namespace moppe { // A partition is represented by its quotient map. Two elements occupy the // same block exactly when the map gives them equal block values. The block // type belongs to each use of the abstraction; there is no universal block // identifier. template concept Partition = std::equality_comparable && requires (const Map& partition, const Element& element) { { std::invoke (partition, element) } -> std::same_as; }; template requires Partition> constexpr bool equivalent (const Map& partition, const Element& a, const Element& b) { return std::invoke (partition, a) == std::invoke (partition, b); } } #endif Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGFydGl0aW9uLmho#content"] 2. Source file: moppe/spatial/bundle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content Size: 17471 bytes, 500 lines Matching excerpt: #ifndef MOPPE_SPATIAL_BUNDLE_HH #define MOPPE_SPATIAL_BUNDLE_HH #include #include #include #include #include #include #include #include #include #include #include // A Bundle is an eager, finite materialization of a heterogeneous section // over a domain. Values are stored by column, while BundleRow and // BundleFocus expose one typed site to local rules. Its finiteness is a // storage boundary, not a claim about a more general section calculus. namespace moppe::spatial { namespace detail { template struct NeighbourhoodProbe { template requires std::convertible_to void operator() (OtherIndex&&, Influence&&) const; }; template struct InterpolationProbe { template requires std::convertible_to && std::convertible_to void operator() (OtherIndex&&, Weight&&) const; }; } template concept FiniteDomain = std::move_constructible && requires (const Domain& domain, typename D Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content"] 3. Source file: moppe/game/river_surface.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9yaXZlcl9zdXJmYWNlLmNj#content Size: 21842 bytes, 467 lines Matching excerpt: #include #include #include #include #include #include #include namespace moppe::game { namespace river_surface_detail { constexpr float depth_span_m = 2.5f; constexpr std::array cross_positions = { -1.15f, -1.0f, -0.54f, 0.0f, 0.54f, 1.0f, 1.15f }; constexpr std::array cross_opacity = { 0.0f, 0.62f, 0.92f, 1.0f, 0.92f, 0.62f, 0.0f }; struct SurfacePoint { Vec3 position; Vec3 tangent; float width_m; // Cross-section extents to each side of the centerline. They default // to half the discharge width; across ribbon-owned pools they extend // to the probed waterline so flooded stretches keep real banks. float half_left_m; float half_right_m; float flow_distance_m; float rapid; float waterfall; float opacity; // Signed plan-view curvature in 1/m; positive when the channel bends // toward the +across direction, i.e. the bend center lies on the // +across side. float curvature_across; }; struct RibbonVertex { Vec3 position; Vec3 normal; float u; float flow_distance_m; float rapid; float depth; float waterfall; float opacity; }; using RibbonRow = std::array #include #include #include #include #include #include #include using namespace moppe; namespace { terrain::RiverAlignmentPoint river_test_point (float x, float z, float flow_distance, float area, float standing_water = 0.0f) { return { .x_m = x, .z_m = z, .flow_distance_m = flow_distance, .contributing_area_m2 = area, .slope = 0.05f, .standing_water = standing_water, .water_level_m = 6.0f }; } terrain::RiverReach reach_with_alignment () { terrain::RiverReach reach; reach.id = 0; reach.upstream_body = terrain::no_water_body; reach.downstream_body = terrain::no_water_body; reach.downstream_reach = terrain::RiverReach::no_id; reach.alignment.points = { river_test_point (40, 10, -30, 25000), river_test_point (40, 20, -20, 100000), river_test_point (40, 30, -10, 400000, 0.35f), river_test_point (40, 40, 0, 1000000, 1.0f) }; for (std::size_t i = 0; i < reach.alignment.points.size (); ++i) reach.alignment.points[i].distance_m = static_cast (10 * i); reach.alignment.length = 30.0 * mp_units::si::metre; return reach; } } MOPPE_TEST (visible_river_area_scales Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9yaXZlcl9zdXJmYWNlX3Rlc3QuY2M#content"] 5. Source file: tests/terrain/drainage_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvdGVycmFpbi9kcmFpbmFnZV90ZXN0LmNj#content Size: 18442 bytes, 391 lines Matching excerpt: #include #include #include #include #include #include #include using namespace moppe::terrain; MOPPE_TEST (d8_drainage_routes_to_the_steepest_lower_neighbor) { const std::array heights { 30.0f, 20.0f, 30.0f, 20.0f, 0.0f, 20.0f, 30.0f, 20.0f, 30.0f }; const ElevationMap terrain = make_elevation_map ( TerrainDomain ( 3, 3, 2.0f * mp_units::si::metre, 2.0f * mp_units::si::metre), heights); const DrainageGraph graph = analyze_drainage (terrain); MOPPE_CHECK (graph.sinks.size () == 1); MOPPE_CHECK (graph.sinks[0] == 4); for (std::uint32_t cell = 0; cell < 9; ++cell) MOPPE_CHECK (graph.receiver[cell] == 4); MOPPE_CHECK_NEAR (graph.contributing_area.sample (1, 1).numerical_value_in ( mp_units::si::metre * mp_units::si::metre), 36.0f, 0.0f); MOPPE_CHECK_NEAR ( graph.slope.sample (0, 0).numerical_value_in (mp_units::one), 30.0f / std::sqrt (8.0f), 1e-6f); } MOPPE_TEST (periodic_drainage_crosses_the_wrap) { // Cell (0,0) reaches the low point at (2,0) by crossing the wrap. const std::array heights { 2.0f, 3.0f, 0.0f, 4.0f, 4.0f, 4.0f, 4.0f, 4.0f, 4.0f }; const Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvdGVycmFpbi9kcmFpbmFnZV90ZXN0LmNj#content"] 6. Source file: moppe/game/hud.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9odWQuaGg#content Size: 3789 bytes, 104 lines Matching excerpt: #ifndef MOPPE_GAME_HUD_HH #define MOPPE_GAME_HUD_HH #include #include #include namespace moppe { namespace render { class Renderer; } namespace game { // Game state consumed by the compact overlay. Hud::draw clamps // normalized inputs before deriving dial geometry. struct HudState { // length(active_vehicle().velocity()) * 3.6f; ignored (treated // as 0) while on_foot, as at the old call site. float speed_kmh; // active_vehicle().boost_charge(): 0..1. Drives the boost dial's // blue reserve arc; ignored (treated as 1.0) on foot. float boost_ready01; // m_health / 100: 0..1. Drives the health bar fill and color. float health01; // m_odometer: meters ridden; displayed as km with one decimal. float odometer_m; // m_lives: 0..10 filled hearts. int lives; // m_star_field.collected(): the "x N" star counter. int stars; // Accumulated stunt score and the current/resulting long jump. int score; float airtime_s; float landed_airtime_s; int landed_points; float landed_age_s; // m_mode == M_FOOT: zeroes the speed, parks the boost dial and // shows the "ON FOOT" tag. bool on_foot; // Soaring reuses the speed cluster as an airspeed instrum Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9odWQuaGg#content"] 7. Source file: tests/map/surface_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvbWFwL3N1cmZhY2VfdGVzdC5jYw#content Size: 18236 bytes, 433 lines Matching excerpt: #include #include #include #include #include #include #include #include #include #include #include namespace { float elevation_value (const moppe::map::SurfaceElevation& elevation) { return elevation.quantity_from_zero ().numerical_value_in (moppe::u::m); } moppe::Vec3 normal_value (const moppe::map::SurfaceNormal& normal) { return normal.numerical_value_in (mp_units::one); } void check_surface_vector (const moppe::Vec3& actual, const moppe::Vec3& expected, float tolerance = 1e-6f) { MOPPE_CHECK_NEAR (actual[0], expected[0], tolerance); MOPPE_CHECK_NEAR (actual[1], expected[1], tolerance); MOPPE_CHECK_NEAR (actual[2], expected[2], tolerance); } moppe::terrain::MoistureMap moisture_map (const moppe::map::SurfaceDomain& domain, std::span samples) { std::vector values; values.reserve (samples.size ()); for (float sample : samples) values.push_back (sample * moppe::terrain::surface_moisture[mp_units::one]); ret Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvbWFwL3N1cmZhY2VfdGVzdC5jYw#content"] 8. Source file: moppe/terrain/trail.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi90cmFpbC5jYw#content Size: 68294 bytes, 1546 lines Matching excerpt: #include #include #include #include #include #include #include #include #include #include #include #include #include #include namespace moppe::terrain { namespace { constexpr float maximum_traversable_grade = 0.85f; float shoulder_ramp (float distance, float half_width, float blend) { if (distance <= half_width) return 1.0f; if (blend <= 0.0f) return 0.0f; const float t = std::min ((distance - half_width) / blend, 1.0f); const float smooth = t * t * (3.0f - 2.0f * t); return 1.0f - smooth; } float receiver_distance_m (std::size_t cell, std::size_t receiver, const TerrainDomain& grid) { const int width = static_cast (grid.width ()); const int height = static_cast (grid.height ()); int dx = static_cast (receiver % width) - static_cast (cell % width); int dy = static_cast (receiver / width) - static_cast (cell / width); if (dx > width / 2) dx -= width; if (dx < -width / 2) dx += width; if (dy > height / 2) dy -= height; if (dy < -height / 2) dy += height; return Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi90cmFpbC5jYw#content"] 9. Source file: moppe/game/cinematic_flight.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaW5lbWF0aWNfZmxpZ2h0LmNj#content Size: 39889 bytes, 938 lines Matching excerpt: #include #include #include #include #include namespace moppe::game { namespace { constexpr terrain::CellIndex no_cell = terrain::no_cell; struct FeatureCandidate { terrain::CellIndex cell = no_cell; float score = -std::numeric_limits::infinity (); Vec3 direction { 0, 0, 1 }; }; float clamp_length (Vec3& value, float maximum) { const float magnitude = length (value); if (magnitude > maximum && magnitude > 1e-5f) value *= maximum / magnitude; return magnitude; } int flight_minimum_image_delta (int delta, int period) { if (delta > period / 2) delta -= period; else if (delta < -period / 2) delta += period; return delta; } Vec3 unwrap_near (Vec3 point, const Vec3& reference, const map::Surface& map) { const Vec3 size = map.world_extent (); for (int axis : { 0, 2 }) { while (point[axis] - reference[axis] > size[axis] * 0.5f) point[axis] -= size[axis]; while (point[axis] - reference[axis] < -size[axis] * 0.5f) point[axis] += size[axis]; } return point; } float flight_height_sample (const map::Surface& map, int x, int z) { x = terrain::wrap_index (x, map.width ()); z = terrain::wrap_index (z, map.height Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9jaW5lbWF0aWNfZmxpZ2h0LmNj#content"] 10. Source file: moppe/game/hud.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9odWQuY2M#content Size: 24839 bytes, 674 lines Matching excerpt: #include #include #include #include #include #include namespace moppe { namespace game { using render::DrawList; using render::Prim; // ---- instrument cluster drawing helpers -------------------------- namespace { const float PI = 3.14159265f; struct Point { float x; float y; Point () : x (0), y (0) {} Point (float px, float py) : x (px), y (py) {} }; struct Rect { float x; float y; float width; float height; Rect (float px, float py, float w, float h) : x (px), y (py), width (w), height (h) {} }; struct Dial { Point center; float radius; Dial () : radius (0) {} Dial (const Point& c, float r) : center (c), radius (r) {} Point at (float radius_scale, float angle_deg) const { const float a = angle_deg * PI / 180.0f; return Point (center.x + radius_scale * radius * std::cos (a), center.y - radius_scale * radius * std::sin (a)); } }; // Positions are local to two anchors: the status panel's top-left // and the instrument cluster's bottom-right. Mini dials are derived // from the speed dial, keeping their column aligned by construction. struct HudLayout { Rect status; Point cluster_anchor; Dial speed; Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9odWQuY2M#content"] Approximate matches 1. Source file: planning/tracks/current-engine-refactoring/items/ENG-020-localize-transform-validation.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMjAtbG9jYWxpemUtdHJhbnNmb3JtLXZhbGlkYXRpb24ubWQ#content Size: 1417 bytes, 39 lines Score: 0.016 Related excerpt: +++ id = "ENG-020" title = "Localize terrain-transform validation and editing semantics" rfc = "RFC-0001" track = "current-engine-refactoring" status = "done" depends_on = ["ENG-002"] order = 60 areas = ["terrain", "terrain-lab"] +++ # Localize terrain-transform validation and editing semantics ## Outcome Each terrain transform owns its validation, identity, semantics, and editable description, rather than contributing another arm to central switchboards. ## Scope Start with `validate_program` and its adjacent variant dispatch. Preserve the current `TerrainProgram` value and evaluator contract. ## Acceptance - Adding a transform has one obvious local implementation path. - Program validation no longer dominates terrain control-flow complexity. - Invalid programs still fail with useful, stable diagnostics. ## Evidence Every concrete transform now owns `validate`, `description`, `detail`, and editable-property methods. `validate_program` and the Terrain Lab use only generic variant visitation, so no type-specific validation, identity, semantics, or property rows remain in their switchboards. Focused program tests cover each transform's description and property count plus stable inval Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMjAtbG9jYWxpemUtdHJhbnNmb3JtLXZhbGlkYXRpb24ubWQ#content"] 2. Source file: .clang-format Resource: https://m.sheaf.less.rest/3CV92Z/source-files/LmNsYW5nLWZvcm1hdA#content Size: 716 bytes, 27 lines Score: 0.016 Related excerpt: BasedOnStyle: LLVM AccessModifierOffset: -2 AlignAfterOpenBracket: Align AllowShortBlocksOnASingleLine: Empty AllowShortFunctionsOnASingleLine: Empty AllowShortIfStatementsOnASingleLine: Never AllowShortLoopsOnASingleLine: false AlwaysBreakTemplateDeclarations: Yes BinPackArguments: false BinPackParameters: false BreakBeforeBraces: Attach ColumnLimit: 80 ContinuationIndentWidth: 2 Cpp11BracedListStyle: false DerivePointerAlignment: false FixNamespaceComments: false IndentCaseLabels: false IndentPPDirectives: None IndentWidth: 2 NamespaceIndentation: All PointerAlignment: Left QualifierAlignment: Leave SpaceBeforeCpp11BracedList: true SpaceBeforeParens: Always SpacesInAngles: Never TabWidth: 8 UseTab: Never Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/LmNsYW5nLWZvcm1hdA#content"] 3. Source file: moppe/platform/tvos/Info.plist.in Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGxhdGZvcm0vdHZvcy9JbmZvLnBsaXN0Lmlu#content Size: 1239 bytes, 44 lines Score: 0.016 Related excerpt: CFBundleDevelopmentRegion English CFBundleDisplayName Moppe CFBundleExecutable ${MACOSX_BUNDLE_EXECUTABLE_NAME} CFBundleIdentifier ${MACOSX_BUNDLE_GUI_IDENTIFIER} CFBundleInfoDictionaryVersion 6.0 CFBundleName ${MACOSX_BUNDLE_BUNDLE_NAME} CFBundlePackageType APPL CFBundleShortVersionString ${MACOSX_BUNDLE_SHORT_VERSION_STRING} CFBundleVersion ${MACOSX_BUNDLE_BUNDLE_VERSION} GCSupportedGameControllers ProfileName ExtendedGamepad ProfileName MicroGamepad GCSupportsControllerUserInteraction ITSAppUsesNonExemptEncryption LSRequiresIPhoneOS UILaunchScreen Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGxhdGZvcm0vdHZvcy9JbmZvLnBsaXN0Lmlu#content"] 4. Source file: CMakePresets.json Resource: https://m.sheaf.less.rest/3CV92Z/source-files/Q01ha2VQcmVzZXRzLmpzb24#content Size: 2032 bytes, 79 lines Score: 0.016 Related excerpt: { "version": 6, "cmakeMinimumRequired": { "major": 3, "minor": 24, "patch": 0 }, "configurePresets": [ { "name": "homebrew-llvm", "displayName": "Homebrew LLVM (macOS)", "description": "Configure a Homebrew LLVM unity analysis build and export compile commands.", "generator": "Ninja", "binaryDir": "${sourceDir}/build-homebrew", "toolchainFile": "${sourceDir}/cmake/toolchains/homebrew-llvm.cmake", "cacheVariables": { "CMAKE_EXPORT_COMPILE_COMMANDS": "ON", "MOPPE_UNITY_BUILD": "ON", "BUILD_TESTING": "OFF" } }, { "name": "xcode", "displayName": "Xcode (macOS)", "description": "Generate the Moppe macOS project for Xcode.", "generator": "Xcode", "binaryDir": "${sourceDir}/build-xcode", "cacheVariables": { "BUILD_TESTING": "OFF", "MOPPE_BUILD_DEVELOPER_TOOLS": "OFF" } }, { "name": "tracy", "displayName": "Tracy profiling (macOS)", "description": "Optimized Moppe build with on-demand Tracy profiling.", "generator": "Ninja", "binaryDir": "${sourceDir}/build-tracy", "cacheVariables": { "BUILD_TESTING": "OFF", "MOPPE_BUILD_DEVELOPER_TOOLS": "OFF", "MOPPE_ENABLE_TRACY": "ON" } } ], "buildPresets": [ { "name": "homebrew-llvm", "displayName": "Homebrew LLVM", "configurePreset": "homebrew-llvm" Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/Q01ha2VQcmVzZXRzLmpzb24#content"] 5. Source file: moppe/platform/mac/Info.plist.in Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGxhdGZvcm0vbWFjL0luZm8ucGxpc3QuaW4#content Size: 887 bytes, 27 lines Score: 0.015 Related excerpt: CFBundleDevelopmentRegion English CFBundleExecutable ${MACOSX_BUNDLE_EXECUTABLE_NAME} CFBundleIdentifier ${MACOSX_BUNDLE_GUI_IDENTIFIER} CFBundleInfoDictionaryVersion 6.0 CFBundleName ${MACOSX_BUNDLE_BUNDLE_NAME} CFBundlePackageType APPL CFBundleShortVersionString ${MACOSX_BUNDLE_SHORT_VERSION_STRING} CFBundleVersion ${MACOSX_BUNDLE_BUNDLE_VERSION} NSHighResolutionCapable NSPrincipalClass NSApplication Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGxhdGZvcm0vbWFjL0luZm8ucGxpc3QuaW4#content"] 6. Source file: moppe/profile.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcHJvZmlsZS5oaA#content Size: 1281 bytes, 36 lines Score: 0.015 Related excerpt: #pragma once #include // Tracy compiles these macros away completely in ordinary builds. Keeping // the dependency behind this small vocabulary lets Moppe's profiling map stay // meaningful without spreading profiler-specific names through the game. #if defined(TRACY_ENABLE) #include #include #include namespace moppe::profile { inline void wait_for_profiler () { while (!TracyIsConnected) std::this_thread::sleep_for (std::chrono::milliseconds (1)); } } #define MOPPE_PROFILE_FRAME() FrameMark #define MOPPE_PROFILE_PLOT(name, value) \ TracyPlot (name, static_cast (value)) #define MOPPE_PROFILE_THREAD(name) tracy::SetThreadName (name) #define MOPPE_PROFILE_ZONE(name) ZoneScopedN (name) #define MOPPE_PROFILE_NAMED_ZONE(variable, name) \ ZoneNamedN (variable, name, true) #define MOPPE_PROFILE_WAIT() ::moppe::profile::wait_for_profiler () #else #define MOPPE_PROFILE_FRAME() ((void)0) #define MOPPE_PROFILE_PLOT(name, value) ((void)0) #define MOPPE_PROFILE_THREAD(name) ((void)0) #define MOPPE_PROFILE_ZONE(name) ((void)0) #define MOPPE_PROFILE_NAMED_ZONE(variable, name) ((void)0) #define MOPPE_PROFILE_WAIT() ((void)0) #endif Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcHJvZmlsZS5oaA#content"] 7. Source file: cmake/toolchains/homebrew-llvm.cmake Resource: https://m.sheaf.less.rest/3CV92Z/source-files/Y21ha2UvdG9vbGNoYWlucy9ob21lYnJldy1sbHZtLmNtYWtl#content Size: 1177 bytes, 31 lines Score: 0.015 Related excerpt: # Configure CMake with the Homebrew LLVM toolchain. Homebrew LLVM can lag the # active Xcode SDK, so prefer the matching Command Line Tools SDK when present. find_program(MOPPE_BREW_EXECUTABLE brew REQUIRED) execute_process( COMMAND "${MOPPE_BREW_EXECUTABLE}" --prefix llvm@20 RESULT_VARIABLE MOPPE_BREW_LLVM_RESULT OUTPUT_VARIABLE MOPPE_BREW_LLVM_PREFIX OUTPUT_STRIP_TRAILING_WHITESPACE) if(NOT MOPPE_BREW_LLVM_RESULT EQUAL 0) execute_process( COMMAND "${MOPPE_BREW_EXECUTABLE}" --prefix llvm RESULT_VARIABLE MOPPE_BREW_LLVM_RESULT OUTPUT_VARIABLE MOPPE_BREW_LLVM_PREFIX OUTPUT_STRIP_TRAILING_WHITESPACE) endif() if(NOT MOPPE_BREW_LLVM_RESULT EQUAL 0) message(FATAL_ERROR "Install Homebrew LLVM with: brew install llvm") endif() set(CMAKE_CXX_COMPILER "${MOPPE_BREW_LLVM_PREFIX}/bin/clang++" CACHE FILEPATH "") set(CMAKE_OBJCXX_COMPILER "${MOPPE_BREW_LLVM_PREFIX}/bin/clang++" CACHE FILEPATH "") set(MOPPE_CLT_SDK "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk") if(APPLE AND EXISTS "${MOPPE_CLT_SDK}" AND NOT CMAKE_OSX_SYSROOT) set(CMAKE_OSX_SYSROOT "${MOPPE_CLT_SDK}" CACHE PATH "macOS SDK used with Homebrew LLVM") endif() Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/Y21ha2UvdG9vbGNoYWlucy9ob21lYnJldy1sbHZtLmNtYWtl#content"] 8. Source file: moppe/platform/ios/Info.plist.in Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGxhdGZvcm0vaW9zL0luZm8ucGxpc3QuaW4#content Size: 1221 bytes, 40 lines Score: 0.015 Related excerpt: CFBundleDevelopmentRegion English CFBundleExecutable ${MACOSX_BUNDLE_EXECUTABLE_NAME} CFBundleIdentifier ${MACOSX_BUNDLE_GUI_IDENTIFIER} CFBundleInfoDictionaryVersion 6.0 CFBundleDisplayName Moppe CFBundleName ${MACOSX_BUNDLE_BUNDLE_NAME} CFBundlePackageType APPL CFBundleShortVersionString ${MACOSX_BUNDLE_SHORT_VERSION_STRING} CFBundleVersion ${MACOSX_BUNDLE_BUNDLE_VERSION} ITSAppUsesNonExemptEncryption LSRequiresIPhoneOS UILaunchScreen UIRequiresFullScreen UIStatusBarHidden UISupportedInterfaceOrientations UIInterfaceOrientationLandscapeLeft UIInterfaceOrientationLandscapeRight Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGxhdGZvcm0vaW9zL0luZm8ucGxpc3QuaW4#content"] 9. Source file: planning/tracks/current-engine-refactoring/items/ENG-001-trustworthy-complexity-report.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMDEtdHJ1c3R3b3J0aHktY29tcGxleGl0eS1yZXBvcnQubWQ#content Size: 1234 bytes, 38 lines Score: 0.014 Related excerpt: +++ id = "ENG-001" title = "Make the complexity report trustworthy under unity builds" rfc = "RFC-0001" track = "current-engine-refactoring" status = "done" depends_on = [] order = 10 areas = ["tools", "build"] +++ # Make the complexity report trustworthy under unity builds ## Outcome The report analyzes only the current repository's intended C++ sources and associates cognitive-complexity diagnostics with their original files. ## Scope Use an analysis-specific non-unity compilation database and enumerate only sources under `moppe/` from it. Exclude build products, copied worktrees, tests, and unrelated tools unless a separate report explicitly requests them. ## Acceptance - `make complexity` produces a current-source-only CSV. - Cyclomatic and cognitive rows refer to the same original source locations. - The report documents which source roots and build configuration it used. ## Evidence `make complexity` generated 867 rows from 62 `moppe/` sources with the non-unity `homebrew-llvm` preset. Its `complexity-metadata.json` records the source roots and disabled unity/test configuration; every CSV location names an existing source beneath `moppe/`. The standalone `moppe` target built Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMDEtdHJ1c3R3b3J0aHktY29tcGxleGl0eS1yZXBvcnQubWQ#content"] 10. Source file: planning/tracks/current-engine-refactoring/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL1JFQURNRS5tZA#content Size: 2639 bytes, 63 lines Score: 0.014 Related excerpt: # Current-engine refactoring (completed) This is the completed executable track for [RFC-0001](../../rfcs/0001-current-engine-refactoring.md). It was a dependency graph, not a release calendar: work could happen in parallel when nodes were independent, and an item became `ready` only when its declared dependencies were `done`. All 19 work items are now `done`; the graph is preserved as the decision and validation history behind the current [engine atlas] (../../../docs/engine-atlas.md). The first item intentionally repairs the complexity instrument. The earlier report showed real cyclomatic concentration, but unity builds currently make its cognitive column and scan scope unreliable. We should not steer a large refactor with a crooked compass. ```mermaid flowchart LR ENG001["ENG-001: trustworthy complexity report"] ENG002["ENG-002: characterize seams"] ENG010["ENG-010: one Bundle"] ENG011["ENG-011: SurfaceAtlas"] ENG012["ENG-012: presentation bridge"] ENG020["ENG-020: local transform validation"] ENG021["ENG-021: WorldRecipe"] ENG022["ENG-022: GeneratedWorld"] ENG023["ENG-023: async world handoff"] ENG030["ENG-030: InputFrame"] ENG031["ENG-031: GameSession"] ENG032["ENG-032: public Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL1JFQURNRS5tZA#content"] ### 32. Tool result: search_text Exact matches 1. Source file: moppe/spatial/bundle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content Size: 17471 bytes, 500 lines Matching excerpt: #ifndef MOPPE_SPATIAL_BUNDLE_HH #define MOPPE_SPATIAL_BUNDLE_HH #include #include #include #include #include #include #include #include #include #include #include // A Bundle is an eager, finite materialization of a heterogeneous section // over a domain. Values are stored by column, while BundleRow and // BundleFocus expose one typed site to local rules. Its finiteness is a // storage boundary, not a claim about a more general section calculus. namespace moppe::spatial { namespace detail { template struct NeighbourhoodProbe { template requires std::convertible_to void operator() (OtherIndex&&, Influence&&) const; }; template struct InterpolationProbe { template requires std::convertible_to && std::convertible_to void operator() (OtherIndex&&, Weight&&) const; }; } template concept FiniteDomain = std::move_constructible && requires (const Domain& domain, typename D Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content"] 2. Source file: moppe/terrain/types.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi90eXBlcy5oaA#content Size: 3511 bytes, 107 lines Matching excerpt: #ifndef MOPPE_TERRAIN_TYPES_HH #define MOPPE_TERRAIN_TYPES_HH #include #include #include #include #include namespace moppe::terrain { struct Seed { std::uint32_t value; friend constexpr bool operator== (Seed, Seed) = default; }; constexpr Seed next_seed (Seed seed) { return Seed { seed.value + 1 }; } template struct Identifier { std::uint32_t value; constexpr Identifier () noexcept : value (0) {} constexpr Identifier (std::uint32_t value) noexcept : value (value) {} // Hydrology arrays are dense and indexed by these values. This conversion // keeps indexing cheap; construction and assignment remain nominal. constexpr operator std::uint32_t () const noexcept { return value; } friend constexpr bool operator== (Identifier, Identifier) = default; template friend constexpr bool operator== (Identifier id, I value) noexcept { return id.value == static_cast (value); } template friend constexpr bool operator== (I value, Identifier id) noexcept { return static_cast (value) == id.value; } template requires (!std::same_as #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::Bundle; using moppe::spatial::bundle_values; using moppe::spatial::BundleFocus; using moppe::spatial::extend_into; using moppe::spatial::get; using moppe::spatial::laplacian; namespace { struct AtelierFourSites { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 4; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } }; struct AtelierThreeSiteRing { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 3; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } template constexpr void visit_neighbourhood (index_type index, Visitor&& visitor) const { visitor ((index + 2) % 3, 0.25f); visitor ((index + 1) % 3, 0.75f); } }; struct AtelierSquar Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9idW5kbGVfdGVzdC5jYw#content"] 4. Source file: moppe/partition.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGFydGl0aW9uLmho#content Size: 1077 bytes, 30 lines Matching excerpt: #ifndef MOPPE_PARTITION_HH #define MOPPE_PARTITION_HH #include #include namespace moppe { // A partition is represented by its quotient map. Two elements occupy the // same block exactly when the map gives them equal block values. The block // type belongs to each use of the abstraction; there is no universal block // identifier. template concept Partition = std::equality_comparable && requires (const Map& partition, const Element& element) { { std::invoke (partition, element) } -> std::same_as; }; template requires Partition> constexpr bool equivalent (const Map& partition, const Element& a, const Element& b) { return std::invoke (partition, a) == std::invoke (partition, b); } } #endif Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcGFydGl0aW9uLmho#content"] 5. Source file: atelier/tree.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content Size: 7467 bytes, 207 lines Matching excerpt: #pragma once #include "atelier/space.hh" #include #include #include #include #include #include #include #include // A tree is an oriented one-dimensional complex. The topology remembers // lineage and incidence; typed bundles carry the organism's intrinsic state. // Neither layer says where the tree currently happens to be in world space. namespace atelier { using TreeVertexId = std::size_t; using TreeEdgeId = std::size_t; inline constexpr TreeEdgeId no_tree_edge = static_cast (-1); struct TreeVertex { std::size_t generation; std::uint64_t lineage; }; enum class TreeOrgan { shoot, root }; struct TreeEdge { TreeVertexId parent; TreeVertexId child; std::size_t branch_order; bool continues_axis; TreeOrgan organ = TreeOrgan::shoot; }; class DirectedTreeTopology { public: DirectedTreeTopology (std::vector vertices, std::vector edges); [[nodiscard]] std::size_t vertex_count () const noexcept; [[nodiscard]] std::size_t edge_count () const noexcept; [[nodiscard]] const TreeVertex& vertex (TreeVertexId id) const; [[nodiscard]] const TreeEdge& edge (TreeEdgeId id) cons Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content"] 6. Source file: moppe/terrain/fractional_drainage.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9mcmFjdGlvbmFsX2RyYWluYWdlLmho#content Size: 10177 bytes, 261 lines Matching excerpt: #ifndef MOPPE_TERRAIN_FRACTIONAL_DRAINAGE_HH #define MOPPE_TERRAIN_FRACTIONAL_DRAINAGE_HH #include #include #include #include #include #include #include #include #include #include namespace moppe::terrain { struct FloodField; struct LakeCensus; // The unique samples of a materialized terrain. Unlike SurfaceDomain, this // domain omits the duplicated rendering seam and exposes the intrinsic // neighbourhood used by geological analyses. class TerrainLatticeDomain { public: using index_type = CellIndex; explicit TerrainLatticeDomain (TerrainDomain domain); const TerrainDomain& terrain_domain () const noexcept { return m_domain; } std::size_t width () const noexcept { return m_domain.width (); } std::size_t height () const noexcept { return m_domain.height (); } std::size_t size () const noexcept { return m_domain.size (); } std::size_t offset (CellIndex index) const; CellIndex index (std::size_t offset) const; std::optional neighbour (CellIndex index, int columns, int rows) const; template void visit Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9mcmFjdGlvbmFsX2RyYWluYWdlLmho#content"] 7. Source file: atelier/space.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9zcGFjZS5oaA#content Size: 4992 bytes, 128 lines Matching excerpt: #pragma once #include #include #include #include #include #include #ifdef __APPLE__ #include #endif // The atelier's model space: a three-dimensional metric stage. // // Everything the scene reasons about is a genuine quantity: lengths in // metres, time in seconds, and angles in the strong angular system, so // a bare number can never pose as an angle. Spatial values divide in // the affine style into points (places) and displacements (differences // of places); points admit no addition or scaling, so the compiler // keeps the geometry honest. Bare floats exist only past the GPU // bridge at the bottom of this file. namespace atelier { namespace si = mp_units::si; namespace isq = mp_units::isq; namespace angular = mp_units::angular; using mp_units::absolute_point_origin; using mp_units::quantity; using mp_units::quantity_point; using mp_units::quantity_spec; using Real = float; using Vec3 = mp_units::utility::cartesian_vector; using Length = quantity; using Duration = quanti Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9zcGFjZS5oaA#content"] 8. Source file: moppe/terrain/elevation_map.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9lbGV2YXRpb25fbWFwLmho#content Size: 2179 bytes, 59 lines Matching excerpt: #ifndef MOPPE_TERRAIN_ELEVATION_MAP_HH #define MOPPE_TERRAIN_ELEVATION_MAP_HH #include #include #include #include #include #include #include #include #include namespace moppe::terrain { using ElevationMap = spatial::Bundle; template concept TerrainElevations = requires { typename std::remove_cvref_t::domain_type; } && std::same_as::domain_type, TerrainDomain> && spatial::BundleContains>; template std::span elevations (const Bundle& terrain) noexcept { return spatial::get (terrain); } template requires std::same_as>, float> ElevationMap make_elevation_map (TerrainDomain domain, Samples&& samples) { const std::span values (std::ranges::data (samples), std::ranges::size (samples)); if (values.size () != domain.size ()) t Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9lbGV2YXRpb25fbWFwLmho#content"] 9. Source file: moppe/gfx/math.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2Z4L21hdGguaGg#content Size: 9776 bytes, 310 lines Matching excerpt: #ifndef MOPPE_MATH_HH #define MOPPE_MATH_HH #include #include #include #include #include #include #include #include #include namespace moppe { using namespace mp_units; // Quantity literals: 90 * u::deg, 2.5f * u::m, 60 * u::Hz. namespace u { using namespace mp_units::si::unit_symbols; } inline constexpr float PI = std::numbers::pi_v; inline constexpr float PI2 = 2.0f * PI; using seconds_t = quantity; using degrees_t = quantity; using radians_t = quantity; using magnitude_t = quantity; using speed_t = quantity; using velocity_component_t = quantity; using acceleration_component_t = quantity (si::second)], float>; using newtons_t = quantity; using watts_t = quantity; using kilograms_t = quantity; // Dimension-one kinds from moppe/quantities.hh. using proportion_t = Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2Z4L21hdGguaGg#content"] 10. Source file: moppe/game/graphics_benchmark.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9ncmFwaGljc19iZW5jaG1hcmsuaGg#content Size: 8256 bytes, 267 lines Matching excerpt: #ifndef MOPPE_GAME_GRAPHICS_BENCHMARK_HH #define MOPPE_GAME_GRAPHICS_BENCHMARK_HH #include #include #include #include #include #include #include #include #include #include #include #include namespace moppe::game { inline constexpr float GRAPHICS_BENCHMARK_DT = 1.0f / 120.0f; template concept GraphicsFeaturePartition = requires { typename P::block_type; } && Partition; template concept NamedFiniteGraphicsFeaturePartition = GraphicsFeaturePartition

&& requires { P::blocks; } && std::ranges::forward_range && std::same_as, typename P::block_type> && requires (typename P::block_type block) { { P::name (block) } -> std::convertible_to; }; inline uint32_t gray_code (uint32_t index) { return index ^ (index >> 1); } // The ordinary riding benchmark preserves the four distinctions that have // shown measurable cost, including rivers, and deliberately identifies t Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9ncmFwaGljc19iZW5jaG1hcmsuaGg#content"] Approximate matches 1. Source file: moppe/spatial/bundle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content Size: 17471 bytes, 500 lines Score: 0.042 Related excerpt: #ifndef MOPPE_SPATIAL_BUNDLE_HH #define MOPPE_SPATIAL_BUNDLE_HH #include #include #include #include #include #include #include #include #include #include #include // A Bundle is an eager, finite materialization of a heterogeneous section // over a domain. Values are stored by column, while BundleRow and // BundleFocus expose one typed site to local rules. Its finiteness is a // storage boundary, not a claim about a more general section calculus. namespace moppe::spatial { namespace detail { template struct NeighbourhoodProbe { template requires std::convertible_to void operator() (OtherIndex&&, Influence&&) const; }; template struct InterpolationProbe { template requires std::convertible_to && std::convertible_to void operator() (OtherIndex&&, Weight&&) const; }; } template concept FiniteDomain = std::move_constructible && requires (const Domain& domain, typename D Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content"] 2. Source file: moppe/gfx/math.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2Z4L21hdGguaGg#content Size: 9776 bytes, 310 lines Score: 0.032 Related excerpt: y - a.z * q.z; return *this; } inline QuaternionG conjugate () const { return QuaternionG (-x, -y, -z, w); } T length () const { return std::sqrt (x * x + y * y + z * z + w * w); } }; template inline QuaternionG operator* (QuaternionG a, const QuaternionG& b) { a *= b; return a; } using Vec3 = Vec3T; using Quaternion = QuaternionG; // Physical spatial vectors keep one unit around one numerical vector. The // simulation can migrate fields to these types incrementally without ever // constructing a vector whose individual elements are quantities. using position_t = quantity; using displacement_t = quantity; using spatial_extent_t = quantity; using velocity_t = quantity; using acceleration_t = quantity (si::second)], Vec3>; using force_t = quantity; inline position_t position (const Vec3& value) { return value * isq::position_vector[si::metre]; } inline displacement_t displacement (const Vec3& value) { return value * isq::displacemen Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2Z4L21hdGguaGg#content"] 3. Source file: docs/units.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy91bml0cy5tZA#content Size: 28065 bytes, 600 lines Score: 0.027 Related excerpt: e. Trail guidance uses continuous grades of 8–10% for accessible or casual use even where 12–16% may be structurally sustainable (`#D33DUB`). It also gives hillslope-to-trail grade ratios around 2:1 to 3:1 (`#SFWHTE`). These are dimensionless ratios, whereas a 10-degree biomechanical incline is an angle; they must not share an unlabeled `slope` control. Road examples add feature sizes such as 50–300 m tunnel and bridge masks on grids with 10 m spacing (`#WJSTC2`). A racing example combines a 4.5 km circuit, friction coefficient `mu = 0.90`, peak acceleration near `0.9 g`, lap time in seconds, and a controller rate of 200 Hz (`#8AQDAB`, `#3LSFWC`). Geometry, material response, dynamics, and control frequency are distinct even when they all influence whether a route feels traversable. ## Scaling and similarity A visually small world cannot preserve every real-world scale at once. When compressing space or geological time, decide what the model is meant to preserve: drainage topology, channel width relative to vehicle size, sediment budget, characteristic slope, flood travel time, or visual legibility. Geometric scaling alone is insufficient for dynamics. If lengths are scaled by a fa Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy91bml0cy5tZA#content"] 4. Source file: moppe/quantities.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcXVhbnRpdGllcy5oaA#content Size: 4830 bytes, 128 lines Score: 0.016 Related excerpt: #ifndef MOPPE_QUANTITIES_HH #define MOPPE_QUANTITIES_HH #include #include #include #include namespace moppe { using mp_units::non_negative; using mp_units::quantity_spec; using meters_t = mp_units::quantity; using meters_f64_t = mp_units::quantity; using square_meters_t = mp_units::quantity; using cubic_meters_t = mp_units::quantity; using cubic_meters_f64_t = mp_units::quantity; using meters_per_second_t = mp_units::quantity; using julian_years_t = mp_units::quantity; using meters_per_julian_year_t = mp_units::quantity; using square_meters_per_julian_year_t = mp_units::quantity; inline float meter Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcXVhbnRpdGllcy5oaA#content"] 5. Source file: tests/units_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvdW5pdHNfdGVzdC5jYw#content Size: 2153 bytes, 56 lines Score: 0.016 Related excerpt: #include #include #include namespace { using namespace mp_units; using namespace mp_units::si::unit_symbols; MOPPE_TEST (mp_units_is_available_to_project_targets) { const auto distance = 125 * m; const auto duration = 5 * s; const auto speed = distance / duration; MOPPE_CHECK (speed == 25 * m / s); } // Vec3 is mp-units' built-in Cartesian representation: indexed // access gives it tensor order 1, norm() supplies the magnitude, and // scalar algebra makes it scalable, so vector-character quantities // can carry it (unit outside, numerical vector inside). static_assert (RepresentationOf); static_assert (QuantityOf); static_assert (QuantityOf); static_assert (QuantityOf); static_assert (QuantityOf); MOPPE_TEST (vector3d_is_a_vector_quantity_representation) { const quantity displacement = moppe::Vec3 (3, 4, 0) * isq::displacement[m]; // The magnitude of a vector quantity is a scalar quantity. MOPPE_CHECK (displacement.magnitude () == 5 * m) Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvdW5pdHNfdGVzdC5jYw#content"] 6. Source file: moppe/terrain/terrain_quantities.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi90ZXJyYWluX3F1YW50aXRpZXMuaGg#content Size: 2382 bytes, 66 lines Score: 0.015 Related excerpt: #ifndef MOPPE_TERRAIN_TERRAIN_QUANTITIES_HH #define MOPPE_TERRAIN_TERRAIN_QUANTITIES_HH #include #include #include namespace moppe::terrain { // A point in the world's vertical reference frame. Terrain storage uses // metres directly; differences between elevations are ordinary lengths. inline constexpr struct surface_elevation : quantity_spec { } surface_elevation; using SurfaceElevation = quantity_point; inline SurfaceElevation surface_elevation_point (meters_t value) { return SurfaceElevation (meters_value (value) * surface_elevation[u::m]); } inline float surface_elevation_value (SurfaceElevation value) { return value.quantity_from_zero ().numerical_value_in (u::m); } inline constexpr struct terrain_normal : quantity_spec { } terrain_normal; using TerrainNormal = mp_units::quantity; inline constexpr struct surface_moisture : quantity_spec { } surface_moisture Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi90ZXJyYWluX3F1YW50aXRpZXMuaGg#content"] 7. Source file: moppe/terrain/types.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi90eXBlcy5oaA#content Size: 3511 bytes, 107 lines Score: 0.015 Related excerpt: #ifndef MOPPE_TERRAIN_TYPES_HH #define MOPPE_TERRAIN_TYPES_HH #include #include #include #include #include namespace moppe::terrain { struct Seed { std::uint32_t value; friend constexpr bool operator== (Seed, Seed) = default; }; constexpr Seed next_seed (Seed seed) { return Seed { seed.value + 1 }; } template struct Identifier { std::uint32_t value; constexpr Identifier () noexcept : value (0) {} constexpr Identifier (std::uint32_t value) noexcept : value (value) {} // Hydrology arrays are dense and indexed by these values. This conversion // keeps indexing cheap; construction and assignment remain nominal. constexpr operator std::uint32_t () const noexcept { return value; } friend constexpr bool operator== (Identifier, Identifier) = default; template friend constexpr bool operator== (Identifier id, I value) noexcept { return id.value == static_cast (value); } template friend constexpr bool operator== (I value, Identifier id) noexcept { return static_cast (value) == id.value; } template requires (!std::same_as #include #include #include #include #include #ifdef __APPLE__ #include #endif // The atelier's model space: a three-dimensional metric stage. // // Everything the scene reasons about is a genuine quantity: lengths in // metres, time in seconds, and angles in the strong angular system, so // a bare number can never pose as an angle. Spatial values divide in // the affine style into points (places) and displacements (differences // of places); points admit no addition or scaling, so the compiler // keeps the geometry honest. Bare floats exist only past the GPU // bridge at the bottom of this file. namespace atelier { namespace si = mp_units::si; namespace isq = mp_units::isq; namespace angular = mp_units::angular; using mp_units::absolute_point_origin; using mp_units::quantity; using mp_units::quantity_point; using mp_units::quantity_spec; using Real = float; using Vec3 = mp_units::utility::cartesian_vector; using Length = quantity; using Duration = quanti Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9zcGFjZS5oaA#content"] 9. Source file: tests/atelier/bundle_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9idW5kbGVfdGVzdC5jYw#content Size: 6383 bytes, 183 lines Score: 0.015 Related excerpt: #include #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::Bundle; using moppe::spatial::bundle_values; using moppe::spatial::BundleFocus; using moppe::spatial::extend_into; using moppe::spatial::get; using moppe::spatial::laplacian; namespace { struct AtelierFourSites { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 4; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } }; struct AtelierThreeSiteRing { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 3; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } template constexpr void visit_neighbourhood (index_type index, Visitor&& visitor) const { visitor ((index + 2) % 3, 0.25f); visitor ((index + 1) % 3, 0.75f); } }; struct AtelierSquar Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9idW5kbGVfdGVzdC5jYw#content"] 10. Source file: tests/spatial/bundle_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvc3BhdGlhbC9idW5kbGVfdGVzdC5jYw#content Size: 2562 bytes, 80 lines Score: 0.014 Related excerpt: #include #include #include #include using namespace moppe; namespace { struct ThreeSiteRing { using index_type = std::size_t; constexpr std::size_t size () const { return 3; } constexpr std::size_t offset (index_type index) const { return index; } constexpr index_type index (std::size_t offset) const { return offset; } template void visit_neighbourhood (index_type index, Visitor&& visitor) const { visitor ((index + 2) % 3, 0.25f); visitor ((index + 1) % 3, 0.75f); } }; inline constexpr struct test_displacement : quantity_spec { } test_displacement; inline constexpr auto test_velocity = test_displacement / mp_units::isq::duration; using TestDisplacement = quantity; using TestVelocity = quantity; using TestBundle = spatial::Bundle; } MOPPE_TEST (bundle_exposes_quantity_columns_and_rows_by_specification) { TestBundle bundle (ThreeSiteRing {}); auto& [displacement, velocity] = bundle; displacement[1] = 2.0f * test_displacement[u::m]; velocity[ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvc3BhdGlhbC9idW5kbGVfdGVzdC5jYw#content"] ### 33. Tool result: search_text Exact matches 1. Source file: moppe/spatial/bundle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content Size: 17471 bytes, 500 lines Matching excerpt: #ifndef MOPPE_SPATIAL_BUNDLE_HH #define MOPPE_SPATIAL_BUNDLE_HH #include #include #include #include #include #include #include #include #include #include #include // A Bundle is an eager, finite materialization of a heterogeneous section // over a domain. Values are stored by column, while BundleRow and // BundleFocus expose one typed site to local rules. Its finiteness is a // storage boundary, not a claim about a more general section calculus. namespace moppe::spatial { namespace detail { template struct NeighbourhoodProbe { template requires std::convertible_to void operator() (OtherIndex&&, Influence&&) const; }; template struct InterpolationProbe { template requires std::convertible_to && std::convertible_to void operator() (OtherIndex&&, Weight&&) const; }; } template concept FiniteDomain = std::move_constructible && requires (const Domain& domain, typename D Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content"] 2. Source file: docs/surface-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content Size: 6695 bytes, 107 lines Matching excerpt: # The current-engine surface atlas This is the small atlas for Moppe's adopted Atelier earth vocabulary. It describes the current engine, not the proposed second engine. The purpose is to make its topology, intrinsic readings, and rendering bridge enumerable. For the wider ownership, state, presentation, and target map, start with the [engine atlas](engine-atlas.md). ## Storeys | Storey | Current object | Responsibility | | --- | --- | --- | | Combinatorial | `map::SurfaceDomain` | The finite toroidal vertex lattice, index/offset correspondence, horizontal spacing, and bilinear reconstruction stencil. | | Intrinsic | `map::SurfaceAtlas`, `map::WaterSurfaceSections` | Typed 0-cochains sharing the lattice but kept in named ground groups and a distinct water bundle. `map::Surface` owns the authoritative ground geometry and its later analyses. | | Extrinsic | `game::SurfacePresentation`, `game::WaterPresentation` | Convert typed columns to plain scalar texture payloads and upload them through `render::Renderer`. These are the quantity-to-number bridges. | Terrain generation writes the mandatory geometry bundle directly. Hydrology, geology, ecology, and use add readings at later, named Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content"] 3. Source file: docs/atelier-earth.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content Size: 15763 bytes, 318 lines Matching excerpt: # The Atelier earth A proposal to widen the atelier's scope: from a studio of small organisms (the tree, the carpet, the cellular sheet) to a second implementation of the engine itself, begun again from the foundations of the earth. This is not a refactor of moppe and not a port. Moppe continues to run, generate, and play. The atelier grows a world beside it, small and whole at every stage, made of the semantic material we have learned to want: typed quantities, affine frames, rank-graded domains, sections, and a discrete calculus — with Metal as the prime instance substrate. Where moppe discovered these ideas mid-flight and carries them partially, the atelier bakes them in from the first line. The two meet later by adoption, organ by organ, never by conversion. ## What "engine" means here Not "motorcycle game." The engine is a simulation of a world: - a **combinatorial storey** — finite topologies: lattices, trees, sheets; vertices, edges, faces; incidence and orientation. No positions live here. - an **intrinsic storey** — typed sections over those topologies: bundles whose columns are labelled by mp-units quantity specifications. Elevation is a point-valued 0-cochain; a flow is Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content"] 4. Source file: docs/terrain-expressions.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90ZXJyYWluLWV4cHJlc3Npb25zLm1k#content Size: 7006 bytes, 174 lines Matching excerpt: # Terrain generation and analysis Moppe has one finite terrain lattice and one authoritative ground bundle. Generation creates typed columns over that lattice; ordered transforms mutate the elevation and material-history columns; analyses return named finite products. There is no runtime field-expression language or general materialization backend. ## The common domain `terrain::TerrainDomain` owns: - periodic width and height; - physical X/Z sample spacing; - cell area and world periods; - checked index/offset conversion; - the bilinear stencil used for continuous sampling. An NxN domain is N periodic cells. It stores no duplicated seam. CPU neighbours and GPU texel reads wrap at N. `map::SurfaceDomain` is an alias for this type. Terrain generation, surface geometry, flood, drainage, merge trees, trails, waterlines, and water surfaces therefore exchange the same domain value rather than translating between grid descriptions. ## Typed finite bundles `spatial::Bundle` stores one native vector per quantity specification over a finite domain. A row is one site; a focus is a site plus its domain position for local rules. `spatial::get` selects a column by mea Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90ZXJyYWluLWV4cHJlc3Npb25zLm1k#content"] 5. Source file: moppe/map/water_surface.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbWFwL3dhdGVyX3N1cmZhY2UuaGg#content Size: 1767 bytes, 58 lines Matching excerpt: #ifndef MOPPE_MAP_WATER_SURFACE_HH #define MOPPE_MAP_WATER_SURFACE_HH #include #include namespace moppe::terrain { struct WaterSheets; } namespace moppe::map { inline constexpr struct wave_amplitude : quantity_spec { } wave_amplitude; inline constexpr struct water_velocity : quantity_spec { } water_velocity; using WaveAmplitude = quantity; using WaterVelocity = quantity; using WaterSurfaceSections = spatial:: Bundle; // Standing and running water sampled over the terrain lattice. Elevation // shares the ground's affine frame; amplitude and velocity describe the // water itself and therefore live in a distinct bundle. class WaterSurface { public: // Painted water sheets and the ground share one lattice. WaterSurface (SurfaceDomain domain, const terrain::WaterSheets& sheets); WaterSurface (SurfaceDomain domain, std::span level_and_amplitude, std::span planar_flow); const WaterSurfaceSections Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbWFwL3dhdGVyX3N1cmZhY2UuaGg#content"] 6. Source file: moppe/map/surface_sections.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbWFwL3N1cmZhY2Vfc2VjdGlvbnMuaGg#content Size: 4008 bytes, 97 lines Matching excerpt: #ifndef MOPPE_MAP_SURFACE_SECTIONS_HH #define MOPPE_MAP_SURFACE_SECTIONS_HH #include #include #include namespace moppe::map { using terrain::surface_elevation; using terrain::SurfaceElevation; // The upward component of a broad local support plane. Snow responds to // this material-scale reading rather than the detailed lighting normal. inline constexpr struct snow_support : quantity_spec { } snow_support; inline constexpr struct eroded_surface_material : quantity_spec { } eroded_surface_material; inline constexpr struct deposited_surface_material : quantity_spec { } deposited_surface_material; // Planar channel direction scaled by log-compressed fluvial activity. inline constexpr struct channel_flux : quantity_spec { } channel_flux; using terrain::surface_moisture; using terrain::waterline_distance; // Normalized exposure of material removed during the world's history. inline constexpr struct e Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbWFwL3N1cmZhY2Vfc2VjdGlvbnMuaGg#content"] 7. Source file: planning/tracks/current-engine-refactoring/items/ENG-010-consolidate-finite-bundle.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMTAtY29uc29saWRhdGUtZmluaXRlLWJ1bmRsZS5tZA#content Size: 1254 bytes, 39 lines Matching excerpt: +++ id = "ENG-010" title = "Consolidate the finite typed Bundle abstraction" rfc = "RFC-0001" track = "current-engine-refactoring" status = "done" depends_on = ["ENG-002"] order = 30 areas = ["spatial", "atelier"] +++ # Consolidate the finite typed Bundle abstraction ## Outcome Terrain sections and Atelier organism state use one shared finite, columnar, quantity-spec-labelled bundle implementation. ## Scope Move common behavior deliberately and migrate both consumers. Do not broaden the finite abstraction into a speculative general section calculus here. ## Acceptance - There is one implementation of `Bundle`, `BundleRow`, `BundleFocus`, and spec-based `get`. - Surface and tree tests retain their present semantics. - The duplicate Atelier implementation is removed rather than wrapped. ## Evidence `cmake --build build --target moppe-tests` and `ctest --test-dir build --output-on-failure` pass, including the surface and Atelier tree/bundle semantics. `cmake --build build --target atelier` also passes. `atelier::Tree` and `atelier::HexSheet` now name `moppe::spatial::Bundle` directly, and `atelier/bundle.hh` is removed; the shared header is the only implementation of `Bundle`, `Bundle Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMTAtY29uc29saWRhdGUtZmluaXRlLWJ1bmRsZS5tZA#content"] 8. Source file: docs/engine-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9lbmdpbmUtYXRsYXMubWQ#content Size: 12439 bytes, 222 lines Matching excerpt: # Moppe engine atlas This is the reader's map of the current engine after RFC-0001. It names the values that make up a world, the mutable state that rides it, the immutable reading that presents a frame, and the CMake targets that carry those boundaries. Read it before the detailed subsystem documents; the `current-engine-refactoring` track is retained as the history of how this shape was reached, not as the architecture reference. ## One world, one frame The main flow is data and borrows, not a generic scene graph or an ownership diagram for CMake: ```mermaid flowchart LR recipe["WorldRecipe"] --> build["direct world construction"] build --> world["GeneratedWorld"] world --> session["GameSession"] world --> view["FrameView"] session --> view view --> scene["world, actor, water, effect, HUD presentation"] scene --> renderer["render::Renderer"] renderer --> metal["Metal backend"] renderer --> webgpu["WebGPU backend"] app["application: loading, input, mode selection"] --> build app --> session app --> view ``` `GeneratedWorld` is the stable owner of one completed landscape. `GameSession` is the mutable life played on that landscape. `FrameView` is a new immutable reading composed for Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9lbmdpbmUtYXRsYXMubWQ#content"] 9. Source file: docs/lattice-harmonization.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9sYXR0aWNlLWhhcm1vbml6YXRpb24ubWQ#content Size: 8995 bytes, 178 lines Matching excerpt: # Lattice harmonization The game is a couple dozen named fields on one lattice, plus a motorcycle. The seamless-torus and authoritative-surface passes removed the two largest historical splits: duplicated seam storage and the 2008 height-map hierarchy. This document records what landed and the smaller harmonization work that remains. ## Decisions - **The world is a torus.** `Topology::Bounded` and every `periodic ()` conditional are deleted, not preserved. - **Storage is the unique lattice.** The duplicated seam row/column dies. A 2048-resolution torus stores 2048x2048 samples; spacing = extent/2048. Wrap is owned by the sampling boundary: CPU interpolation wraps indices, GPU shaders wrap texel fetches with period = texture size. - Default resolutions become powers of two: 2048 (play/research), 1024 (fast). - Test fixtures convert once, to the final semantics: an NxN map is N periodic cells, spacing = size/N. ## Stage: seamless torus (done) Touch points, surveyed: - `terrain/topology.hh` — Topology enum deleted; carriers drop the field (`TerrainGrid`, `TerrainDiscretization`, recipes, `WorldParams`, `SurfaceDomain`). - `TerrainGrid.unique_width/height/size` — deleted; there is only Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9sYXR0aWNlLWhhcm1vbml6YXRpb24ubWQ#content"] 10. Source file: tests/atelier/bundle_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9idW5kbGVfdGVzdC5jYw#content Size: 6383 bytes, 183 lines Matching excerpt: #include #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::Bundle; using moppe::spatial::bundle_values; using moppe::spatial::BundleFocus; using moppe::spatial::extend_into; using moppe::spatial::get; using moppe::spatial::laplacian; namespace { struct AtelierFourSites { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 4; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } }; struct AtelierThreeSiteRing { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 3; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } template constexpr void visit_neighbourhood (index_type index, Visitor&& visitor) const { visitor ((index + 2) % 3, 0.25f); visitor ((index + 1) % 3, 0.75f); } }; struct AtelierSquar Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9idW5kbGVfdGVzdC5jYw#content"] Approximate matches 1. Source file: moppe/spatial/bundle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content Size: 17471 bytes, 500 lines Score: 0.048 Related excerpt: #ifndef MOPPE_SPATIAL_BUNDLE_HH #define MOPPE_SPATIAL_BUNDLE_HH #include #include #include #include #include #include #include #include #include #include #include // A Bundle is an eager, finite materialization of a heterogeneous section // over a domain. Values are stored by column, while BundleRow and // BundleFocus expose one typed site to local rules. Its finiteness is a // storage boundary, not a claim about a more general section calculus. namespace moppe::spatial { namespace detail { template struct NeighbourhoodProbe { template requires std::convertible_to void operator() (OtherIndex&&, Influence&&) const; }; template struct InterpolationProbe { template requires std::convertible_to && std::convertible_to void operator() (OtherIndex&&, Weight&&) const; }; } template concept FiniteDomain = std::move_constructible && requires (const Domain& domain, typename D Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvc3BhdGlhbC9idW5kbGUuaGg#content"] 2. Source file: docs/lattice-harmonization.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9sYXR0aWNlLWhhcm1vbml6YXRpb24ubWQ#content Size: 8995 bytes, 178 lines Score: 0.028 Related excerpt: # Lattice harmonization The game is a couple dozen named fields on one lattice, plus a motorcycle. The seamless-torus and authoritative-surface passes removed the two largest historical splits: duplicated seam storage and the 2008 height-map hierarchy. This document records what landed and the smaller harmonization work that remains. ## Decisions - **The world is a torus.** `Topology::Bounded` and every `periodic ()` conditional are deleted, not preserved. - **Storage is the unique lattice.** The duplicated seam row/column dies. A 2048-resolution torus stores 2048x2048 samples; spacing = extent/2048. Wrap is owned by the sampling boundary: CPU interpolation wraps indices, GPU shaders wrap texel fetches with period = texture size. - Default resolutions become powers of two: 2048 (play/research), 1024 (fast). - Test fixtures convert once, to the final semantics: an NxN map is N periodic cells, spacing = size/N. ## Stage: seamless torus (done) Touch points, surveyed: - `terrain/topology.hh` — Topology enum deleted; carriers drop the field (`TerrainGrid`, `TerrainDiscretization`, recipes, `WorldParams`, `SurfaceDomain`). - `TerrainGrid.unique_width/height/size` — deleted; there is only Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9sYXR0aWNlLWhhcm1vbml6YXRpb24ubWQ#content"] 3. Source file: moppe/gfx/math.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2Z4L21hdGguaGg#content Size: 9776 bytes, 310 lines Score: 0.027 Related excerpt: y - a.z * q.z; return *this; } inline QuaternionG conjugate () const { return QuaternionG (-x, -y, -z, w); } T length () const { return std::sqrt (x * x + y * y + z * z + w * w); } }; template inline QuaternionG operator* (QuaternionG a, const QuaternionG& b) { a *= b; return a; } using Vec3 = Vec3T; using Quaternion = QuaternionG; // Physical spatial vectors keep one unit around one numerical vector. The // simulation can migrate fields to these types incrementally without ever // constructing a vector whose individual elements are quantities. using position_t = quantity; using displacement_t = quantity; using spatial_extent_t = quantity; using velocity_t = quantity; using acceleration_t = quantity (si::second)], Vec3>; using force_t = quantity; inline position_t position (const Vec3& value) { return value * isq::position_vector[si::metre]; } inline displacement_t displacement (const Vec3& value) { return value * isq::displacemen Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2Z4L21hdGguaGg#content"] 4. Source file: tests/atelier/bundle_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9idW5kbGVfdGVzdC5jYw#content Size: 6383 bytes, 183 lines Score: 0.016 Related excerpt: #include #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::Bundle; using moppe::spatial::bundle_values; using moppe::spatial::BundleFocus; using moppe::spatial::extend_into; using moppe::spatial::get; using moppe::spatial::laplacian; namespace { struct AtelierFourSites { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 4; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } }; struct AtelierThreeSiteRing { using index_type = std::size_t; [[nodiscard]] constexpr std::size_t size () const { return 3; } [[nodiscard]] constexpr std::size_t offset (index_type index) const { return index; } [[nodiscard]] constexpr index_type index (std::size_t offset) const { return offset; } template constexpr void visit_neighbourhood (index_type index, Visitor&& visitor) const { visitor ((index + 2) % 3, 0.25f); visitor ((index + 1) % 3, 0.75f); } }; struct AtelierSquar Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9idW5kbGVfdGVzdC5jYw#content"] 5. Source file: planning/tracks/current-engine-refactoring/items/ENG-010-consolidate-finite-bundle.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMTAtY29uc29saWRhdGUtZmluaXRlLWJ1bmRsZS5tZA#content Size: 1254 bytes, 39 lines Score: 0.015 Related excerpt: +++ id = "ENG-010" title = "Consolidate the finite typed Bundle abstraction" rfc = "RFC-0001" track = "current-engine-refactoring" status = "done" depends_on = ["ENG-002"] order = 30 areas = ["spatial", "atelier"] +++ # Consolidate the finite typed Bundle abstraction ## Outcome Terrain sections and Atelier organism state use one shared finite, columnar, quantity-spec-labelled bundle implementation. ## Scope Move common behavior deliberately and migrate both consumers. Do not broaden the finite abstraction into a speculative general section calculus here. ## Acceptance - There is one implementation of `Bundle`, `BundleRow`, `BundleFocus`, and spec-based `get`. - Surface and tree tests retain their present semantics. - The duplicate Atelier implementation is removed rather than wrapped. ## Evidence `cmake --build build --target moppe-tests` and `ctest --test-dir build --output-on-failure` pass, including the surface and Atelier tree/bundle semantics. `cmake --build build --target atelier` also passes. `atelier::Tree` and `atelier::HexSheet` now name `moppe::spatial::Bundle` directly, and `atelier/bundle.hh` is removed; the shared header is the only implementation of `Bundle`, `Bundle Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvdHJhY2tzL2N1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nL2l0ZW1zL0VORy0wMTAtY29uc29saWRhdGUtZmluaXRlLWJ1bmRsZS5tZA#content"] 6. Source file: tests/spatial/bundle_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvc3BhdGlhbC9idW5kbGVfdGVzdC5jYw#content Size: 2562 bytes, 80 lines Score: 0.015 Related excerpt: #include #include #include #include using namespace moppe; namespace { struct ThreeSiteRing { using index_type = std::size_t; constexpr std::size_t size () const { return 3; } constexpr std::size_t offset (index_type index) const { return index; } constexpr index_type index (std::size_t offset) const { return offset; } template void visit_neighbourhood (index_type index, Visitor&& visitor) const { visitor ((index + 2) % 3, 0.25f); visitor ((index + 1) % 3, 0.75f); } }; inline constexpr struct test_displacement : quantity_spec { } test_displacement; inline constexpr auto test_velocity = test_displacement / mp_units::isq::duration; using TestDisplacement = quantity; using TestVelocity = quantity; using TestBundle = spatial::Bundle; } MOPPE_TEST (bundle_exposes_quantity_columns_and_rows_by_specification) { TestBundle bundle (ThreeSiteRing {}); auto& [displacement, velocity] = bundle; displacement[1] = 2.0f * test_displacement[u::m]; velocity[ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvc3BhdGlhbC9idW5kbGVfdGVzdC5jYw#content"] 7. Source file: atelier/space.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9zcGFjZS5oaA#content Size: 4992 bytes, 128 lines Score: 0.015 Related excerpt: #pragma once #include #include #include #include #include #include #ifdef __APPLE__ #include #endif // The atelier's model space: a three-dimensional metric stage. // // Everything the scene reasons about is a genuine quantity: lengths in // metres, time in seconds, and angles in the strong angular system, so // a bare number can never pose as an angle. Spatial values divide in // the affine style into points (places) and displacements (differences // of places); points admit no addition or scaling, so the compiler // keeps the geometry honest. Bare floats exist only past the GPU // bridge at the bottom of this file. namespace atelier { namespace si = mp_units::si; namespace isq = mp_units::isq; namespace angular = mp_units::angular; using mp_units::absolute_point_origin; using mp_units::quantity; using mp_units::quantity_point; using mp_units::quantity_spec; using Real = float; using Vec3 = mp_units::utility::cartesian_vector; using Length = quantity; using Duration = quanti Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9zcGFjZS5oaA#content"] 8. Source file: docs/terrain-expressions.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90ZXJyYWluLWV4cHJlc3Npb25zLm1k#content Size: 7006 bytes, 174 lines Score: 0.014 Related excerpt: # Terrain generation and analysis Moppe has one finite terrain lattice and one authoritative ground bundle. Generation creates typed columns over that lattice; ordered transforms mutate the elevation and material-history columns; analyses return named finite products. There is no runtime field-expression language or general materialization backend. ## The common domain `terrain::TerrainDomain` owns: - periodic width and height; - physical X/Z sample spacing; - cell area and world periods; - checked index/offset conversion; - the bilinear stencil used for continuous sampling. An NxN domain is N periodic cells. It stores no duplicated seam. CPU neighbours and GPU texel reads wrap at N. `map::SurfaceDomain` is an alias for this type. Terrain generation, surface geometry, flood, drainage, merge trees, trails, waterlines, and water surfaces therefore exchange the same domain value rather than translating between grid descriptions. ## Typed finite bundles `spatial::Bundle` stores one native vector per quantity specification over a finite domain. A row is one site; a focus is a site plus its domain position for local rules. `spatial::get` selects a column by mea Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90ZXJyYWluLWV4cHJlc3Npb25zLm1k#content"] 9. Source file: docs/surface-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content Size: 6695 bytes, 107 lines Score: 0.014 Related excerpt: # The current-engine surface atlas This is the small atlas for Moppe's adopted Atelier earth vocabulary. It describes the current engine, not the proposed second engine. The purpose is to make its topology, intrinsic readings, and rendering bridge enumerable. For the wider ownership, state, presentation, and target map, start with the [engine atlas](engine-atlas.md). ## Storeys | Storey | Current object | Responsibility | | --- | --- | --- | | Combinatorial | `map::SurfaceDomain` | The finite toroidal vertex lattice, index/offset correspondence, horizontal spacing, and bilinear reconstruction stencil. | | Intrinsic | `map::SurfaceAtlas`, `map::WaterSurfaceSections` | Typed 0-cochains sharing the lattice but kept in named ground groups and a distinct water bundle. `map::Surface` owns the authoritative ground geometry and its later analyses. | | Extrinsic | `game::SurfacePresentation`, `game::WaterPresentation` | Convert typed columns to plain scalar texture payloads and upload them through `render::Renderer`. These are the quantity-to-number bridges. | Terrain generation writes the mandatory geometry bundle directly. Hydrology, geology, ecology, and use add readings at later, named Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content"] 10. Source file: moppe/quantities.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcXVhbnRpdGllcy5oaA#content Size: 4830 bytes, 128 lines Score: 0.014 Related excerpt: #ifndef MOPPE_QUANTITIES_HH #define MOPPE_QUANTITIES_HH #include #include #include #include namespace moppe { using mp_units::non_negative; using mp_units::quantity_spec; using meters_t = mp_units::quantity; using meters_f64_t = mp_units::quantity; using square_meters_t = mp_units::quantity; using cubic_meters_t = mp_units::quantity; using cubic_meters_f64_t = mp_units::quantity; using meters_per_second_t = mp_units::quantity; using julian_years_t = mp_units::quantity; using meters_per_julian_year_t = mp_units::quantity; using square_meters_per_julian_year_t = mp_units::quantity; inline float meter Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcXVhbnRpdGllcy5oaA#content"] ### 34. Assistant Yes—I think you mean **customization point objects**: named operations such as `std::ranges::begin`, where different concrete types can provide their own realization without inheriting from a common base class. That has a strong affinity with the ontology idea. A CPO can provide a single, stable name for an ontological relation or reading while allowing motorcycles, gliders, trees, terrain cells, snapshots, and replays to represent it differently. But there is an important distinction: > A CPO can express how we **ask about** an ontological relation; it does not by itself store or constitute that relation. ## A semantic query vocabulary Instead of an ECS-style operation like: ```cpp get (entity) ``` you could ask: ```cpp spatial_location (snapshot, bike); motion_of (snapshot, bike); participants (motion); bearer_of (quality); parts_of (bike); attachment_of (snapshot, bike); ``` That difference is significant. `get` exposes a storage decision. `spatial_location(snapshot, bike)` names what the answer *means*. The concrete implementation might retrieve a rigid-body pose, derive a position from an attachment, sample a trajectory, or reconstruct a location from replay state. The caller need not know. ## A possible CPO Using the general `tag_invoke` idiom, it could resemble: ```cpp struct spatial_location_t { template requires tag_invocable constexpr auto operator() ( const World& world, Entity entity ) const noexcept ( nothrow_tag_invocable< spatial_location_t, const World&, Entity>) -> tag_invoke_result_t< spatial_location_t, const World&, Entity> { return tag_invoke (*this, world, entity); } }; inline constexpr spatial_location_t spatial_location; ``` A session snapshot could then customize it: ```cpp friend OccupiedRegion tag_invoke ( spatial_location_t, const SessionSnapshot& snapshot, MotorcycleId bike) { const RigidPose pose = snapshot.motorcycle_pose (bike); return transform (pose, snapshot.motorcycle_shape (bike)); } ``` Whereas an attached motorcycle could derive its pose through the glider configuration: ```cpp friend OccupiedRegion tag_invoke ( spatial_location_t, const FlightSnapshot& snapshot, AttachedMotorcycle bike) { const RigidPose glider_pose = pose_of (snapshot, bike.glider); const RigidPose bike_pose = glider_pose * bike.tether_configuration; return transform (bike_pose, bike.shape); } ``` Both answer the same ontological question. They do not need the same storage representation. ## The world should be an argument I think this is especially important: ```cpp spatial_location (world, entity) ``` is more truthful than: ```cpp entity.position () ``` Location does not inhere intrinsically in the entity. It belongs to a relation between: - an entity; - a spatial region; - a world or reference body; - an instant or snapshot. Likewise: ```cpp velocity_of (motion, relative_to (world_frame)); ``` is more truthful than: ```cpp entity.velocity () ``` The first form leaves room for ground-relative velocity, airspeed, glider-relative motion, and universal-cover displacement without pretending they are one unqualified property. ## CPOs could correspond to relations, not components A compact vocabulary might include: ```cpp // Mereology parts_of proper_part_of // Dependence bearer_of qualities_of functions_of dispositions_of // Spatial relations spatial_location occupies pose_relative_to contact_between supported_by // Process relations motion_of participants realizes initiates terminates process_profile // Configuration attached_to mounted_on tethered_to ``` Then concepts can state which questions make sense: ```cpp template concept SpatiallyLocated = requires (const World& world, Entity entity) { spatial_location (world, entity); }; template concept MovingMaterialBody = MaterialBody && requires (const Snapshot& snapshot, Body body) { motion_of (snapshot, body); pose_relative_to ( snapshot, body, world_frame (snapshot)); }; ``` This is closer to an ontological grammar than a component mask. ## Universals need nominal types too CPOs represent the shared vocabulary of relations and queries. The universals themselves could be nominal type-level values, much as Moppe already gives quantity universals distinct `quantity_spec` identities: ```cpp struct motion_process {}; struct gravitational_motion : motion_process {}; struct supported_motion : motion_process {}; struct rolling : supported_motion {}; struct skidding : supported_motion {}; struct aerodynamic_flight : motion_process {}; struct gliding : aerodynamic_flight {}; struct thrust_production : process {}; ``` A particular process would then instantiate one or more universals: ```cpp ProcessInstance jump { .id = ..., .participants = { bike }, .universals = { motion_process, gravitational_motion, aerodynamic_flight } }; ``` Some classifications are known statically; others are necessarily dynamic. The C++ type system should encode invariants, but it should not force every transient fact into a distinct compile-time entity type. ## A useful three-layer separation I would separate the design into: ### 1. Universal vocabulary Nominal types or values: ```cpp rolling gliding boost_charge propulsion_function ``` Moppe’s quantity specs already demonstrate this pattern: `airspeed` and `rate_of_climb` remain distinct even though both use $\mathrm{m/s}$. ### 2. Ontological relations and readings CPOs: ```cpp spatial_location (snapshot, bike) motion_of (snapshot, bike) process_profile (motion, air_frame) realizes (boost_burn, propulsion_function) ``` ### 3. Concrete representations Domain-specific values: ```cpp VehicleState GliderState RigidPose Trajectory AttachmentConfiguration ProcessRecord FrameView Replay ``` This means the ontology does not dictate one universal storage system. A motorcycle can remain an efficient concrete value, while a replay, renderer snapshot, and simulation session all expose compatible semantic readings. ## Why this may be better than a conventional ECS A conventional ECS usually says: ```text entity has component X ``` A CPO-based ontological vocabulary can distinguish: ```text quality inheres in bearer part belongs to whole object occupies region participant takes part in process process realizes function body is attached to another body snapshot represents a relation ``` Those are not interchangeable forms of “has.” The repository already contains pieces of this style. `quantity_spec` gives semantic identities to magnitudes; `spatial::Bundle` retrieves columns by those specifications; `Partition` is defined behaviorally as a quotient map rather than by inheritance. There is no CPO framework currently, but the code is already moving toward **nominal semantic vocabulary plus concepts plus concrete models**. The most promising first experiment would be one very small query surface around the motorcycle and glider: ```cpp pose_relative_to spatial_location motion_of velocity_profile supported_by attached_to ``` implemented for both live `GameSession` state and immutable `FrameView`/checkpoint readings. That would test whether CPOs really provide an ontological interface rather than merely disguising component lookup. ### 35. User Let's also look at the against Fantology kind of stuff. ### 36. Assistant tool calls #### Tool call: `get_document` ```json { "id": "CGE2NC" } ``` ### 37. Tool result: get_document DOCUMENT #CGE2NC Title: Against Fantology Outline: - 1 #SFAYRE Against Fantology - 1.1 #J6X7B4 1. Introduction - 1.2 #WMS82X 2. History - 1.3 #K8PYLN 3. The Secret Doctrine - 1.4 #KFAUX3 4. The Spreadsheet Ontology - 1.5 #V2DRED 5. The Picture Theory - 1.6 #77SZY4 6. The Special Case of Mathematics - 1.7 #T3V2BX 7. First-Order Logic as Characteristica Universalis - 1.8 #C2K4WC 8. All Generality Belongs to the Predicate - 1.9 #QNF4XD 9. Reality is Made of Atoms ('Bare Particulars') - 1.10 #DXU96N 10. ... and Sets - 1.11 #PVQQC7 11. Particulars are Unknowable - 1.12 #5JU942 12. Predication is Functional Application - 1.13 #WKX2QZ 13. The Vanishing Copula - 1.14 #8EKBDV 14. All Particulars are Bare Particulars - 1.15 #QK6C6U 15. A Peculiar Insensitivity to Time - 1.16 #63LUN3 16. Poor Treatment of Relations - 1.17 #W2NUZ7 17. Booleanism - 1.18 #MW9JFA 18. No Room for Dependent Continuants - 1.19 #ZAUEPE 19. A New, Enhanced Davidsonism - 1.20 #CCHP6D 20. Predicates Do Not Represent - 1.21 #HKGX5U Acknowledgements - 1.22 #HLYX3V References ### 38. Assistant tool calls #### Tool call: `read` ```json { "blocks": [ "KFAUX3", "QNF4XD", "PVQQC7", "QK6C6U", "63LUN3", "W2NUZ7", "MW9JFA", "ZAUEPE", "CCHP6D" ], "expand": true } ``` ### 39. Tool result: read DOCUMENT #CGE2NC Against Fantology SECTION #KFAUX3 4. The Spreadsheet Ontology EXCERPT #PSR7FP p. 3 We can gain some impression of what more recent fantological philosophy looks like by considering what Armstrong was once pleased to call his “Spreadsheet Ontology” (see Armstrong 2004, a work published only in French). EXCERPT #27FLQD p. 3 F G H I J K L M N O P Q R S T U ... a x x x x x b x x x x x c x x x x x d x x e x x x x f x x x x x g x x x x x h x x x x i x x x x j x x x x x ... EXCERPT #8TUXEE p. 3 Figure 1: Armstrong’s Spreadsheet Ontology EXCERPT #Y7TY94 p. 3 Reality, we are to suppose, is made up of concrete individuals ( a , ...) plus abstract ‘properties’ or ‘attributes’ (F, ...). The rows of Armstrong’s spreadsheet (see Figure 1) then corresponding to the individuals, the columns to the properties. When the spreadsheet has been filled in completely – a task which Armstrong seems to have believed could be left to the physicists of the future – then we will be able to read off for every object a list of its properties and for every property a list of the objects to which it applies, and in this way gain a complete assay of reality. EXCERPT #MR2WHK p. 3 EXCERPT #R4LQU8 p. 4 At the time when he advanced his Spreadsheet Ontology, Armstrong seems to have believed not only that such an essay is at least in principle possible, but further that its provision is the very goal of physics in its march towards future perfection. Wittgenstein's Tractatus , too, of course, expresses a vision along similar lines, his elementary propositions corresponding to the cells of the spreadsheet after the latter has been modified to allow some extra room for relations. David Lewis and the Carnap of the state descriptions enrich the vision by having many spreadsheets, one for each 'world', the worlds themselves enjoying a stunning mathematical elegance in virtue of the fact that they are identified with sets of propositions of simple ( Fa , Rab , etc.) forms. DOCUMENT #CGE2NC Against Fantology SECTION #QNF4XD 9. Reality is Made of Atoms ('Bare Particulars') EXCERPT #LJHYLZ p. 7 Those advocates of fantology who allow only logically simple names are then led by the doctrine which identifies ontological form with logical form in the direction of one or other atomistic conception of reality. This atomism is manifest in Armstrong's Spreadsheet Ontology and by his repeated appeals to the basic truths of some future perfected physics. But it is demonstrated most starkly in the Tractatus , which denies that there exist complex objects at levels of granularity above the level of the absolutely simple substances to which the logically proper names of the Tractatus are supposed to refer. Wittgenstein seems, indeed, to deny all ontological complexity at levels of granularity above that of the states of affairs which such objects go to form. EXCERPT #3GDQTX p. 7 Fantology has of course proved conducive not only to atomistic doctrines but also to other, associated forms of reductionism and eliminativism, including Russell's view to the effect that proper names refer to sense data. Wittgenstein's assumption that the effect that all elementary propositions are logically independent of each other likewise consolidated a resistance to holistic views about the structure of reality (thus to patterns, laws, systems). Fantologically inspired philosophy has thus also faced difficulties in doing justice in its theories to the objects of biology. Where fantology departs from atomism at all, it has normally embraced doctrines of complexity powered by set theory – and of course the central role of set theory in analytical philosophy itself has fantological roots. Alternatively, it has seen virtue in theories of 'bundles' – resting again on the assumption that the key to good ontology lies in breaking down reality into smallest bits. DOCUMENT #CGE2NC Against Fantology SECTION #PVQQC7 11. Particulars are Unknowable EXCERPT #JVASDY p. 8 EXCERPT #CMFR6F p. 9 It is not only all generality, on the fantological view, that is confined to the predicate, but also (at least on some versions of fantology) all connotation, all meaning. Names are mere ciphers – a matter of pure denotation. Thus if all truths are to be capable of being expressed in predicate-logical terms, then this implies a noumenal view of what the classical fantologists liked to call “bare particulars”, an outcome in fact explicitly embraced by Quine (Oderberg 2005). And, if (as on some standard fantological views) universals are identified as mere sets of particulars – or with functions between such sets of particulars and what some fantologists are pleased to call ‘worlds’ – then this implies a noumenal view of universals, too. We cannot express in our theories what particulars, or universals, are like; at best we can capture only a certain structure (or pattern or net or mesh) which reality somehow realizes. We cannot know what numbers are like, because even in second-order Peano arithmetic we cannot justify identifying the natural numbers with any specific omega sequence. EXCERPT #GWM63B p. 9 In the hands of some, the formal limitations on our capacity to specify such structures univocally (for example as implied by the Löwenheim-Skolem result) are held (incredibly) to be a sign of a psychological incapacity on our part to understand the corresponding objects. Here again (and now for spurious technical reasons) fantology connives to Kantian conclusions. EXCERPT #BY7MK3 p. 9 In fantological philosophy of natural science, the world itself is unknowable. At best we can appeal in Neokantian style to physics as it will exist in some never quite realized future state of epistemological perfection – a physics in which all of the differential equations will somehow have disappeared. Fantology thus implies, as in the hands of Carnap, a noumenal view of science. DOCUMENT #CGE2NC Against Fantology SECTION #QK6C6U 15. A Peculiar Insensitivity to Time EXCERPT #Z3AL8C p. 11 EXCERPT #6664AF p. 12 Because fantologists think it fitting to deal with predications about empirically existing objects in just the same way that they deal with predications about mathematical objects, this means that – because it is predications of the latter sort which wear the ontological trousers – they have developed no clear way of dealing with time. Fantologists such as Carnap were content to conceive the passage of time in terms of a sequence of static worlds, one for each time, in which all that is dynamic has been carefully eliminated. EXCERPT #5VU9UZ p. 12 The predicate logical ‘ Fa ’ had its origins, after all, in the work of Frege, who was concerned first of all with the truths of mathematics. And Frege’s logic does indeed work very well, in its way, for the formulation of many types of mathematical truths. When it comes to truths about things marked by change, however, then it needs to be extended by some sort of new machinery. EXCERPT #45T4NZ p. 12 The three alternative ways of doing this within a still recognizable predicate-logical framework are by now well known (see e.g. Lowe 2002a, p. 43f.). ‘ F holds of a at t ’ can be parsed in three ways: EXCERPT #G5YCTA p. 12 (1) the property F holds-at- t of object a (the copula is indexed by times); (2) the property F is a relation between object a and time t ; (3) the property F holds of a new special entity called ‘ a t ’ or ‘ a-at-t ’ (an object stage or phase or slice ). EXCERPT #UKW25R p. 12 That none of these alternatives for representing time has established itself as victor over the others turns on the fact that each involves a heavy price. EXCERPT #TG3HD3 p. 12 The first, which is sometimes called the adverbial solution, involves too great a departure from fantological orthodoxy – holding is no longer capable of being interpreted as functional application in the standard mathematical sense; rather it comes to signify something more like inherence or exemplification as conceived by Aristotelians. Indeed Lowe sees it as understandable why alternative (1) “should have been overlooked, at least by philosophers trained to think in terms of the categories of modern quantification or predicate logic, as it is called. For such logic simply has no place for adverbs.” (2002a, p. 47) EXCERPT #Z8BE3Q p. 12 The second seeks to simulate the temporal nature of holding by viewing each contingent property as a relation to a time. The problem here is that the result contravenes almost everything that we know about properties of almost all familiar kinds. EXCERPT #R57XL4 p. 12 The third represents, once again, a nuclear option. It amounts to sacrificing three-dimensional enduring entities for reasons which have to do (at least in part) with the desire to hold on to a trusted syntax. On this third option you yourself do not exist; rather there exists only a sequence of youish phases in continuous temporal succession. (For arguments against such views see Inwagen 2000.) EXCERPT #DA87AB p. 12 EXCERPT #J56YW9 p. 13 Nowadays, philosophers who wish to hold on to the framework of first-order logic in order to formulate their ontological views often advance one or other four-dimensionalist position which denies the existence of three-dimensional (endurant) objects but replaces them not by phases, or stages, but rather by four-dimensional (perdurant) processes. There is not Bill Clinton , but rather a certain process-of-a-Bill-Clintonizing-sort . This allows the four-dimensionalist to hold on to a timeless version of first-order logic without the need for special temporal variables or operators, since all the denizens of the four-dimensional process plenum have all their properties in timeless fashion. The problem with this view, again, is that it implies that you and I, our cells and organs, the buildings and cities in which we live, do not exist. DOCUMENT #CGE2NC Against Fantology SECTION #63LUN3 16. Poor Treatment of Relations EXCERPT #JJMCCN p. 13 The doctrine according to which relations are sets of ordered tuples, while it falls outside the syntactic repertoire of fantology that is here our primary concern, is yet clearly part of the same stable of views and has similar consequences in the form of denials of ontological distinctions hitherto (and for good reasons) accepted as a matter of course. EXCERPT #F4R2RA p. 13 The tradition found it necessary to distinguish between several radically different types of relations. First there are real material relational endurants, like love or hate, and other relational qualities (for example Jonathan's knowledge of Greek), which, like endurant entities in general, change in different ways while preserving their identity through time. There are real material relational events , like wars and conversations, kicks and kisses, relational entities which call for a treatment along roughly Davidsonian lines, like events of every other sort. There are family relations, such as is consanguineous with or is the brother of , and there are comparatives such as is taller than or is warmer than . EXCERPT #Q95W24 p. 13 When binary relations are identified with sets of ordered pairs, then all of these putatively distinct types of relations become identified. What is the adicity of your headache (a relation between your consciousness and various processes taking place in an around your brain)? What is the adicity of the Battle of Waterloo? Does John's being in love with Mary or being the cousin of Mary, consist in his being, with Mary, a term in an ordered pair belonging to a certain abstract entity in the realm of sets? Which analysis, here, comes closer to reproducing the order of ontological primacy? EXCERPT #TEK6JZ p. 13 Of course it is possible in various ways to resist the identification of relations with sets of tuples in a predicate logical framework. One can insist that, while standard model theory typically employs such sets of tuples as assignments for relational predicates, this does not mean that such sets of tuples must be part of the intended interpretations of theories formulated in the predicate logical language. EXCERPT #GFDM6L p. 13 EXCERPT #3T5WVY p. 14 Note, too, that at least one relation – the relation of set-membership itself – must remain unamenable to an analysis in terms of the relations-are-sets-of-tuples view. This relation is, in David Lewis’s terms, a mystery. (Lewis 1991) From the perspective of many adherents of fantological semantics ( inter alia in the realm of computer science), we can understand a theory only when we have provided a set-theoretic semantics for that theory and proved consistency, completeness, etc. Clearly such a doctrine can provide no help in understanding set theory itself. EXCERPT #629Q6A p. 14 According to Russell’s History of Western Philosophy the introduction of the new style ‘ Rab ’ was seen as having initiated a revolution in the treatment of relations and as representing a genuine advance in our understanding which allowed its adherents to overcome the problems which had confronted earlier thinkers, such as Aristotle and the scholastics, who (as Russell says) had been led by their own subject-predicate logic to identify relations with monadic relational properties. The ‘ Rab ’ was seen as having freed us also from the errors of those, such as Spinoza or Leibniz or Bradley (or Hegel), whose failure to understand relations had led them to embrace monistic or monadological doctrines that were an offence to common sense. As we have seen, however, when applied to the different types of relations with which we are pre-theoretically familiar, the Rab account faces considerable difficulties of its own. EXCERPT #Q9HSDV p. 14 There are many other doctrines which have been found attractive by those who fall within the gravitational field of fantology. It is fantology which lent credence to Kim’s doctrine (1976), according to which an event consists in an individual’s exemplifying a property at a time, a doctrine which assimilates real change to Cambridge change. And indeed, with its reduction of relations to sets of ordered tuples, fantology is likewise ex officio not in a position to resist the assimilation of properties (such as hardness or shape) to Cambridge properties (such as being thought about). DOCUMENT #CGE2NC Against Fantology SECTION #W2NUZ7 17. Booleanism EXCERPT #VAA4FX p. 14 Another problem with fantology, at least on some variants, concerns its treatment of properties as inhabiting a realm structured by Boolean combination. If F and G are properties, then so also are \sim F , F \vee G , F \wedge G , F \rightarrow G , F \leftrightarrow G , F \wedge \sim G , and so on – as if establishing the properties in reality was a matter not of empirical science but of logic. (See Meixner 1992, for a particularly severe strain of the Boolean fantological orthodoxy, and Newman 1992 for an alternative view.) EXCERPT #HAXCPB p. 14 This Booleanism – which is properly at home not in ontology but rather in logic or mathematics – derives from Frege’s assimilation of predicates to sentences via his notion of unsaturatedness. Predicates are, as one says, ‘open sentences’. At the same time they correspond to what is general in reality (somewhat confusingly called by Frege ‘concepts’). The sleight of hand here turns on the fact that what is general in reality is hereby brought within the realm of operators such as and or not – operators which are essentially linguistic. There are indeed some who think that we can read off the properties in reality by looking at the language we use to talk about it. Kantians and relativists even find such doctrines attractive for reasons which have nothing to do with any influence of fantology. But they are, surely, doctrines which enjoy too many of the advantages of theft over honest toil. EXCERPT #882YUP p. 14 EXCERPT #89NP7J p. 15 Frege's idea led, by degrees, to a lazy use of the word 'property'. (The fantologist's strong comprehension axiom asserts that there is a property corresponding to every expressible formula with exactly one free variable.) In this way, too, fantology came to be conducive to nominalism (for an ontologist, surely, cannot take seriously properties like: being non-identical to Socrates , being such that 2 + 2 = 4 , being a unicorn unless sleeping , being either not a silverfish or not magnetically charged , being green if examined before a certain date ). Set theory, too, of course, is marked by a Booleanism of this sort – a Booleanism which shares part of the responsibility for Russell's paradox. Booleanism is in this way responsible also for the phobia of quantification over properties/universals (for no dangers need arise through such quantification in the absence of Boolean combination). In this respect, too, Booleanism is conducive to nominalism. EXCERPT #MCVL63 p. 15 The tradition surely had it right when it took for granted the thesis that the question which simple and complex general expressions stand for properties or universals in reality is a question to be decided in each case only on the basis of special inquiries – for example on the part of natural science. So powerful is the force of Booleanism, however, that even the valiant efforts of Armstrong to fight against it with his 'sparse' or 'non-abundant' theory of universals (Armstrong 1978; see also Lewis 1983) are thus far still a minority taste among analytical metaphysicians. EXCERPT #R69SDG p. 15 So powerful, indeed, is the solid wall of Booleanist orthodoxy in the philosophy of the twentieth century that its penetration on the part of Armstrong comes close to constituting a miracle of modern intellectual history. Note, though, that this magnificent achievement did no more than bring him back to the point where Aristotelians had been from the very start. DOCUMENT #CGE2NC Against Fantology SECTION #MW9JFA 18. No Room for Dependent Continuants EXCERPT #7AYNAL p. 15 Davidson, too, with his ontology of events, did much to break down fantological orthodoxy. His quantificational analysis of sentences about occurrents (actions, events) was an important step forward not least in the area where logic meets linguistics: it meant that those linguists who had thus far been too heavily influenced by fantology were finally able to deal coherently with verbs. As analytical metaphysicians have in recent years increasingly turned their attention to powers, qualities, roles, conditions, functions, dispositions, and so forth, they have thereby extended the Davidson-style analysis of occurrents into the realm of dependent continuants. Sadly it is still in too many quarters fashionable to talk indiscriminately of “tropes” in this connection (reflecting, once again, the fact that fantology encourages an indiscriminating representation of all entities not belonging to the category of independent object). Tropes are individualized properties – but properties as fantologically conceived, which means: properties conceived through the running together of all that is expressed by means of the ‘Fa’ and the ‘Rab’. EXCERPT #WNCGCL p. 15 EXCERPT #D6BEJX p. 16 For exactly as the classical fantologists made too few distinctions in the realm of properties, so their trope-ontologist successors make too few distinctions in the realm of dependent entities, not least in failing to distinguish clearly between dependent continuants such as qualities, powers, functions, roles, dispositions, and dependent occurrents such as actions and events (Grenon and Smith 2004). When we do make such distinctions, then we arrive at a more adequate ontology, which might be represented in the form of what we can call the Aristotelian Ontological Sextet, as follows: EXCERPT #8MW8B5 p. 16 Independent Continuant Dependent Continuant Occurrent (Process) Universal Second substance man cat ox Second quality headache sun-tan dread Second process copulation walking thinking Particular First substance this man this cat this ox First quality this headache this sun-tan this dread First process this copulation this walking this thinking EXCERPT #3TSJ8M p. 16 Figure 3: The Ontological Sextet EXCERPT #2HSCQG p. 16 This more adequate ontology goes beyond Aristotle in embracing, in addition to, individual and universal substances, also individual and universal qualities (as well as functions , dispositions , etc.), and both individual and universal processes . (See Figure 3.) Entities in these categories would be joined together by formal relations such as instantiation , exemplification and participation , as well as by the part relation (obtaining for example between the parts of a process and the process whole), and by the realization relation (obtaining between a function and the processes through which it is executed). EXCERPT #C5L2ZX p. 16 DOCUMENT #CGE2NC Against Fantology SECTION #ZAUEPE 19. A New, Enhanced Davidsonism EXCERPT #CX2YXN p. 17 We can solve the problems of fantology in a number of ways. We can follow the route taken by Leśniewski or Sommers and replace fantological logic with a term logic owing more to the older logico-ontological tradition than to the post-Fregean logic of functional application. Or we can follow Wiggins in bringing the copula back into predicate logic, or Gupta (1980) in developing a logic of common nouns. Here, however, we concentrate on a still too little explored alternative, which involves a minimal adjustment to the standard syntax of first-order logic – but an adjustment which nonetheless protects us from its fantological influence – effectively by eliminating the ‘F’ in ‘Fa’ and by radically confining and reconceiving the range of substitution-instances of the ‘R’ in ‘Rab’. EXCERPT #YAM8TJ p. 17 We have already noted how, because of its roots in mathematics, Fregean logic yields from within its own resources no satisfactory way of dealing with time and change. Matters were improved in this respect through Davidson’s treatment of events, and the idea here is that the latter can be generalized in a radical way to solve the problems of fantology in one foul swoop. EXCERPT #LXQV4L p. 17 First we expand still further the repertoire of types of entities over which our variables range, in such a way that they embrace both particulars and universals in all the six categories distinguished in our Ontological Sextet (and conceivably also further groups of entities such as temporal instants or spatial regions not here considered). Second, we eliminate all predicates of the ‘F’ and ‘R’ style, replacing them with a small number of relational expressions, but confining ourselves to formal ties which, like ‘=’, come with fixed interpretations. EXCERPT #RUTAX2 p. 17 Relations of the sorts we have in mind are represented in Figure 4, as follows: EXCERPT #3TTLCK p. 17 graph TD SU[Substantial universal] QU[Quality universal] PU[Process universal] SP[Substantial particular] QP[Quality particular] PP[Process particular] SU -- "differentia of" --> QU SP -- "instantiates" --> SU QP -- "instantiates" --> QU PP -- "instantiates" --> PU SP -- "exemplifies" --> QU SP -- "has participant" --> PP QP -- "inheres in" --> SP Figure 4: Relations connecting the six different types of entities in the Ontological Sextet. The diagram shows six nodes arranged in a 2x3 grid. The top row contains 'Substantial universal', 'Quality universal', and 'Process universal'. The bottom row contains 'Substantial particular', 'Quality particular', and 'Process particular'. Arrows connect the nodes with labels: 'differentia of' (top row, left to right), 'instantiates' (vertical arrows from each particular to its universal), 'exemplifies' (diagonal arrow from Substantial particular to Quality universal), 'has participant' (horizontal arrow from Substantial particular to Process particular), and 'inheres in' (bottom row, right to left). EXCERPT #WC33RR p. 17 Figure 4. Relations connecting the six different types of entities in the Ontological Sextet EXCERPT #XRYNEW p. 17 EXCERPT #GSRT4P p. 18 Our restricted vocabulary for predicate logic might then contain a list of predicates along the following lines: EXCERPT #WRVKYL p. 18 =(x, y) , for: x is identical to y \text{Part}(x, y) , for: individual x is part of individual y \text{Inst}(x, y) , for: individual x instantiates universal y \text{Inhere}(x, y) , for: individual x inheres in individual y \text{Exemp}(x, y) , for: individual x exemplifies property y \text{Dep}(x, y) , for: individual x depends for its existence on individual y \text{Is\_a}(x, y) , for: universal x is a subkind of universal y \text{Precedes}(x, y) , for: individual process x precedes individual process y \text{Has\_Participant}(x, y) , for: individual thing y participates in individual occurrent x \text{Has\_Agent}(x, y) , for: individual thing y is agent of individual occurrent x \text{Realizes}(x, y) , for: individual process x realizes individual function y EXCERPT #MJWNMR p. 18 ‘John is wise’, in this vocabulary, becomes: \text{Exemp}(\text{John}, \text{wisdom}) – ‘wisdom’ here is the name of a universal. ‘John is a man’ becomes: \text{Inst}(\text{John}, \text{man}) . ‘Man is a subtype of animal’ becomes: \text{Isa}(\text{man}, \text{animal}) , and so on. The vocabulary allows us also to formulate a range of axioms governing the formal behavior of the relations thereby distinguished, for example: EXCERPT #CEVAQB p. 18 \text{Realizes}(x, y) \rightarrow \exists z (\text{Dep}(x, y) \wedge \text{Dep}(y, z)) \text{Exempt}(x, y) \rightarrow \exists z (\text{Inst}(z, y) \wedge \text{Inhere}(z, x)) EXCERPT #W89VQK p. 18 The result is comparable to the vocabulary of set theory in the sense that there, too, we have a restricted number (two) of relational predicates: = and \in , both of which are formal, governed by a restricted number of axioms. But while the language we are proposing has a vocabulary structurally very similar to that of set theory, it differs radically in that the formal tie of set-theoretic membership itself emanates from the fantological stable (and thus represents a brutal gliding over of the distinction between logical and ontological form). DOCUMENT #CGE2NC Against Fantology SECTION #CCHP6D 20. Predicates Do Not Represent EXCERPT #ALZYD4 p. 18 Our fundamental idea is that predicates (the standard predicates of first-order logic fantologically conceived) do not represent. Even the formal predicates which we allow in our vocabulary do not stand for anything. (They are to this degree analogous to the logical constants as conceived by Wittgenstein.) Rather they are what link together variable and constant terms which are those parts of the syntax which do stand for something. The logical constants do not represent, and nor, either, do the ontological constants. EXCERPT #4UD577 p. 18 EXCERPT #TZS3JA p. 19 Formal ties such as instantiates, part-of, connected-to, boundary-of are for familiar Bradleyan reasons not extra ingredients of being. For if they were entities in their own right then there would arise for them, too, the question: what connects them to their bearers? EXCERPT #8EGEZG p. 19 The relevant mistake of fantology here lies in the assumption that the ‘F’ in ‘Fa’ stands for something, something that would somehow span the border between what is general in reality (universals, properties, essences) and what is logico-linguistic in the realm of meanings (concepts, propositions). It is from this fateful mistake, introduced into philosophy by Frege (through Plato, too, must bear some part of the blame), that Booleanism stems. Boolean operators such as ‘and’ and ‘or’ connect what is logico-linguistic in nature, they do not connect the kinds and universals in reality. EXCERPT #V5457K p. 19 Our approach avoids Booleanism, since we deal with universals, with what is general, via names and not via predicates, and names cannot be joined together ad libitum via logical operators. Our approach allows us at the same time to simulate some of the advantages of second-order logic – above all in that we can quantify over universals – without the disadvantage in the form of the paradoxes which second-order logic is sometimes held to bring in its wake. Our use of names for universals implies also that our framework lends no support to the temptations of nominalism. We are protected from the consequences of fantology above all, however, because our procedure keeps the logical and ontological parts of our language rigorously separate. EXCERPT #6BUB8K p. 19 Our selected formal ties indeed derive squarely from ontology, and logic gives us no clue as to what these formal ties should be. To establish the appropriate list requires extralogical work (Smith et al. , 2005), just as it requires extralogical work to find out what the universals and particulars in reality are. ### 40. Assistant Yes—and *Against Fantology* sharpens the CPO/ECS idea considerably. Smith’s target is almost exactly the naïve metaphysics implicit in a conventional ECS: Armstrong’s “spreadsheet ontology” has individuals as rows, properties as columns, and marks indicating which individual has which property (#Y7TY94). An ECS often looks like: ```text Position Velocity Bike Airborne Boosting entity 17 × × × × entity 18 × × ``` That is extremely useful storage, but Smith’s point is that it is not an adequate account of reality. ## The ECS spreadsheet collapses categories In the spreadsheet, all these become equivalent instances of “has component”: ```text bike has mass bike has wheel bike has position bike has velocity bike has rider bike has airborne bike has boost ``` Ontologically, however: ```text mass quality inheres_in bike wheel part_of bike bike occupies spatial region bike participates_in motion rider mounted_on bike flight has_participant bike boost burn realizes propulsion function ``` Smith’s criticism is precisely that `Fa` and `Rab` flatten radically different kinds of entities and relations. He distinguishes qualities, functions, roles, dispositions, processes, and other dependent entities instead of calling all of them properties or “tropes” (#7AYNAL, #D6BEJX). An ECS can remain the physical storage mechanism, but `has` should not become the game’s semantic language. ## CPOs resemble Smith’s “formal ties” The strongest connection is in the paper’s proposed replacement. Smith suggests: 1. variables and names ranging over particulars and universals in six categories; 2. a small, curated vocabulary of formal relations with fixed meanings. His list includes (#WRVKYL): ```text Part Instantiates InheresIn Exemplifies DependsOn IsA Precedes HasParticipant HasAgent Realizes ``` That looks remarkably like a family of CPOs: ```cpp part_of (wheel, bike); instantiates (bike, motorcycle); instantiates (jump, gravitational_motion); inheres_in (boost_charge, bike); has_participant (jump, bike); realizes (boost_burn, propulsion_function); precedes (takeoff, landing); ``` The CPO is not the universal. It is the **formal tie** connecting named entities. The universal is an argument: ```cpp instantiates (this_jump, gravitational_free_fall); ``` Here: - `this_jump` denotes a process particular; - `gravitational_free_fall` denotes a process universal; - `instantiates` is the fixed formal connection between them. That is more faithful than: ```cpp has (bike); ``` because free fall classifies the process, not the motorcycle. ## Universals should be names, not arbitrary predicates This is where Smith’s criticism of **Booleanism** becomes directly relevant to C++. C++ concepts invite constructions like: ```cpp template concept InterestingMovingThing = Movable && (!Grounded || Boosting) && Renderable; ``` That predicate may be useful for compile-time selection. But its expressibility does not imply that **interesting moving thing** is a universal in the world. Smith rejects the assumption that every logical combination of predicates corresponds to a real property. If $F$ and $G$ are genuine properties, it does not follow that all of $$ \neg F,\quad F \lor G,\quad F \land G,\quad F \to G $$ are additional universals (#VAA4FX). Which universals genuinely exist must be established through substantive inquiry, not generated automatically from syntax (#MCVL63). So in the C++ design: - **concepts** describe admissible representations and overloads; - **universals** are a sparse, curated, nominal vocabulary; - arbitrary concept expressions do not manufacture new world kinds. For example: ```cpp inline constexpr ProcessUniversal motion; inline constexpr ProcessUniversal rolling; inline constexpr ProcessUniversal skidding; inline constexpr ProcessUniversal gravitational_free_fall; inline constexpr ProcessUniversal thrust_production; ``` These are deliberately named universals. By contrast: ```cpp Airborne && Boosting && Red ``` is merely a useful logical query unless the game has a substantive reason to recognize a corresponding kind. ## Particular qualities should not disappear into scalar cells A spreadsheet records: ```cpp bike.boost_charge = 0.72f; ``` But the ontological account can distinguish: ```text this boost-charge quality instantiates → boost-charge universal inheres in → this motorcycle has measured value at t → 0.72 ``` The **quality particular** can persist while its determinate magnitude changes. Smith’s sextet explicitly contains both quality universals and particular qualities, alongside substances and processes (#8MW8B5). That does not mean every scalar needs a heap allocation and globally unique ID. It means the semantic model should distinguish: ```cpp BoostCharge // universal/specification BoostChargeQuality // dependent token borne by one bike ChargeMeasurement // numerical reading at one instant ``` Moppe’s `quantity_spec` already handles the first distinction well: airspeed and climb rate remain different named magnitudes even when dimensionally identical. The next ontological step is to distinguish the enduring quality or process profile from its current numerical value. ## Time is where the spreadsheet fails hardest Smith criticizes the treatment of change as merely a sequence of static spreadsheets—one complete world-state per time step (#6664AF). That description is uncomfortably close to: ```cpp WorldState frame_0; WorldState frame_1; WorldState frame_2; ``` Snapshots are useful, but they do not replace processes. For Moppe: ```text Snapshot at t₀: bike is airborne Snapshot at t₁: bike is airborne Snapshot at t₂: bike is grounded ``` does not by itself represent: ```text this jump begins with → takeoff has participant → bike has velocity profile → … ends with → touchdown precedes → subsequent ride ``` A good design therefore needs both: ```cpp Snapshot // current continuants and readings ProcessStore // motion, jump, boost burn, collision, ride EventStore // takeoff, deployment, touchdown, collection ``` Replay should preserve not only a reconstructible sequence of states but the identity and structure of significant processes. ## Relations should remain different relations Smith also objects to reducing every relation to an undifferentiated set of ordered pairs. Love, kinship, comparison, conversation, and collision are not ontologically the same just because they can all be encoded as tuples (#F4R2RA, #Q95W24). The software analogue is avoiding: ```cpp Relation relations; ``` with a runtime relation label for everything. Physical storage can certainly use common tables, but the public vocabulary should preserve laws: ```cpp part_of attached_to located_in inheres_in participates_in realizes precedes ``` For example: - `part_of` may be transitive; - `attached_to` is temporary and potentially symmetric; - `inheres_in` implies existential dependence; - `participates_in` crosses from continuant to occurrent; - `precedes` relates processes or events temporally; - `realizes` connects a process to a realizable dependent continuant. A generic pair table cannot supply those laws by itself. ## Bare entity IDs are “bare particulars” Smith also criticizes the picture in which particulars are meaningless ciphers and all intelligibility lies in predicates attached to them (#CMFR6F). A generic ECS entity often is exactly that: ```cpp using Entity = uint32_t; ``` Nothing about entity `1742` says whether it denotes a motorcycle, a boost-charge quality, a landing event, or a spatial region. Every fact must be recovered through component probing. A more ontologically typed system might have: ```cpp ParticularId bike; ParticularId charge; ParticularId jump; ParticularId touchdown; ParticularId occupied_region; ``` And preferably stronger domain types where practical: ```cpp MotorcycleId MotionId BoostChargeId LandingEventId ``` The identifiers can still be dense handles internally. What matters is that the program does not expose all particulars as unknowable IDs surrounded by nullable component queries. ## The resulting C++ shape The paper suggests a clean division: ```cpp // Entities that represent something Motorcycle bike; BoostChargeQuality charge; MotionProcess jump; inline constexpr SubstanceUniversal motorcycle; inline constexpr QualityUniversal boost_charge; inline constexpr ProcessUniversal gravitational_free_fall; // Formal ties that connect them instantiates (bike, motorcycle); instantiates (charge, boost_charge); instantiates (jump, gravitational_free_fall); inheres_in (charge, bike); has_participant (jump, bike); ``` CPOs are attractive for the final group because they provide: - one stable name; - representation-independent dispatch; - compile-time constraints; - no requirement for a universal base class; - compatibility with concrete values, handles, snapshots, and views. But their customizations must obey **one fixed semantic contract**. `part_of(a,b)` cannot mean ownership for one type and spatial containment for another. Otherwise customization recreates the very flattening the ontology was meant to avoid. ## The central design principle Smith’s enhanced Davidsonism gives a surprisingly direct software rule: > Represent universals and particulars with names and values; connect them through a small, law-governed vocabulary of formal relations. For Moppe, that suggests: - ECS-like columnar storage may remain underneath; - C++ concepts constrain implementation types; - nominal types or values name genuine universals; - CPOs expose fixed ontological relations; - processes and dependent continuants become first-class; - logical predicates remain queries rather than automatically becoming world entities. In that form, the system keeps the performance advantages of an ECS without accepting the **spreadsheet ontology** as its account of what the world contains. ### 41. User It's also nice to think about what I was thinking about. We already have, in the atelier, in the tree organism, for example, this topological model that is then embedded in 3D space, and I feel like something very analogous. It's basically the way you have to think about something like motocross. It has this hierarchy, this engineering structure of how its parts are linked by linkages or joints or springs, and that's kind of like the discrete model of it. That gets embedded into the 3D space somehow. ### 42. Assistant tool calls #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 12, "query": "TreeEmbedding EmbeddedTree embed tree topology intrinsic extrinsic" } ``` #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 12, "query": "motorcycle wheel suspension steering linkage axle frame render vehicle pose" } ``` #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 12, "query": "combinatorial intrinsic extrinsic embedding tree" } ``` ### 43. Tool result: search_text Exact matches 1. Source file: tests/atelier/tree_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content Size: 3350 bytes, 93 lines Matching excerpt: #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::get; MOPPE_TEST (tree_is_one_valid_oriented_complex) { const Tree tree; const DirectedTreeTopology& topology = tree.topology (); MOPPE_CHECK (topology.is_valid ()); MOPPE_CHECK (topology.edge_count () + 1 == topology.vertex_count ()); MOPPE_CHECK (tree.tip_count () > 20); MOPPE_CHECK (tree.vertices ().size () == topology.vertex_count ()); MOPPE_CHECK (tree.edges ().size () == topology.edge_count ()); std::size_t shoot_edges = 0; std::size_t root_edges = 0; for (TreeEdgeId edge = 0; edge < topology.edge_count (); ++edge) if (topology.edge (edge).organ == TreeOrgan::shoot) ++shoot_edges; else ++root_edges; MOPPE_CHECK (shoot_edges > 0); MOPPE_CHECK (root_edges > 0); } MOPPE_TEST (seed_changes_the_organism_not_only_its_embedding) { const Tree first (0x1001U); const Tree second (0x2002U); MOPPE_CHECK (first.topology ().edge_count () != second.topology ().edge_count ()); MOPPE_CHECK (first.form (0).material_seed != second.form (0).material_seed); } MOPPE_TEST (one_accumulation_law_runs_with_o Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content"] 2. Source file: docs/atelier-tree.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content Size: 6005 bytes, 130 lines Matching excerpt: # The Atelier tree The Atelier tree is a small proof that an organism can remain itself while its presentation changes completely. Run it as a wind-bent object: ```sh cmake --build build --target atelier ./build/atelier.app/Contents/MacOS/atelier --tree ``` or as a diagram of the same organism: ```sh ./build/atelier.app/Contents/MacOS/atelier --tree-diagram ``` Deterministic stills can be made without opening a window: ```sh ./build/atelier.app/Contents/MacOS/atelier \ --tree --capture /tmp/tree.png 7 ./build/atelier.app/Contents/MacOS/atelier \ --tree-diagram --capture /tmp/tree-diagram.png 7 ``` ## Three storeys `DirectedTreeTopology` is the combinatorial storey. It owns vertices, edges, incidence, generation, lineage, branch order, and the distinction between the shoot and root trees. It has no positions. `Tree::VertexState`, `Tree::EdgeState`, and `TreeEdgeForm` are the intrinsic storey. They are typed `Bundle`s over the vertex and edge domains. Rest length, radius, flexibility, azimuth, elevation, water potential, sugar potential, and bud vigor all belong here. Radius is derived from the terminal mass supported by an edge, so thickening is a property of the organism rather tha Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content"] 3. Source file: atelier/tree_embedding.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content Size: 11417 bytes, 265 lines Matching excerpt: #include "atelier/tree_embedding.hh" #include #include #include #include namespace atelier { using moppe::spatial::get; using namespace si::unit_symbols; namespace { Vec3 edge_direction (const TreeEdgeForm& form) { const Real elevation = in_radians (form.elevation); const Real azimuth = in_radians (form.azimuth); const Real horizontal = std::cos (elevation); return { horizontal * std::sin (azimuth), std::sin (elevation), horizontal * std::cos (azimuth) }; } Vec3 branch_normal (const Vec3& direction) { const Vec3 anchor = std::abs (scalar_product (direction, up)) > 0.92f ? east : up; const Vec3 across = vector_product (direction, anchor).unit (); return vector_product (across, direction).unit (); } Matrix bud_placement (const Point& at, const Vec3& facing, Length radius) { Matrix place = rotation (up, facing); const Real scale = in_metres (radius); place.columns[0] *= scale; place.columns[1] *= 0.24f * scale; place.columns[2] *= scale; place.columns[3] = simd_make_float4 (in_metres (at), 1.0f); return place; } EmbeddedTreeBranch branch_between (const Tree& tree, TreeEdgeId id, const std::vector& positions, Real bend) { const TreeEdge& ed Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content"] 4. Source file: atelier/tree_embedding.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5oaA#content Size: 935 bytes, 42 lines Matching excerpt: #pragma once #include "atelier/matrix.hh" #include "atelier/tree.hh" #include namespace atelier { enum class TreeEmbeddingKind { diagram, wind_bent }; struct EmbeddedTreeBud { Matrix place_in_world; Real vigor; Real material_seed; TreeOrgan organ; }; struct EmbeddedTreeBranch { simd_float3 start; simd_float3 end; simd_float3 start_normal; simd_float3 end_normal; Real strain; Real bend; Length radius; Real material_seed; Real xylem; Real phloem; }; struct EmbeddedTree { Matrix world_to_clip; Point eye; std::vector buds; std::vector branches; }; [[nodiscard]] EmbeddedTree embed_tree (const Tree& tree, TreeEmbeddingKind kind, Duration elapsed, Real aspect_ratio); } Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5oaA#content"] 5. Source file: atelier/tree.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content Size: 7467 bytes, 207 lines Matching excerpt: #pragma once #include "atelier/space.hh" #include #include #include #include #include #include #include #include // A tree is an oriented one-dimensional complex. The topology remembers // lineage and incidence; typed bundles carry the organism's intrinsic state. // Neither layer says where the tree currently happens to be in world space. namespace atelier { using TreeVertexId = std::size_t; using TreeEdgeId = std::size_t; inline constexpr TreeEdgeId no_tree_edge = static_cast (-1); struct TreeVertex { std::size_t generation; std::uint64_t lineage; }; enum class TreeOrgan { shoot, root }; struct TreeEdge { TreeVertexId parent; TreeVertexId child; std::size_t branch_order; bool continues_axis; TreeOrgan organ = TreeOrgan::shoot; }; class DirectedTreeTopology { public: DirectedTreeTopology (std::vector vertices, std::vector edges); [[nodiscard]] std::size_t vertex_count () const noexcept; [[nodiscard]] std::size_t edge_count () const noexcept; [[nodiscard]] const TreeVertex& vertex (TreeVertexId id) const; [[nodiscard]] const TreeEdge& edge (TreeEdgeId id) cons Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content"] 6. Source file: tests/atelier/embedding_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9lbWJlZGRpbmdfdGVzdC5jYw#content Size: 2319 bytes, 60 lines Matching excerpt: #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; MOPPE_TEST (embeddings_leave_the_intrinsic_partition_unchanged) { HexSheet sheet; sheet.advance (2.35f * s); const std::vector leaves = sheet.leaves (); const EmbeddedHexSheet shell = embed_hex_sheet (sheet, EmbeddingKind::toroidal_shell, 2.35f * s, 1.5f); const EmbeddedHexSheet plane = embed_hex_sheet (sheet, EmbeddingKind::repeating_plane, 2.35f * s, 1.5f); std::size_t degree_sum = 0; for (TileId id = 0; id < sheet.topology ().size (); ++id) degree_sum += sheet.topology ().neighbours (id).size (); const std::size_t edge_count = degree_sum / 2; MOPPE_CHECK (shell.tiles.size () == leaves.size ()); MOPPE_CHECK (plane.tiles.size () == 15 * leaves.size ()); MOPPE_CHECK (shell.ligaments.size () == edge_count); MOPPE_CHECK (plane.ligaments.size () == 15 * edge_count); MOPPE_CHECK (sheet.leaves ().size () == leaves.size ()); } MOPPE_TEST (flat_embedding_repeats_identical_tile_readings) { HexSheet sheet; sheet.advance (2.35f * s); const std::vector leaves = sheet.leaves (); const EmbeddedHexSheet plane = embed_hex_sheet (sheet, EmbeddingKind::re Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9lbWJlZGRpbmdfdGVzdC5jYw#content"] 7. Source file: docs/atelier-earth.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content Size: 15763 bytes, 318 lines Matching excerpt: # The Atelier earth A proposal to widen the atelier's scope: from a studio of small organisms (the tree, the carpet, the cellular sheet) to a second implementation of the engine itself, begun again from the foundations of the earth. This is not a refactor of moppe and not a port. Moppe continues to run, generate, and play. The atelier grows a world beside it, small and whole at every stage, made of the semantic material we have learned to want: typed quantities, affine frames, rank-graded domains, sections, and a discrete calculus — with Metal as the prime instance substrate. Where moppe discovered these ideas mid-flight and carries them partially, the atelier bakes them in from the first line. The two meet later by adoption, organ by organ, never by conversion. ## What "engine" means here Not "motorcycle game." The engine is a simulation of a world: - a **combinatorial storey** — finite topologies: lattices, trees, sheets; vertices, edges, faces; incidence and orientation. No positions live here. - an **intrinsic storey** — typed sections over those topologies: bundles whose columns are labelled by mp-units quantity specifications. Elevation is a point-valued 0-cochain; a flow is Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content"] 8. Source file: planning/rfcs/0001-current-engine-refactoring.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvcmZjcy8wMDAxLWN1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nLm1k#content Size: 2525 bytes, 60 lines Matching excerpt: # RFC-0001: Evolve the current engine toward the Atelier architecture Status: realized (decision accepted) ## Decision Moppe will not be replaced by a second engine. It will adopt the Atelier's architecture organ by organ, preserving a working game at every stage. The desired shape is: ```text topological domain -> typed intrinsic sections -> focused laws and simulation -> explicit extrinsic presentation ``` The current `Surface`/`WaterSurface` atlas and the Atelier tree are proofs of this shape. The completed execution track is [`current-engine-refactoring`](../tracks/current-engine-refactoring/README.md). The reader-facing result is the [engine atlas](../../docs/engine-atlas.md). ## Constraints - Prefer concrete domain values over generic manager frameworks. - Preserve the current game and its deterministic checks while boundaries move. - Keep quantities and their semantic kinds until the explicit renderer bridge. - Treat generation, mutable simulation, and presentation as different kinds of state. - Let the source and target graph follow the proven dependencies, rather than moving files first. ## Result The RFC is realized. `spatial::Bundle` is the shared finite-section abstract Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvcmZjcy8wMDAxLWN1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nLm1k#content"] 9. Source file: atelier/tree.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmNj#content Size: 11327 bytes, 297 lines Matching excerpt: #include "atelier/tree.hh" #include #include #include #include #include #include namespace atelier { using moppe::spatial::get; using namespace si::unit_symbols; DirectedTreeTopology::DirectedTreeTopology (std::vector vertices, std::vector edges) : m_vertices (std::move (vertices)), m_edges (std::move (edges)), m_parent_edges (m_vertices.size (), no_tree_edge), m_child_edges (m_vertices.size ()) { for (TreeEdgeId id = 0; id < m_edges.size (); ++id) { const TreeEdge& edge = m_edges[id]; if (edge.parent >= m_vertices.size () || edge.child >= m_vertices.size ()) throw std::invalid_argument ("Tree edge names a missing vertex"); if (m_parent_edges[edge.child] != no_tree_edge) throw std::invalid_argument ("Tree vertex has two parents"); m_parent_edges[edge.child] = id; m_child_edges[edge.parent].push_back (id); } if (!is_valid ()) throw std::invalid_argument ("Directed tree topology is inconsistent"); } std::size_t DirectedTreeTopology::vertex_count () const noexcept { return m_vertices.size (); } std::size_t DirectedTreeTopology::edge_count () const noexcept { return m_edges.size (); } const TreeVertex& D Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmNj#content"] 10. Source file: docs/surface-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content Size: 6695 bytes, 107 lines Matching excerpt: # The current-engine surface atlas This is the small atlas for Moppe's adopted Atelier earth vocabulary. It describes the current engine, not the proposed second engine. The purpose is to make its topology, intrinsic readings, and rendering bridge enumerable. For the wider ownership, state, presentation, and target map, start with the [engine atlas](engine-atlas.md). ## Storeys | Storey | Current object | Responsibility | | --- | --- | --- | | Combinatorial | `map::SurfaceDomain` | The finite toroidal vertex lattice, index/offset correspondence, horizontal spacing, and bilinear reconstruction stencil. | | Intrinsic | `map::SurfaceAtlas`, `map::WaterSurfaceSections` | Typed 0-cochains sharing the lattice but kept in named ground groups and a distinct water bundle. `map::Surface` owns the authoritative ground geometry and its later analyses. | | Extrinsic | `game::SurfacePresentation`, `game::WaterPresentation` | Convert typed columns to plain scalar texture payloads and upload them through `render::Renderer`. These are the quantity-to-number bridges. | Terrain generation writes the mandatory geometry bundle directly. Hydrology, geology, ecology, and use add readings at later, named Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content"] 11. Source file: atelier/atelier.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content Size: 4395 bytes, 117 lines Matching excerpt: #include "atelier/atelier.hh" #include #include namespace atelier { using namespace si::unit_symbols; namespace { simd_float4 material_parameters (const EmbeddedTile& tile) { constexpr simd_float3 ivory { 0.74f, 0.66f, 0.56f }; constexpr simd_float3 compressed { 0.64f, 0.54f, 0.50f }; constexpr simd_float3 new_growth { 0.64f, 0.70f, 0.62f }; const Real deformation = tile.deformation.numerical_value_in (mp_units::one); const simd_float3 mature = simd_mix (ivory, compressed, simd_float3 (deformation)); const simd_float3 colour = simd_mix (mature, new_growth, simd_float3 (tile.generation)); return simd_make_float4 (colour, tile.material_seed); } } bool Viewport::is_empty () const { return width == 0 || height == 0; } Real Viewport::aspect_ratio () const { if (is_empty ()) throw std::invalid_argument ("An empty viewport has no aspect ratio"); return Real (width) / Real (height); } Frame compose_frame (const HexSheet& sheet, EmbeddingKind embedding, Duration elapsed, Viewport viewport) { const EmbeddedHexSheet world = embed_hex_sheet (sheet, embedding, elapsed, viewport.aspect_ratio ()); Frame frame { .uniforms = Uniforms { .world_to_clip = world.world_to_clip, . Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content"] 12. Source file: research/vegetation/README.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvdmVnZXRhdGlvbi9SRUFETUUubWQ#content Size: 14261 bytes, 225 lines Matching excerpt: # Vegetation rendering research This shelf collects papers and production material for dense vegetation that looks alive without making the renderer revolve around it. It is deliberately matched to Moppe's current split: - the terrain has a filtered grass material; the former per-blade mesh-shader experiment remains useful history but is not in the current game; - trees have a global habitat-driven canopy field and cheap chunked population, while distinct Atelier organisms form the detailed mixed-age stand; - moisture, elevation, slope, shore clearance, and tree line already provide ecological placement fields; - grass and tree vertices already share a continuous wind vocabulary. The most useful conclusion is not one representation for every distance. Keep individual geometry where its silhouette, parallax, interaction, or identity is visible; progressively turn it into filtered coverage and canopy appearance as it becomes subpixel. ## Start here 1. `wohllaib-2021-ghost-grass.pdf` is the closest production analogue to the current grass renderer: tile-local GPU generation, field sampling, culling, per-blade variation, animation, and LOD. 2. `kuth-2025-gpu-tree-generation.pdf` is the Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cmVzZWFyY2gvdmVnZXRhdGlvbi9SRUFETUUubWQ#content"] Approximate matches 1. Source file: atelier/embedding.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuY2M#content Size: 17402 bytes, 410 lines Score: 0.041 Related excerpt: bits *= 0x7feb352dU; bits ^= bits >> 15; return Real (bits & 0x00ffffffU) / Real (0x01000000U); } EmbeddedLigament make_ligament (const SurfaceFrame& first, const SurfaceFrame& second, Length first_radius, Length second_radius, NormalDisplacement first_displacement, NormalDisplacement second_displacement, Real seed) { const simd_float3 between = second.centre - first.centre; simd_float3 first_direction = between - first.outward * simd_dot (between, first.outward); simd_float3 second_direction = -between + second.outward * simd_dot (between, second.outward); first_direction = simd_normalize (first_direction); second_direction = simd_normalize (second_direction); const Real first_attachment = in_metres (0.58f * first_radius); const Real second_attachment = in_metres (0.58f * second_radius); const Real hover = in_metres (ligament_hover); const Length rest_length = std::numbers::sqrt3_v * (first_radius + second_radius) / 2.0f; const Real bend = Real ((second_displacement - first_displacement) / rest_length); const Real strain = std::sqrt (1.0f + bend * bend) - 1.0f; return { .start = first.centre + first_attachment * first_direction + hover * first.outward, .end = second.centre + Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuY2M#content"] 2. Source file: atelier/tree_embedding.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content Size: 11417 bytes, 265 lines Score: 0.032 Related excerpt: #include "atelier/tree_embedding.hh" #include #include #include #include namespace atelier { using moppe::spatial::get; using namespace si::unit_symbols; namespace { Vec3 edge_direction (const TreeEdgeForm& form) { const Real elevation = in_radians (form.elevation); const Real azimuth = in_radians (form.azimuth); const Real horizontal = std::cos (elevation); return { horizontal * std::sin (azimuth), std::sin (elevation), horizontal * std::cos (azimuth) }; } Vec3 branch_normal (const Vec3& direction) { const Vec3 anchor = std::abs (scalar_product (direction, up)) > 0.92f ? east : up; const Vec3 across = vector_product (direction, anchor).unit (); return vector_product (across, direction).unit (); } Matrix bud_placement (const Point& at, const Vec3& facing, Length radius) { Matrix place = rotation (up, facing); const Real scale = in_metres (radius); place.columns[0] *= scale; place.columns[1] *= 0.24f * scale; place.columns[2] *= scale; place.columns[3] = simd_make_float4 (in_metres (at), 1.0f); return place; } EmbeddedTreeBranch branch_between (const Tree& tree, TreeEdgeId id, const std::vector& positions, Real bend) { const TreeEdge& ed Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content"] 3. Source file: atelier/tree.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmNj#content Size: 11327 bytes, 297 lines Score: 0.029 Related excerpt: ove (construction.edges)); return std::tuple (std::move (topology), std::move (construction.forms)); }()) {} Tree::Tree (std::tuple, std::vector> construction) : m_topology (std::move (std::get<0> (construction))), m_vertices (TreeVertexDomain (m_topology)), m_edges (TreeEdgeDomain (m_topology)), m_forms (std::move (std::get<1> (construction))) { auto& water = get (m_vertices); auto& sugar = get (m_vertices); auto& vigor = get (m_vertices); std::vector terminal_supply (m_topology->vertex_count (), 0.0f); std::size_t maximum_generation = 1; for (TreeVertexId vertex = 0; vertex < m_topology->vertex_count (); ++vertex) { maximum_generation = std::max (maximum_generation, m_topology->vertex (vertex).generation); if (m_topology->is_tip (vertex)) terminal_supply[vertex] = 0.75f + 0.5f * unit_hash (static_cast ( m_topology->vertex (vertex).lineage)); } const std::vector supported_tips = accumulate_along_tree ( *m_topology, terminal_supply, TreeFlowDirection::toward_root, [] (Real first, Real second) { return first + second; }); const Real total_supply = std::ma Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmNj#content"] 4. Source file: atelier/tree_embedding.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5oaA#content Size: 935 bytes, 42 lines Score: 0.016 Related excerpt: #pragma once #include "atelier/matrix.hh" #include "atelier/tree.hh" #include namespace atelier { enum class TreeEmbeddingKind { diagram, wind_bent }; struct EmbeddedTreeBud { Matrix place_in_world; Real vigor; Real material_seed; TreeOrgan organ; }; struct EmbeddedTreeBranch { simd_float3 start; simd_float3 end; simd_float3 start_normal; simd_float3 end_normal; Real strain; Real bend; Length radius; Real material_seed; Real xylem; Real phloem; }; struct EmbeddedTree { Matrix world_to_clip; Point eye; std::vector buds; std::vector branches; }; [[nodiscard]] EmbeddedTree embed_tree (const Tree& tree, TreeEmbeddingKind kind, Duration elapsed, Real aspect_ratio); } Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5oaA#content"] 5. Source file: docs/atelier-tree.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content Size: 6005 bytes, 130 lines Score: 0.016 Related excerpt: # The Atelier tree The Atelier tree is a small proof that an organism can remain itself while its presentation changes completely. Run it as a wind-bent object: ```sh cmake --build build --target atelier ./build/atelier.app/Contents/MacOS/atelier --tree ``` or as a diagram of the same organism: ```sh ./build/atelier.app/Contents/MacOS/atelier --tree-diagram ``` Deterministic stills can be made without opening a window: ```sh ./build/atelier.app/Contents/MacOS/atelier \ --tree --capture /tmp/tree.png 7 ./build/atelier.app/Contents/MacOS/atelier \ --tree-diagram --capture /tmp/tree-diagram.png 7 ``` ## Three storeys `DirectedTreeTopology` is the combinatorial storey. It owns vertices, edges, incidence, generation, lineage, branch order, and the distinction between the shoot and root trees. It has no positions. `Tree::VertexState`, `Tree::EdgeState`, and `TreeEdgeForm` are the intrinsic storey. They are typed `Bundle`s over the vertex and edge domains. Rest length, radius, flexibility, azimuth, elevation, water potential, sugar potential, and bud vigor all belong here. Radius is derived from the terminal mass supported by an edge, so thickening is a property of the organism rather tha Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content"] 6. Source file: tests/atelier/tree_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content Size: 3350 bytes, 93 lines Score: 0.015 Related excerpt: #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::get; MOPPE_TEST (tree_is_one_valid_oriented_complex) { const Tree tree; const DirectedTreeTopology& topology = tree.topology (); MOPPE_CHECK (topology.is_valid ()); MOPPE_CHECK (topology.edge_count () + 1 == topology.vertex_count ()); MOPPE_CHECK (tree.tip_count () > 20); MOPPE_CHECK (tree.vertices ().size () == topology.vertex_count ()); MOPPE_CHECK (tree.edges ().size () == topology.edge_count ()); std::size_t shoot_edges = 0; std::size_t root_edges = 0; for (TreeEdgeId edge = 0; edge < topology.edge_count (); ++edge) if (topology.edge (edge).organ == TreeOrgan::shoot) ++shoot_edges; else ++root_edges; MOPPE_CHECK (shoot_edges > 0); MOPPE_CHECK (root_edges > 0); } MOPPE_TEST (seed_changes_the_organism_not_only_its_embedding) { const Tree first (0x1001U); const Tree second (0x2002U); MOPPE_CHECK (first.topology ().edge_count () != second.topology ().edge_count ()); MOPPE_CHECK (first.form (0).material_seed != second.form (0).material_seed); } MOPPE_TEST (one_accumulation_law_runs_with_o Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content"] 7. Source file: atelier/tree.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content Size: 7467 bytes, 207 lines Score: 0.015 Related excerpt: #pragma once #include "atelier/space.hh" #include #include #include #include #include #include #include #include // A tree is an oriented one-dimensional complex. The topology remembers // lineage and incidence; typed bundles carry the organism's intrinsic state. // Neither layer says where the tree currently happens to be in world space. namespace atelier { using TreeVertexId = std::size_t; using TreeEdgeId = std::size_t; inline constexpr TreeEdgeId no_tree_edge = static_cast (-1); struct TreeVertex { std::size_t generation; std::uint64_t lineage; }; enum class TreeOrgan { shoot, root }; struct TreeEdge { TreeVertexId parent; TreeVertexId child; std::size_t branch_order; bool continues_axis; TreeOrgan organ = TreeOrgan::shoot; }; class DirectedTreeTopology { public: DirectedTreeTopology (std::vector vertices, std::vector edges); [[nodiscard]] std::size_t vertex_count () const noexcept; [[nodiscard]] std::size_t edge_count () const noexcept; [[nodiscard]] const TreeVertex& vertex (TreeVertexId id) const; [[nodiscard]] const TreeEdge& edge (TreeEdgeId id) cons Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content"] 8. Source file: atelier/embedding.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuaGg#content Size: 1183 bytes, 45 lines Score: 0.015 Related excerpt: #pragma once #include "atelier/hex_sheet.hh" #include "atelier/matrix.hh" #include // World embeddings are views of the same intrinsic sheet. The embedding // chooses both its boundary law and its placement in space. namespace atelier { enum class EmbeddingKind { rope_bridge, toroidal_shell, repeating_plane }; [[nodiscard]] SheetBoundary boundary_for (EmbeddingKind kind); struct EmbeddedTile { Matrix place_in_world; DeformationReading deformation; Real generation; Real material_seed; }; struct EmbeddedLigament { simd_float3 start; simd_float3 end; simd_float3 start_normal; simd_float3 end_normal; Real strain; Real bend; Length radius; Real material_seed; }; struct EmbeddedHexSheet { Matrix world_to_clip; Point eye; std::vector tiles; std::vector ligaments; }; [[nodiscard]] EmbeddedHexSheet embed_hex_sheet (const HexSheet& sheet, EmbeddingKind kind, Duration elapsed, Real aspect_ratio); } Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuaGg#content"] 9. Source file: tests/atelier/embedding_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9lbWJlZGRpbmdfdGVzdC5jYw#content Size: 2319 bytes, 60 lines Score: 0.014 Related excerpt: #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; MOPPE_TEST (embeddings_leave_the_intrinsic_partition_unchanged) { HexSheet sheet; sheet.advance (2.35f * s); const std::vector leaves = sheet.leaves (); const EmbeddedHexSheet shell = embed_hex_sheet (sheet, EmbeddingKind::toroidal_shell, 2.35f * s, 1.5f); const EmbeddedHexSheet plane = embed_hex_sheet (sheet, EmbeddingKind::repeating_plane, 2.35f * s, 1.5f); std::size_t degree_sum = 0; for (TileId id = 0; id < sheet.topology ().size (); ++id) degree_sum += sheet.topology ().neighbours (id).size (); const std::size_t edge_count = degree_sum / 2; MOPPE_CHECK (shell.tiles.size () == leaves.size ()); MOPPE_CHECK (plane.tiles.size () == 15 * leaves.size ()); MOPPE_CHECK (shell.ligaments.size () == edge_count); MOPPE_CHECK (plane.ligaments.size () == 15 * edge_count); MOPPE_CHECK (sheet.leaves ().size () == leaves.size ()); } MOPPE_TEST (flat_embedding_repeats_identical_tile_readings) { HexSheet sheet; sheet.advance (2.35f * s); const std::vector leaves = sheet.leaves (); const EmbeddedHexSheet plane = embed_hex_sheet (sheet, EmbeddingKind::re Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9lbWJlZGRpbmdfdGVzdC5jYw#content"] 10. Source file: atelier/atelier.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content Size: 4395 bytes, 117 lines Score: 0.014 Related excerpt: #include "atelier/atelier.hh" #include #include namespace atelier { using namespace si::unit_symbols; namespace { simd_float4 material_parameters (const EmbeddedTile& tile) { constexpr simd_float3 ivory { 0.74f, 0.66f, 0.56f }; constexpr simd_float3 compressed { 0.64f, 0.54f, 0.50f }; constexpr simd_float3 new_growth { 0.64f, 0.70f, 0.62f }; const Real deformation = tile.deformation.numerical_value_in (mp_units::one); const simd_float3 mature = simd_mix (ivory, compressed, simd_float3 (deformation)); const simd_float3 colour = simd_mix (mature, new_growth, simd_float3 (tile.generation)); return simd_make_float4 (colour, tile.material_seed); } } bool Viewport::is_empty () const { return width == 0 || height == 0; } Real Viewport::aspect_ratio () const { if (is_empty ()) throw std::invalid_argument ("An empty viewport has no aspect ratio"); return Real (width) / Real (height); } Frame compose_frame (const HexSheet& sheet, EmbeddingKind embedding, Duration elapsed, Viewport viewport) { const EmbeddedHexSheet world = embed_hex_sheet (sheet, embedding, elapsed, viewport.aspect_ratio ()); Frame frame { .uniforms = Uniforms { .world_to_clip = world.world_to_clip, . Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content"] 11. Source file: atelier/atelier.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmho#content Size: 2246 bytes, 76 lines Score: 0.013 Related excerpt: #pragma once #include "atelier/embedding.hh" #include "atelier/hex_sheet.hh" #include "atelier/matrix.hh" #include "atelier/prism.hh" #include "atelier/space.hh" #include "atelier/tree_embedding.hh" #include "atelier/wire.hh" #include #include // The scene: a cellular sheet composed each frame into the flat instance data // the renderer uploads. namespace atelier { enum class SceneKind { tree_wind, tree_diagram, rope_bridge, toroidal_sheet, repeating_sheet, }; // A viewport measured in physical pixels. struct Viewport { std::size_t width = 0; std::size_t height = 0; [[nodiscard]] bool is_empty () const; [[nodiscard]] Real aspect_ratio () const; }; // GPU-facing frame data, mirrored field for field by the shader // structs in atelier_shaders.hh. struct Uniforms { Matrix world_to_clip; simd_float4 eye; // the camera's place, in metres from the origin // x is elapsed time in seconds; the remaining lanes are reserved for // atmosphere controls that should stay global rather than per tile. simd_float4 atmosphere; }; struct TileInstance { Matrix place_in_world; // RGB is the body colour and W is a stable intrinsic material seed. simd_float4 material; }; struct Ligament Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmho#content"] 12. Source file: moppe/game/tree_stand.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS90cmVlX3N0YW5kLmNj#content Size: 21918 bytes, 522 lines Score: 0.013 Related excerpt: #include #include #include #include #include #include #include #include #include #include namespace moppe::game { namespace { using namespace mp_units; float unit_hash (std::uint32_t bits) { bits += 0x9e3779b9U; bits ^= bits >> 16; bits *= 0x7feb352dU; bits ^= bits >> 15; return static_cast (bits & 0x00ffffffU) / static_cast (0x01000000U); } float elevation_value (const map::Surface& surface, float x, float z) { return surface.elevation_at (position (Vec3 (x, 0, z))) .quantity_from_zero () .numerical_value_in (u::m); } Vec3 normal_value (const map::Surface& surface, float x, float z) { return normalized ( surface.normal_at (position (Vec3 (x, 0, z))).numerical_value_in (one)); } float habitat_value (const map::Surface& surface, float x, float z) { return surface.tree_habitat_at (position (Vec3 (x, 0, z))) .numerical_value_in (one); } float forest_cover_value (const map::Surface& surface, float x, float z) { return surface.forest_cover_at (position (Vec3 (x, 0, z))) .numerical_value_in (one); } TreeSite site_at (const map:: Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS90cmVlX3N0YW5kLmNj#content"] ### 44. Tool result: search_text Exact matches 1. Source file: moppe/game/vehicle_render.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5jYw#content Size: 19470 bytes, 510 lines Matching excerpt: #include #include #include #include #include namespace moppe { namespace game { static degrees_t boost_nozzle_angle (const VehiclePose& vehicle) { // The exhaust points opposite the force: backward when boosting // forward, straight down at neutral drive, and forward in reverse. return (90.0f + 60.0f * vehicle.boost_drive) * u::deg; } // -- baked bike assemblies ------------------------------------------ // // The bike's rigid clusters are recorded once into retained meshes // and replayed with a model matrix, so no per-vertex CPU work // remains on the hot path. Only geometry that actually changes // shape per frame -- the suspension links and the additive flames // -- still records immediate vertices. namespace { struct BikeMeshes { render::MeshPtr wheel; // spoked wheel around z; spin is Rz render::MeshPtr chassis; // rigid frame cluster in bike space render::MeshPtr steering; // clamp cluster in steering space render::MeshPtr nozzle; // one jump-jet cone along +z }; // The dirt bike's spoked wheel with a knobby tire, around the z // axis; the model matrix lays the axle on Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5jYw#content"] 2. Source file: moppe/mov/vehicle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content Size: 8839 bytes, 305 lines Matching excerpt: #ifndef MOPPE_VEHICLE_HH #define MOPPE_VEHICLE_HH #include #include #include #include #include namespace moppe { namespace mov { using namespace moppe::map; // An axis-aligned solid block (a building): the vehicle bounces // off its walls, and its top is drivable ground. struct Box { float x0, z0, x1, z1, top; }; class Vehicle { public: struct State { position_t position {}; velocity_t velocity {}; Vec3 heading {}; Vec3 thrust_orientation {}; radians_t yaw {}; radians_t yaw_target {}; float lean {}; Vec3 render_heading {}; Vec3 render_normal {}; float susp {}; float susp_v {}; float wheel_spin {}; bool boost_flight {}; control_signal_t thrust {}; float boost_input {}; float boost_drive {}; float boost_level {}; float boost_charge {}; seconds_t boost_recharge_delay {}; meters_t water_level {}; seconds_t airborne_time {}; speed_t impact {}; meters_t fall_top {}; meters_t fall_drop {}; int body_kind {}; DisplayColor body_color {}; }; // max_thrust caps the wheel force (launch punch); power caps // force * speed, so acceleration tapers like a real engine // instead of shoving at 3 g all the way to the hori Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content"] 3. Source file: moppe/game/vehicle_render.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5oaA#content Size: 1530 bytes, 36 lines Matching excerpt: #ifndef MOPPE_GAME_VEHICLE_RENDER_HH #define MOPPE_GAME_VEHICLE_RENDER_HH #include #include #include namespace moppe { namespace game { // The drawing half of the old Vehicle::render, split out so the // simulation stays renderer-free. Reads one immutable vehicle pose; // the bike's rigid assemblies // are baked meshes drawn straight through the renderer, while // shape-changing parts (suspension links) record into the frame's // draw list. Dispatches bike vs. commandeered car/truck on the // body kind. `time` (seconds) replaces the hidden // glutGet(GLUT_ELAPSED_TIME) that drove the flashing light bars. void render_vehicle (render::Renderer& r, render::DrawList& dl, const VehiclePose& vehicle, float time, const Vec3& visual_scale = Vec3 (1, 1, 1)); // The exhaust lick and jump-jet plumes: baked unit cones replayed // with breathing scale matrices. Additive glow must blend over the // already-drawn solids, so the caller invokes this after playing // the world draw list (alongside the star halos), not at vehicle // draw time. void render_vehicle_flames (render::Renderer& r, const VehiclePose& vehicle, float Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5oaA#content"] 4. Source file: moppe/mov/vehicle.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content Size: 21178 bytes, 538 lines Matching excerpt: #include #include namespace moppe { namespace mov { static const float radius = 1; // metres // How fast full steering input swings the bike itself, in radians // per second per radian of yaw input. Grip then drags the // velocity around after the heading. static const float steering_rate = 1.6; static const float air_steering_rate = 0.9; static const acceleration_component_t boost_acceleration = 26.0f * isq::acceleration[u::m / pow<2> (u::s)]; static const radians_t boost_max_tilt = 60.0f * u::deg; static const seconds_t boost_full_burn_time = seconds (3.0f); static const seconds_t boost_recharge_time = seconds (5.0f); static const seconds_t boost_recharge_pause = seconds (0.65f); static const float boost_reserve_charge = 0.06f; static const float boost_emergency_level = 0.18f; Vehicle::Vehicle (position_t position, degrees_t orientation, const Surface& map, newtons_t max_thrust, watts_t power, kilograms_t mass) : m_position (position), m_velocity (moppe::velocity (Vec3 ())), m_heading (sin (orientation), 0, cos (orientation)), m_thrust_orientation (m_heading), m_yaw (), m_yaw_target (), m_lean (0), m_render_heading (m_heading), m_render_normal (0, 1 Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content"] 5. Source file: moppe/game/frame_view.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3LmNj#content Size: 13431 bytes, 318 lines Matching excerpt: #include #include #include #include namespace moppe::game { namespace { constexpr float SUN_AZIMUTH = 0.8f; // Keep the historical art-direction calculations bit-for-bit aligned // with the game loop while moving them behind the presentation seam. constexpr float ART_PI = 3.14159f; float smooth_curve (float edge0, float edge1, float value) { const float t = std::clamp ((value - edge0) / (edge1 - edge0), 0.0f, 1.0f); return t * t * (3.0f - 2.0f * t); } float sun_elevation_for (float sun_height) { return std::sin ((sun_height - 0.5f) * ART_PI); } float daylight_for (float sun_height) { return smooth_curve (-0.08f, 0.18f, sun_elevation_for (sun_height)); } float golden_light_for (float sun_height) { const float elevation = sun_elevation_for (sun_height); return daylight_for (sun_height) * (1.0f - smooth_curve (0.15f, 0.65f, elevation)); } FrameVisibility visibility_for (const FrameViewInput& input, const FrameView& view) { const bool cinematic = input.scene == FrameSceneMode::Cinematic; const bool water = input.scene == FrameSceneMode::WaterInspection; const bool tree = input.scene == FrameSceneMode::TreeDemo; FrameVisibility vis Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3LmNj#content"] 6. Source file: moppe/game/frame_view.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3Lmho#content Size: 7224 bytes, 224 lines Matching excerpt: #ifndef MOPPE_GAME_FRAME_VIEW_HH #define MOPPE_GAME_FRAME_VIEW_HH #include #include #include #include #include #include namespace moppe::game { // The one selected presentation mode for a finished world frame. These are // deliberately concrete application modes, not a generic scene hierarchy. enum class FrameSceneMode { Gameplay, Cinematic, WaterInspection, TreeDemo }; // A camera has already been selected by the application before composing a // frame. Keeping its view matrix here preserves cinematics' banked camera // while still letting FrameView apply riding-only shake afterward. struct FrameCameraReading { Vec3 position {}; Vec3 forward { 0, 0, 1 }; Mat4 view {}; float field_of_view = 70.0f; }; // Renderer-facing snapshots of the parts of a vehicle that actually affect // its visible pose. They intentionally omit controls and physical state. struct VehiclePose { Vec3 position {}; Vec3 render_orientation { 0, 0, 1 }; Vec3 render_normal { 0, 1, 0 }; float suspension = 0.0f; float lean_radians = 0.0f; float wheel_spin_radians = 0.0f; float yaw_radians = 0.0f; Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9mcmFtZV92aWV3Lmho#content"] 7. Source file: tests/game/game_state_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nYW1lX3N0YXRlX3Rlc3QuY2M#content Size: 23339 bytes, 558 lines Matching excerpt: #include #include #include #include #include #include #include #include namespace { void check_vector (const moppe::Vec3& actual, const moppe::Vec3& expected) { MOPPE_CHECK_NEAR (actual[0], expected[0], 1e-6f); MOPPE_CHECK_NEAR (actual[1], expected[1], 1e-6f); MOPPE_CHECK_NEAR (actual[2], expected[2], 1e-6f); } void check_position (const moppe::position_t& actual, const moppe::position_t& expected) { check_vector (moppe::position_value (actual), moppe::position_value (expected)); } void check_velocity (const moppe::velocity_t& actual, const moppe::velocity_t& expected) { check_vector (moppe::velocity_value (actual), moppe::velocity_value (expected)); } void check_color (moppe::DisplayColor actual, moppe::DisplayColor expected) { MOPPE_CHECK_NEAR (actual.red, expected.red, 1e-6f); MOPPE_CHECK_NEAR (actual.green, expected.green, 1e-6f); MOPPE_CHECK_NEAR (actual.blue, expected.blue, 1e-6f); } } MOPPE_TEST (vehicle_state_restores_hidden_simulation_state) { using namespace moppe; map::Surface map (9, 9, Vec3 (100, 20, 100)) Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9nYW1lX3N0YXRlX3Rlc3QuY2M#content"] 8. Source file: moppe/game/walker_render.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXJfcmVuZGVyLmho#content Size: 484 bytes, 16 lines Matching excerpt: #ifndef MOPPE_GAME_WALKER_RENDER_HH #define MOPPE_GAME_WALKER_RENDER_HH #include #include namespace moppe::game { // The walking figure reads the frozen presentation pose rather than the // mutable walker simulation object. void render_walker (render::DrawList& draw, const WalkerPose& walker, float time, const Vec3& visual_scale = Vec3 (1, 1, 1)); } #endif Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXJfcmVuZGVyLmho#content"] 9. Source file: docs/renderer-design.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZW5kZXJlci1kZXNpZ24ubWQ#content Size: 31751 bytes, 526 lines Matching excerpt: # Moppe rendering & platform architecture Status: current Metal/backend implementation record. This document preserves the port's technical decisions and implementation detail; the [engine atlas](engine-atlas.md) is the current map of source ownership, state, and CMake targets. A playable browser backend now implements the same renderer contract through WebGPU; see [WebAssembly and WebGPU](web.md). Android remains a future possibility. ## Port goals and retained constraints 1. Render through Metal on macOS and iOS with one shared game codebase. 2. Keep the game's look and feel: same pass order, same haze/lighting math, same HUD, same physics. 3. Abstract the renderer and platform behind small, game-shaped interfaces so a WebGPU (or other) backend is an additive job, not a rewrite. 4. Refactor as we go: split the 4000-line main.cc into modules, remove dead code, de-boost, kill hidden global state where cheap. 5. Modernize where it pays: vertex-pulled terrain from a height texture (replaces ~100 MB of CPU-built triangle-strip soup), an explicit post chain, background-thread world generation with a loading screen (required on iOS anyway). ## Review amendments (adopted) A three-lens ad Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZW5kZXJlci1kZXNpZ24ubWQ#content"] 10. Source file: moppe/game/game.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lLmNj#content Size: 69597 bytes, 1717 lines Matching excerpt: // The game: the port of the original MoppeGLUT application class onto // the platform/render abstractions. World generation runs on a // background thread behind a loading screen; the frame follows the // exact pass order of the GL build's render_scene(). The command line // that configures a launch is resolved before this file is reached; see // launch_options.hh and main.cc. #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include # Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lLmNj#content"] 11. Source file: moppe/game/game_session.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content Size: 22571 bytes, 576 lines Matching excerpt: #include #include #include #include namespace moppe::game { namespace { void sync_attached_bike (GameSession& session) { const mov::Glider& glider = session.glider (); const Vec3 up = Quaternion::rotate (Vec3 (0, 1, 0), glider.heading (), -glider.bank ()); session.bike ().carry (glider.physical_position () - up * 2.4f * u::m, glider.physical_velocity (), glider.heading (), up); } void set_turn (GameSession& session, float value) { GameLogicState& logic = session.logic (); logic.m_turn_input = value; if (logic.m_mode == M_FOOT) session.walker ().set_turn (value); else if (logic.m_mode == M_GLIDER) session.glider ().set_turn (value); else session.active_vehicle ().set_yaw ((90 * value) * u::deg); } void set_go (GameSession& session, float value) { GameLogicState& logic = session.logic (); logic.m_go_input = value; if (logic.m_mode == M_FOOT) session.walker ().set_walk (value > 0 ? value : value * 0.6f); else if (logic.m_mode == M_GLIDER) session.glider ().set_speed_control (value); else { session.active_vehicle ().set_thrust (value); session.active_vehicle ().set_boost (logic.m_boost_input, logic.m_go_input); } } void set_boos Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content"] 12. Source file: tests/game/frame_view_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9mcmFtZV92aWV3X3Rlc3QuY2M#content Size: 14552 bytes, 352 lines Matching excerpt: #include #include #include #include #include #include #include using namespace moppe; namespace { void frame_view_check_vector (const Vec3& actual, const Vec3& expected) { MOPPE_CHECK_NEAR (actual[0], expected[0], 1e-6f); MOPPE_CHECK_NEAR (actual[1], expected[1], 1e-6f); MOPPE_CHECK_NEAR (actual[2], expected[2], 1e-6f); } void frame_view_check_color (DisplayColor actual, DisplayColor expected) { MOPPE_CHECK_NEAR (actual.red, expected.red, 1e-6f); MOPPE_CHECK_NEAR (actual.green, expected.green, 1e-6f); MOPPE_CHECK_NEAR (actual.blue, expected.blue, 1e-6f); } bool frame_view_same_matrix (const Mat4& left, const Mat4& right) { for (int i = 0; i < 16; ++i) if (left.m[i] != right.m[i]) return false; return true; } struct FrameFixture { map::Surface map { 17, 17, Vec3 (160, 40, 160) }; game::WorldParams world; std::unique_ptr session; game::GraphicsSettings graphics = game::high_graphics_settings (); FrameFixture () { map.fill_elevation (moppe::terrain::surface_elevation_point ( (0.25f) * 40.0f * mp_units::si::metre)); map.rebuild_geometry_readings (); world.map_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9mcmFtZV92aWV3X3Rlc3QuY2M#content"] Approximate matches 1. Source file: moppe/game/vehicle_render.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5jYw#content Size: 19470 bytes, 510 lines Score: 0.048 Related excerpt: #include #include #include #include #include namespace moppe { namespace game { static degrees_t boost_nozzle_angle (const VehiclePose& vehicle) { // The exhaust points opposite the force: backward when boosting // forward, straight down at neutral drive, and forward in reverse. return (90.0f + 60.0f * vehicle.boost_drive) * u::deg; } // -- baked bike assemblies ------------------------------------------ // // The bike's rigid clusters are recorded once into retained meshes // and replayed with a model matrix, so no per-vertex CPU work // remains on the hot path. Only geometry that actually changes // shape per frame -- the suspension links and the additive flames // -- still records immediate vertices. namespace { struct BikeMeshes { render::MeshPtr wheel; // spoked wheel around z; spin is Rz render::MeshPtr chassis; // rigid frame cluster in bike space render::MeshPtr steering; // clamp cluster in steering space render::MeshPtr nozzle; // one jump-jet cone along +z }; // The dirt bike's spoked wheel with a knobby tire, around the z // axis; the model matrix lays the axle on Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5jYw#content"] 2. Source file: moppe/mov/vehicle.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content Size: 21178 bytes, 538 lines Score: 0.045 Related excerpt: w, but pitch the chassis tangent to // the landing surface. The sampled normal supplies the corresponding // roll, so sidehill touchdowns meet both tires instead of one edge. forward = m_heading - up * dot (m_heading, up); if (length2 (forward) < 0.0001f) { const Vec3 impact_velocity = velocity + Vec3 (0, -gravity * t, 0); forward = impact_velocity - up * dot (impact_velocity, up); } if (length2 (forward) < 0.0001f) return false; normalize (forward); time_to_landing = t; return true; } return false; } // The obstacle box whose roof is the effective ground under the // bike -- only counts once the bike is up at roof level, so a // building towering overhead is not "ground". const Box* Vehicle::roof_under () const { if (!m_obstacles) return 0; const Box* found = 0; const Vec3& p = position_value (m_position); float best = m_map.interpolated_height (p[0], p[2]); for (size_t i = 0; i < m_obstacles->size (); ++i) { const Box& b = (*m_obstacles)[i]; if (p[0] >= b.x0 && p[0] <= b.x1 && p[2] >= b.z0 && p[2] <= b.z1 && p[1] > b.top - 2 * radius && b.top > best) { best = b.top; found = &b; } } return found; } void Vehicle::collide_with_walls () { if (!m_obstacles) return; Vec3& p = position_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuY2M#content"] 3. Source file: moppe/mov/vehicle.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content Size: 8839 bytes, 305 lines Score: 0.029 Related excerpt: #ifndef MOPPE_VEHICLE_HH #define MOPPE_VEHICLE_HH #include #include #include #include #include namespace moppe { namespace mov { using namespace moppe::map; // An axis-aligned solid block (a building): the vehicle bounces // off its walls, and its top is drivable ground. struct Box { float x0, z0, x1, z1, top; }; class Vehicle { public: struct State { position_t position {}; velocity_t velocity {}; Vec3 heading {}; Vec3 thrust_orientation {}; radians_t yaw {}; radians_t yaw_target {}; float lean {}; Vec3 render_heading {}; Vec3 render_normal {}; float susp {}; float susp_v {}; float wheel_spin {}; bool boost_flight {}; control_signal_t thrust {}; float boost_input {}; float boost_drive {}; float boost_level {}; float boost_charge {}; seconds_t boost_recharge_delay {}; meters_t water_level {}; seconds_t airborne_time {}; speed_t impact {}; meters_t fall_top {}; meters_t fall_drop {}; int body_kind {}; DisplayColor body_color {}; }; // max_thrust caps the wheel force (launch punch); power caps // force * speed, so acceleration tapers like a real engine // instead of shoving at 3 g all the way to the hori Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvbW92L3ZlaGljbGUuaGg#content"] 4. Source file: moppe/game/walker_render.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXJfcmVuZGVyLmNj#content Size: 4269 bytes, 130 lines Score: 0.015 Related excerpt: #include #include #include #include namespace moppe::game { void render_walker (render::DrawList& draw, const WalkerPose& walker, float time, const Vec3& visual_scale) { draw.set_texture (nullptr); // The rider, dismounted: the same guy in the same gear, with knees and // elbows that actually articulate through the gait. const bool moving = std::abs (walker.walk) > 0.01f; const float phase = walker.animation_distance * 3.6f; const float bob = moving ? 0.025f * std::fabs (std::sin (phase)) : 0.0f; const float breathe = moving ? 0.0f : 0.006f * std::sin (time * 2.0f); draw.push (); draw.translate ( walker.position[0], walker.position[1] + bob, walker.position[2]); draw.rotate ( std::atan2 (walker.heading[0], walker.heading[2]) * u::rad, 0, 1, 0); draw.scale (visual_scale); // Legs: the thigh swings from the hip, the shin lags behind with a knee // bend that folds on the back-swing, and the boot rides along. for (int side = -1; side <= 1; side += 2) { const float leg_phase = phase + (side > 0 ? 0.0f : PI); const float thigh = moving ? -30.0f * std::sin (leg_phase) : 0.0f; const float knee = moving ? 12.0f + 30.0f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS93YWxrZXJfcmVuZGVyLmNj#content"] 5. Source file: moppe/game/vehicle_render.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5oaA#content Size: 1530 bytes, 36 lines Score: 0.015 Related excerpt: #ifndef MOPPE_GAME_VEHICLE_RENDER_HH #define MOPPE_GAME_VEHICLE_RENDER_HH #include #include #include namespace moppe { namespace game { // The drawing half of the old Vehicle::render, split out so the // simulation stays renderer-free. Reads one immutable vehicle pose; // the bike's rigid assemblies // are baked meshes drawn straight through the renderer, while // shape-changing parts (suspension links) record into the frame's // draw list. Dispatches bike vs. commandeered car/truck on the // body kind. `time` (seconds) replaces the hidden // glutGet(GLUT_ELAPSED_TIME) that drove the flashing light bars. void render_vehicle (render::Renderer& r, render::DrawList& dl, const VehiclePose& vehicle, float time, const Vec3& visual_scale = Vec3 (1, 1, 1)); // The exhaust lick and jump-jet plumes: baked unit cones replayed // with breathing scale matrices. Additive glow must blend over the // already-drawn solids, so the caller invokes this after playing // the world draw list (alongside the star halos), not at vehicle // draw time. void render_vehicle_flames (render::Renderer& r, const VehiclePose& vehicle, float Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS92ZWhpY2xlX3JlbmRlci5oaA#content"] 6. Source file: moppe/game/model.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9tb2RlbC5jYw#content Size: 2783 bytes, 95 lines Score: 0.014 Related excerpt: #include #include namespace moppe { namespace game { namespace model { void box (render::DrawList& dl, float width, float height, float depth) { dl.push (); dl.scale (width, height, depth); dl.cube (1.0f); dl.pop (); } void ellipsoid (render::DrawList& dl, float rx, float ry, float rz, int slices, int stacks) { dl.push (); dl.scale (rx, ry, rz); dl.sphere (1.0f, slices, stacks); dl.pop (); } void link (render::DrawList& dl, const Vec3& start, const Vec3& end, float thickness) { const Vec3 midpoint = (start + end) * 0.5f; const Vec3 direction = end - start; const float beam_length = moppe::length (direction); const float flat = std::sqrt (direction[0] * direction[0] + direction[2] * direction[2]); dl.push (); dl.translate (midpoint); dl.rotate (std::atan2 (direction[0], direction[2]) * u::rad, 0, 1, 0); dl.rotate (-std::atan2 (direction[1], flat) * u::rad, 1, 0, 0); box (dl, thickness, thickness, beam_length); dl.pop (); } void rider_material (render::DrawList& dl, RiderMaterial material) { switch (material) { case RiderMaterial::Pants: dl.color (0.13f, 0.14f, 0.19f); break; case RiderMaterial::Jersey: dl.color (0.15f, 0.28f, 0.55f); break; case RiderMa Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9tb2RlbC5jYw#content"] 7. Source file: moppe/game/glider_render.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nbGlkZXJfcmVuZGVyLmNj#content Size: 4083 bytes, 120 lines Score: 0.014 Related excerpt: #include #include #include #include namespace moppe::game { namespace { void wing_triangle (render::DrawList& dl, const Vec3& a, const Vec3& b, const Vec3& c) { dl.normal (normalized (cross (b - a, c - a))); dl.vertex (a); dl.vertex (b); dl.vertex (c); } Mat4 glider_frame (const GliderPose& glider, const Vec3& visual_scale) { const Vec3 fwd = normalized (glider.heading); const Vec3 right = normalized (cross (Vec3 (0, 1, 0), fwd)); const Vec3 up = cross (fwd, right); return Mat4::translation (glider.position) * Mat4::basis (right, up, fwd) * Mat4::rotation (-glider.bank_radians * u::rad, Vec3 (0, 0, 1)) * Mat4::scaling (visual_scale); } } void render_glider (render::DrawList& dl, const GliderPose& glider, float time, const Vec3& visual_scale) { const Vec3 nose (0, 0.18f, 1.8f); const Vec3 left (-4.6f, 0, -0.75f); const Vec3 right (4.6f, 0, -0.75f); const Vec3 tail (0, -0.08f, -2.15f); const Vec3 center (0, 0.20f, -0.30f); const Vec3 hang (0, -1.15f, -0.22f); dl.push (); dl.mult (glider_frame (glider, visual_scale)); // A lightly faceted Rogallo wing. The darker underside is explicitly // wound the other Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nbGlkZXJfcmVuZGVyLmNj#content"] 8. Source file: moppe/game/model.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9tb2RlbC5oaA#content Size: 1039 bytes, 39 lines Score: 0.014 Related excerpt: #ifndef MOPPE_GAME_MODEL_HH #define MOPPE_GAME_MODEL_HH #include namespace moppe { namespace game { namespace model { // Small, renderer-independent vocabulary shared by procedural models. // Dimensions are full extents for boxes and radii for ellipsoids. void box (render::DrawList& dl, float width, float height, float depth); void ellipsoid (render::DrawList& dl, float rx, float ry, float rz, int slices = 16, int stacks = 16); void link (render::DrawList& dl, const Vec3& start, const Vec3& end, float thickness); enum class RiderMaterial { Pants, Jersey, Armor, Boots, Gloves, HelmetShell, Visor }; void rider_material (render::DrawList& dl, RiderMaterial material); void rider_helmet (render::DrawList& dl); } } } #endif Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9tb2RlbC5oaA#content"] 9. Source file: moppe/game/game_session.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content Size: 22571 bytes, 576 lines Score: 0.014 Related excerpt: #include #include #include #include namespace moppe::game { namespace { void sync_attached_bike (GameSession& session) { const mov::Glider& glider = session.glider (); const Vec3 up = Quaternion::rotate (Vec3 (0, 1, 0), glider.heading (), -glider.bank ()); session.bike ().carry (glider.physical_position () - up * 2.4f * u::m, glider.physical_velocity (), glider.heading (), up); } void set_turn (GameSession& session, float value) { GameLogicState& logic = session.logic (); logic.m_turn_input = value; if (logic.m_mode == M_FOOT) session.walker ().set_turn (value); else if (logic.m_mode == M_GLIDER) session.glider ().set_turn (value); else session.active_vehicle ().set_yaw ((90 * value) * u::deg); } void set_go (GameSession& session, float value) { GameLogicState& logic = session.logic (); logic.m_go_input = value; if (logic.m_mode == M_FOOT) session.walker ().set_walk (value > 0 ? value : value * 0.6f); else if (logic.m_mode == M_GLIDER) session.glider ().set_speed_control (value); else { session.active_vehicle ().set_thrust (value); session.active_vehicle ().set_boost (logic.m_boost_input, logic.m_go_input); } } void set_boos Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvZ2FtZS9nYW1lX3Nlc3Npb24uY2M#content"] 10. Source file: tests/game/frame_view_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9mcmFtZV92aWV3X3Rlc3QuY2M#content Size: 14552 bytes, 352 lines Score: 0.013 Related excerpt: #include #include #include #include #include #include #include using namespace moppe; namespace { void frame_view_check_vector (const Vec3& actual, const Vec3& expected) { MOPPE_CHECK_NEAR (actual[0], expected[0], 1e-6f); MOPPE_CHECK_NEAR (actual[1], expected[1], 1e-6f); MOPPE_CHECK_NEAR (actual[2], expected[2], 1e-6f); } void frame_view_check_color (DisplayColor actual, DisplayColor expected) { MOPPE_CHECK_NEAR (actual.red, expected.red, 1e-6f); MOPPE_CHECK_NEAR (actual.green, expected.green, 1e-6f); MOPPE_CHECK_NEAR (actual.blue, expected.blue, 1e-6f); } bool frame_view_same_matrix (const Mat4& left, const Mat4& right) { for (int i = 0; i < 16; ++i) if (left.m[i] != right.m[i]) return false; return true; } struct FrameFixture { map::Surface map { 17, 17, Vec3 (160, 40, 160) }; game::WorldParams world; std::unique_ptr session; game::GraphicsSettings graphics = game::high_graphics_settings (); FrameFixture () { map.fill_elevation (moppe::terrain::surface_elevation_point ( (0.25f) * 40.0f * mp_units::si::metre)); map.rebuild_geometry_readings (); world.map_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9mcmFtZV92aWV3X3Rlc3QuY2M#content"] 11. Source file: docs/renderer-design.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZW5kZXJlci1kZXNpZ24ubWQ#content Size: 31751 bytes, 526 lines Score: 0.013 Related excerpt: # Moppe rendering & platform architecture Status: current Metal/backend implementation record. This document preserves the port's technical decisions and implementation detail; the [engine atlas](engine-atlas.md) is the current map of source ownership, state, and CMake targets. A playable browser backend now implements the same renderer contract through WebGPU; see [WebAssembly and WebGPU](web.md). Android remains a future possibility. ## Port goals and retained constraints 1. Render through Metal on macOS and iOS with one shared game codebase. 2. Keep the game's look and feel: same pass order, same haze/lighting math, same HUD, same physics. 3. Abstract the renderer and platform behind small, game-shaped interfaces so a WebGPU (or other) backend is an additive job, not a rewrite. 4. Refactor as we go: split the 4000-line main.cc into modules, remove dead code, de-boost, kill hidden global state where cheap. 5. Modernize where it pays: vertex-pulled terrain from a height texture (replaces ~100 MB of CPU-built triangle-strip soup), an explicit post chain, background-thread world generation with a loading screen (required on iOS anyway). ## Review amendments (adopted) A three-lens ad Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9yZW5kZXJlci1kZXNpZ24ubWQ#content"] 12. Source file: moppe/render/renderer.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcmVuZGVyL3JlbmRlcmVyLmho#content Size: 11435 bytes, 294 lines Score: 0.013 Related excerpt: // downstream arrows, lakes almost none; the water shader advects // its surface detail along them. Optional; an empty span clears. virtual void set_water_flow (std::span flow) { (void)flow; } // Ground moisture in [0,1] following the terrain grid. Optional. // Lifetime sediment ledger as interleaved (eroded, deposited) // pairs, width*height cells, both channels normalized to [0, 1]. // Materials read it to place raw cuts and pale alluvium. virtual void set_terrain_geology (std::span geology) { (void)geology; } // Horizontal distance to the nearest waterline per cell, in // meters, clamped to the extraction band. The wet-soil band and // swash-zone detail hug the true shoreline curve through it. virtual void set_terrain_shore (std::span distance) { (void)distance; } // Shoulder-blended trail membership in [0,1], following the terrain // grid. This is a material reading: the surface remains the geometric // authority, while the shader can make formed paths unambiguous. virtual void set_terrain_paths (std::span influence, std::span home_base_influence = {}) { (void)influence; (void)home_base_influence; } virtual void s Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvcmVuZGVyL3JlbmRlcmVyLmho#content"] ### 45. Tool result: search_text Exact matches 1. Source file: docs/atelier-tree.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content Size: 6005 bytes, 130 lines Matching excerpt: # The Atelier tree The Atelier tree is a small proof that an organism can remain itself while its presentation changes completely. Run it as a wind-bent object: ```sh cmake --build build --target atelier ./build/atelier.app/Contents/MacOS/atelier --tree ``` or as a diagram of the same organism: ```sh ./build/atelier.app/Contents/MacOS/atelier --tree-diagram ``` Deterministic stills can be made without opening a window: ```sh ./build/atelier.app/Contents/MacOS/atelier \ --tree --capture /tmp/tree.png 7 ./build/atelier.app/Contents/MacOS/atelier \ --tree-diagram --capture /tmp/tree-diagram.png 7 ``` ## Three storeys `DirectedTreeTopology` is the combinatorial storey. It owns vertices, edges, incidence, generation, lineage, branch order, and the distinction between the shoot and root trees. It has no positions. `Tree::VertexState`, `Tree::EdgeState`, and `TreeEdgeForm` are the intrinsic storey. They are typed `Bundle`s over the vertex and edge domains. Rest length, radius, flexibility, azimuth, elevation, water potential, sugar potential, and bud vigor all belong here. Radius is derived from the terminal mass supported by an edge, so thickening is a property of the organism rather tha Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content"] 2. Source file: docs/atelier-earth.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content Size: 15763 bytes, 318 lines Matching excerpt: # The Atelier earth A proposal to widen the atelier's scope: from a studio of small organisms (the tree, the carpet, the cellular sheet) to a second implementation of the engine itself, begun again from the foundations of the earth. This is not a refactor of moppe and not a port. Moppe continues to run, generate, and play. The atelier grows a world beside it, small and whole at every stage, made of the semantic material we have learned to want: typed quantities, affine frames, rank-graded domains, sections, and a discrete calculus — with Metal as the prime instance substrate. Where moppe discovered these ideas mid-flight and carries them partially, the atelier bakes them in from the first line. The two meet later by adoption, organ by organ, never by conversion. ## What "engine" means here Not "motorcycle game." The engine is a simulation of a world: - a **combinatorial storey** — finite topologies: lattices, trees, sheets; vertices, edges, faces; incidence and orientation. No positions live here. - an **intrinsic storey** — typed sections over those topologies: bundles whose columns are labelled by mp-units quantity specifications. Elevation is a point-valued 0-cochain; a flow is Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content"] 3. Source file: CMakeLists.txt Resource: https://m.sheaf.less.rest/3CV92Z/source-files/Q01ha2VMaXN0cy50eHQ#content Size: 29646 bytes, 791 lines Matching excerpt: cmake_minimum_required(VERSION 3.24) set(MOPPE_IOS FALSE) set(MOPPE_TVOS FALSE) set(MOPPE_MOBILE_APPLE FALSE) if(CMAKE_SYSTEM_NAME STREQUAL "iOS") set(MOPPE_IOS TRUE) set(MOPPE_MOBILE_APPLE TRUE) elseif(CMAKE_SYSTEM_NAME STREQUAL "tvOS") set(MOPPE_TVOS TRUE) set(MOPPE_MOBILE_APPLE TRUE) endif() # Ninja and Makefiles otherwise default to an unoptimized build. Keep symbols # for useful crash reports while making the normal desktop build representative # of real gameplay performance. if(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "Build type (Debug, Release, RelWithDebInfo, or MinSizeRel)" FORCE) set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS Debug Release RelWithDebInfo MinSizeRel) endif() # Without an explicit target, Xcode uses the installed SDK version as the # minimum OS, making device builds uninstallable on slightly older iPhones. if(MOPPE_MOBILE_APPLE AND NOT DEFINED CMAKE_OSX_DEPLOYMENT_TARGET) if(MOPPE_TVOS) set(CMAKE_OSX_DEPLOYMENT_TARGET "16.0" CACHE STRING "Minimum supported tvOS version") else() set(CMAKE_OSX_DEPLOYMENT_TARGET "15.0" CACHE STRING "Minimum supported iOS version") endif() endif() project(mo Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/Q01ha2VMaXN0cy50eHQ#content"] 4. Source file: atelier/atelier.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmho#content Size: 2246 bytes, 76 lines Matching excerpt: #pragma once #include "atelier/embedding.hh" #include "atelier/hex_sheet.hh" #include "atelier/matrix.hh" #include "atelier/prism.hh" #include "atelier/space.hh" #include "atelier/tree_embedding.hh" #include "atelier/wire.hh" #include #include // The scene: a cellular sheet composed each frame into the flat instance data // the renderer uploads. namespace atelier { enum class SceneKind { tree_wind, tree_diagram, rope_bridge, toroidal_sheet, repeating_sheet, }; // A viewport measured in physical pixels. struct Viewport { std::size_t width = 0; std::size_t height = 0; [[nodiscard]] bool is_empty () const; [[nodiscard]] Real aspect_ratio () const; }; // GPU-facing frame data, mirrored field for field by the shader // structs in atelier_shaders.hh. struct Uniforms { Matrix world_to_clip; simd_float4 eye; // the camera's place, in metres from the origin // x is elapsed time in seconds; the remaining lanes are reserved for // atmosphere controls that should stay global rather than per tile. simd_float4 atmosphere; }; struct TileInstance { Matrix place_in_world; // RGB is the body colour and W is a stable intrinsic material seed. simd_float4 material; }; struct Ligament Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmho#content"] 5. Source file: docs/surface-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content Size: 6695 bytes, 107 lines Matching excerpt: # The current-engine surface atlas This is the small atlas for Moppe's adopted Atelier earth vocabulary. It describes the current engine, not the proposed second engine. The purpose is to make its topology, intrinsic readings, and rendering bridge enumerable. For the wider ownership, state, presentation, and target map, start with the [engine atlas](engine-atlas.md). ## Storeys | Storey | Current object | Responsibility | | --- | --- | --- | | Combinatorial | `map::SurfaceDomain` | The finite toroidal vertex lattice, index/offset correspondence, horizontal spacing, and bilinear reconstruction stencil. | | Intrinsic | `map::SurfaceAtlas`, `map::WaterSurfaceSections` | Typed 0-cochains sharing the lattice but kept in named ground groups and a distinct water bundle. `map::Surface` owns the authoritative ground geometry and its later analyses. | | Extrinsic | `game::SurfacePresentation`, `game::WaterPresentation` | Convert typed columns to plain scalar texture payloads and upload them through `render::Renderer`. These are the quantity-to-number bridges. | Terrain generation writes the mandatory geometry bundle directly. Hydrology, geology, ecology, and use add readings at later, named Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content"] 6. Source file: atelier/atelier_renderer.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyX3JlbmRlcmVyLmNj#content Size: 4915 bytes, 159 lines Matching excerpt: // The one translation unit that carries the metal-cpp implementation. #define NS_PRIVATE_IMPLEMENTATION #define CA_PRIVATE_IMPLEMENTATION #define MTL_PRIVATE_IMPLEMENTATION #include #include #include #include "atelier/atelier_renderer.hh" #include "atelier/metal.hh" #include "atelier/pipeline.hh" #include "atelier/surface.hh" #include namespace atelier { namespace { bool is_tree_scene (SceneKind scene) { return scene == SceneKind::tree_wind || scene == SceneKind::tree_diagram; } TreeEmbeddingKind tree_embedding (SceneKind scene) { return scene == SceneKind::tree_diagram ? TreeEmbeddingKind::diagram : TreeEmbeddingKind::wind_bent; } EmbeddingKind sheet_embedding (SceneKind scene) { switch (scene) { case SceneKind::rope_bridge: return EmbeddingKind::rope_bridge; case SceneKind::toroidal_sheet: return EmbeddingKind::toroidal_shell; case SceneKind::repeating_sheet: return EmbeddingKind::repeating_plane; case SceneKind::tree_wind: case SceneKind::tree_diagram: break; } throw std::invalid_argument ("A tree scene has no sheet embedding"); } } class Renderer::Impl { public: explicit Impl (SceneKind scene) : Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyX3JlbmRlcmVyLmNj#content"] 7. Source file: tests/atelier/tree_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content Size: 3350 bytes, 93 lines Matching excerpt: #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::get; MOPPE_TEST (tree_is_one_valid_oriented_complex) { const Tree tree; const DirectedTreeTopology& topology = tree.topology (); MOPPE_CHECK (topology.is_valid ()); MOPPE_CHECK (topology.edge_count () + 1 == topology.vertex_count ()); MOPPE_CHECK (tree.tip_count () > 20); MOPPE_CHECK (tree.vertices ().size () == topology.vertex_count ()); MOPPE_CHECK (tree.edges ().size () == topology.edge_count ()); std::size_t shoot_edges = 0; std::size_t root_edges = 0; for (TreeEdgeId edge = 0; edge < topology.edge_count (); ++edge) if (topology.edge (edge).organ == TreeOrgan::shoot) ++shoot_edges; else ++root_edges; MOPPE_CHECK (shoot_edges > 0); MOPPE_CHECK (root_edges > 0); } MOPPE_TEST (seed_changes_the_organism_not_only_its_embedding) { const Tree first (0x1001U); const Tree second (0x2002U); MOPPE_CHECK (first.topology ().edge_count () != second.topology ().edge_count ()); MOPPE_CHECK (first.form (0).material_seed != second.form (0).material_seed); } MOPPE_TEST (one_accumulation_law_runs_with_o Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content"] 8. Source file: atelier/tree_embedding.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content Size: 11417 bytes, 265 lines Matching excerpt: #include "atelier/tree_embedding.hh" #include #include #include #include namespace atelier { using moppe::spatial::get; using namespace si::unit_symbols; namespace { Vec3 edge_direction (const TreeEdgeForm& form) { const Real elevation = in_radians (form.elevation); const Real azimuth = in_radians (form.azimuth); const Real horizontal = std::cos (elevation); return { horizontal * std::sin (azimuth), std::sin (elevation), horizontal * std::cos (azimuth) }; } Vec3 branch_normal (const Vec3& direction) { const Vec3 anchor = std::abs (scalar_product (direction, up)) > 0.92f ? east : up; const Vec3 across = vector_product (direction, anchor).unit (); return vector_product (across, direction).unit (); } Matrix bud_placement (const Point& at, const Vec3& facing, Length radius) { Matrix place = rotation (up, facing); const Real scale = in_metres (radius); place.columns[0] *= scale; place.columns[1] *= 0.24f * scale; place.columns[2] *= scale; place.columns[3] = simd_make_float4 (in_metres (at), 1.0f); return place; } EmbeddedTreeBranch branch_between (const Tree& tree, TreeEdgeId id, const std::vector& positions, Real bend) { const TreeEdge& ed Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content"] 9. Source file: planning/rfcs/0001-current-engine-refactoring.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvcmZjcy8wMDAxLWN1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nLm1k#content Size: 2525 bytes, 60 lines Matching excerpt: # RFC-0001: Evolve the current engine toward the Atelier architecture Status: realized (decision accepted) ## Decision Moppe will not be replaced by a second engine. It will adopt the Atelier's architecture organ by organ, preserving a working game at every stage. The desired shape is: ```text topological domain -> typed intrinsic sections -> focused laws and simulation -> explicit extrinsic presentation ``` The current `Surface`/`WaterSurface` atlas and the Atelier tree are proofs of this shape. The completed execution track is [`current-engine-refactoring`](../tracks/current-engine-refactoring/README.md). The reader-facing result is the [engine atlas](../../docs/engine-atlas.md). ## Constraints - Prefer concrete domain values over generic manager frameworks. - Preserve the current game and its deterministic checks while boundaries move. - Keep quantities and their semantic kinds until the explicit renderer bridge. - Treat generation, mutable simulation, and presentation as different kinds of state. - Let the source and target graph follow the proven dependencies, rather than moving files first. ## Result The RFC is realized. `spatial::Bundle` is the shared finite-section abstract Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbm5pbmcvcmZjcy8wMDAxLWN1cnJlbnQtZW5naW5lLXJlZmFjdG9yaW5nLm1k#content"] 10. Source file: atelier/tree.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content Size: 7467 bytes, 207 lines Matching excerpt: #pragma once #include "atelier/space.hh" #include #include #include #include #include #include #include #include // A tree is an oriented one-dimensional complex. The topology remembers // lineage and incidence; typed bundles carry the organism's intrinsic state. // Neither layer says where the tree currently happens to be in world space. namespace atelier { using TreeVertexId = std::size_t; using TreeEdgeId = std::size_t; inline constexpr TreeEdgeId no_tree_edge = static_cast (-1); struct TreeVertex { std::size_t generation; std::uint64_t lineage; }; enum class TreeOrgan { shoot, root }; struct TreeEdge { TreeVertexId parent; TreeVertexId child; std::size_t branch_order; bool continues_axis; TreeOrgan organ = TreeOrgan::shoot; }; class DirectedTreeTopology { public: DirectedTreeTopology (std::vector vertices, std::vector edges); [[nodiscard]] std::size_t vertex_count () const noexcept; [[nodiscard]] std::size_t edge_count () const noexcept; [[nodiscard]] const TreeVertex& vertex (TreeVertexId id) const; [[nodiscard]] const TreeEdge& edge (TreeEdgeId id) cons Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content"] 11. Source file: atelier/atelier.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content Size: 4395 bytes, 117 lines Matching excerpt: #include "atelier/atelier.hh" #include #include namespace atelier { using namespace si::unit_symbols; namespace { simd_float4 material_parameters (const EmbeddedTile& tile) { constexpr simd_float3 ivory { 0.74f, 0.66f, 0.56f }; constexpr simd_float3 compressed { 0.64f, 0.54f, 0.50f }; constexpr simd_float3 new_growth { 0.64f, 0.70f, 0.62f }; const Real deformation = tile.deformation.numerical_value_in (mp_units::one); const simd_float3 mature = simd_mix (ivory, compressed, simd_float3 (deformation)); const simd_float3 colour = simd_mix (mature, new_growth, simd_float3 (tile.generation)); return simd_make_float4 (colour, tile.material_seed); } } bool Viewport::is_empty () const { return width == 0 || height == 0; } Real Viewport::aspect_ratio () const { if (is_empty ()) throw std::invalid_argument ("An empty viewport has no aspect ratio"); return Real (width) / Real (height); } Frame compose_frame (const HexSheet& sheet, EmbeddingKind embedding, Duration elapsed, Viewport viewport) { const EmbeddedHexSheet world = embed_hex_sheet (sheet, embedding, elapsed, viewport.aspect_ratio ()); Frame frame { .uniforms = Uniforms { .world_to_clip = world.world_to_clip, . Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content"] 12. Source file: atelier/embedding.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuaGg#content Size: 1183 bytes, 45 lines Matching excerpt: #pragma once #include "atelier/hex_sheet.hh" #include "atelier/matrix.hh" #include // World embeddings are views of the same intrinsic sheet. The embedding // chooses both its boundary law and its placement in space. namespace atelier { enum class EmbeddingKind { rope_bridge, toroidal_shell, repeating_plane }; [[nodiscard]] SheetBoundary boundary_for (EmbeddingKind kind); struct EmbeddedTile { Matrix place_in_world; DeformationReading deformation; Real generation; Real material_seed; }; struct EmbeddedLigament { simd_float3 start; simd_float3 end; simd_float3 start_normal; simd_float3 end_normal; Real strain; Real bend; Length radius; Real material_seed; }; struct EmbeddedHexSheet { Matrix world_to_clip; Point eye; std::vector tiles; std::vector ligaments; }; [[nodiscard]] EmbeddedHexSheet embed_hex_sheet (const HexSheet& sheet, EmbeddingKind kind, Duration elapsed, Real aspect_ratio); } Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuaGg#content"] Approximate matches 1. Source file: atelier/tree_embedding.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content Size: 11417 bytes, 265 lines Score: 0.032 Related excerpt: #include "atelier/tree_embedding.hh" #include #include #include #include namespace atelier { using moppe::spatial::get; using namespace si::unit_symbols; namespace { Vec3 edge_direction (const TreeEdgeForm& form) { const Real elevation = in_radians (form.elevation); const Real azimuth = in_radians (form.azimuth); const Real horizontal = std::cos (elevation); return { horizontal * std::sin (azimuth), std::sin (elevation), horizontal * std::cos (azimuth) }; } Vec3 branch_normal (const Vec3& direction) { const Vec3 anchor = std::abs (scalar_product (direction, up)) > 0.92f ? east : up; const Vec3 across = vector_product (direction, anchor).unit (); return vector_product (across, direction).unit (); } Matrix bud_placement (const Point& at, const Vec3& facing, Length radius) { Matrix place = rotation (up, facing); const Real scale = in_metres (radius); place.columns[0] *= scale; place.columns[1] *= 0.24f * scale; place.columns[2] *= scale; place.columns[3] = simd_make_float4 (in_metres (at), 1.0f); return place; } EmbeddedTreeBranch branch_between (const Tree& tree, TreeEdgeId id, const std::vector& positions, Real bend) { const TreeEdge& ed Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5jYw#content"] 2. Source file: atelier/tree_embedding.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5oaA#content Size: 935 bytes, 42 lines Score: 0.016 Related excerpt: #pragma once #include "atelier/matrix.hh" #include "atelier/tree.hh" #include namespace atelier { enum class TreeEmbeddingKind { diagram, wind_bent }; struct EmbeddedTreeBud { Matrix place_in_world; Real vigor; Real material_seed; TreeOrgan organ; }; struct EmbeddedTreeBranch { simd_float3 start; simd_float3 end; simd_float3 start_normal; simd_float3 end_normal; Real strain; Real bend; Length radius; Real material_seed; Real xylem; Real phloem; }; struct EmbeddedTree { Matrix world_to_clip; Point eye; std::vector buds; std::vector branches; }; [[nodiscard]] EmbeddedTree embed_tree (const Tree& tree, TreeEmbeddingKind kind, Duration elapsed, Real aspect_ratio); } Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlX2VtYmVkZGluZy5oaA#content"] 3. Source file: docs/atelier-tree.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content Size: 6005 bytes, 130 lines Score: 0.016 Related excerpt: # The Atelier tree The Atelier tree is a small proof that an organism can remain itself while its presentation changes completely. Run it as a wind-bent object: ```sh cmake --build build --target atelier ./build/atelier.app/Contents/MacOS/atelier --tree ``` or as a diagram of the same organism: ```sh ./build/atelier.app/Contents/MacOS/atelier --tree-diagram ``` Deterministic stills can be made without opening a window: ```sh ./build/atelier.app/Contents/MacOS/atelier \ --tree --capture /tmp/tree.png 7 ./build/atelier.app/Contents/MacOS/atelier \ --tree-diagram --capture /tmp/tree-diagram.png 7 ``` ## Three storeys `DirectedTreeTopology` is the combinatorial storey. It owns vertices, edges, incidence, generation, lineage, branch order, and the distinction between the shoot and root trees. It has no positions. `Tree::VertexState`, `Tree::EdgeState`, and `TreeEdgeForm` are the intrinsic storey. They are typed `Bundle`s over the vertex and edge domains. Rest length, radius, flexibility, azimuth, elevation, water potential, sugar potential, and bud vigor all belong here. Radius is derived from the terminal mass supported by an edge, so thickening is a property of the organism rather tha Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLXRyZWUubWQ#content"] 4. Source file: tests/atelier/embedding_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9lbWJlZGRpbmdfdGVzdC5jYw#content Size: 2319 bytes, 60 lines Score: 0.015 Related excerpt: #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; MOPPE_TEST (embeddings_leave_the_intrinsic_partition_unchanged) { HexSheet sheet; sheet.advance (2.35f * s); const std::vector leaves = sheet.leaves (); const EmbeddedHexSheet shell = embed_hex_sheet (sheet, EmbeddingKind::toroidal_shell, 2.35f * s, 1.5f); const EmbeddedHexSheet plane = embed_hex_sheet (sheet, EmbeddingKind::repeating_plane, 2.35f * s, 1.5f); std::size_t degree_sum = 0; for (TileId id = 0; id < sheet.topology ().size (); ++id) degree_sum += sheet.topology ().neighbours (id).size (); const std::size_t edge_count = degree_sum / 2; MOPPE_CHECK (shell.tiles.size () == leaves.size ()); MOPPE_CHECK (plane.tiles.size () == 15 * leaves.size ()); MOPPE_CHECK (shell.ligaments.size () == edge_count); MOPPE_CHECK (plane.ligaments.size () == 15 * edge_count); MOPPE_CHECK (sheet.leaves ().size () == leaves.size ()); } MOPPE_TEST (flat_embedding_repeats_identical_tile_readings) { HexSheet sheet; sheet.advance (2.35f * s); const std::vector leaves = sheet.leaves (); const EmbeddedHexSheet plane = embed_hex_sheet (sheet, EmbeddingKind::re Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci9lbWJlZGRpbmdfdGVzdC5jYw#content"] 5. Source file: tests/atelier/tree_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content Size: 3350 bytes, 93 lines Score: 0.015 Related excerpt: #include #include #include #include using namespace atelier; using namespace mp_units::si::unit_symbols; using moppe::spatial::get; MOPPE_TEST (tree_is_one_valid_oriented_complex) { const Tree tree; const DirectedTreeTopology& topology = tree.topology (); MOPPE_CHECK (topology.is_valid ()); MOPPE_CHECK (topology.edge_count () + 1 == topology.vertex_count ()); MOPPE_CHECK (tree.tip_count () > 20); MOPPE_CHECK (tree.vertices ().size () == topology.vertex_count ()); MOPPE_CHECK (tree.edges ().size () == topology.edge_count ()); std::size_t shoot_edges = 0; std::size_t root_edges = 0; for (TreeEdgeId edge = 0; edge < topology.edge_count (); ++edge) if (topology.edge (edge).organ == TreeOrgan::shoot) ++shoot_edges; else ++root_edges; MOPPE_CHECK (shoot_edges > 0); MOPPE_CHECK (root_edges > 0); } MOPPE_TEST (seed_changes_the_organism_not_only_its_embedding) { const Tree first (0x1001U); const Tree second (0x2002U); MOPPE_CHECK (first.topology ().edge_count () != second.topology ().edge_count ()); MOPPE_CHECK (first.form (0).material_seed != second.form (0).material_seed); } MOPPE_TEST (one_accumulation_law_runs_with_o Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvYXRlbGllci90cmVlX3Rlc3QuY2M#content"] 6. Source file: atelier/embedding.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuaGg#content Size: 1183 bytes, 45 lines Score: 0.015 Related excerpt: #pragma once #include "atelier/hex_sheet.hh" #include "atelier/matrix.hh" #include // World embeddings are views of the same intrinsic sheet. The embedding // chooses both its boundary law and its placement in space. namespace atelier { enum class EmbeddingKind { rope_bridge, toroidal_shell, repeating_plane }; [[nodiscard]] SheetBoundary boundary_for (EmbeddingKind kind); struct EmbeddedTile { Matrix place_in_world; DeformationReading deformation; Real generation; Real material_seed; }; struct EmbeddedLigament { simd_float3 start; simd_float3 end; simd_float3 start_normal; simd_float3 end_normal; Real strain; Real bend; Length radius; Real material_seed; }; struct EmbeddedHexSheet { Matrix world_to_clip; Point eye; std::vector tiles; std::vector ligaments; }; [[nodiscard]] EmbeddedHexSheet embed_hex_sheet (const HexSheet& sheet, EmbeddingKind kind, Duration elapsed, Real aspect_ratio); } Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuaGg#content"] 7. Source file: atelier/tree.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content Size: 7467 bytes, 207 lines Score: 0.015 Related excerpt: #pragma once #include "atelier/space.hh" #include #include #include #include #include #include #include #include // A tree is an oriented one-dimensional complex. The topology remembers // lineage and incidence; typed bundles carry the organism's intrinsic state. // Neither layer says where the tree currently happens to be in world space. namespace atelier { using TreeVertexId = std::size_t; using TreeEdgeId = std::size_t; inline constexpr TreeEdgeId no_tree_edge = static_cast (-1); struct TreeVertex { std::size_t generation; std::uint64_t lineage; }; enum class TreeOrgan { shoot, root }; struct TreeEdge { TreeVertexId parent; TreeVertexId child; std::size_t branch_order; bool continues_axis; TreeOrgan organ = TreeOrgan::shoot; }; class DirectedTreeTopology { public: DirectedTreeTopology (std::vector vertices, std::vector edges); [[nodiscard]] std::size_t vertex_count () const noexcept; [[nodiscard]] std::size_t edge_count () const noexcept; [[nodiscard]] const TreeVertex& vertex (TreeVertexId id) const; [[nodiscard]] const TreeEdge& edge (TreeEdgeId id) cons Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmho#content"] 8. Source file: atelier/atelier.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content Size: 4395 bytes, 117 lines Score: 0.014 Related excerpt: #include "atelier/atelier.hh" #include #include namespace atelier { using namespace si::unit_symbols; namespace { simd_float4 material_parameters (const EmbeddedTile& tile) { constexpr simd_float3 ivory { 0.74f, 0.66f, 0.56f }; constexpr simd_float3 compressed { 0.64f, 0.54f, 0.50f }; constexpr simd_float3 new_growth { 0.64f, 0.70f, 0.62f }; const Real deformation = tile.deformation.numerical_value_in (mp_units::one); const simd_float3 mature = simd_mix (ivory, compressed, simd_float3 (deformation)); const simd_float3 colour = simd_mix (mature, new_growth, simd_float3 (tile.generation)); return simd_make_float4 (colour, tile.material_seed); } } bool Viewport::is_empty () const { return width == 0 || height == 0; } Real Viewport::aspect_ratio () const { if (is_empty ()) throw std::invalid_argument ("An empty viewport has no aspect ratio"); return Real (width) / Real (height); } Frame compose_frame (const HexSheet& sheet, EmbeddingKind embedding, Duration elapsed, Viewport viewport) { const EmbeddedHexSheet world = embed_hex_sheet (sheet, embedding, elapsed, viewport.aspect_ratio ()); Frame frame { .uniforms = Uniforms { .world_to_clip = world.world_to_clip, . Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9hdGVsaWVyLmNj#content"] 9. Source file: atelier/embedding.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuY2M#content Size: 17402 bytes, 410 lines Score: 0.014 Related excerpt: ile.deformation, tile.site.generation, tile.material_seed }); append_toroidal_ligaments (result, sheet); return result; } EmbeddedHexSheet repeating_embedding (const HexSheet& sheet, Real aspect_ratio) { const std::vector leaves = sheet.leaves (); constexpr Length pitch_across = std::numbers::sqrt3_v * puck_radius; constexpr Length period_across = Real (hex_sheet_columns) * pitch_across; const Point target = scene - east * (5.75f * m); const Point eye = target + east * (11.0f * m) + up * (11.0f * m) + north * (11.0f * m); EmbeddedHexSheet result { .world_to_clip = simd_mul ( orthographic ( 0.45f * period_across, aspect_ratio, 0.05f * m, 80.0f * m), look_at (eye, target)), .eye = eye, .tiles = {}, .ligaments = {}, }; result.tiles.reserve (15 * leaves.size ()); result.ligaments.reserve (15 * 3 * sheet.topology ().size ()); for (int image_away = -2; image_away <= 2; ++image_away) { for (int image_across = -1; image_across <= 1; ++image_across) { append_flat_ligaments (result, sheet, image_across, image_away); for (const TileLeaf& tile : leaves) result.tiles.push_back ( { placement (flat_frame (tile, image_across, image_away), tile.site.radius), tile.deformation, tile.s Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci9lbWJlZGRpbmcuY2M#content"] 10. Source file: atelier/tree.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmNj#content Size: 11327 bytes, 297 lines Score: 0.014 Related excerpt: #include "atelier/tree.hh" #include #include #include #include #include #include namespace atelier { using moppe::spatial::get; using namespace si::unit_symbols; DirectedTreeTopology::DirectedTreeTopology (std::vector vertices, std::vector edges) : m_vertices (std::move (vertices)), m_edges (std::move (edges)), m_parent_edges (m_vertices.size (), no_tree_edge), m_child_edges (m_vertices.size ()) { for (TreeEdgeId id = 0; id < m_edges.size (); ++id) { const TreeEdge& edge = m_edges[id]; if (edge.parent >= m_vertices.size () || edge.child >= m_vertices.size ()) throw std::invalid_argument ("Tree edge names a missing vertex"); if (m_parent_edges[edge.child] != no_tree_edge) throw std::invalid_argument ("Tree vertex has two parents"); m_parent_edges[edge.child] = id; m_child_edges[edge.parent].push_back (id); } if (!is_valid ()) throw std::invalid_argument ("Directed tree topology is inconsistent"); } std::size_t DirectedTreeTopology::vertex_count () const noexcept { return m_vertices.size (); } std::size_t DirectedTreeTopology::edge_count () const noexcept { return m_edges.size (); } const TreeVertex& D Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/YXRlbGllci90cmVlLmNj#content"] 11. Source file: ideas/reading-map.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvcmVhZGluZy1tYXAubWQ#content Size: 61127 bytes, 1041 lines Score: 0.014 Related excerpt: se relatives of Moppe's terrain renderer. - Filip Strugar, [CDLOD][cdlod]. A direct implementation reference for distance-dependent terrain LOD, morph intervals, visibility ranges, and crack prevention. - Eric Bruneton and Fabrice Neyret, [*Precomputed Atmospheric Scattering*][atmospheric-scattering]. More physical machinery than Moppe necessarily wants, but good background for deciding which relationships in sky and distance should remain coupled. - Sebastien Lagarde and Charles de Rousiers, [*Moving Frostbite to Physically Based Rendering*][frostbite-pbr]. Useful lighting, exposure, and material vocabulary without implying that Moppe should surrender its art direction to generic PBR. - [Inigo Quilez's articles][iquilez] remain exceptionally useful practical reading on analytical noise derivatives, terrain normals, atmosphere, and procedural texturing. - [InfiniteDiffusion][infinite-diffusion] is an instructive contrasting answer to terrain authorship: learned refinement of coarse procedural controls. It is valuable partly because its tradeoffs around reproducibility, explainability, and geological history differ sharply from Moppe's. ## 18. Rendering water that belongs to the ter Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvcmVhZGluZy1tYXAubWQ#content"] 12. Source file: ideas/structure-of-space.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content Size: 24239 bytes, 620 lines Score: 0.014 Related excerpt: ded into structural bays according to the local meter. 7. Bays become deformed construction cells and select vernacular modules. 8. Piers, arches, beams, rails, stairs, and abutments adapt to local facts. 9. Terrain transforms fit the approaches while preserving the surrounding drainage and landform. 10. Use, repair, flood, and later additions continue the bridge's history. The scales divide responsibility cleanly: ```text spline says where the bridge goes cells say how the span is composed modules articulate local relationships history says what the bridge becomes ``` The bridge may begin as stepping stones, a ferry, or a timber span. Later stonework can retain the old ford, repaired footings, flood marks, a shrine to safe passage, or a desire path beneath an arch. Construction becomes geological in its own way: buildings are strata. ## Positive space and settlement Object placement optimizes buildings and inherits whatever space remains between them. A cellular construction language can shape occupied and unoccupied space together. - a loop of built cells creates a courtyard; - a widened route creates a square; - two offset buildings make a gateway; - an arcade mediates between i Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content"] ### 46. Assistant Yes. The motorcycle can follow almost exactly the Atelier tree’s three-storey architecture—but its combinatorial object is a **multibody mechanism** rather than a branching tree. The tree already establishes the principle: ```text combinatorial topology ↓ typed intrinsic structure ↓ embedding in world space ``` `DirectedTreeTopology` knows incidence, lineage, branch order, and shoot/root identity but no positions. Its bundles carry rest length, radius, flexibility, water potential, and so on. `embed_tree` then gives the same organism a diagrammatic or wind-bent spatial realization. For a motorcycle: ```text engineering topology ↓ mechanical qualities and current configuration ↓ kinematic embedding into world space ``` ## The combinatorial motorcycle A motorcycle is not fundamentally one pose-bearing blob. It is a structured mechanism: ```text motorcycle ├── chassis ├── steering assembly │ ├── fork │ └── front wheel ├── rear suspension │ ├── swingarm │ ├── spring │ └── damper ├── rear wheel ├── propulsion system └── rider-support system ``` But there are two structures here that should not be confused. ### Mereological structure What is part of what: ```text front wheel part_of motorcycle fork part_of steering assembly steering assembly part_of motorcycle ``` ### Kinematic topology What is mechanically connected to what: ```text chassis connected_to fork by steering joint fork connected_to front wheel by axle joint chassis connected_to swingarm by pivot joint swingarm connected_to rear wheel by axle joint chassis connected_to swingarm by spring-damper ``` The first may be a nested part hierarchy. The second is a typed graph and may contain loops. A suspension linkage, for example, cannot always be represented truthfully as a tree. So one possible combinatorial value is: ```cpp struct MotorcycleMechanism { RigidBodyDomain bodies; JointDomain joints; Incidence incidence; }; ``` with body particulars such as: ```text Chassis Fork Swingarm FrontWheel RearWheel ``` and joint particulars instantiating universals: ```text SteeringHead instantiates RevoluteJoint SwingarmPivot instantiates RevoluteJoint FrontAxle instantiates RevoluteJoint RearAxle instantiates RevoluteJoint RearShock instantiates SpringDamperLink ``` None of these needs a world position yet. ## The intrinsic mechanical storey Typed sections over the body and joint domains could carry the mechanism’s own engineering constitution. For rigid bodies: ```text mass center of mass in body frame inertia tensor collision shape material local attachment sites ``` For joints: ```text joint kind axis in each incident body’s frame rest transform allowed coordinate range spring stiffness damping coefficient steering limit drive coupling ``` For wheels: ```text radius axle direction rotational inertia tire compliance traction disposition ``` These facts are intrinsic to the motorcycle’s construction. Rotating or translating the whole motorcycle does not change them. This matches the spatial-functional hierarchy from the bodily-systems paper: the spatial taxonomy says what is an element of what, while the functional taxonomy says which lower-level operations enable the functioning of the whole (#77LY9W). ## Configuration is not yet embedding At a particular instant, the mechanism has a **configuration**: ```cpp struct MotorcycleConfiguration { RigidPose root_pose; SteeringAngle steering; SuspensionTravel front_suspension; SuspensionTravel rear_suspension; Angle front_wheel_rotation; Angle rear_wheel_rotation; }; ``` The joint values are generalized coordinates, commonly written as $q$. Their rates are $\dot q$: $$ q(t) = \begin{bmatrix} \text{steering}\\ \text{front suspension}\\ \text{rear suspension}\\ \text{front wheel spin}\\ \text{rear wheel spin} \end{bmatrix}. $$ The root pose places one distinguished body—probably the chassis—in the world. The other body poses are derived by forward kinematics: $$ E_t : (\text{mechanism},q(t),T_{\text{world}\leftarrow\text{chassis}}) \longrightarrow \{\text{world pose of each body}\}. $$ Conceptually: ```cpp EmbeddedMotorcycle embed ( const MotorcycleMechanism& mechanism, const MotorcycleIntrinsicState& intrinsic, const MotorcycleConfiguration& configuration, WorldFrame world); ``` The result might contain: ```cpp struct EmbeddedMotorcycle { Section body_poses; Section joints; }; ``` That is directly analogous to `EmbeddedTree`. ## Motion is a changing embedding This also gives a more exact account of motion. The motorcycle’s motion is not just a changing `position`. It is a curve through the configuration space of the entire mechanism: $$ t\mapsto \left( T_{\text{world}\leftarrow\text{chassis}}(t), q(t) \right). $$ That one curve includes: - translation and rotation of the chassis; - steering; - suspension compression and rebound; - wheel rotation; - rider articulation, if modeled; - eventually deformation or damage. The particular ride is a process. The configurations are its successive SNAP readings. Velocity is then a profile of this richer process: ```text chassis linear velocity chassis angular velocity steering rate suspension compression rate wheel angular velocity ``` The current `Vehicle::State` already contains a compressed version of these generalized coordinates: `position`, `velocity`, `yaw`, `susp`, `susp_v`, and `wheel_spin`. `VehiclePose` carries the presentation subset. Then `vehicle_render.cc` reconstructs the rigid chassis, steering assembly, wheels, and changing suspension links. So the current renderer already contains an **implicit motorcycle embedding function**. The engineering topology is encoded procedurally inside its draw logic rather than represented as a first-class value. ## Contact belongs outside the mechanism The embedded motorcycle can then enter relations with the world: ```text front tire contacts terrain region A rear tire contacts terrain region B chassis spatially disconnected from terrain rear tire supports part of motorcycle weight front tire participates in rolling contact ``` Contact is not part of the motorcycle’s intrinsic topology. It is a relation between an embedded motorcycle part and an embedded part of the world. This cleanly separates: ```text mechanism topology what can move relative to what configuration its current articulation embedding where its parts are now contact how those parts meet the environment dynamics how forces change the configuration presentation how the result is drawn ``` ## The spring is ontologically rich A suspension spring is a particularly good example because it participates in every layer: ```text spring part_of motorcycle connected_between chassis and swingarm bears_quality stiffness bears_quality rest length bears_disposition resist compression bears_function maintain wheel contact ``` During a ride: ```text this compression process has_participant spring realizes spring’s elastic disposition causally contributes to motorcycle support ``` The embedded distance between its attachment sites determines its current compression. That compression influences force: $$ F_s=-kx-c\dot{x}. $$ Here $k$ and $c$ are intrinsic qualities of the spring-damper system; $x$ is a reading of its current embedding; and the force is a magnitude associated with an ongoing interaction process. That is considerably more meaningful than a generic `SuspensionComponent`. ## Rendering becomes an explicit projection There may be several legitimate embeddings or projections of the same mechanism: ```text physical embedding collision and dynamics visual embedding shaped meshes, rider lean, squash engineering diagram labeled bodies, joints and forces HUD schematic suspension travel and contact ``` Just as the same Atelier tree can be shown as a wind-bent organism or a diagram, the same motorcycle could be shown as: - its ordinary rendered vehicle; - a Terrain Lab multibody diagram; - a contact and force visualization; - an exploded part hierarchy; - a suspension linkage inspection view. The mechanism remains the same. Only the projection changes. ## A compact architecture A first conceptual design could therefore be: ```text MotorcyclePartonomy nested substantial parts and assemblies MotorcycleMechanism rigid bodies, typed joints, incidence MotorcycleIntrinsic mass, inertia, dimensions, axes, limits, stiffness, damping, wheel radius MotorcycleConfiguration root pose, joint coordinates, coordinate rates MotorcycleEmbedding body and joint poses in the world MotorcycleInteraction contacts, support, traction, thrust, drag MotorcycleMotion the temporally extended process through configurations ``` This is also an answer to the spreadsheet ontology. The motorcycle is not a bare entity carrying `Position`, `Suspension`, and `WheelSpin` columns. It is a structured whole whose parts bear qualities and functions, whose joints delimit a space of possible configurations, and whose current configuration is embedded into the world. The particularly strong analogy is: > The tree’s topology expresses how growth can be connected; the motorcycle’s mechanism expresses how engineered motion can be connected. Both remain themselves independently of where they happen to be in world space. ### 47. User Oh yeah, I also wonder if it would be helpful to think in terms of different ranks of co-chains, or whatever: zero coaching, one co-chains, and so on. We don't really have that in that right now, but ### 48. Assistant Yes. The Atelier tree already has an implicit rank grading: - `Tree::VertexState` is a collection of sections over **0-cells**; - `Tree::EdgeState` and `TreeEdgeForm` are sections over **1-cells**; - `DirectedTreeTopology` supplies incidence between them. It does not presently abstract that as a general cochain complex, but the structure is there. ## For the motorcycle Treat rigid bodies as vertices and mechanical connections as oriented edges: ```text 0-cells: rigid bodies chassis fork swingarm front wheel rear wheel 1-cells: joints and mechanical connections steering joint swingarm pivot front axle rear axle spring-damper connection ``` Then quantities naturally live at different ranks. ### Rank 0: body readings ```text mass inertia center of mass world pose linear velocity angular velocity momentum external load ``` These assign one value to each rigid body, so they are 0-sections and, where the coefficient structure permits it, 0-cochains. ### Rank 1: joint readings ```text joint axis rest transform steering angle suspension displacement relative angular velocity spring force constraint wrench transmitted power ``` These belong to connections between bodies, so they are naturally 1-sections or 1-cochains. This already prevents a common modeling mistake: suspension travel does not simply inhere in “the motorcycle.” It is a reading associated with the connection between the chassis and suspension assembly. ## Incidence gives useful operators Suppose an edge $e$ is oriented from body $a$ to body $b$. For a scalar 0-cochain $\phi$, the coboundary is $$ (d\phi)(e)=\phi(b)-\phi(a). $$ So a body-valued quantity can induce a relative joint quantity: ```text body angular velocity ↓ coboundary relative angular velocity across joint ``` Conversely, forces transmitted along joints can be accumulated onto incident bodies using the signed incidence structure: ```text joint wrenches ↓ signed accumulation net internal wrench on each body ``` This is the discrete analogue of gradient and divergence. It could organize the mechanics around laws rather than component iteration: $$ \frac{d\mathbf p}{dt} = \text{external load} + \operatorname{div}(\text{joint load}). $$ The orientations are bookkeeping conventions, not physical asymmetries. Reversing a joint edge reverses the sign of its relative displacement, velocity, force, or flow. ## Pose makes it nonlinear Rigid transformations do not form a vector space, so world poses are not ordinary linear cochains. A pose assigns an element of $SE(3)$ to each body: $$ T_a\in SE(3). $$ The relative placement across a joint is $$ T_{a\to b}=T_a^{-1}T_b. $$ That acts like a nonlinear, group-valued discrete derivative. Velocities and infinitesimal displacements live in the corresponding Lie algebra $\mathfrak{se}(3)$, where more ordinary linear operations become available. So the wider abstraction might be **ranked sections over a complex**, with ordinary cochains as the important linear case: ```text ranked section ├── scalar/vector cochain ├── point-valued section ├── frame-valued section ├── SE(3)-valued placement └── nominal joint-kind section ``` That language would fit the existing Atelier architecture better than claiming every typed bundle is literally a cochain. ## Rank 2 for closed linkages If the mechanism has closed linkage loops, 2-cells become meaningful. Consider bodies and joints forming a loop: ```text chassis → linkage A → linkage B → swingarm → chassis ``` A 2-cell can name that kinematic loop. Its closure law says that the product of relative transformations around its boundary must return to the starting frame: $$ T_{01}T_{12}T_{23}T_{30}=I. $$ In a linearized model, the corresponding signed joint displacements sum to zero around the boundary: $$ \sum_{e\in\partial f}\epsilon_{fe}q_e=0. $$ Thus: - 0-cells say which bodies exist; - 1-cells say how bodies are connected; - 2-cells say which connection cycles must close. A basic bike mechanism may be mostly tree-like and need only ranks 0 and 1. A realistic rear linkage, steering assembly, or articulated suspension can introduce genuine cycles. Rank 2 should appear because the engineering structure calls for it, not merely to complete an abstract hierarchy. ## Contact can extend the complex temporarily Terrain contact can be represented by adding transient relational edges: ```text front wheel —contact→ terrain support region rear wheel —contact→ terrain support region ``` Those contact 1-cells can carry: ```text normal force friction force slip velocity contact normal penetration/compression ``` When the bike becomes airborne, those edges cease to exist. Takeoff and landing are therefore changes in the topology of the active interaction complex, as well as process boundaries. That is a particularly elegant description: > Grounded riding has wheel–terrain contact edges; airborne motion does not. ## An ontological caution Cochain rank belongs to a **chosen representation**, not automatically to the entity’s metaphysical category. For example, a physical spring is: - a material part of the motorcycle; - perhaps a 0-cell in a partonomy of components; - represented as a 1-cell in the mechanism graph because it connects two bodies; - the bearer of qualities such as stiffness and rest length. So it would be dangerous to say “all 1-cells are relations” or “all substances are 0-cells.” The same real thing can appear at different ranks in different granular partitions. The ontology says what the spring is. The complex says how the current model uses it. ## A possible concrete C++ shape Without generalizing `Bundle` too early: ```cpp struct MotorcycleComplex { BodyDomain bodies; // rank 0 JointDomain joints; // rank 1 LinkageLoopDomain loops; // rank 2, possibly empty BodyId source (JointId) const; BodyId target (JointId) const; void visit_boundary (LinkageLoopId, auto&& visitor) const; }; ``` Then: ```cpp using BodyState = spatial::Bundle< BodyDomain, BodyMass, BodyInertia, BodyPose, LinearVelocity, AngularVelocity>; using JointState = spatial::Bundle< JointDomain, JointCoordinate, JointRate, JointLoad, JointPower>; ``` Only after the tree and motorcycle both demonstrate the same laws would it be worth extracting something like: ```cpp CellDomain<0, Complex> CellDomain<1, Complex> CellDomain<2, Complex> coboundary<0> (complex, body_values) boundary<1> (complex, joint_values) ``` The strongest formulation is therefore: > The tree and motorcycle are both rank-graded complexes with typed sections. The tree’s edges carry biological transport and form; the motorcycle’s edges carry kinematic constraint, force, and power. Embedding turns their intrinsic structures into spatial configurations. That could become a genuinely unifying mathematical layer between the Atelier organism and the moving engineered vehicle. ### 49. User ah, here is some stuff we found in the Relations Ontology Read it — 704 relations, and it's a goldmine, partly because RO doesn't just name relations, it declares their *algebra*: transitivity, symmetry, inverses, domain/range, and composition laws (`holds_over_chain`, `transitive_over`). That last one is the part I'd steal wholesale. Here's the harvest, sorted by the storeys in your design. ## Partonomy — and the distinction RO draws that you'd want `part of` / `has part` are transitive, and both are subrelations of `overlaps` ("x overlaps y iff there exists z such that x has part z and z part of y", symmetric). But the one you actually want for assemblies is narrower: > **has component** — "w has component p if w has part p and w is such that it can be **directly disassembled** into n parts p, p2, … pn, where these parts are **of similar type**." That's a bolt-apart relation, not just any parthood — exactly the difference between "the swingarm is part of the motorcycle" and "the motorcycle has components: chassis, fork, swingarm, wheels." And separately: > **member of** — "a mereological relation between an item and a **collection**" (is_a `part of`) which is the fleet relation, formally distinguished from component-hood. Stars are members of the star field; the fork is a component of the steering assembly. RO keeps these apart and so should we. Best find in this group: > **has skeleton** — "a relation between a segment or subdivision of an organism and the **maximal subdivision of material entities that provides structural support** for that segment." The chassis is the skeleton of the motorcycle. And `skeleton of` is_a `part of`, so the algebra is already right. ## Kinematic topology — RO has your joint relation, and it's mechanically defined This is where I got genuinely excited, because the definitions are *physical*, not anatomical hand-waving: > **connected to** — "a is connected to b iff a and b are discrete structures, and there exists some **connecting structure c** such that c connects a and b." > **connects** — "c connects a iff there exists b such that a and b are similar parts of the same system, and c connects a with b. **When one structure connects two others it unites some aspect of the function or role they play within the system.**" That is precisely your `Incidence`: the joint is the connecting structure, the bodies are the connected ones, and connectedness is *mediated by a third entity* rather than being a bare edge. Then: > **attached to** — "a is attached to b iff a and b are discrete objects or object parts, and there are physical connections between a and b such that **a force pulling a will move b, or a force pulling b will move a**." (symmetric, is_a `connected to`) A force-transmission definition, sitting one level below `connected to`. A revolute joint is `connected to` with freedom; a weld is `attached to`. And the umbrella term is an open invitation: > **biomechanically related to** — "a relation that holds between elements of a musculoskeletal system **or its analogs**." (is_a `functionally related to`) A motorcycle is an analog of a musculoskeletal system. Under it live the two relations I'd most want for actuators: > **has muscle origin** — "m has_muscle_origin s iff m is attached_to s, and **when m contracts, s does not move**." > **has muscle insertion** — "m has_muscle_insertion s iff m attaches to s, and **when m contracts, s moves**." That's the fixed end versus the driven end of any actuator — the shock's chassis mount versus its swingarm mount, the chain's sprocket versus the wheel. The asymmetry is defined by *what moves when it acts*, which is the mechanically meaningful thing. Plus `has muscle antagonist` for opposed pairs (spring versus damper, throttle versus brake). ## The dependent-continuant fourfold — your spring example, formalized RO distinguishes four kinds of thing that inhere in a bearer, and the spring instantiates all four: - **has quality** — actual, occurrent-free: stiffness *k*, rest length, current compression - **has disposition** — a potential, realized only in a process: resists compression - **has function** — what it is *for*: maintain wheel contact (a function is a disposition the thing exists in order to have) - **has role** — externally conferred, not intrinsic: this body serves as *the root* of forward kinematics All four are `has characteristic`, all with `characteristic of` inverses. Then the disposition/process bridge: > **realizes** — "a relation between a process and a realizable entity, where some material entity bears the realizable entity and participates in the process, and the realizable entity **comes to be realized in the course of** the process." Your `this compression process realizes spring's elastic disposition` is verbatim correct RO. And the pair that grounds a disposition in structure — `realizable has basis in` / `is basis for realizable` — says stiffness-the-quality is the basis for resist-compression-the-disposition. That's *F = −kx − cẋ* read ontologically: intrinsic qualities are the basis, the process realizes the disposition, the force is the magnitude of the interaction. One more, straight from the bodily-systems criticality idea: > **determined by** — "s determined by f iff s is a **system**, f is a material entity part of s, f exerts a strong causal influence on the functioning of s, and **the removal of f would cause the collapse of s**." Critical components, defined by counterfactual removal. Lose a mirror, keep the motorcycle; lose the swingarm pivot, and there is no mechanism left. ## Contact and environment — the layer outside the mechanism > **occurs across** — "a process occurring in a region **spanning a barrier**." (their example: transport across a membrane) Rolling contact occurs across the tire–ground interface. That's the right shape for contact: not a property of the tire, but a process spanning a boundary between two embedded things. Supporting cast: `adjacent to` ("x and y share a boundary"), `surrounded by`, `has 2D boundary` / `2D boundary of`, and > **immersed in** — "a relation between a physical entity and a **fluid substance** in which the entity is wholly or substantially surrounded by the substance." which is the water level relation you already compute for wading and underwater grading, with a name. ## Processes — Allen's interval algebra, formally axiomatized RO gives the full temporal vocabulary with α (start) and ω (end) functions: `precedes` / `preceded by` (transitive), `starts with` ("α(y) = α(x) ∧ ω(y) < ω(x)"), `ends with`, `happens during`, `encompasses`, `simultaneous with`, `immediately precedes`, `before`. Plus the participation family — `has participant`, `has input` ("present at the start, and **the state of c is modified during** p"), `has output` ("present at the end, and **not present in the same state** at the beginning"), `has intermediate`, `has component process`, `results in movement of`, `results in transport along`. And the pair that bridges continuant lifetimes into process time — which is your genidentity story stated precisely: > **existence starts during** / **existence ends during** — "x existence starts during y iff α(x) ≥ α(y) and α(x) ≤ ω(y)." A dust emission's existence starts during the ride; a star's existence-interval versus the session's. Causality gets `causally upstream of` (transitive, is_a `precedes`) and `immediately causally upstream of` ("the end of p is coincident with the beginning of q"). ## Two relations aimed straight at parts of moppe that aren't the motorcycle **Hydrology** — RO has a complete drainage vocabulary, apparently designed for exactly your merge trees: `tributary of` ("a channel for the flow of a substance into y, where y is larger"), `proper tributary of` ("and x does not originate from y"), `distributary of`, `main stem of` ("a channel tracing a linear path through y such that x has **higher capacity than any other such path**"), `branching part of`, `conduit for`, `drains`, `lumen of` — and my favorite piece of vocabulary in the whole file: > **anabranch of** — "x is a distributary of y which **ultimately channels the flow back into y**." A braided-river side channel, named. That is a term the drainage code could use tomorrow. **Registration** — for the surface atlas and multi-channel textures: > **in register with** — "A depicts X; B depicts Y; A and B are **aligned according to a shared coordinate framework** so that common features of X and Y are coincident." (examples: two channels collected simultaneously from a confocal microscope; a tracing and the coordinate space of the stack) That's the invariant binding every bundle column, texture lane, and presentation buffer over the same surface domain — and it's the True Grid transparency condition restated for the multi-layer case. Adjacent: `aligned with`, `coincident with` ("two linear structures approximately parallel for their entire length" — a trail running alongside a river), `spatially coextensive with`, `continuous with` ("X and Y **share a fiat boundary**" — Smith's fiat boundaries showing up inside RO). Also worth noting: `concretizes` / `is concretized as` / `is carrier of` — the generically-dependent-continuant machinery, which is the pattern-versus-instance relation. A world recipe is a generic pattern; a generated world concretizes it; a mesh carries it. That's the vocabulary for seeds and recipes we sketched in the ontology doc. ## The thing I'd actually steal Beyond the terms: RO relations ship with their **composition laws**. `occurs in` is `transitive_over part_of` — if a process occurs in the wheel and the wheel is part of the bike, it occurs in the bike. `has participant` holds over the chain `has part` + `has participant` — if the bike has a wheel and the wheel participates in the rolling, the bike participates. `attached to part of` holds over `attached to` + `part of`. Those are exactly the inference rules a typed relation library would want to encode — and they're the reason a relation vocabulary is more than naming: the laws let you *derive* facts about wholes from facts about parts, which is precisely what forward kinematics and contact aggregation do numerically. Worth a section in [docs/ontology.md](docs/ontology.md) if you want me to add one, or a companion note pinning down which RO relations moppe adopts and what each one licenses. ### 50. Assistant tool calls #### Tool call: `search_text` ```json { "document_id": "3CV92Z", "limit": 15, "query": "Relations Ontology holds_over_chain transitive_over has component has skeleton" } ``` #### Tool call: `web_search` ```json { "query": "OBO Relations Ontology RO holds_over_chain transitive_over has component definition attached to connects has skeleton" } ``` #### Tool call: `web_search` ```json { "query": "Relations Ontology RO has muscle origin has muscle insertion determined by definition" } ``` #### Tool call: `web_search` ```json { "query": "OBO Relations Ontology GitHub ro.owl relation composition holds over chain" } ``` ### 51. Tool result: search_text Exact matches 1. Source file: moppe/terrain/merge_tree.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9tZXJnZV90cmVlLmNj#content Size: 10408 bytes, 262 lines Matching excerpt: #include #include #include #include #include #include namespace moppe::terrain { namespace { struct MergeOffset { int x; int y; }; constexpr std::array merge_neighbors { { { -1, -1 }, { 0, -1 }, { 1, -1 }, { -1, 0 }, { 1, 0 }, { -1, 1 }, { 0, 1 }, { 1, 1 } } }; std::size_t merge_wrapped (int value, std::size_t period) { const int n = static_cast (period); const int result = value % n; return static_cast (result < 0 ? result + n : result); } // Path-halving union-find over cell indices; the component root // carries the id of its current merge-tree node. std::uint32_t find_root (std::vector& parent, std::uint32_t cell) { while (parent[cell] != cell) { parent[cell] = parent[parent[cell]]; cell = parent[cell]; } return cell; } } MergeTree detail::build_merge_tree (const TerrainDomain& grid, std::span elevations) { const std::size_t width = grid.width (); const std::size_t height = grid.height (); const std::size_t count = width * height; // Sort unique cells by (height, index): the same deterministic // order the drainage analyses us Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9tZXJnZV90cmVlLmNj#content"] 2. Source file: ideas/structure-of-space.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content Size: 24239 bytes, 620 lines Matching excerpt: # The structure of space *Notes toward a cellular tissue for places, construction, and memory.* ## The proposition Moppe's landscape is currently represented with great success as fields: height at a position, water over rock, slope, drainage, material, and the successive results of terrain transformations. This is the right language for geology at landscape scale. It is not by itself the right language for everything that may later inhabit the land. Paths, crossings, rooms, courtyards, bridges, property, construction stages, names, and remembered events want discrete identity. They want adjacency, containment, boundaries, and persistence. They want to say *this place*, *this edge*, and *these neighbors*, even while their physical realization remains smooth and irregular. The proposed middle layer is a **draped cellular tissue**: a mostly quadrilateral, locally rhythmic, irregular two-dimensional cell complex embedded in the smooth terrain. It exists lightly across the world and grows sparse three-dimensional cellular structure where construction takes hold. The terrain remains continuous where continuity matters. The tissue becomes discrete where composition matters. This is not t Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc3RydWN0dXJlLW9mLXNwYWNlLm1k#content"] 3. Source file: docs/ontology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines Matching excerpt: # What Exists in Moppe Moppe keeps careful accounts of *how much*: heights in meters, thrust in newtons, sink rates in meters per second. The type system refuses to add an airspeed to an altitude, and the codebase is better for it. This document starts a parallel set of accounts about *what kinds of things there are*. It is not a specification and it proposes no work. It is a vocabulary — a way of talking about the game world that stays truthful about the structure of what the code simulates, the way `units.md` stays truthful about magnitudes. The vocabulary is borrowed, mostly from the ontologist Barry Smith and his collaborators, whose papers live in `research/` (readable in sections at `https://m.sheaf.less.rest/` with `Accept: text/markdown`). Their subject is ordinary reality — mountains, headaches, county borders, orchestras — but a game world turns out to be built from the same kinds of things, and it is clarifying to call them by their proper names. ## Fields and things Ask what the terrain *is* and two honest answers come back. To the simulation, the terrain is a field: elevation as a value at every position, and alongside it moisture, forest cover, snow support, channel f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content"] 4. Source file: plan/rfc-014-merge-tree-hydrology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9yZmMtMDE0LW1lcmdlLXRyZWUtaHlkcm9sb2d5Lm1k#content Size: 5730 bytes, 121 lines Matching excerpt: # RFC-014: The merge tree as the one hydrological data structure - Status: Draft - Area: terrain analysis (hydrology), enabling simulation and Lab work - Interacts with: RFC-001 (depression routing per step), Lab sea-level interaction, storm/spectacle ideas (`ideas/terrain-lab-spectacles.md`, `geometry-from-fields.md` item 8) ## Problem Every standing-water question is currently answered by re-running a priority flood at one fixed sea level. `analyze_standing_water` floods the whole map to produce one `FloodField`; `census_lakes` labels its bodies; spills are recovered by walking receiver chains; the endorheic and all-land cases need explicit special handling (`flood.cc:70,155`). Change the sea level -- or ask "what if this basin filled?" -- and everything recomputes from scratch. RFC-001 would need depression routing *every timestep*, and the Lab cannot offer a continuous sea-level slider or a "watch the basins fill" spectacle at interactive cost. The underlying structure is well known: sinks are minima of the height function, spills are saddles, lakes are connected components of sublevel sets, and the way components merge as the water rises is the **merge tree** of the heightfiel Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9yZmMtMDE0LW1lcmdlLXRyZWUtaHlkcm9sb2d5Lm1k#content"] 5. Source file: moppe/terrain/merge_tree.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9tZXJnZV90cmVlLmho#content Size: 3304 bytes, 90 lines Matching excerpt: #ifndef MOPPE_TERRAIN_MERGE_TREE_HH #define MOPPE_TERRAIN_MERGE_TREE_HH #include #include #include #include #include namespace moppe::terrain { // The merge tree of the heightfield: how connected components of the // sublevel sets are born at minima and join at saddles as the water // level rises. One deterministic O(n log n) precomputation answers // every standing-water question -- floods, lakes, spills, sea-level // queries -- as views, replacing per-query priority floods. // // Nodes are stored in creation order, so every parent appears after // all of its children; a single forward or reverse pass visits the // tree bottom-up or top-down. Ties in height break by cell index, // preserving determinism-by-construction. struct MergeTreeNode { static constexpr std::uint32_t no_node = 0xffffffffu; // Leaves are born at their minimum's height; merge nodes at the // saddle height where two or more components join. float birth; // The minimum cell for a leaf; the saddle cell for a merge node. CellIndex origin; std::uint32_t parent = no_node; // Number of children (0 for a leaf); child Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9tZXJnZV90cmVlLmho#content"] 6. Source file: docs/surface-atlas.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content Size: 6695 bytes, 107 lines Matching excerpt: # The current-engine surface atlas This is the small atlas for Moppe's adopted Atelier earth vocabulary. It describes the current engine, not the proposed second engine. The purpose is to make its topology, intrinsic readings, and rendering bridge enumerable. For the wider ownership, state, presentation, and target map, start with the [engine atlas](engine-atlas.md). ## Storeys | Storey | Current object | Responsibility | | --- | --- | --- | | Combinatorial | `map::SurfaceDomain` | The finite toroidal vertex lattice, index/offset correspondence, horizontal spacing, and bilinear reconstruction stencil. | | Intrinsic | `map::SurfaceAtlas`, `map::WaterSurfaceSections` | Typed 0-cochains sharing the lattice but kept in named ground groups and a distinct water bundle. `map::Surface` owns the authoritative ground geometry and its later analyses. | | Extrinsic | `game::SurfacePresentation`, `game::WaterPresentation` | Convert typed columns to plain scalar texture payloads and upload them through `render::Renderer`. These are the quantity-to-number bridges. | Terrain generation writes the mandatory geometry bundle directly. Hydrology, geology, ecology, and use add readings at later, named Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9zdXJmYWNlLWF0bGFzLm1k#content"] 7. Source file: ideas/watersheds-of-execution.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvd2F0ZXJzaGVkcy1vZi1leGVjdXRpb24ubWQ#content Size: 13418 bytes, 287 lines Matching excerpt: # The watersheds of execution *Notes toward reading a program as a landscape of paths, catchments, and moving attention.* ## The resemblance Moppe's terrain machinery and its source-code analysis have arrived at nearly the same object from opposite directions. The hydrology begins with a field, derives a drainage graph, accumulates contributing area, finds catchments and confluences, and asks where water is likely to travel. The program begins with source files, derives a call graph, accumulates structural importance, finds communities and bottlenecks, and asks where execution is likely to travel. This is not only a convenient metaphor. Both are directed systems whose local structure produces larger paths: ```text terrain program cell or drainage node function downhill connection call catchment entrypoint reachability region contributing area transitive callers confluence high fan-in discharge call frequency or PageRank sediment load carried complexity watershed divide module or community boundary closed depression recursive component ocean return from the outermost entrypoint ``` A river is not bad because it carries a great deal of water, and a function is not bad because it has Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvd2F0ZXJzaGVkcy1vZi1leGVjdXRpb24ubWQ#content"] 8. Source file: docs/project.org Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9wcm9qZWN0Lm9yZw#content Size: 39327 bytes, 737 lines Matching excerpt: #+title: Moppe project #+startup: overview * Purpose Moppe is currently a motorcycle game and a laboratory for generated worlds. It has several inherited or experimental modes, but the main line of work is the random world: generate a landscape, understand how it formed, render it convincingly, and ride through it. The immediate goal is not yet to build a large game around that world. It is to make the world coherent enough that riding it produces places worth noticing: waterways that make sense, terrain with a readable history, and routes and obstacles that arise from the land rather than being scattered on top of it. The more speculative ambition is an inhabited procedural world. The [[file:../ideas/second-author.md][second-author notes]] explore how geology might eventually support paths, roads, centers, and settlements. The [[file:../ideas/tending-the-world.md][tending-the-world essay]] develops the related possibility that riding, interpreting, and changing the landscape could become one continuous form of play instead of a game/editor split. The [[file:../ideas/structure-of-space.md][structure-of-space notes]] explore an irregular cellular tissue between smooth terrain fields Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9wcm9qZWN0Lm9yZw#content"] 9. Source file: tests/game/cinematic_flight_test.cc Resource: https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9jaW5lbWF0aWNfZmxpZ2h0X3Rlc3QuY2M#content Size: 14886 bytes, 348 lines Matching excerpt: #include #include #include #include using namespace moppe; namespace { struct FlightFixture { static constexpr int side = 17; static constexpr std::size_t count = side * side; map::Surface map { side, side, Vec3 (1600, 240, 1600) }; terrain::TerrainDomain grid = map.domain (); terrain::RasterDomain domain { .width = side, .height = side }; terrain::FloodField flood; terrain::LakeCensus census; terrain::DrainageGraph drainage; terrain::RiverNetwork rivers; FlightFixture () : flood { .domain = grid, .sea_level = 0.1f, .has_ocean = false, .water_level = terrain::ScalarRaster ( domain, std::vector (count, 0.1f)), .water_depth = terrain::ScalarRaster ( domain, std::vector (count, 0.0f)), .ocean = std::vector (count, 0), .spill_receiver = std::vector (count), .outlets = {} }, census { .body = std::vector ( count, terrain::LakeCensus::dry) }, drainage { .domain = grid, .receiver = std::vector (count), .slope = terrain::SlopeRaster (terrain::ScalarRaster ( domain, std::vector (count, 0.05f))), .contributing_area = terrain::Co Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/dGVzdHMvZ2FtZS9jaW5lbWF0aWNfZmxpZ2h0X3Rlc3QuY2M#content"] 10. Source file: ideas/second-author.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc2Vjb25kLWF1dGhvci5tZA#content Size: 20020 bytes, 372 lines Matching excerpt: # The Second Author *Notes toward an inhabited world — a design brief for the layer above geology.* --- ## Where we stand The world currently has one author. A `GeologicalSource` expands into a `ScalarField`; the field materializes into a raster; a sequence of `TerrainTransform`s — normalize, power, droplets, talus — gives it a history; the whole thing is a `TerrainProgram`, a value you can hold, edit in the Tycoon window, and replay deterministically on the current evaluator. Stable serialization and cross-machine golden terrain are goals, not present contracts. The random world wraps: it is a flat torus with no edge to apologize for. `DrainageGraph` already records dry receivers and contributing area; `FloodField` and the lake census record standing water. Depression-aware routing is still the first author's active frontier—rock proposed, water disposing, the score kept in strata. And the first author's work, when it's done well, is already alive in a specific, checkable sense: erosion manufactures most of what Alexander called the fifteen properties. Levels of scale come from the stream hierarchy, strong centers from peaks and confluences, boundaries from ridgelines, gradients f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/aWRlYXMvc2Vjb25kLWF1dGhvci5tZA#content"] 11. Source file: plan/done/rfc-001-uplift-stream-power.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9kb25lL3JmYy0wMDEtdXBsaWZ0LXN0cmVhbS1wb3dlci5tZA#content Size: 7346 bytes, 150 lines Matching excerpt: # RFC-001: Uplift fields and stream power run to quasi-equilibrium - Status: Implemented (2026-07-13) - Area: terrain simulation - Interacts with: RFC-002 (diffusion), RFC-004 (performance), RFC-014 (merge-tree hydrology) ## Problem The generator composes noise first and erodes second. The recipe blends continent, plains, and ridged-mountain noise through a mask (`make_geological_fields` in `moppe/terrain/geological.cc`), and only then do droplets and talus modify the result. Erosion is a garnish on shapes that never earned their drainage: ridged noise produces mountain *texture*, not mountain *structure*. Valley networks are shallow and local, divides sit wherever the noise put them, and no amount of droplet count buys the dendritic coherence, uniform profile concavity, and knickpoint character that real landscapes get from the interplay of uplift and incision. ## Current situation - `AnalyticalErosion` (`moppe/terrain/analytical_erosion.cc`) already implements the finite-time n = 1 stream-power characteristic solution after Tzathas et al., with `uplift_rate` in metres per Julian year, a fixed sea level, per-iteration depression-aware drainage (`analyze_wet_drainage`), and relaxat Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/cGxhbi9kb25lL3JmYy0wMDEtdXBsaWZ0LXN0cmVhbS1wb3dlci5tZA#content"] 12. Source file: docs/atelier-earth.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content Size: 15763 bytes, 318 lines Matching excerpt: # The Atelier earth A proposal to widen the atelier's scope: from a studio of small organisms (the tree, the carpet, the cellular sheet) to a second implementation of the engine itself, begun again from the foundations of the earth. This is not a refactor of moppe and not a port. Moppe continues to run, generate, and play. The atelier grows a world beside it, small and whole at every stage, made of the semantic material we have learned to want: typed quantities, affine frames, rank-graded domains, sections, and a discrete calculus — with Metal as the prime instance substrate. Where moppe discovered these ideas mid-flight and carries them partially, the atelier bakes them in from the first line. The two meet later by adoption, organ by organ, never by conversion. ## What "engine" means here Not "motorcycle game." The engine is a simulation of a world: - a **combinatorial storey** — finite topologies: lattices, trees, sheets; vertices, edges, faces; incidence and orientation. No positions live here. - an **intrinsic storey** — typed sections over those topologies: bundles whose columns are labelled by mp-units quantity specifications. Elevation is a point-valued 0-cochain; a flow is Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9hdGVsaWVyLWVhcnRoLm1k#content"] 13. Source file: moppe/terrain/flood.hh Resource: https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9mbG9vZC5oaA#content Size: 3865 bytes, 108 lines Matching excerpt: #ifndef MOPPE_TERRAIN_FLOOD_HH #define MOPPE_TERRAIN_FLOOD_HH #include #include #include #include #include #include namespace moppe::terrain { // The standing liquid surface over a materialized terrain. Rasters contain // unique torus samples; spill_receiver forms a deterministic forest leading // to the largest connected below-sea component (or the global-minimum // fallback when the world has no ocean). struct FloodField { TerrainDomain domain; float sea_level; bool has_ocean; ScalarRaster water_level; ScalarRaster water_depth; std::vector ocean; std::vector spill_receiver; std::vector outlets; std::size_t width () const noexcept { return domain.width (); } std::size_t height () const noexcept { return domain.height (); } }; enum class WaterBodyClass { Puddle, Pond, Lake, Sea }; struct WaterBody { static constexpr CellIndex no_cell = terrain::no_cell; WaterBodyId id; CellCount cells; square_meters_t area; meters_t maximum_depth; meters_t mean_depth; cubic_meters_t volume; meters_t surface_level; bool ocean_connected; CellIndex outlet_ Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/bW9wcGUvdGVycmFpbi9mbG9vZC5oaA#content"] 14. Source file: docs/terrain-expressions.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90ZXJyYWluLWV4cHJlc3Npb25zLm1k#content Size: 7006 bytes, 174 lines Matching excerpt: # Terrain generation and analysis Moppe has one finite terrain lattice and one authoritative ground bundle. Generation creates typed columns over that lattice; ordered transforms mutate the elevation and material-history columns; analyses return named finite products. There is no runtime field-expression language or general materialization backend. ## The common domain `terrain::TerrainDomain` owns: - periodic width and height; - physical X/Z sample spacing; - cell area and world periods; - checked index/offset conversion; - the bilinear stencil used for continuous sampling. An NxN domain is N periodic cells. It stores no duplicated seam. CPU neighbours and GPU texel reads wrap at N. `map::SurfaceDomain` is an alias for this type. Terrain generation, surface geometry, flood, drainage, merge trees, trails, waterlines, and water surfaces therefore exchange the same domain value rather than translating between grid descriptions. ## Typed finite bundles `spatial::Bundle` stores one native vector per quantity specification over a finite domain. A row is one site; a focus is a site plus its domain position for local rules. `spatial::get` selects a column by mea Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90ZXJyYWluLWV4cHJlc3Npb25zLm1k#content"] 15. Source file: docs/trails.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90cmFpbHMubWQ#content Size: 15727 bytes, 339 lines Matching excerpt: # Trail system Moppe currently makes one deliberate leisure circuit. It is not a natural track network extracted from drainage, and its continuous alignment is not placed independently of the terrain. The system first chooses a plausible home base and a scenic reason for a loop, searches for two distinct rides around that feature, refines the discrete route into a smooth designed alignment, and then reconciles that alignment with the heightmap using bounded cut and fill. The result has four related but separate meanings: - a discrete plan and directed circuit that records the searched topology; - a continuous plan-view alignment used by grading and presentation; - shaped terrain where construction was needed and possible; - continuous trail and home-base influence fields used by materials and surface queries. This distinction is important: the trail material covers the complete planned circuit. Trail influence is not created only where earthworks changed the heightmap. ## Place in world generation World construction runs trail formation after geological evolution: ```text geological source -> orogeny and erosion -> drainage and standing-water readings -> trail planning -> continuou Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy90cmFpbHMubWQ#content"] Approximate matches 1. Source file: docs/ontology.md Resource: https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content Size: 15137 bytes, 290 lines Score: 0.033 Related excerpt: # What Exists in Moppe Moppe keeps careful accounts of *how much*: heights in meters, thrust in newtons, sink rates in meters per second. The type system refuses to add an airspeed to an altitude, and the codebase is better for it. This document starts a parallel set of accounts about *what kinds of things there are*. It is not a specification and it proposes no work. It is a vocabulary — a way of talking about the game world that stays truthful about the structure of what the code simulates, the way `units.md` stays truthful about magnitudes. The vocabulary is borrowed, mostly from the ontologist Barry Smith and his collaborators, whose papers live in `research/` (readable in sections at `https://m.sheaf.less.rest/` with `Accept: text/markdown`). Their subject is ordinary reality — mountains, headaches, county borders, orchestras — but a game world turns out to be built from the same kinds of things, and it is clarifying to call them by their proper names. ## Fields and things Ask what the terrain *is* and two honest answers come back. To the simulation, the terrain is a field: elevation as a value at every position, and alongside it moisture, forest cover, snow support, channel f Read the complete file with read blocks=["https://m.sheaf.less.rest/3CV92Z/source-files/ZG9jcy9vbnRvbG9neS5tZA#content"] ### 52. Tool result: web_search WEB SEARCH RESULTS Query: OBO Relations Ontology RO holds_over_chain transitive_over has component definition attached to connects has skeleton In the **OBO Relations Ontology (RO)**, these terms mean: ### Property-chain tags - **`holds_over_chain: R1 R2`** in the stanza for relation `R` means: ```text R1(x,y) and R2(y,z) → R(x,z) ``` It corresponds to the OWL axiom: ```owl SubObjectPropertyOf( ObjectPropertyChain(R1 R2) R ) ``` - **`transitive_over: Q`** in the stanza for relation `P` is the special case: ```text P(x,y) and Q(y,z) → P(x,z) ``` Thus it is equivalent to `holds_over_chain: P Q`. ([owlcollab.github.io](https://owlcollab.github.io/oboformat/doc/GO.format.obo-1_4.html?utm_source=openai)) ### Relations | Relation | RO identifier | Meaning | |---|---|---| | **has component** | `RO:0002180` | `w` has component `p` when `p` is a part of `w`, and `w` can be directly decomposed into multiple similar-type components. It is a subproperty of **has part**, but is deliberately non-transitive so it can be used in cardinality restrictions such as `has component exactly 5 digit`. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) | | **attached to** | `RO:0002371` | Two discrete objects or object parts are physically connected such that pulling either one would move the other. The relation is symmetric and is a subproperty of **connected to**. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) | | **connects** | `RO:0002176` | A connecting structure joins two similar parts of the same system, uniting some aspect of their function or role. Example: a joint connects two bones. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) | | **has skeleton** | `RO:0002551` | Relates an anatomical subdivision to the maximal material subdivision providing its structural support. It is a subproperty of **has part**, is asymmetric, and has inverse **skeleton of** (`RO:0002576`). ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) | ### Relevant RO chain example RO defines **attached to part of** (`RO:0002177`) using: ```obo holds_over_chain: RO:0002371 BFO:0000050 ``` Therefore: ```text x attached_to y y part_of z ───────────────── x attached_to_part_of z ``` This chain produces **attached to part of**, not plain **attached to**. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) The current RO file does **not** declare `has component`, `attached to`, `connects`, or `has skeleton` themselves as transitive relations. In particular, treating **has component** as transitive would conflict with its intended use for direct-component cardinalities. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) Cited sources: - The OBO Flat File Format Guide, version 1.4: https://owlcollab.github.io/oboformat/doc/GO.format.obo-1_4.html?utm_source=openai - : https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo ### 53. Tool result: web_search WEB SEARCH RESULTS Query: Relations Ontology RO has muscle origin has muscle insertion determined by definition In the **OBO Relations Ontology (RO)**, the distinction is determined primarily by **movement during muscle contraction**: - **has muscle origin — RO:0002372** `muscle m has muscle origin structure s` iff **m is attached to s and s does not move when m contracts**. The origin also tends to be the more proximal or larger attachment. - **has muscle insertion — RO:0002373** `muscle m has muscle insertion structure s` iff **m is attached to s and s moves when m contracts**. Insertions are commonly tendon-to-bone attachments. ([docs.biobox.io](https://docs.biobox.io/guide/data-packages/external-ontologies/tissue?utm_source=openai)) Formally: ```text has_muscle_origin(m, s) ↔ attached_to(m, s) ∧ does_not_move_during_contraction(s, m) has_muscle_insertion(m, s) ↔ attached_to(m, s) ∧ moves_during_contraction(s, m) ``` Therefore, in RO, **origin versus insertion is functionally determined by which attachment is relatively stationary and which moves**, rather than strictly by proximal versus distal position. Cited sources: - Tissue | Docs | BioBox Platform: https://docs.biobox.io/guide/data-packages/external-ontologies/tissue?utm_source=openai ### 54. Tool result: web_search WEB SEARCH RESULTS Query: OBO Relations Ontology GitHub ro.owl relation composition holds over chain In the OBO Relations Ontology, **`holds_over_chain`** represents relation composition—a property-chain axiom. ```obo [Typedef] id: R holds_over_chain: S T ``` means: ```text S(x, y) ∧ T(y, z) → R(x, z) ``` or: ```text S o T ⊑ R ``` The converse is **not** implied. ([oborel.github.io](https://oborel.github.io/obo-relations/property-chains/)) ### Example from RO ```obo [Typedef] id: RO:0002158 name: shares ancestor with holds_over_chain: RO:0002156 RO:0002157 ``` This states: ```text derived_by_descent_from(x, a) AND has_derived_by_descendant(a, z) → shares_ancestor_with(x, z) ``` The current `ro.obo` contains this declaration. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) In `ro.owl`, it is serialized as: ```xml ``` ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.owl)) Equivalent OWL functional syntax: ```owl SubObjectPropertyOf( ObjectPropertyChain(RO:0002156 RO:0002157) RO:0002158 ) ``` Thus, **the relation whose stanza contains `holds_over_chain` is the resulting/super-property**, while the listed relations form the ordered chain. Cited sources: - Property Chains - OBO Relation Ontology: https://oborel.github.io/obo-relations/property-chains/ - : https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo - : https://raw.githubusercontent.com/oborel/obo-relations/master/ro.owl ### 55. Assistant tool calls #### Tool call: `web_search` ```json { "query": "site:raw.githubusercontent.com/oborel/obo-relations/master/ro.obo \"determined by\" \"collapse\" RO" } ``` #### Tool call: `web_search` ```json { "query": "site:raw.githubusercontent.com/oborel/obo-relations/master/ro.obo \"has muscle antagonist\" spring damper" } ``` #### Tool call: `web_search` ```json { "query": "site:raw.githubusercontent.com/oborel/obo-relations/master/ro.obo \"in register with\" definition" } ``` #### Tool call: `web_search` ```json { "query": "OBO Relations Ontology \"has component\" similar type directly disassembled meaning" } ``` ### 56. Tool result: web_search WEB SEARCH RESULTS Query: site:raw.githubusercontent.com/oborel/obo-relations/master/ro.obo "determined by" "collapse" RO **RO:0002507 — “determined by”** > A system **s** is determined by a material entity **f** when **f** is part of **s**, strongly influences its functioning, and removing **f** would cause **s** to collapse. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) Key metadata: - **Domain:** `RO:0002577` — system - **Range:** `BFO:0000040` — material entity - **Inverse:** `RO:0002508` — determines - **Example:** A coral reef environment is determined by a particular coral reef. - **Note:** The label may be renamed because its meaning is restricted to systems. - **Release inspected:** `2025-12-17` ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) Cited sources: - : https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo ### 57. Tool result: web_search WEB SEARCH RESULTS Query: site:raw.githubusercontent.com/oborel/obo-relations/master/ro.obo "has muscle antagonist" spring damper In the current `ro.obo`: - **has muscle antagonist** — `RO:0002568` - Parent relation: **biomechanically related to** — `RO:0002567` - Neither **“spring”** nor **“damper”** occurs in the file. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) ```obo [Typedef] id: RO:0002568 name: has muscle antagonist is_a: RO:0002567 ! biomechanically related to ``` Note: the definition appears to contain a typo—`has_muscle_insection` likely means `has_muscle_insertion`. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) Cited sources: - : https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo ### 58. Tool result: web_search WEB SEARCH RESULTS Query: site:raw.githubusercontent.com/oborel/obo-relations/master/ro.obo "in register with" definition **“In register with” (RO:0002026):** A relationship between two 2D or 3D images that depict entities of the same type and are aligned within a shared coordinate framework, such that corresponding features coincide. Examples include aligned microscopy channels, image annotation layers, neuron tracings aligned to an EM stack, and separately acquired images aligned using registration software. ([raw.githubusercontent.com](https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo)) Cited sources: - : https://raw.githubusercontent.com/oborel/obo-relations/master/ro.obo ### 59. Tool result: web_search WEB SEARCH RESULTS Query: OBO Relations Ontology "has component" similar type directly disassembled meaning In the **OBO Relations Ontology**, **`has component` (RO:0002180)** means: > A whole **has component** a part when the whole can be divided at one structural level into that part and other **comparable or similar kinds of parts**. It is a more specific form of **`has part`**. ([dashboard.obofoundry.org](https://dashboard.obofoundry.org/dashboard/ro/robot_report.html?utm_source=openai)) ### Meaning of the wording - **“Directly disassembled”** means decomposed **one level down**, without passing through an intermediate whole. - **“Parts of similar type”** means the resulting parts have comparable structural or functional status—not necessarily that they belong to exactly the same ontology class. - It does **not necessarily mean physically dismantled**; it describes an immediate conceptual or structural decomposition. ### Example A bicycle can be directly decomposed into: - frame - wheels - handlebars - pedals Therefore: ```text bicycle has component wheel ``` But: ```text bicycle has component spoke ``` would normally be inappropriate because a spoke is reached through an intermediate component: ```text bicycle has component wheel wheel has component spoke ``` Nevertheless, the bicycle **has part** the spoke. ### Key distinction | Relation | Meaning | |---|---| | **has part** (`BFO:0000051`) | Any part, whether immediate or deeply nested | | **has component** (`RO:0002180`) | An immediate, same-decomposition-level constituent | | **has component process** (`RO:0002018`) | The corresponding relation specifically between processes | Thus, **every component is a part, but not every part is a direct component**. ([oborel.github.io](https://oborel.github.io/obo-relations/process-relations/?utm_source=openai)) Cited sources: - ROBOT Report - ro: https://dashboard.obofoundry.org/dashboard/ro/robot_report.html?utm_source=openai - Process relations - OBO Relation Ontology: https://oborel.github.io/obo-relations/process-relations/?utm_source=openai ### 60. Assistant tool calls #### Tool call: `write_note` ```json { "block_ids": [ "WRVKYL", "2HSCQG", "V5457K", "6BUB8K" ], "text": "The OBO Relations Ontology suggests a concrete implementation path for Moppe's anti-fantological vocabulary: represent universals and particulars explicitly, then expose a small curated set of relations carrying inverse, symmetry, transitivity, domain/range, and one-way property-chain laws. This closely matches Smith's enhanced Davidsonian list of formal ties (#WRVKYL) and the sextet connected by instantiation, inherence, participation, parthood, and realization (#2HSCQG). Caution: adopt an RO-inspired Moppe profile rather than reusing biomedical labels outside their licensed domains. In particular, coin mechanical subrelations for fixed/driven actuator attachments rather than `has muscle origin/insertion`; do not call spring and damper antagonists; distinguish contact-at-interface from `occurs across` a barrier; and treat a recipe file as concretizing recipe information while generation realizes the plan and outputs a world. Property chains derive propositions and are directional; they are not the same as numerical transform composition in forward kinematics. C++ concepts may combine freely, but only curated named universals should enter the ontology, preserving the separation of logical and ontological vocabulary emphasized in #V5457K and #6BUB8K.", "title": "RO as a law-governed relation vocabulary for Moppe" } ``` ### 61. Tool result: write_note NOTE SAVED #ZMR5CF IRI: https://m.sheaf.less.rest/ZMR5CF ### 62. Assistant This is genuinely valuable. It turns the discussion from “perhaps CPOs could name some semantic operations” into a much more concrete proposal: > A relation is a named formal tie together with laws governing what may be inferred from it. That is almost exactly Smith’s enhanced Davidsonian proposal: a small vocabulary of `Part`, `Instantiates`, `InheresIn`, `DependsOn`, `Precedes`, `HasParticipant`, and `Realizes` connecting explicitly represented universals and particulars (#WRVKYL, #2HSCQG). ## The property chains are the major discovery A relation declaration could carry metadata like: ```cpp template <> struct relation_traits { using inverse = has_part_t; static constexpr bool transitive = true; static constexpr bool symmetric = false; using domain = continuant; using range = continuant; }; ``` And composition laws: ```cpp relation_chain< has_participant_t, part_of_t, has_participant_t >; ``` meaning, directionally: ```text has_participant(process, wheel) part_of(wheel, motorcycle) ─────────────────────────── has_participant(process, motorcycle) ``` The essential detail is that `holds_over_chain` is a **one-way implication**: $$ R_1(x,y)\land R_2(y,z)\implies R(x,z). $$ It does not assert equality between $R$ and the composition, and ordering matters. That makes relation chains suitable for controlled inference rather than arbitrary graph traversal. ## This gives CPOs a precise role The CPO would name the formal tie: ```cpp part_of (wheel, motorcycle); inheres_in (compression, spring); has_participant (rolling, rear_wheel); realizes (compression_process, elastic_disposition); ``` The relation traits would state its algebra. Concrete world representations would customize how the facts are retrieved, but not what the relation means. That last constraint is crucial: ```text different representation → permitted different meaning → not permitted ``` A `part_of` customization for a motorcycle cannot mean C++ ownership while `part_of` for a tree means material parthood. The shared name earns its place only if it preserves one semantic contract. ## `has component` is an especially good distinction The current RO definition makes `has component` narrower than transitive parthood: it identifies an immediate level of structural decomposition. It is deliberately **not transitive**. So: ```text motorcycle has_component wheel wheel has_component spoke motorcycle has_part spoke ``` but not necessarily: ```text motorcycle has_component spoke ``` This is exactly what a mechanical assembly needs. It separates: - transitive material parthood; - immediate engineering decomposition; - collection membership; - mechanical connection. The motorcycle could therefore have several overlapping structures: ```text partonomy transitive material parthood assembly decomposition immediate has-component relations mechanism complex bodies connected through joints functional hierarchy lower functions enabling higher functions ``` These are not competing hierarchies. They answer different questions. ## The mediated account of connection fits the mechanism complex The `connects` relation is stronger than treating a joint as an abstract edge: ```text steering joint connects chassis and fork ``` From that, the bodies are derivatively `connected_to` one another. This matches the engineering ontology nicely: ```cpp connects (steering_head, chassis, fork); connected_to (chassis, fork); // derived ``` The joint is a material connecting structure with its own qualities, functions, and spatial embedding. The mechanism’s 1-cell is therefore not merely a bare binary relation: it can name a particular joint that mediates the relation. That provides a bridge between the two interpretations discussed earlier: - a joint is a **material particular** in the partonomy; - the same joint serves as a **connecting 1-cell** in the mechanism complex. ## Some biomedical relations should inspire, not be imported literally A few extensions in the pasted analysis go beyond what RO itself licenses. ### Skeleton `has skeleton` is defined for anatomical subdivisions. The chassis analogy is excellent, but Moppe should probably define: ```text has load-bearing structure load-bearing structure of ``` as project relations inspired by `has skeleton`, rather than asserting that a motorcycle literally has a biological skeleton. ### Muscle origin and insertion The fixed-versus-driven distinction is useful, but mechanical names would be clearer: ```text actuator has fixed attachment actuator has driven attachment ``` These could be subrelations of `attached_to`. Calling a shock mount a muscle origin would import biological domain assumptions unnecessarily. Also, a spring and damper are not really antagonists: the spring stores and returns energy, while the damper dissipates it. They usually cooperate in controlling the same degree of freedom. Brake and throttle produce opposed effects, but even there “antagonist” may be less precise than a project-specific control relation. ### Contact `occurs across` is intended for processes spanning a barrier, such as transport across a membrane. Tire contact is more safely represented as: ```text rolling occurs_at contact interface rolling has_participant tire rolling has_participant supporting surface contact interface boundary_of tire/terrain regions ``` A tire and terrain also have distinct but coincident boundaries at contact; they do not necessarily literally share one identical boundary. Smith’s mereotopological distinction matters here. ### Registration `in register with` is defined for aligned images. Surface-atlas columns are not all images or depictions, so Moppe could adopt a wider relation: ```text registered_with ``` with an explicit domain of fields, sections, images, and representations sharing one coordinate framework. The RO term supplies the pattern, while Moppe supplies the truthful scope. ## The recipe/concretization point needs one correction In BFO/RO terms, `concretizes` connects a generically dependent information entity to a concrete bearer. Thus: ```text recipe information concretized in → recipe file or in-memory value ``` The generation process then **realizes or executes the plan**, and the generated world is its output: ```text generation process realizes → generative plan has input → seed and recipe has output → generated world ``` The world itself does not straightforwardly “concretize” the recipe. It is produced according to it. A mesh or file may carry information representing the world, but that is another relation again. ## Logical inference is not numerical composition There is an important analogy—but also a boundary—between RO chains and forward kinematics. RO inference: ```text wheel part_of bike wheel participates_in rolling → bike participates_in rolling ``` Kinematic composition: $$ T_{\text{world}\leftarrow\text{wheel}} = T_{\text{world}\leftarrow\text{chassis}} T_{\text{chassis}\leftarrow\text{fork}} T_{\text{fork}\leftarrow\text{wheel}}. $$ Both follow paths through structured relations, but they produce different things: - a property chain derives another proposition; - forward kinematics computes a transformation. The relation library could organize both, but it should not confuse logical closure with numerical evaluation. ## A practical Moppe relation profile Rather than importing all 704 relations, I would define a curated profile: ```text Identity and classification instantiates is_a Partonomy part_of / has_part component_of / has_component member_of / has_member overlaps Dependence inheres_in / has_quality has_disposition has_function has_role has_basis depends_on Mechanism connects connected_to attached_to has_fixed_attachment has_driven_attachment supports transmits_force_to Space and contact occupies located_in adjacent_to boundary_of immersed_in registered_with Processes has_participant has_agent realizes has_input / has_output has_component_process precedes causally_upstream_of Hydrology tributary_of distributary_of anabranch_of main_stem_of drains ``` Each relation would declare only the laws Moppe actually relies upon: ```text inverse symmetry/asymmetry transitivity domain and range property chains possibly irreflexivity ``` This is also where tests become powerful. A relation is not complete merely when its name compiles; its algebra should be executable and tested. ## The anti-fantological payoff This avoids both extremes: - not a spreadsheet where every fact is `has`; - not an unrestricted RDF soup where every relation is merely a labeled edge. Instead: ```text named universals and particulars + small, typed relation vocabulary + declared algebra and composition laws + concrete domain representations ``` That preserves Smith’s separation between logical expressions and real universals: C++ predicates may be composed freely, but the ontology admits only investigated, deliberately named universals and relations (#V5457K, #6BUB8K). I persisted the main design conclusion and cautions as research note #ZMR5CF.