Building a No-Spacetime Physics Engine: Tired Light, Entropic Gravity, and the ArcSecs Relational Universe

What would a physics engine look like if it refused to treat spacetime as a physical fabric? The ArcSecs no-spacetime engine begins with that question and turns it into a simulation architecture. Instead of expanding coordinate space, curving a four-dimensional manifold, or inserting invisible dark matter halos by default, it models the universe as a relational system: matter nodes, informational states, light packets, coupling parameters, and observable measurements.

This is not established cosmology. It is a speculative simulation framework. Its purpose is to explore whether redshift, galaxy rotation curves, dark-matter-like effects, photon propagation, and cosmic-scale structure can be modeled without reifying spacetime as a physical substance.

The result is a hybrid engine concept that combines teleparallel-style flat coordinates, entropic gravity, tired-light energy attenuation, covarying coupling constants, Proca-like massive photon behavior, MOND-style interpolation, rotation curve fitting, plasma interaction models, EIT slow-light subroutines, and real-time web diagnostics.

“`

The Core Claim: Stop Simulating a Fabric

“`

Most cosmological simulations begin by accepting a background geometric structure. In the standard general-relativistic picture, gravity is encoded in the curvature of a four-dimensional pseudo-Riemannian manifold. Matter tells spacetime how to curve, and spacetime tells matter how to move.

The ArcSecs engine intentionally starts somewhere else. It asks whether the simulation can preserve observational behavior while removing the idea that spacetime is a physical container. In this model, “space” is not a stretchy substance. “Time” is not a universal fluid. Both are treated as emergent bookkeeping structures reconstructed from relations among physical states.

That changes the software design. Instead of building a metric-first universe, the engine builds a relation-first universe.

No physical spacetime fabric: coordinates are computational tools, not ontological objects.
No mandatory metric expansion: redshift can be simulated through photon energy loss and evolving coupling constants.
No default dark matter halo insertion: rotation curves can be explored through relational coupling, MOND-style behavior, and frame-mapping models.
No hidden magic layer: every observable effect must be represented as an explicit solver, state transition, field interaction, or diagnostic output.

“`

Ontological Relationalism: Space as a Web of Relations

“`

The engine’s philosophical foundation is relationalism. In a relational model, space is not a thing that exists independently of matter. It is a pattern of distances, directions, measurements, and interactions among physical systems. Remove every physical object and field, and there is no remaining “place” for empty space to occupy.

This view has a long history, often associated with Leibnizian relationalism. In the ArcSecs implementation, that idea becomes a software constraint: a simulated world state is not primarily a set of objects placed into a pre-existing arena. It is a graph of relations among nodes.

A galaxy is not merely an object in space. It is a structured relationship among baryonic mass nodes, light packets, field states, angular observations, density gradients, and observer-frame mappings. A distance is not an absolute background length. It is a derived relation between simulated states.

This allows the engine to explore a cosmology where observables such as redshift, proper motion, parallax, gravitational attraction, and rotation curves are calculated without making coordinate spacetime the ultimate physical object.

“`

Point-Coincidences and the Hole Argument

“`

One motivation for rejecting physical coordinate spacetime is the hole argument associated with general relativity. If manifold points had independent physical identity, then shifting the coordinate mapping inside an empty region could produce mathematically different descriptions that satisfy the same equations. That creates a problem: the same physical universe could appear under multiple coordinate assignments with no observable difference.

The relational answer is to treat point-coincidences as physically meaningful, not bare manifold points. A point-coincidence is an event-like intersection of physical fields, worldlines, or measurable states. The coordinates are labels. The coincidence is the physical content.

For the engine, this means the simulation does not need to preserve the metaphysical reality of empty coordinate locations. It only needs to preserve the relational structure of events, fields, nodes, and measurements.

In the ArcSecs model, coordinates are not the universe. They are a debugging interface for the universe.

“`

Flat Weitzenböck Coordinates and Teleparallel Gravity

“`

