It's multiple full time Phd level careers, and most people think it's easy and they could do all of it if given the opportunity.
It's multiple full time Phd level careers, and most people think it's easy and they could do all of it if given the opportunity.
There’s a famous “ray tracing in a weekend” book even.
Color spaces and PBR also isn’t some magic. It’s just math. You implement it in shaders and color space conversion functions.
It gets really hard when you try to optimize it, like you said with render farms. IMO synchronization in Vulkan (and other low low level graphics APIs) is the really difficult stuff.
But nothing that requires a PhD or whatever.
For the curious “Real Time Rendering” is a really great textbook all about modern rendering techniques
The math behind rendering is pretty straightforward and has been available since forever (Graphics Gems). On top of that, three.js was sort of a port of an existing library called away3D, which was a port of papervision, but that's another story.
I remember you from the good ol flash times. I didn't wanted to downplay your effort you put into threejs. <3
My point was that you don't have to have a PhD to write a 3D engine, the math is here, there's a plenty of literature, reference and libraries at hand that anyone can make their own toy 3D rendered on a weekend.
... to make that work in the browserland, that's whole another story. :)
I remember writing a tiny deeplinking "library", back in 2006. When I finished implementing the specification it had ~30 lines of code. At the time it was compatible with all common browsers it got to about 500. :)
But, take a game, or a movie. One needs render things very efficiently in a game, you have 33.3ms of frame budget. Today, raytracing in games either uses just 1 or 2 techniques (e.g. shadows) and calls it a day. If you want to do more, you probably need some help with machine learning (think DLSS). Not to mention, you need a system that accelerates the structures needed to perform it, and somehow marry all this with everything else in game that uses the GPU. You get animations into the mix and the complexity goes up in all areas.
In movies, you have more leeway, but the artists still need to iterate fast. You want them to be able to see something akin to the final product fast.
It intersects a lot of areas.
What I'm used to, using hardware APIs, or software rendering: - Nodes - Edges - Triangles - Meshes - Shaders - Matrices - Quaternions (Or bivectors etc) - Projection (3d state to 2d screen)
I suppose I'm confused because the basics don't seem cosmic. It's a straightforward application of considering the state you need to store your 3D model in, then some linear algebra and quaternion operations to convert that 3d state to a 2d screen.
For quality level seen in media, it's different; all the additional techniques that make things realistic or have effects that get complicated. I suspect this is where the disconnect lies; if so, I suppose my point is that it's not 3D that's complicated; it's realistic 3D.
edit: I Looked up Gaussian Splats: Very cool!
rebuilding every feature of a 3d engine takes lots of time but getting to a lit model does not.