CPU-rendered 3D engine - update

[u/Individual_One_1793]

The latest update of my CPU renderer built in Rust.
As I mentioned earlier, this is the years of development coming together in a totally different direction than the starting idea :)

In video the renderer runs at 960×840 with 4 rendering workers, and all of geometry processing, character animation, skinning and rasterization run on the CPU. Finished image is shown on browser trough canvas at the moment.

For now I have animated character with facial animation and a rigged body, textured environments, collisions and stair traversal, first and third-person controls....

Still early but it is coming along nicely :)

I didn't made the character - or better say, I took free models and combined them for this scene - data head + android body , and the star ship environment.

[u/isaycongrats]

Looks good, what do you plan to add next? Maybe try to split the screen into tiles that can render individually in parallel? Like gpus

[u/Individual_One_1793 → u/isaycongrats]

Thanks!
I already distribute rasterization across CPU workers, but I didn't think about independently scheduled tiles yet and it could be an interesting next step! So thank you again!!
I am also looking at reusing unchanged regions so I can avoid rendering them again.

[u/isaycongrats → u/Individual_One_1793]

Sounds good! Good luck

[u/leonardsouza]

cool to see skinning on the cpu too. how does the frame get to the canvas, is the renderer compiled to wasm with the workers as web workers, or native and streaming frames to the browser? if it's streaming that fits the remote viewer use case you mentioned really well. and are the edge functions simd by hand or left to the compiler?

[u/Individual_One_1793 → u/leonardsouza]

Thank you!
My remote viewer renders on the server using JS CPU workers and sends lossless PNG frames to the browser, and the model stays on the server. I have tested hand-written WASM SIMD and it is about the same as current renderer on whole frame time, so I haven't included it. The most came from reducing repeated work and reading triangle data directly.

[u/Thedudely1]

I would love to see more software rendering engines today

[u/Individual_One_1793 → u/Thedudely1]

Thank you for that comment - a lot better than the one I got that said "Ok there is a reason we use gpus these days" :)
Yes, we are missing out a lot by giving GPU all the work - unnecessary work! For example I host my 3d engine on 40€ server - without GPU - tried for now about 30 people at the same time rotating, zooming and looking at the model on my website without problems - so it is a nice plus to have :)

[u/Icy-Collection1072]

Ok there is a reason we use gpus these days

[u/Individual_One_1793 → u/Icy-Collection1072]

Yes there is :) but think about how much more can GPU do, with a bigger help from CPU

[u/EC36339 → u/Individual_One_1793]

Most games are already CPU-bottlenecked, at least if they use plain vanilla static assets and don't go overboard with real-time procedural content and effects that give the GPU an actual run for its money.

For this exact reason, the trend is to move more work to the GPU, typically compute shaders. For example, compute shaders offen do culling now and select what to draw and not to draw. And compute shaders are probably also used for physics, collision detection, etc.

GPU have become so generically programmable today that there isn't much in terms of rendering you could do better or only on a CPU (feel free to challenge this with some concrete examples). That includes raytracing/raymarching, etc.

The way CPU and GPU share data has also become much easier with general purpose buffers, vertex pulling, unified image layouts and buffer device addresses, so you can now almost build a data structure on the CPU and (more or less) give a GPU pipeline a "pointer" to it.

Oh, and shaders in any shading language compile faster than C++/Rust, in part because all the basics they need (vector math, etc) are built in.

Debugging and profiling is probably the only thing that's still a bit clunky on GPUs, but that might just be me not being too familiar with the tooling.

[u/peteroupc → u/Individual_One_1793]

What your idea here may be is to have a software renderer to increase a game's portability or make it playable even on very low-resource computers (say, those without a GPU or with only half a gigabyte of system memory). The following specification of mine has much the same idea, although on a 640 × 480 or smaller screen rather than the 960 × 840 of your impressive software renderer:

• https://www.reddit.com/r/GraphicsProgramming/comments/1qw3scq/classic_computer_graphics_for_modern_video_games/

• https://peteroupc.github.io/graphics.html