Removing curved spacetime from the ontology does not mean removing gravity from the simulation. One practical route is a teleparallel-style representation. In the Teleparallel Equivalent of General Relativity, gravitational effects can be expressed through torsion rather than curvature. The connection is flat in the Riemannian curvature sense, but it carries non-zero torsion.

In ordinary general relativity, the Levi-Civita connection is torsion-free and curvature carries the gravitational information. In a teleparallel framing, the Weitzenböck connection has vanishing curvature but non-vanishing torsion. That allows the engine to keep high-performance flat-coordinate vector math while still modeling gravitational behavior through a translational gauge-force style mechanism.

Domain	Standard Metric Simulation	ArcSecs Relational Engine
Space and time	Continuous curved manifold	Emergent relation network
Gravity carrier	Metric curvature	Torsion / relational force / informational gradient
Coordinate status	Part of the geometric model	Computational labels over relational states
Numerical burden	Heavy differential geometry and constraint maintenance	Flat vector math plus explicit solver modules
Failure mode	Coordinate singularities and constraint drift	Solver instability, state divergence, or bad coupling rules

This is useful for a web physics demo because it avoids the cost and fragility of trying to render a full curved-manifold simulation. The engine can remain interactive while still demonstrating gravity-like behavior, field effects, and galaxy-scale relations.

“`

The Discrete Informational Lattice

“`

The next architectural layer is the discrete informational lattice. Rather than treating physical systems as values on a smooth continuum, the engine represents them as stateful nodes with local algebraic update rules.

This has several advantages:

Bounded computation: the engine can update finite relational states instead of solving unbounded continuous fields everywhere.
Deterministic replay: the same serialized state can be loaded, mutated, and tested repeatedly.
Debuggable dynamics: node transitions, contacts, forces, and field changes can be visualized directly.
Singularity resistance: the engine does not need to assign physical meaning to infinitely small coordinate regions.

The lattice is not necessarily a claim that the real universe is a simple grid. It is a computational strategy: replace the impossible task of simulating every point in a continuum with a structured, inspectable network of physical relations.

“`

Rigid-Body Solver Mechanics: Making Cosmology Interactive

“`

A speculative cosmology engine can become too abstract very quickly. To keep the system testable and visually useful, ArcSecs integrates a conventional rigid-body physics layer. The demo can include crates, platforms, test meshes, collisions, springs, constraints, friction, restitution, angular motion, and serialized scenes.

This matters because it gives users an intuitive bridge from everyday physics to cosmological speculation. A user can see a box bounce, slide, collide, or rotate before seeing the same solver architecture extended into relational gravity, photon packets, or galaxy rotation models.

Contact Resolution

At the narrowphase collision level, the engine detects overlaps between rigid bodies and calculates a collision normal, penetration depth, and contact point. It then applies impulses based on restitution and friction.

Restitution controls bounciness. Friction controls tangential resistance. Low-friction surfaces can simulate ice-like behavior, while high-friction surfaces stabilize stacking and sliding.

Constraints and Springs

More complex mechanisms require constraints. The engine uses constraint equations, joint relationships, and spring-mass-damper structures to model connected systems. If springs are too stiff relative to the simulation step rate, numerical instability appears. This is why the engine must expose solver frequency, damping, stiffness, and integration settings clearly.

For structural assemblies, triangulated geometry is preferred because it distributes stress and avoids unstable high-frequency springs. That design principle becomes important later when simulating large-scale relational structures, field lattices, and spacecraft-like assemblies.

Scene Serialization

The engine uses a JSON scene-graph approach so simulations can be saved, shared, replayed, and tested. Every rigid body, mass value, friction coefficient, restitution parameter, spring, constraint, and velocity vector can become part of a deterministic test scene.

This makes the engine more than an animation. It becomes an experimental sandbox.

“`

Entropic Gravity and Beta-Matter

“`

If spacetime curvature is removed from the physical model, gravity must be rebuilt another way. One candidate is entropic gravity. In this view, gravitational attraction is not fundamental curvature but an emergent force related to information, entropy, and holographic boundary behavior.

