3D CPU rendering engine

[TheProKnightGamer]

This is a 3D rendering engine that uses the Scene module.
With proper adjustments you can reach 60 fps and on newer iPad models can even support full resolution at 60 fps.
https://github.com/TheProKnightGamer/3DPythonista
The default map contains 50 blocks and can be modified, full motion controls will be added later to allow exploration of maps.

[cvpe]

Tried, got this error

Traceback (most recent call last):
  File "/var/containers/Bundle/Application/47EE896D-6D79-4316-83F7-36C4982BF508/Pythonista3.app/Frameworks/Py3Kit.framework/pylib/site-packages/pythonista/scene.py", line 199, in _draw
    self.update()
  File "/var/mobile/Containers/Shared/AppGroup/94C45A26-1F47-4486-9539-896F8F44AA91/Pythonista3/Documents/MesTests/3D game.py", line 314, in update
    self.render()
  File "/var/mobile/Containers/Shared/AppGroup/94C45A26-1F47-4486-9539-896F8F44AA91/Pythonista3/Documents/MesTests/3D game.py", line 307, in render
    _triangle_strip(coords)
NameError: name '_triangle_strip' is not defined

[mmccthomas]

Simple typo on line 25.
I had been doing something along the same lines recently using the SceneKit library.
https://github.com/mmccthomas/Pythonista_games/blob/main/AI_Games/rubik.py

Just for interest and fun, a review from Google Gemini in response to the prompt:
“Review this code to render 3dshapes in Pythonista. Frame rate is very low. Can it be improved?”
Response :
You've written a raycaster in Pythonista, which is a fantastic project! However, raycasting is computationally intensive, and Python, being an interpreted language, can be slow for such tasks. Pythonista's scene module provides some hardware acceleration for 2D drawing, but your 3D rendering is done pixel-by-pixel in pure Python, which is the bottleneck.
Here's a breakdown of why your frame rate is low and how you might improve it within the constraints of Pythonista, along with the realistic limitations:
Why the Frame Rate is Low:

• Pure Python Pixel Manipulation: You're calculating the color for every pixel (or rather, every res x res block of pixels) on the screen for every frame. This involves:
  • Iterating through sx * sy (screen width/resolution * screen height/resolution) pixels.
  • For each pixel, performing ray direction calculations involving trigonometric functions (cos, sin) and vector normalization (_sqrt).
  • For each ray, iterating through all blocks in your scene.
  • Inside the block loop, performing multiple intersection calculations (t1, t2, u1, u2, v1, v2) and comparisons.
  • If shading is enabled, more calculations for light intensity.
  • If edges are enabled, more calculations for edge detection.
