A bit of homework, but Ray Tracing in One Weekend is legendary (and free).
Disney’s short video on pathtracing can also help explain some concepts.
Another important thing is understanding the intersection that raytracing has with rasterization, since that is what consumers are seeing now with the new Turing cores. What the difference is, why people should care, etc.
It’s funny, I have been reading a lot online and observing people’s reactions to the new cards- and most of the backlash simply comes from not understanding what raytracing is. For graphics engineers in the industry, rasterizers (as brilliant as they are) always feel like a hack at some point or another- ray tracing is “the right way”, and that has us very excited
I've been working on games for quite a long while so I picked it up here and there.
I haven't gone through this particular series myself, but I've browsed through it and his (thebennybox - everything he makes is high quality) series on creating a software renderer, and they are fantastic!
https://www.youtube.com/watch?v=ss3AnSxJ2X8&list=PLEETnX-uPtBXP_B2yupUKlflXBznWIlL5
This is by far my favorite book:
https://www.amazon.com/Engine-Architecture-Second-Jason-Gregory/dp/1466560010
I'd recommend thebennybox's video series first, the book may not be quite as beginner-friendly.
You can just use the compute functionality of Vulkan (no swapchain) and maybe accelerate it using either VK_KHR_ray_query or VK_KHR_ray_tracing_pipeline. You could follow the NVIDIA ray tracing tutorials or you may take a look at Ray Tracing in one Weekend. There are also a lot of examples on shadertoy.
> Game Engine Architecture
That is a fantastic book. Highly recommend it.
Tip: You can shorten the URL down to just the number after the dp
portion:
3D graphics is a few things, fundamental to all of them is understanding the mathematics of Linear Algebra, meaning vectors and matrices, and efficient implementations of them as geometry pipelines in the separate environments of a) tools with no visualization, b) CPU executed geometry and texture pipelines with optional partial GPU assist, also no visualization but still engaging with GPUs and OpenGL, c) CPU assisting GPU based applications, which may be desktop compiled or web/browser based and d) new hybrids combining everything previous with compute shaders, wasm, and kitchen sinks. Across all these environments and languages are different methods of working with vectors and matrices to produce geometry and geometry transformation (we call animation) pipelines. Fancy geometry pipelines have integrated physics and collision engines, which are also vector and matrix transformations.
I'd also recommend some additional reference sources as you teach yourself OpenGL and 3D: this book is considered the 3D graphics bible: https://www.amazon.com/Computer-Graphics-Principles-Practice-3rd/dp/0321399528/ref=pd_sbs_1/131-8595678-4937945?pd_rd_w=NL5Sd&pf_rd_p=f8e24c42-8be0-4374-84aa-bb08fd897453&pf_rd_r=HJTFQB8K7HNM1F4GNWCB&pd_rd_r=b611597e-3a74-45c9-8330-897... It covers the entire field and will have a reference for everything worth knowing, often by the original authors. Then try to locate the decades old Transactions on Computer Graphics https://dl.acm.org/journal/tog That's the original algorithms written on decades old hardware, which re implemented on today's hardware simply screams.
Always remember that OpenGL is just one implementation of doing 3D, which has countless ways of connecting its internals, but all that devolves into just working with vectors and matrices in efficient manners. If you do 3D in your career, it may not have OpenGL available, but that should not stop you.
Pick up Ray Tracing In One Weekend, Author's Blog & Amazon. It's a fun little ebook that walks you through building a very small, fun path tracer. He codes his version in C++, but you can build it in any language!
I got the book over Thanksgiving and used it as an exercise to learn OCaml. I'll be revisiting the book anytime I want to a new language again.
This is one of the best game programming books i've read. https://www.amazon.com/Engine-Architecture-Third-Jason-Gregory/dp/1138035459
This one is also a must read, and its free. https://gameprogrammingpatterns.com/
Ok! So, for generations the primary reference for 2D/3D graphics had been "Computer Graphics: Principles and Practice" and it's an academic handful. Computer Graphics Not recommend that you buy that, but wanted to give you a heads-up on how deep the graphics field goes.
Knowing that, what OS and graphics system are you interested in working in? Say for OpenGL or Direct 3D the documentation will include basic shaders, and will cover the simpler math required to understand what each shader does.
Do you have any 3D math knowledge of vectors, matrix dot and cross products? Or early color theory of RGB and how colors are stored?
> Shirley's minibooks
I assume you are talking about this book ? I'm not familiar with it but any resources are good!
Learning D3D12 is good just be aware that it is easy to get bogged down in the "weeds" if you don't understand the full pipeline. The D3D samples are good to look at.
https://www.amazon.com/Digital-Lighting-Rendering-Voices-Matter/dp/0321928989/
I have the first edition, and then noticed this 3rd edition is available... kind of pricy, though. I thought it (1st edition) was quite good. I'm not sure what has been added to each update.
Sure thing!
A commonly used one is the Physically Based Rendering: From Theory to Implementation
A cheaper option would be The PBR Guide
As far as my specialty goes, I have been focusing on material development, both in-engine (Unreal Engine shaders) and for texture creation (Substance Designer and Painter). I originally went to school to try and become a 3D Character artist and although I still find the work very fun, once I was tasked with creating some VFX for a game I was part of, I immediately attached to it. Something about the logic in shaders and especially using node graphs to create a desired output just immediately spoke to me and understanding it was very natural.
I've done a decent amount of work in nearly every area of 3D development. Lighting, compositing, hard surface and organic modeling, shader work, texture authoring, procedural creation, etc... I just had a natural inclination towards material-based and shader-based pipelines and development. I understand it (mostly... there's always more to learn) and I love working with it. It just so happens to be in a field of large demand and specialization, so the pay turns out pretty decent too.
LearnOpenGL is a good starting point. I’m also reading Game Engine Architecture which I have found interesting but not been able to put into to practice yet.
Here's another book suggestion. A book like this will tell you about everything that you need to know to build your own game engine https://www.amazon.ca/Engine-Architecture-Third-Jason-Gregory/dp/1138035459/ref=sr_1_2?dchild=1&keywords=game+engine&qid=1628536036&sr=8-2
Check out the book "production pipeline fundamentals for film and games" it's worth the read:
Unfortunately even the most famous work on VFX pipelines in IMO, quite lacking. Although the issue is that in my opinion it's just too thin, but it might work for you. This one is the one people usually recommend.
As usual, PhD is commonly asked, but it's not like everybody at Pixar (or Disney or whatever) has PhD.
That sounds troubling! You need to talk about expectations with the team. First, get the supervisors to specify everything they expect to produce. Ask the artists what they can do and how they expect to contribute. Establish the gaps between team ability and team expectations. Understand time scales, budget, existing tools. Then work out what you need to do to bridge any gaps in the production pipeline. It might be tools. It might be training. It might be engine work or fx. Whatever it is, you need to gather the information before you can create a plan.
And read this book as fast as you can: Production Pipeline Fundamentals for Film and Games https://www.amazon.com/dp/0415812291
> and even those are legacy projects
What's not good with C++ legacy projects? Might even make your job more secure.
> I used in my work was C++11
Standard adaptaion is not that fast with industrial projects; even the game industry doesn't instantly switch to new versions; e.g. Jason Gregory writes in the 2018 edition of https://www.amazon.com/Engine-Architecture-Third-Jason-Gregory/dp/1138035459 that they only recently adopted a subset of C++11 and only for The Last of Us Part II, and the other projects are still C++98. So I wouldn't worry too much about it.
This is a very generic question. 😅 Game engines can be really complex to describe because it is composed of a variety of subsystems inside it. I think you could learn more about it in the game engine architecture book how these subsystems are organized and implemented. Also how they interact with each other.
Game engine architecture Amazon shop
If you want to have some hands on in something already made in c++, Ogre engine is open source and it was used to develop tourch light 2. Also godot engine is open source and written in c++.
Unreal is very know these days. It's written in c++ and c#. But this one is not open source. But I think it could be nice to look around unreal code just for learning purposes.
Oh. Also if you just want to make games instead of doing your own engine. You could use Godot. It also have interfaces to write your game in c++, python, or Godot language. I think it is good just to start making your own projects and game systems before jumping into some complex subjects.
Have fun ✌🏼🙂
If you're interested in this I can recommend the Raytracing mini-books by Peter Shirley. I ran through them back in '16 and it is probably the most comprehensive intro book/tutorial I've seen. Does go heavy on the math and actually shows all the code needed.
https://www.amazon.com/Ray-Tracing-Weekend-Minibooks-Book-ebook/dp/B01B5AODD8
Buy a book on Unity (or something similar) and work through it. Also if you want to get into game dev you'll want to read this book: Game Engine Architecture
Don't know about the 3rd edition, but the 2nd edition is probably published in 1987, and 3rd edition from amazon is completely different. https://www.amazon.com/Computer-Graphics-Principles-Practice-3rd/dp/0321399528/ref=sr_1_1?ie=UTF8&qid=1530000672&sr=8-1&keywords=computer+graphics+principles+and+practice
I've written a path tracer before, and I did it by modifying my ray tracer. A path tracer is really just a ray tracer that traces even more rays. The difference between them is really not that great. The same data structures can be used for either. There's a book called Ray Tracing in a Weekend, and it teaches you how to write a path tracer. The book's written by Peter Shirley, who's kind of an authority on the topic.
Nowadays, no one talks about ray tracing in the strict way that you do. People will some times refer to different things like path tracers, bidrectional path tracer, and photon mappers all as ray tracers. DirectX Raytracing is definitely not just limited to ray tracing as you described. If it was, it wouldn't be much use to anyone.
The text book I used for my Computer Graphics course has everything you'll need. Any 3D game programming material deals with the 2D window into a 3D model.
If you're looking to do this to understand the problem better, then you're taking the right approach by starting with understanding the problem. If this is just a challenge to learn to code, then a code-first approach would probably serve you better. In the latter case, a book on Unity might get you where you want to be faster.
This is the classic text on computer graphics. It's been at least 10 years since I touched it though, so I'm not sure how up to date the latest edition is.
I'd recommend this book, though if new to coding it may be a bit overwhelming https://www.amazon.com/Engine-Architecture-Second-Jason-Gregory/dp/1466560010/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=NC95XNX16602MDF2SG80
I designed my main map generator based on the book Mazes for Programmers. This is about true Mazes though so it was just a starting point.
A sim/render split was a standard practice in the AAA side of the industry during most of 00's. The practice is becoming outdated as more shops embrace more fundamentally multithreaded practices, pursuing the dream of 100% hardware utilization across a wide variety of hardware.
The engines powering the Saints Row franchise, Red Faction Guerrilla, and Red Faction Armageddon, were all written to place game logic on the "sim" thread and rendering logic on the "render" thread. A minimal footprint of data was copied from sim to render during a step called "the handshake". This allowed a thread to spend most of our 33ms slice of time (targeting 30fps) on just rendering calls, while the other threads handled various pieces of gameplay logic or other engine tasks (sound, for instance, was run in its own thread, and we let Havok do its own multithreading).
Nowadays, more engines are moving to functional programming practices, allocating jobs from a pool that can be dispatched to any number of threads, because functional programming practices are easier to multithread (there are fewer memory hazards), and modern hardware offers many more logical processors than previous generations did.
If you're interested in engine architecture, the best book on this is probably Jason Gregory's Game Engine Architecture (ISBN 978-1-4665-6001-7).
It's not really practical. Making a full featured game engine from 'scratch' isn't easy, but it is possible.
I reccomend reading this book: Game Engine Architecture
It tells you everything about how game engines work and how to make your own. I did a good amount of it in a post-grad college program, and learned a lot, but ultimately decided to use Unity for actual development.
Unity's good. Flash with Flixel is good. Haxe with HaxeFlixel is good.
Heck, I made a match 3 game in plain old Flash years ago. Didn't even have to program or borrow an 'engine' for it, Flash did the heavy lifting.