The engine can represent gravitational attraction as an informational gradient between baryonic mass nodes. A central mass, an enclosing screen, and the information associated with that screen provide the basis for an acceleration relation. The exact implementation can be changed, but the architectural goal remains the same: gravity is calculated from relational information, not from a curved coordinate fabric.

The uploaded engine model also introduces a localized coupling parameter that behaves like a dark-matter substitute. In dense regions, gravity behaves normally. In low-acceleration or low-density regions, the effective coupling strengthens. This creates a phantom mass effect without adding non-baryonic dark matter particles.

This “beta-matter” or relational coupling effect is not treated as actual invisible matter. It is a behavior of the solver. The visible baryonic distribution remains the source, but the local response changes depending on acceleration, density, and relational context.

“`

Rotation Curves Without Particle Dark Matter

“`

Spiral galaxy rotation curves are one of the strongest motivations for dark matter. In a simple Newtonian model using only visible matter, stars far from the galactic center should orbit more slowly. Instead, observed rotation curves often remain flat.

The ArcSecs engine explores several ways to reproduce those flat curves without inserting a cold dark matter halo.

MOND-Style Low-Acceleration Behavior

One route is MOND-like interpolation. In high-acceleration regimes, the solver returns ordinary Newtonian behavior. In low-acceleration regimes, the effective relationship changes so that orbital velocity becomes approximately independent of radius. This reproduces the broad shape of flat rotation curves and connects naturally to the Baryonic Tully-Fisher relation.

Relational Coupling

A second route is local coupling variation. The engine calculates a baryonic mass distribution and then allows the gravitational coupling response to vary depending on local density and acceleration thresholds. The result is a dark-matter-like gravitational profile generated from visible matter plus relational rules.

Rotation Curve Fitting Model

A third route is the Rotation Curve Fitting Model. Instead of treating observed velocities as simple Galilean differences, the model examines relativistic frame effects between emitter and receiver. This reframes the velocity curve as a mapping problem between observational frames.

Rotation Curve Approach	Invisible Particle Halo?	Main Mechanism	Engine Role
Standard dark matter halo	Yes	Additional non-baryonic mass	Baseline comparison model
MOND-style solver	No	Low-acceleration modification	Alternative force law module
Relational beta-matter	No	Density-dependent coupling variation	Local emergent gravity module
RCFM	No	Emitter-receiver frame mapping	Observation and velocity interpretation module

The important point is not that one of these alternatives is declared correct. The important point is that the engine can compare them. A good speculative simulator should let models compete.

“`

Modernized Tired Light and CCC+TL

“`

Tired light is the idea that photons lose energy as they travel cosmic distances. Historically, simple tired-light models were rejected because they created serious observational problems: image blurring, wavelength-dependent dispersion, and conflict with surface brightness tests.

The ArcSecs engine does not merely reuse classical tired light. It explores a modernized hybrid: Covarying Coupling Constants plus Tired Light, or CCC+TL.

In this framework, redshift is not caused by metric expansion alone. Instead, observed redshift can be split between photon energy attenuation and the covarying evolution of physical constants. The engine can vary quantities such as the speed of light, gravitational coupling, Planck-scale terms, and charge-related constants in a coordinated way while preserving dimensionless ratios such as the fine-structure constant.

That last constraint matters. If dimensionless ratios drift wildly, chemistry and atomic spectra break. A viable simulation cannot simply change constants independently. It has to maintain internal physical consistency.

What the CCC+TL Module Must Track

Photon packet energy: how much energy a light packet loses over relational distance.
Emission epoch: what the source conditions were when the photon was emitted.
Covarying constants: how major physical constants evolve together.
Dimensionless invariants: ratios that must remain stable for recognizable physics.
Observed redshift: the final combined result of propagation and source-state evolution.

This is where the engine becomes especially useful. It can expose sliders and diagnostic plots for each contribution, making it clear how much of a simulated redshift comes from energy attenuation, how much comes from changing atomic emission states, and how much would normally be assigned to expansion.