• Lack of Hardware Acceleration for 3D: Pythonista's scene module is primarily designed for 2D graphics and sprite manipulation. It uses OpenGL under the hood for its drawing functions (_fill, _triangle_strip), but you're feeding it already-computed pixel data from your CPU-bound raycasting loop. True 3D rendering typically relies on a GPU to perform these calculations in parallel much faster.
• Dynamic Object Iteration: Every frame, you iterate through self.blocks to check for intersections. While your current scene has a fixed number of blocks, in a more complex scene, this linear search can become very slow.
• Floating-Point Operations: 3D math involves a lot of floating-point arithmetic, which is generally slower than integer operations.
  Potential Improvements (within Pythonista's scene limits):
  The most significant performance gains would come from moving the core raycasting logic out of pure Python into a more performant language (like C, via a Python extension), or using a library that leverages OpenGL for 3D rendering. However, in Pythonista, you're largely limited to what's available.
• Reduce Resolution (self.res): This is by far the most effective immediate change. A higher self.res means fewer pixels are computed, significantly speeding up the render. For example, changing self.res = 10 to self.res = 20 or even 40 will drastically increase your FPS, albeit at the cost of visual fidelity.
  • self.res = 10 (current) -> 1/10th resolution in each dimension, so 1/100th the pixels.
  • self.res = 20 -> 1/400th the pixels.
  • self.res = 40 -> 1/1600th the pixels.
• Optimize Math Operations:
  • Pre-calculate where possible: Some values, like inv_sx2, inv_sy2, fov * aspect, and fov are constant per frame (or even always constant). You've done some of this already.
  • Avoid redundant calculations: Look for any expressions that are calculated multiple times within loops but whose values don't change.
  • Use math.hypot for distance (minor): For _sqrt(dxdx + dydy + dz*dz), math.hypot(dx, dy, dz) can sometimes be slightly faster as it's optimized for this common operation.
  • numpy for vector operations (if possible): While you import numpy, you're not using it for vector math. If you could represent your rays and normals as NumPy arrays, operations like dot products (np.dot) and cross products would be much faster as they leverage C implementations. However, integrating this deeply into your existing raycasting loop might be complex without a complete rewrite.
• Simplify Shading and Edges:
  • The shading and edges calculations add a significant overhead. If you don't strictly need them, disabling them will improve performance.
  • The tol calculation for edges (bs * 0.01) involves a multiplication. A fixed, small eps value might be slightly faster if appropriate.
  • The RGB conversion for shading is also an extra step. If you can use pre-calculated shaded colors or simplify the blending, that could help.
• Early Exit/Culling:
  • Frustum Culling: Currently, you're checking every block against every ray. In a larger scene, many blocks will be outside the camera's field of view. Implementing a simple frustum culling mechanism (checking if a block's bounding box intersects the camera's view frustum) before iterating through rays for that block could save a lot of calculations. This is often done by checking the block's corners against the planes of the view frustum.
  • Backface Culling (for cubes): For opaque cubes, you only need to render the faces that are visible to the camera. You could determine which faces are outward-facing relative to the camera and only check those for intersection. Since you're raycasting to the entire cube, this might be more complex to integrate efficiently, but for polygons, it's a standard optimization.
• Data Structure for Blocks:
  • A flat list of tuples for self.blocks is simple, but for many objects, a more spatially aware data structure like an Octree or a Bounding Volume Hierarchy (BVH) would dramatically speed up the for xmin, ymin, ... in blocks: loop. Instead of checking every block, you'd quickly narrow down the potential intersections to a few blocks based on the ray's path through the spatial subdivision. This is a significant undertaking but would yield the largest gains for complex scenes.
• Avoid ShapeNode Updates in update Loop (for Gizmo):
  • In your Gizmo.update_gizmo, you're setting cube.position and cube.size for each cube. While ShapeNodes are more performant than direct pixel drawing, if you have many gizmos or complex ShapeNode operations, this can still contribute to slowdowns. For your current Gizmo implementation, it's likely not the primary bottleneck, but it's good to be aware of.
    Example of Resolution Change:

... (rest of your code) ...

class Game(Scene):
def setup(self):
motion.start_updates()
self.background_color = '#ffffff'
self.pos = [50.0, 50.0, 50.0]
self.vel = [0.0, 0.0, 0.0]
self._t = _time()
self.pitch = self.yaw = self.roll = 0.0
self.fov_tan = tan(radians(70) * 0.5)
self.Plus = radians(90)
self.res = 20 # <-- CHANGE THIS TO A HIGHER VALUE

    # ... (rest of setup) ...

Realistic Expectations:
Given that Pythonista's scene module doesn't provide direct 3D rendering primitives that leverage the GPU, you're essentially performing software rendering. This means you will always be limited in performance compared to true 3D engines or frameworks. Achieving smooth, high-resolution 3D graphics with complex scenes in pure Python on a mobile device is extremely challenging.
Your code is already quite optimized for pure Python raycasting, using local variables and pre-calculating constants where appropriate. The core issue is the fundamental approach of pixel-by-pixel ray intersection in Python.
In summary, for the best performance boost without a complete rewrite using an external 3D library (if one were available for Pythonista that used OpenGL/Metal directly), try increasing self.res significantly. Beyond that, more advanced optimizations like spatial partitioning would be necessary but are much more complex to implement.

Best Regards,
Chris

[TheProKnightGamer]

Thanks for pointing out the typo, on the topic of optimization I don’t think I can squeeze any substantial amount of speed from pre-calculating more as I am by the edge of hardware limitations so I’m researching using iOS metal through objc_util to leverage GPU.

[cvpe]

ChatGPT says that SceneKit, from ios10, uses automatically METAL.
Test this little code (generated by ChatGPT to prove it)

from objc_util import *
import ui

# load Objective-C classes
SCNView = ObjCClass('SCNView')
SCNScene = ObjCClass('SCNScene')
SCNSphere = ObjCClass('SCNSphere')
SCNNode = ObjCClass('SCNNode')
SCNLight = ObjCClass('SCNLight')
SCNCamera = ObjCClass('SCNCamera')

# Scene creation
def create_scn_view(frame):
    options = None
    scn_view = SCNView.alloc().initWithFrame_options_(frame, options)
    
    rendering_api = scn_view.renderingAPI()
    print('Rendering API =', rendering_api)
    print('0 = Metal, 1 = OpenGL, 2 = Vulkan (rare), 3 = softw')
    
    scene = SCNScene.scene()
    scn_view.setScene_(scene)
    
    sphere = SCNSphere.sphereWithRadius_(1.0)
    node = SCNNode.nodeWithGeometry_(sphere)
    node.setPosition_((0.0, 0.0, -5.0))
    scene.rootNode().addChildNode_(node)
    
    light = SCNLight.light()
    light.setType_('omni')
    light_node = SCNNode.node()
    light_node.setLight_(light)
    light_node.setPosition_((0.0, 10.0, 10.0))
    scene.rootNode().addChildNode_(light_node)
    
    camera = SCNCamera.camera()
    camera_node = SCNNode.node()
    camera_node.setCamera_(camera)
    camera_node.setPosition_((0.0, 0.0, 10.0))
    scene.rootNode().addChildNode_(camera_node)
    
    scn_view.setAllowsCameraControl_(True)
    scn_view.setBackgroundColor_(UIColor.blackColor())
    
    return scn_view

# Creation of UI view
class SceneKitView(ui.View):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        frame = ((0, 0), (self.width, self.height))
        scn_view = create_scn_view(frame)
        self.objc_instance.addSubview_(scn_view)

v = SceneKitView(frame=(0, 0, 400, 400))
v.present('sheet')

[cvpe]

"Given that Pythonista's scene module doesn't provide direct 3D rendering primitives..." but you could do it in ObjectiveC (not obvious).
See my little example where you have to select one of your photos and you will get a 3D cube that you can move and rotate with your fingers or by moving your iDevice.
Try it for the fun

https://github.com/cvpe/Pythonista-scripts/blob/master/Gists/scenekit%20image%203d%20rotate.py

Vidéo:
https://github.com/user-attachments/assets/9ddf61f8-64a3-498a-9dae-a257f83850f0

other video:
https://github.com/user-attachments/assets/de9fc87c-044a-4da8-acd8-34f28064fbca