Books I used to develop a game engine
haroldserrano.com
haroldserrano.com
I actually think (as someone with gamedev experience) that the explanation has to do with the difficulty of creating art assets for 3d games rather than complex math (as other users have pointed out, current widely used engines take care of mostly).
Indeed, even indie games that are made in 3d generally take a low poly style as they are easier to make (and obviously easier to achieve performant results).
As somebody who is a hobbyist at best, this is my biggest sticking point. Anybody can learn to slam together some pixel art in Paint, and even doing more advanced work in Photoshop is not out of reach with a little time and practice. But learning a 3D modeling tool is orders of magnitude harder - I've made a couple runs at Blender and older versions of 3D Max, and there's just so much to making meshes that look decent, and then you have to skin them. And then there is the question of adding animations. My hat is off to people who have developed those skills.
My only hope is that technology to make this process easier will advance. I've seen some demos of people using their phone cameras to scan real objects and generate 3D models, but even if that worked perfectly, it appears to me that there would be a lot of work to process that into passable 3D art assets.
A good pixel or 2D artist may have more skill in many dimensions than an average 3D artist, but given the fidelity of what is being created they will be able to produce more in a given set of time. Ideally, as an independent game developer you want to have one artist. You can do that if you choose 2D.
There's also modelmakers that scan real objects as well too
If you just want to source art assets using 'standard' definitions used in CG and games you
a. Subcontract them b. Purchase them from some store or source free ones c. Use generator programs like Poser
and any combination of those.
If you want to learn modeling and art in general,you learn modeling. The trick is it's partly art, so unlike, say, woodworking, the number of free parameters to master is quite large.
3D sculpting and CAD modelling are entirely different beasts however (I've never actually seen CAD tools involved in a game asset workflow, but it could be done and would be fairly useful for inorganic assets). Sculpting is dead simple in principle, in the same sense that drawing is; meaning you don't need to worry about the tools in the same way. CAD is a different beast, but still works on some pretty simple principles (constraint-driven CSG).
I think the only real "hard" part right now is getting low-poly versions of assets that can be used inside of your engine. Making the high-poly assets might require more actual work (and 3D scanning could help there), but it's nonetheless fairly straightforward.
edit: "low-poly" here meaning "reasonable number of polygons", not visibly low-poly.
The reason why most people are bad at 3d modeling is that most people are bad at art. Reproducing shapes from real life to any medium, if it's charcoal, or clay, or 3d, is very difficult. People who are good at it typically spent tens of thousands of hours practicing.
Part of what you learn in this practice is patience. Part of what you learn is a good eye. However, unless you're fundamentally allergic to tech - tools like Blender are simply way faster and more powerful than any other medium.
Consider an 'art' skill like making woodcuts. There's no 'undo'. Mistakes are very easy to make, and often involve stabbing yourself through the web of your thumb with a chisel. It takes days of painful, physically tiring work, that is very bad for your hands, to simply make the lines. It's like that because real material processes don't care about user-friendliness.
For me, learning Blender as an interface was enjoyable because I could see how much easier it was going to make my life. It's neither large, nor unduly complicated - I'd consider it similar to learning vim, or photoshop. The real problems - the hard problems, are art problems.
[1] https://www.amazon.com/Advanced-Animation-Rendering-Techniqu...
[2] https://www.amazon.com/Game-Engine-Architecture-Jason-Gregor...
Not really, listing 50 books without any explanation is as good as listing none. A reader is none the wiser.
Out of all of them Realtime Collision Detection stands out. It's basically datastructures for real-time spatial data. Every chapter of that book is gold.
> All illustrations in the book were redrawn from my original illustrations. Unfortunately, the company in charge of redrawing the illustrations mangled almost all of the illustrations doing so (right angles became accute or obtuse, etc). I thought I had caught all their errors before the book went to print but sadly it seems I missed a few.
Tangent: his 2003 presentation on memory optimisation[1] is also still a very interesting read, especially the last section on aliasing. I wonder how much of those comments still apply to modern languages (or C and C++ compilers, for that matter).
[0] http://realtimecollisiondetection.net/books/rtcd/errata/`
This list reads like "here is a list of all the books i know that exist somewhat related to this topic"
https://www.amazon.com/Engine-Architecture-Second-Jason-Greg...
https://research.neustar.biz/2012/07/09/sketch-of-the-day-k-...
The things I read without doing exercises gives shallow knowledge indeed, but that shallow knowledge lets me know what I must learn about later when I need it. Also shallow knowledge is easier to obtain, so I can spend time on getting shallow knowledge that would not have been time I could use for real learning because there the limit to how much real learning can be absorbed during say a day is lower than the amount of time available in a day IMO.
https://www.haroldserrano.com/blog/best-books-to-develop-a-g...
It’s just not how I would like to work. I want more control via a super smooth interactive text-based interface; that interface should integrate seamlessly with a visual direct manipulation interface.
The interface improvements that have been made since then have been amazing for discoverability and they have kept (most of) the old keyboard shortcuts too. This is not a bad thing at all, but it does mean that there are tutorials which still make it seem like Blender requires just knowing and memorising loads of keyboard shortcuts.
When learning Blender, the space bar is definitely your friend these days.
The API did not feel totally Pythonic, and it did not feel like it was intended for direct use. It felt more like it was meant for plumbing and plugins, not for creating and controlling a specific scene.
For now, 3D game development will see a lot of growth once VR/AR gains adoption.
Now, to be honest, you can make a decent game with just high school math.
And despite urban myths, game consoles never had much love for OpenGL.
https://softwareengineering.stackexchange.com/a/88055
Had Apple not adopted OpenGL and GL ES as a means to save 3D R&D and make their shinny new OS attractive to UNIX devs (they were researching Quickdraw 3D initially), OpenGL would be history concernig 3D game APIs.