“`

Proca Photons, Dispersion, and Lensing

“`

The engine also explores Proca-like photon behavior. In standard Maxwellian electromagnetism, photons are massless. In Proca electrodynamics, the electromagnetic field is modeled with a massive vector term. This changes propagation, dispersion, and long-range field behavior.

In a no-spacetime simulation, Proca-like behavior is useful because it lets the engine model light as a physical particle-wave system that can experience energy-dependent propagation effects. This becomes relevant for tired light, photon packet stretching, low-energy electromagnetic residue, and gravitational lensing alternatives.

Standard gravitational lensing is usually explained by light following null geodesics through curved spacetime. A flat relational engine cannot rely on that explanation. Instead, it can model deflection as a physical interaction: massive or effectively massive photon-like packets scatter through gravitational or field gradients.

At high photon energies, the correction can be small enough to approximate standard observed deflection. At lower energies, dispersion becomes more important. The engine can then compare predicted deflection against radio, optical, and high-energy observations.

“`

Plasma, EIT, and Slow-Light Subroutines

“`

A realistic intergalactic simulation cannot treat photons as traveling through perfect emptiness. The universe contains plasma, magnetic fields, radiation backgrounds, gas, dust, and local density structures. The ArcSecs engine therefore includes propagation subroutines for medium interactions.

Compton Scattering

A microscopic Compton scattering module can simulate photon-electron interactions in plasma. When a photon scatters from a free electron, it can transfer kinetic energy and shift wavelength. Over cosmic scales, even small effects can accumulate.

Electromagnetically Induced Transparency

The EIT subroutine explores slow-light behavior. Electromagnetically induced transparency is a real quantum optical effect in which a medium can become transparent to a probe field under the right control-field conditions. It can also produce dramatic group-velocity reduction.

In the engine, EIT-inspired behavior is used as a speculative module for mapping electromagnetic wave packets into dark-state polariton-like states. This is important for the broader ArcSecs concept because it provides a computational bridge between active light, slowed light, stored light, and cold tired-light substrate.

This same logic connects directly to the Dark Matter Drive schematic: if tired light can be slowed, trapped, stored, or compressed in the simulation, then the spacecraft architecture can be modeled as a macroscopic field system that captures and re-energizes that substrate.

“`

Relational Space Travel and Drag Laws in a Static Medium

“`

In an expanding-space picture, cosmological motion is often described through metric recession and coordinate expansion. In the ArcSecs static-medium picture, physical travel means moving through a real background of matter, radiation, plasma, and tired-light residue.

That makes drag unavoidable.

The engine models at least two major drag channels:

Baryonic drag: direct collision with gas, plasma, dust, and other matter in the intergalactic medium. This typically scales with density, cross-sectional area, and the square of velocity.
Radiative drag: interaction with ambient radiation fields such as the cosmic microwave background, starlight, and tired-light substrate. This becomes especially significant at high relative speeds or in coherent scattering regimes.

This is one of the most important consequences of rejecting empty spacetime as a free highway. The medium matters. A ship traveling through a static universe is not riding a coordinate wave. It is colliding with an environment.

That is why the Dark Matter Drive concept needs a forward shield, a projected scoop, a drag-decoupling intake, a compression system, and heat rejection. The physics engine gives those visual features a simulation reason to exist.

“`

Web UI and Real-Time Diagnostics

“`

The engine should not hide its physics. It should show the user what is happening. The uploaded architecture emphasizes real-time overlays that make abstract mechanics visible.

Useful Diagnostic Layers

Broadphase overlays: show bounding boxes, spatial grids, and collision-pruning structures.
Narrowphase contact geometry: show contact points, normals, penetration depth, and reflection vectors.
Force propagation maps: show linear velocity, angular velocity, torque, and connected mechanical islands.
Photon path overlays: show tired-light attenuation, frequency shift, and packet dispersion.
Gravity field overlays: show baryonic gravity, beta-matter coupling, MOND transition regions, and predicted rotation curves.
Observer-frame overlays: compare raw coordinate values with what a simulated observer would actually measure.
Error diagnostics: show integration drift, constraint violation, energy leakage, and solver instability.

