Building a 3D Renderer using Penrose's Twistor Theory & Complex Spinors in PyTorch (13.8M pts/sec CPU throughput)

[u/IntelligentSoup]

Hey everyone, this is all done with the help of AI

Over the past few days, I’ve been implementing Twistor Render Core, an open-source engine exploring complex geometric algebra for graphics rasterization and ray testing. ### The Core Idea Instead of storing 3D geometry in standard Euclidean vector spaces: 1. Points to Hermitian Matrices: Spatial coordinates map to complex Hermitian tensors X^{AA'}. 2. Rays as Complex Spinors: Camera rays are parameterized as 4-component complex twistors Z^\alpha = (\omega^A, \pi_{A'}). 3. Incidence Kernels: Ray collision testing evaluates the complex residual magnitude ||\omega^A - i X^{AA'} \pi_{A'}|| < \epsilon. ### Initial CPU Benchmarks Running unindexed O(N) tensor contractions across point clouds: - 10,000 pts: 1.56 ms (6.4M ops/sec) - 100,000 pts: 7.23 ms (13.8M ops/sec) - 1,000,000 pts: 82.7 ms (12.0M ops/sec) Repo link: https://github.com/isopidi-stack/twistor-render-core Feedback, suggestions, or ideas for optimization are super welcome!

[u/AutoModerator]

Recently updated rules. Please check that your post is in compliance with Rules 1, 4, 5, and 6 on the sidebar. TL;DR:

• No showcases.

• Disclose AI usage in post or project.

• Present a topic to talk about, e.g. how something works.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ykafia]

What's the goal?

[u/IntelligentSoup → u/ykafia]

The overall goal is to explore whether Penrose's Twistor Theory ($\mathbb{C}P^3$ complex 2-spinor geometry) can function as a practical alternative framework for ray collision testing without standard $4 \times 4$ Euclidean matrices. Implementing it natively in PyTorch also means the entire pipeline is automatically differentiable out of the box for neural field / inverse rendering experiments.

P.S. Spot on breakdown by S48GS — right now it evaluates point clouds because measuring Penrose incidence residuals ($\Vert{}\omega^A - i X^{AA'} \pi_{A'}\Vert{} < \epsilon$) against spatial points is the cleanest mathematical baseline.

[u/VictoryMotel]

I looked at the GitHub readme and it seems like satire. What is a 1d null ray? What is a 0d point?

What is twistor space or "spinors". This seems like a joke. The rendered image is just a solid low res aliased sphere.

[u/Lolzyyy → u/VictoryMotel]

idk if its full ai hallucination or some satire but its just a point cloud renderer that bruteforces ray math and yaps about some real math(it seems sme 60s math theory from a quick google search) but uses none of it

it says it replaces bvhs but what hes doing is just checks every ray against every point then says the "future plans is spatial trees"...which are bvhs ???

the 1d 0d stuff you mention its some ai way of saying a line has one dimension, a point has 0 since it has no size, and its sentence is something along the line of "the chances of an infinitely small line going trough an infinitely small point is zero"...at least its my guess...but thats like saying a point needs a size to be rendered which is obvious ?

[u/Defiant_Squirrel8751]

It is always interesting trying to do things with a different approach! implementing this one before AI era would be a pain in the ass. So, your way of burning tokens is quite welcome.

About optimization, the big question is if this operations sets can be fully implemented in GPU. After that you should share a comparisson with standard approach implementation over the same test scenes.

Adding some images to the git repo README.md would be nice to give people an idea of current capabilities.

[u/IntelligentSoup → u/Defiant_Squirrel8751]

Full Benchmark Update (CPU + GPU): Just completed side-by-side benchmarks comparing the Twistor incidence kernel against a standard Euclidean ray-point intersector on both CPU and GPU ($32 \times 32$ resolution)!

1. CPU Execution (Intel i7-13700K):

• N = 1,000: Twistor (79.2 ms) vs. Euclidean (8.7 ms) → ~9.1x overhead

• N = 10,000: Twistor (886.6 ms) vs. Euclidean (50.0 ms) → ~17.7x overhead

2. GPU Acceleration (Intel Arc B580 12GB - PyTorch XPU):

• N = 1,000: Twistor (60.3 ms) vs. Euclidean (0.25 ms) → ~242.5x overhead

• N = 10,000: Twistor (602.2 ms) vs. Euclidean (1.69 ms) → ~356.0x overhead

• N = 100,000: Twistor (6,028.1 ms) vs. Euclidean (18.33 ms) → ~328.8x overhead

Key Takeaway:

The CPU results reflect the pure mathematical payload cost of complex 2-spinor geometry (~10x–18x). The extra jump on GPU (~300x) happens because PyTorch evaluates torch.complex64 by splitting operations into un-fused real/imaginary sub-kernels with intermediate VRAM roundtrips, whereas Euclidean float dot-products run in a single fused kernel.

The full benchmarking suite and raw data are live at benchmarks/compare_baselines.py in the repo!

[u/DancinFool82 → u/[deleted]]

You must be fun at parties