Python relativity game in python

AI Thread Summary
The discussion revolves around a Pygame implementation that simulates light emission from a moving object towards a detector, with a focus on visualizing light behavior at finite speeds. While the code effectively creates an animation of light pulses and their fading intensity, it is critiqued for overstating its connection to special relativity. The main argument is that the simulation does not accurately reflect relativistic principles, as it simplifies the scenario to a constant velocity without accounting for effects like time dilation or length contraction, which are essential in relativity. The conversation also touches upon historical misconceptions regarding the speed of light, clarifying that it was known to be finite before Einstein's theory. The invariant nature of light speed across different inertial frames is highlighted as a key distinction from classical physics. Overall, the discussion emphasizes the limitations of the simulation in representing true relativistic effects.
blackholesarecool
Messages
14
Reaction score
2
TL;DR Summary
i simulated relativity, specifically special relativity, in python
[CODE lang="python" title="relativity simulator"]import pygame

# Initialize Pygame
pygame.init()

# Get the screen resolution
info = pygame.display.Info()
WIDTH, HEIGHT = info.current_w, info.current_h # Set to the current screen size

# Constants
WHITE = (255, 255, 255)
LIGHT_COLOR = (255, 255, 100)
OBJECT_COLOR = (100, 255, 100)
DETECTOR_COLOR = (255, 100, 100)
GLOW_COLOR = (255, 200, 100)
LIGHT_SPEED = 1 # Light speed
OBJECT_SPEED = 2
FADE_DURATION = 20 # Duration in terms of frames for light to fully fade away

# Setup screen with the maximum resolution
screen = pygame.display.set_mode((WIDTH, HEIGHT), pygame.RESIZABLE) # Allow resizing
clock = pygame.time.Clock()

# Object properties
object_x = 0
object_y = 100

# Detector properties (single point)
detector_x = WIDTH // 2
detector_y = HEIGHT - 50

# Light list (stores [x, y, angle, emitted_time, intensity, emitted_x, emitted_y])
lights = []
glows = [] # Stores glow positions and intensity

running = True
while running:
screen.fill((0, 0, 0))

# Event handling
for event in pygame.event.get():
if event.type == pygame.QUIT:
running = False
elif event.type == pygame.VIDEORESIZE:
WIDTH, HEIGHT = event.w, event.h # Update width & height on resize
detector_x = WIDTH // 2
detector_y = HEIGHT - 50 # Keep detector at bottom

# Move object (does NOT wrap around)
object_x += OBJECT_SPEED # Moves infinitely off-screen if not resized

# Emit light aimed at the detector
dx = detector_x - object_x
dy = detector_y - object_y
angle = pygame.math.Vector2(dx, dy).normalize() # Normalize direction
lights.append([object_x, object_y, angle, 0, 255, object_x, object_y]) # Store emitted position (object position when light emitted)

# Move lights
for light in lights[:]: # Iterate over a copy of the list to avoid modifying while looping
# Update position
light[0] += light[2].x * LIGHT_SPEED
light[1] += light[2].y * LIGHT_SPEED

# Increase emitted_time to track how many frames the light has existed
light[3] += 0.02

# Calculate intensity based on how long the light has been traveling
light[4] = max(0, 255 - int((light[3] / FADE_DURATION) * 255)) # Fade intensity over time

# Check if the light is below the detector and add glow
if light[1] >= detector_y: # Light has passed or reached below the detector
glows.append([light[5], light[6], light[4]]) # Store the emitted position as the glow's position
lights.remove(light) # Remove the light after it passes the detector

# Draw object (if visible on screen)
if 0 <= object_x <= WIDTH:
pygame.draw.circle(screen, OBJECT_COLOR, (int(object_x), int(object_y)), 10)

# Draw lights (if visible on screen)
for light in lights:
if 0 <= light[0] <= WIDTH and 0 <= light[1] <= HEIGHT:
# Apply fading effect by modifying color intensity
faded_color = (
max(0, LIGHT_COLOR[0] * light[4] // 255),
max(0, LIGHT_COLOR[1] * light[4] // 255),
max(0, LIGHT_COLOR[2] * light[4] // 255),
)
pygame.draw.circle(screen, faded_color, (int(light[0]), int(light[1])), 5)

# Draw detector (single point)
pygame.draw.circle(screen, DETECTOR_COLOR, (detector_x, detector_y), 5)

# Draw glows (lasts only one frame) with intensity
for glow in glows:
glow_x, glow_y, intensity = glow
# Use intensity to modify the brightness of the glow
faded_glow_color = (
max(0, GLOW_COLOR[0] * intensity // 255),
max(0, GLOW_COLOR[1] * intensity // 255),
max(0, GLOW_COLOR[2] * intensity // 255),
)
pygame.draw.circle(screen, faded_glow_color, (int(glow_x), int(glow_y)), 10)
glows.clear() # Remove glows after one frame

pygame.display.flip()
clock.tick(60)

pygame.quit()

[/CODE]
 
Technology news on Phys.org
I would say that "simulating special relativity" is probably exaggerated. What you've produced is an animation of the spatial plane of one frame for a scenario where a single object moves at constant velocity, emitting light pulses towards a target. The only thing particular to relativity is the source-independence of the speed of light, and even that is also consistent with ether models and not unique to relativity.

Can you spot the major flaw in your code?
It has to do with LIGHT_SPEED=1
 
i slowed down light so i can see relativistic effects better, specifically what something looks like if light has a finite speed, which it does, and also works for faster than light objects
 
blackholesarecool said:
faster than light objects
...which makes it inconsistent with relativity.
 
blackholesarecool said:
i slowed down light so i can see relativistic effects better, specifically what something looks like if light has a finite speed, which it does, and also works for faster than light objects
The speed of light was known to be finite before the theory of relativity. The earliest measurement was by Romer in 1676. There is a common misconception that Newton thought the speed of light was infinite. Newton was aware of Romer's estimate.

https://en.wikipedia.org/wiki/Rømer's_determination_of_the_speed_of_light

If you analyse a scenario in one inertial frame of reference, then there is nothing kinematically different between classical physics and relativity. If, however, your scenario involves moving clocks and extended objects, then the relativistic theory would show time dilation, length contraction and the relativity of simultaneity. For moving point particles, you have none of these things.

It's only when you transform the kinematic view to a different inertial reference frame that the differences between classical physics and relativity become apparent. The key difference is that the speed of light is invariant. This means that a beam of light has the same speed in both frames. Something that is impossible in classical physics.

You could check out Eugene Khutoryansky's videos:

 
  • Like
  • Informative
Likes Greg Bernhardt, jack action and Ibix
Dear Peeps I have posted a few questions about programing on this sectio of the PF forum. I want to ask you veterans how you folks learn program in assembly and about computer architecture for the x86 family. In addition to finish learning C, I am also reading the book From bits to Gates to C and Beyond. In the book, it uses the mini LC3 assembly language. I also have books on assembly programming and computer architecture. The few famous ones i have are Computer Organization and...
I had a Microsoft Technical interview this past Friday, the question I was asked was this : How do you find the middle value for a dataset that is too big to fit in RAM? I was not able to figure this out during the interview, but I have been look in this all weekend and I read something online that said it can be done at O(N) using something called the counting sort histogram algorithm ( I did not learn that in my advanced data structures and algorithms class). I have watched some youtube...

Similar threads

Replies
5
Views
2K
Replies
1
Views
4K
Replies
2
Views
3K
Replies
11
Views
2K
Replies
152
Views
9K
Replies
1
Views
2K
Back
Top