These overlays turn the engine into an educational instrument. Instead of saying “gravity changed,” the demo can show where, why, and how the effective coupling changed. Instead of saying “light redshifted,” the demo can show the packet losing energy step by step along a relational path.

“`

Implementation Roadmap

“`

A strong implementation should avoid mixing every feature into one unstable prototype. The engine should be built in disciplined layers.

Phase 1: Flat Coordinate Physics Core

Implement deterministic vector math.
Build rigid-body state objects.
Add collision detection, restitution, friction, and constraints.
Expose debug overlays for broadphase and narrowphase physics.

Phase 2: JSON Scene-Graph and Test Harness

Create a scene serializer and loader.
Allow repeatable simulation states.
Add automated regression tests for collisions, constraints, friction, and conservation behavior.
Build demo scenes such as sliding crates, spring assemblies, rotating mechanisms, and gravity nodes.

Phase 3: Relational Gravity Solver

Add baryonic mass-node gravity.
Add MOND-style interpolation.
Add local beta-matter coupling.
Visualize acceleration thresholds and coupling changes.
Compare standard Newtonian, dark matter halo, MOND-style, and relational coupling outputs.

Phase 4: Tired-Light and CCC+TL Pipeline

Represent photon packets as simulation entities.
Track emitted frequency, observed frequency, travel distance, and energy attenuation.
Add covarying coupling constants.
Preserve dimensionless ratios.
Render redshift contributions as separate diagnostic bands.

Phase 5: Proca and Medium Interaction Modules

Add effective photon mass parameters.
Model vacuum dispersion.
Add Compton scattering subroutines.
Add EIT-inspired slow-light and polariton-like storage states.
Compare lensing predictions against baseline metric expectations.

Phase 6: Space Travel and Dark Matter Drive Demonstrator

Add static-medium drag laws.
Add baryonic and radiative drag diagnostics.
Model forward shielding, scoop capture, intake compression, and exhaust conversion.
Use the Dark Matter Drive schematic as a high-level system architecture target.

“`

Scientific Caution: A Simulation Is Not a Discovery

“`

This framework is speculative. It is not a replacement for established cosmology, and it should not be presented as proven physics. General relativity and the ΛCDM cosmological model remain the mainstream frameworks because they explain a large range of observations with remarkable precision.

Tired light models have historically faced serious objections. MOND and emergent gravity approaches are debated. Photon mass is tightly constrained. Teleparallel representations can be equivalent to general relativity in some contexts, but that does not automatically prove a no-spacetime ontology. EIT is real in laboratory quantum optics, but macroscopic cosmic-scale slow-light engineering is speculative.

The value of the ArcSecs engine is not that it declares the standard model false. The value is that it creates a testable sandbox for radical alternatives. It forces each idea to become code, state, equations, diagnostics, and outputs.

The right standard for speculative physics software is not belief. It is visibility, falsifiability, repeatability, and comparison.

“`

Suggested Image Caption and Alt Text

“`

Caption: Conceptual architecture of the ArcSecs no-spacetime physics engine. The system replaces physical spacetime with relational nodes, flat teleparallel coordinates, entropic gravity, tired-light photon attenuation, Proca dispersion, EIT slow-light behavior, and real-time diagnostic overlays.

Alt text: Detailed technical diagram of a speculative no-spacetime physics engine showing relational lattice nodes, teleparallel gravity, tired-light photon decay, MOND-style galaxy rotation curves, Proca photon dispersion, EIT slow-light storage, drag laws, and web diagnostics.

“`

References and Further Reading

“`

The following links include mainstream physics background, speculative alternatives, critical sources, and implementation-adjacent resources. Inclusion does not imply endorsement; several of these sources disagree with one another.

“`