People have no idea the amount of effort it requires to make 3D anything, and then at the quality level they frequently see 3D things in media. Then there's the different types of ways to do 3D, from scanline to polygons to rays to volumes and then abandon all that for splats; likewise with color models where RGB gets replaced with RGBA and then sRGB/CMYK and others, and now physically based rendering has a whole other color model with different names and formulas. I've not even mentioned the differences between software rendering and hardware accelerated rendering, nor distributed cluster farm rendering as used in film and commercial productions.
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 a ton of knowledge , but not gatekept behind degrees or anything.
Like web development, you can learn much of it by reading freely available documents, blog posts, and white papers. (Tho it’s much more math heavy. Mostly trig and very basic linalg)
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
I don't keep too many reference books forever, but "3D Math Primer for Graphics and Game Development" and Eric Lengyel's book are on my shelf.
The are very accessible, IMO aimed at the "kid who was good at high school math, wanted to make video games".
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. :)
I've forgotten most of the specific matrix multiplication stuff I needed to know to write a ray tracer, and my ray tracer was dog slow compared to pixar's renderman. I wouldn't say it takes multiple PhD careers, though. It was discrete math and a couple upper level CS undergrad courses to get to a working ray tracer, write interesting shaders, and do stuff like fourier transforms of audio on a gpu.
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.
yes, sure people are "starting" toy projects in this area all the time. That's not the same thing as a production version will wide support, deep features and targeting the browser.
I'm having a hard time matching these with some of the 3D things I've done before. As in, little vendiagram overlap.
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.
it's not hard and not that much work. there are tons of people making their own 3d engines for fun all the time. Usually they get something on the screen relatively quickly. There are articles and YouTube channels all over on how to do it. If you want to make all of UE5 then it's a lot of work but if you just want to display a pBR 3d model it's a day's work if you already know how and a few days if you don't
rebuilding every feature of a 3d engine takes lots of time but getting to a lit model does not.
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.