CAMERAS and How They Work | Game Engine series

hey what's up guys my name is Jonah welcome back to my game engine series so last time we took a look at the render on render commands renderer API stuff like that how we can actually kind of like begin beginning and our rendering and submit geometry and meshes and stuff like that in between definitely check out that video if you haven't already and today we're gonna be talking about cameras cameras are a pretty big topic and they're I think something that is both like extremely vile for you to know but also extremely like important that you consider the architecture of cameras and how they work properly and in order to actually consider how to architect a proper kind of I guess camera system in your actual game engine you need to actually know how rendering works but not only the rendering side of things but also kind of the gameplay side of things because cameras are interesting they're vital for rendering you absolutely need to have a good camera system if you want to render anything on your screen and also of course you know that with as with rendering you know you want to make that as optimal as possible because if you can optimize your rendering it means you can have more things on the screen and just more time more kind of actual kind of I guess you can have more but I was gonna say like a higher price essentially right because we can't refer to like something being expensive or cheap as to kind of how how much time it takes and what we're kind of paying with is our time right because we have a finite kind of amount of time in which to render a frame so if you can kind of make you a rendering as efficient as possible you can render more things on the screen and that's obviously very very useful and buy more things on the screen I don't necessarily mean like more objects on the same I just mean kind of you can spend more of your time doing rendering right and more kind of in frame time and that's really really important to actually producing high fidelity graphics now there's also the gameplay side of things there right because whilst you need cameras for rendering a lot of the time cameras respond to your actual interaction with the game right so user input and stuff like that if I kind of move my character around chances are is probably going to move the camera and so because we kind of have that twofold relationship where it's influenced by both the gameplay but then also important to be submitted for rendering the architecture of it is actually a lot more important than you might think and so because of that what we're actually going to do today we're just gonna focus on planning and when deciding to do this video like I was very tempted to just kind of just go into the code and just write a little kind of explain how cameras gonna work and actually come up with like an orthographic camera or something for our kind of 2d scene at the moment and then just kind of you know push that in and actually have that code ready but I thought it would be a much better idea for me to kind of just spend today just actually drawing like diagrams for you guys talking about how cameras work and all that and how we're gonna set them up and hazel and what the kind of be a scale plan is not just what we're gonna do like immediately now to get this thing up and running in its kind of first iteration the other benefit of this tour apart from just you guys having more of a holistic kind of understanding of camera systems is what I want you to do is after this video right go ahead and try and do it yourself you have the source code to hazel on the public github repository right go ahead and just try and take out all the information that we've talked about today and write this camera system based on my guidance yourself right you might even get some other ideas along the way in which to make this camera system even better than what I'm gonna just kind of plan out here right so I really encourage you guys to do that because if just fall if you're following along with this video so just going to get hub and get getting the source code and then just like changing you know hazel to your engine name and that's it you're not really getting anything out of this so I would really encourage you guys to do that and we also thank all the patrons that made this series possible patron Ocampo slash the chatter is where you can go to help support this series you'll get access to source code that I've written already for kind of my version of hazel which is like you know full kind of 3d scene and with a PBR renderer and all that kind of fun stuff and obviously that's got like a full 3d camera system in it and everything so you can kind of see how that works and then you also get videos like a week early as well anyway jumping back to cameras so let's just go ahead and go to the drawing board and actually kind of I guess theorize or talk about how a basic camera systems gonna work and in fact maybe before we go to the drawing board I'll just have a go kind of explaining it and then I can't draw you guys more of the architecture so cameras essentially what we want to do is think about what cameras are used for right so what I like to do when I about any kind of concept right because cameras are just a concept there's no such thing as a camera in OpenGL right so you have to think about what a camera actually is right so camera is used for first of all defining I guess how we look on to a scene and I'm gonna kind of talk about 3d cat 3d cameras in this the same obviously applies to tweedy but it's just I think it's just a bit more like real world and like real cameras in the real world and it's just might be easier and also more powerful to think about cameras and kind of a 3d context then it would encounter just a 2d context because 2d cameras are usually quite easy to kind of do and obviously Hazel's gonna be a 3d engine so when you think about it in that kind of context um but essentially cameras provided a means for us to view into the world right so we have a bunch of objects in our 3d scene and what we want to do is look at them from a particular viewpoint right and not just from a particular viewpoint but I guess in a certain format as well so what I mean by that is like just like in the real world you can take a camera and you can put any kind of lens on that right like you could have like a really wide like 10 millimeter lens or something like that or you could have like a really zoomed in like 200 mil right um want to see if you're not a photographer or a videographer you might understand how these times work but hopefully fluid ah that student kind of kind of makes sense right you can you have different focal lengths and in the same way that's what we kind of have in a you know kind of game engine as well right now we can refer them as field of view rather than actual focal lengths also although if you do actually create a physical camera system which you can do of course and we might explore that in the future and Hazel because I'm I'm quite you know I would love to kind of go down the photo Road photorealistic path um in terms of rendering for hazel anyway if we do that um aside from that it's usually in field of view right so field of view is kind of like how wide or narrow our field of view is right so how much we can actually see you put a camera here but how like how wide is the camera right how much can we actually see of the scene because just having a position of the camera and like an orientation of the camera is all great but we need to still know how much we can see and like you know if I was to destroy a quick diagram for you you know if you imagine that this box over here is like the camera right we have a field of view that could be quite wide which means that if we have you know a cube and it's kinda like a top-down view or a sphere or something like that we can see both of them or the field of view could be quite narrow like this and that would mean that you can see that we kind of clip through the cube and we clip through the sphere so we could have something like that right but this kind of field of view is known as fourth right and it's basically usually given in like either degrees or radians because we're humans we like dealing with degrees more so usually we'd say like a field of view of like 45 degrees or 65 degrees or 90 degrees or something insane like that right so usually you probably want to render at about 45 maybe like 45 to 65 is probably an acceptable range anything higher than that and you'll start to see quite a lot of distortion around the edges same as what you would with like a fisheye lens or even just like a I mean even if you get like a fairly wide like 12 millimeter lens on like a full-frame sensor in the real world and you look at the edges of your frame and you try and take a like a photo of someone's face but like they're like over here in your frame you'll see that they actually end up being quite distorted and it can look quite funny so that's why we generally want to render kind of in this range but the idea is that's kind of what a camera's made up of right it's not just made up of a position like you know if this is like our scene you know this has like an X Y Z coordinate alright and then probably like a rotation as well which you could give in X Y Z as well if it was like Euler rotations or you can use quaternions which is you know what we're gonna use and what you should probably use it's not just that right so it's not just a transform right it's also other physical kind of camera properties like the field of view right there's also an aspect ratio that's usually given right and an aspect ratio is just going to basically determine kind of you know if the camera should render like this if it around like that how wide is it gonna be because that's gonna be really important as well so that we can actually fit this properly into our frame buffer and you know when we've kind of rented to our screen or render into a texture so all of these kind of properties define what a camera is and that's kind of really important to understand so when I don't underst a concept or when I'm kind of talking about a new kind of concept right so cameras like what cameras I don't know what they are I don't know how they go work in my game engine the best thing to do is this right break it down into data what actual data is this data American welcome what kind of data is a camera like what am I actually doing you know but I ran that when I break things down to actual OpenGL calls what data do I need to take from my camera and pass into like graphics rendering territory right and in this case as I said I'm going to need the actual position of the camera somewhere in the world and the orientation of the camera and then actual kind of like the properties of the camera not just kind of the transform but also the field of view and the aspect ratio now let's break that down even further what does it mean to have a camera in OpenGL right like what is actually main like because there's no concept of cameras in OpenGL how two cameras actually work well what happens is a camera is really you know let's we won't talk about filter view we want to talk about aspect ratio let's talk about the transform of camera so it's where the camera is in our 3d world and where it's looking towards where it's kind of pointing towards right what does that actually do and what does that mean so if I have a cube in my scene is at the origin and is here and I move the camera kind of up and it's going to look at it right the thing that's actually moving and the thing that we actually want to do is render the cube at a different position in our screen right as I dragged the camera up if I start here and I driving the camera up right what's actually happening is the cube is moving from here to here right I'm suddenly looking at the cube kind of clock down and again if I draw you a diagram you know we might start with the cube being in the middle of the stream right but then as the camera as the actual like camera which I'll mark with the C moves upwards what's actually gonna happen is that cube is suddenly going to be more like this you know kind of you know view right depending on kind of how you render it I guess right but basically what's gonna happen is and if you get my awful drawing but we're just gonna look at the cube more like this yeah we're gonna see the top face a bit more all right because that camera's moved so if you think about what's actually changed on our screen it's the it's kind of the transform of the cube right the cube has gone from us looking at the front face to us kind of looking at the kind of both the front and the top face so the cube it looks like the cube is kind of rotated a bit and again if we decide that we want to move our camera back if I just undo like all of this um if we decide that we actually want to move our camera back right what actually happens right that's how I did all that one move but anyway what actually happens when we move our camera back well the cube might be you know this big because we're looking at it flat on and then if we kind of just wheel that camera back right it's gonna suddenly be smaller right so what's actually changing on the screen well the cube is the scale of the cube seems to be changing it seems to be getting smaller so what I'm gonna try to get your heads is that the cameras don't exist right what actually happens is based on the kind of made up transform of our camera we want to change the transform of our entire scene and it's important that you think about it as not kind of a per object basis but really it's the whole scene right if I have three cubes in my scene and I move the camera back does one of the cubes gets more known all of the cubes get smaller because I'm going backwards with my camera right so cameras affect the whole scene when you kind of you know last last episode we learn about begin saying and scene right so when we begin a scene that's why we push a camera and that's why I mentioned that in the previous video because when we begin a scene we push a camera for that same why because when I'm start rendering a scene it's all gonna be rendered from that one perspective you know you walk into a room in real life with your camera you take a photo of everything right everything in that seeing that you take a photo of it's gonna be taken from that one people now obviously if you talk about more advanced rendering and where we might want to do additional passes or even additional passes with different camera orientations for example we might need to render a depth buffer like for a shadow map or we might need to render like a dynamic cube map reflection or something like that that doesn't matter right we're not talking about those kind of cameras we're talking about our main same camera we have exactly one of those right so like every scenario and it's gonna be at a particular orientation every single object that we ran in our scene is gonna be from that actual like position in 3-space right so basically what I'm saying is that that transform of the camera right we want to move our objects by that transform now here's another cool question like the dis right we can see that if we move our camera back we want the object to get smaller right I mean it's not we don't want to actually change the scale of the object effectively that is what had that that's what happens if you're dealing with like a perspective projection right objects that are further away I rendered smaller but what's actually happening is what's moving the object further away so when we move the camera back the object it were basically moving the object further away when we move the camera forward we're moving the object closer so it looks like it's kind of inverted right what happens if we have our camera and we move the camera left well let's take a look if we have our camera let's say this is our kind of camera view over here right if we move this camera left right so I'm moving this whole this actual outer kind of rectangle left the cameras gonna end up here right so what's actually happened this cube this cube is effectively moved right because now the view is like this right so moving the camera left who's that right yeah what about what about rotation right so what if I kind of tilt the camera forward well this object's gonna move that way and it's gonna kind of change but the thing is the object isn't gonna rotate around itself right the object is gonna rotate around effectively like the origin of the world but not really right this is a bit difficult to think about and that's why also you know if the object was in the origin of the world and effectively yeah like the object would just rotate but if it if it's offset by some kind of position like so it's got its own own kind of position in the world and it's not centered around the origin effectively what's gonna happen is it's gonna like it might rotate like it's gonna rotate completely differently so I'm just gonna rotate about itself it's gonna actually move as well as kind of rotate but that's a more advanced topic we're really Durning to discuss how that actually works because it will just work if you do your maths properly and we'll see that in action in the future so effectively what I'm saying is that everything is kind of inverted right so whenever we move our camera left all the objects now seem move right we take the transform of all of the objects in our scene and we transform them so that they move the opposite way right so this kind of data that defines where the camera's transform is is a matrix right it's a transformation matrix and specifically we refer to it as the view matrix why because it's kind of like our view into the same some people call like the I matrix because it's like our eye looking into the same but I like calling it a view matrix which is also very popular term for it so this a view matrix what we do and that's the transform of the actual camera just by itself right if we just take the view matrix which again is a transform of where the camera is in 3d space that's what it is it's just the kind of the transform of the camera in 3d space so where is it the translation right so we're actually is it what kind of XYZ coordinate in our scene is the camera at and then the orientation like the rotation matrix that's essentially where the camera is actually oriented that's the location of the camera however what we want to do when we actually render from the cameras point of view and we need to transform our objects is we can't just transform them by the cameras matrix right by the cameras view matrix that doesn't make any sense because what we're supposed to do is move the objects not in the same kind of way right but in the opposite way so what we actually need to do is invert the matrix we need to take that cameras view matrix and just invert it right a few ways you could do that you can actually do that manually just by kind of negating things from the no in other words if I want to move my camera - let's just say X Y that is equal to five so five five five right it's my X players therefore my camera I can just do negative five five five right negative five negative 5 negative five I can kind of manually invert it but usually what you would do is you'll calculate the TRS transform rotation scale cameras user than have don't have scale so you don't have to worry about that translation times rotation and then you take that matrix and you invert it and that is actually kind of the transformation you will be applying to all of the objects in your scene and that's really as simple as it is so what I've talked about so far has just been the data right at that how we get the data what we do is we take the camera we position it somewhere in 3d space we give it an orientation right we get that matrix we construct like a transformation matrix out of those two things the position and the route and the rotation right the orientation and then we invert it and that matrix is what we take and we transform all of our objects by and now what about the field of view and the aspect ratio that's like how does that how is that even stored the way that's stored is in something called a projection matrix specifically for a 3d scene and for that field of view and aspect ratio it's something called a perspective matrix which basically defines a certain projection loosely like really it's a projection which objects that are further away have like the perspective effect right so they're smaller right we have that kind of vanishing point that kind of idea of just you know having like if I just move down here I'm just kind of having this kind of you know if you look like like a street and you look at something like this right where you know you have like a bunch of you might have like a bunch of buildings here or whatever here's a door like there's a door you kind of have that vanishing point where eventually everything kind of just goes into this kind of and I gotta stop doing that everything kind of just goes into this kind of vanishing point in the end right and that's kind of what you end up with so this is kind of a perspective projection there's also something called an orthographic projection usually those use for 2d rendering and in that kind of scenario objects that are further away don't actually get smaller so in other words if I am rendering a cube right and it looks like this and I render a cube that's like a lot like far away kind of behind this cube and a bit off to the right in a perspective projection it would look like this whereas in an orthographic projection there would be like the same size they look like this even though this one's a lot further away okay so we have different kind of projection matrices I mean that's stored as a matrix so this field of view and an aspect ratio kind of all this kind of stuff right that's stuff is stored inside a projection matrix specifically a perspective matrix and since we're using GLM we can just construct one of those by just saying GL em you know perspective right and that will create a perspective matrix for us and then we can actually I think there's a function called perspective of and then we can provide the field of you and aspect ratio and everything will kind of weekend I think we can even provide a width and height of our actual frame buffer and we'll kind of do the intervention itself essentially to come up with the aspect ratio and that it needs and all of that and that just returns to us a four by four matrix so a matte form okay now the cameras transform as I mentioned X Y Z and X Y Zed like ever take a transform you know being the position in the rotation that's also stored in the view matrix which is also a matte form and then obviously the transform of our object and 3d scene is also a matrix so that's TRS translation rotation scale all of that is stored in a matrix as well which is a transformation matrix and then finally we have the actual vertices of the tree of the 3d model now I am getting a bit ahead of myself because we haven't covered any of this really but we will in the future is providing some context so basically what we end up with is a bunch of matrices and in order to actually figure out where our where our objects should be on our like inside our screen right we need to essentially multiply all of those matrices together so what we do is we take the perspective matrix right so we have our projection matrix we multiply that with our view matrix right and then we multiply that with our model matrix which is also known as the world matrix which is essentially the matrix of our models so it's like kind of like this we have this cube that's the transformation matrix of the cube right and then that will also eventually be multiplied by our actual vertex positions okay and that is what gives us the full picture of where our actual model needs to be rendered in our screen and obviously if it lies outside of the screen it they'll just be clipped it'll be cold okay so that's what we end up with now this this order is GLM's order and also the order of multiplication that we see in GLSL shaders because they're column-major in DirectX this is the other way around so you basically you have your vertex position right you multiply that with the model matrix right you multiply that with the view matrix and your model you multiply that with the projection matrix okay so it's the other way around because it's a row major and obviously by the way M like four by four matrix multiplication matters may be in fact matrix multiplication order matters okay so make sure you do it in the right way and that's why I keep saying TRS because we want to multiply translation we want to do translation times rotation time scale to combine all of our matrices together doing them in reverse order gives you a different matrix okay so that's pretty much it that is that's all the data that you actually need right we've spent a lot of this episode actually talking about data which i think is good because that's what it boils down to right I want you guys to realize that we're building in game end and it's fairly complicated but at the end of the day we're just dealing with numbers these are just matrices right they will eventually make their way into the appropriate graphics rendering pipeline areas and that's what actually allows us to render graphics a particular place on the screen in this scenario okay so enough about data I think that makes sense hopefully that's enough for you guys to go on and actually make your own camera system that maybe deals with these kind of matrices and all that now let's talk about how the API works so we have this data fantastic you know my cube has a model matrix which is a transformation matrix that defines where it's going to be in the world you know it's obviously got a bunch of vertices so I've got my vertex positions I've got a camera which has a view matrix right great and the camera also has a Britisher matrix pH metrics defines like the field of view and kind of how it looks into the world view matrix defines where it is in the world and where it's looking right I've got that so in other words the part that actually belongs to the camera just to reiterate is the projection and the view okay model is actually on the object and vertex position is actually on like the mesh right so the projection view on the camera right I've got that what do I do with that data so essentially what we need to do at some point is do this whole multiplication that I've just mentioned right we have this projection times view x model times vertex position projection and view we can just do that multiplication in the camera it's you know that there are a lot of cases in which you will need for example just the camera position right not even the rotation but I just need to know where the position is that's important for when you're trying to calculate a vectors between like a particular pixel and the cameras like view position you know for things like lighting calculations but just for rendering a cube on the screen which is what we're doing right now you you don't actually need these to be separated you can just multiply it and that's it that's kind of your camera matrix draw and you'd probably call that something like VP or you know PV usually you'd call it V pages because that's kind of the UM whoops I meant to do this that's kind of the directx way of doing things but the view the view projection matrix is just projection x view in OpenGL so you have that and you can kind of just use that but the model matrix obviously comes from the object so if I render three objects in my scene that's gonna be three different model matrices right so I can't just kind of bake this in right I can do this like once per scene when I move my camera and I've decided that it's gonna be in this particular place once the frame is what I meant to say I can just bake this kind of I can just do this multiplication done right every single thing that I render is gonna be with this matrix Y because again I've entered my scene I've started in a new scene right the cameras not going to move throughout rendering a scene right when you take a photo no object moves right you kind of have the position of it as in the camera doesn't move while you take a photo right you've taken a photo that's it as a snapshot of the scene from that point of view so this stuff is static right doesn't change but then the model matrix is going to be the transform of each object that does change right and because that changes and because you know you have three cubes you render them at different positions right you can't kind of do this multiplication just then and there right it kind of needs to be done for each object and then finally this vertex position obviously is also kind of done you know for each object as well because obviously objects have unique vertices and they only belong belong to a kind of one mesh so anyway what I'm trying to say is that um we have this VP matrix that's fantastic but then we have to do this model matrix which comes from the actual object itself that's why the camera is part of the same right and that's why we submit it when we begin a scene because we're saying we're beginning a scene with this point of view now when we render the object does a few ways to do this trend this kind of transformation we could actually technically speaking do it in C++ right so we could say that we've got the VP matrix right let's just go down here and maybe over here where we've got some more space so we have the VP matrix we're going to multiply it with the model matrix right where do we do this so we could do this in c++ land but then what we would need to do is actually multiply it do this kind of multiplication for every single model right that's good and that's probably something you'll have to do unless you you know use batching or some kind of other you know instancing in which you probably have like an array of these matrices there's a few different ways to do it but it's essentially you have the opportunity to do this in c++ which means that you kind of do this multiplication and then into your shader which is where you do the matrix times vertex kind of multiplication right so this kind of last step is traditionally done this kind of last step is always done really in the vertex shader no that's what we've kind of been doing but just in a different way because that's essentially the result of this is what we output into GL position right which is inside our vertex shader okay the result of this whole multiplication so all of that stuff right we can do in like this MVP matrix that we end up with we basically take we can take that and we can multiply that by our vertex positions inside the actual vertex shader and that's our GL position so you can do that or you can do even this multiplication in the shader and then you kind of just end up with instead of this you know you just do VP times model times vertex right and I can't really tell you what the best thing to do is the obvious advantage of doing it in C++ means that you don't have to do it for every vertex so a vertex shader runs for every vertex so if you do it in your vertex shader it's going to use multiplication per vertex which may or may not be worse right however if you do in C++ it's kind of done per object that's why we also don't want to do like a projection times a few times model because the British and view stuff we can just rather do once in C++ for our entire scene and then keep using that data rather than having to actually kind of do that you know vertex which is what we would have to do if we were in the vertex shader so anyway um so between these two um it depends on your setup a lot of the time you need this model matrix anyway for example if you want to translate you know normals into like world space or something like that you know you'll need the rotation of the model right not that not that translation really but the rotation of the model so this matrix does come in handy as does this as does potentially the inverse of this there's a lot of different things that are important right so typically I end up doing something like this in my shader right where I have the V projection which is my camera I have the model which is the transform of my model right of my object and then I have obviously the vertex data which comes in in the attributes okay so that's kind of what we end up with so to summarize what we need to do is when we begin our scene right and now we're getting into actual code when we begin our scene we want to submit this view projection matrix and that's why we begin our scene with a camera as a parameter because we need to begin a scene with the camera again if we had an environment and like a light kind of setup or something like that like a bunch of lights we also submit those but we don't right now but we're gonna have a camera that's what we're talking about now so we can submit a camera which basically gives us that view projection matrix however when it comes time to render we might render different objects in our scene with completely different shaders right so it's not just a matter of saying okay when we begin our scene let's take our shader and then just submit the you know upload this view projection matrix into our shader has a uniform right that's what we're going to do but and by the way if you don't understand what uniforms are anything like that you should probably look into the shadows video in OpenGL I actually don't remember if I've done a proper video on uniforms but if I haven't it's gonna definitely come into the OpenGL series very soon but anyway so we need to wait to upload this into our shader however we don't actually know like all of the objects in our scene and what they're gonna be rendered with right like as in what I mean by that is what if we have a sphere that's rendered with one material and therefore uses one kind of you know shader shader number one and then we have a cube or like a background or something like that let's round it with a completely different shader you know what do we do well what actually needs to happen is that view projection matrix needs to be uploaded into both of those shaders right but we haven't we don't know that we're gonna submit this yet so we can't actually do that so what begins scene with the camera should actually do right is it's not going to upload any uniforms it's basically going to do one of two things it could just save a reference to the camera right for later or like you know if you were designing this in a different way and you had like some kind of uniform buffer to fill you could actually copy this view projection matrix into like a uniform buffer essentially just do like a man copy or something into a uniform buffer and then when you actually start rendering with a particular shader and theoretically your render would batch together objects with the same material by the way so with the same shader so that you don't have to kind of keep rebinding show to one shadow to shadow one change to some of that you just bunch adder one do all the objects with that then bind chair to render all the objects with bat shader so when you bind the shader for the first time you have that data inside your Emperor that's the camera that's the camera that belongs to the current scene so what you do is you take the view projection matrix from that and you actually upload it into the shader right as a uniform and that's done and then you render all the objects and then you bind it in different shader you do the upload of the of the view projection matrix and then you render all of the objects right and that kind of gets uploaded as a uniform as I mentioned okay and that's kind of what begin scene is supposed to do the responsibility is let's grab this camera let's either save the view projection data from it or we can actually save a reference to the actual camera usually it's better if you're really being optimal to just copy the data because usually this will be submitted into a like if you got a multi-threaded engine it will be submitted into a render submission queue taking a reference to the camera is very dangerous because before the render submission queue might get evaluated you might have have already changed the position of the camera so it could because you know typically a multi-threaded rendering is one frame behind so anyway there's there's kind of like specifics to all of this that you know it's kind of like an asterisk it might not work if you take a reference so it's usually generally better to at that point in time copy the data that you want and then kind of put that into basically your end a command queue buffer but anyway so that's what begins scene does right and then when we actually do per object rendering that's when we take the transformation matrix of that object which is the model matrix and upload that into the shader right so what I'm trying to kind of iterate a rewrite here is that when we begin a scene we have a whole bunch of actual shader uniforms that we need to set that are part of our renderer so things like camera things like the environment right things like the lights they're not gonna change on a per object basis but then we have a bunch of uniforms again another set of uniforms over here that are kind of part of our material so what is this object we're rendering right is it metal is it plastic how shiny is that how much should it reflect is it wood you know what color is it all that kind of information that is part of the material so we have material uniforms which are kind of per object or material because again we might render several objects with the same material and then we have kind of our renderer uniforms right we should basically you could say you're seeing uniforms or there's a bunch of different ways to call them right but they're kind of handled by the renderer whereas this is handled by the material so this is kind of jumping ahead into creating a whole material system and doing all the fun stuff that we'll be doing but hopefully you guys can kind of see the bigger picture than me just saying that cameras do this and that and that's it okay so to summarize what we need is a function called begin scene that takes in a camera as a parameter right it needs to get the view projection from the camera which is going to be the projection again which is you know there's four of an aspect ratio stuff and by the way it's it's more than four of an aspect ratio it's also the the minimum kind of call distance and the maximum call distance so we define basically clipping plans that are like near and far clipping planes so basically how close can an object be to the camera before it gets cold and how far away does an object have to be from the camera for it not to get rendered because as I said you know this kind of creates a frost like a view frustum which is kind of our camera and then we need to define this far plane which is this right and then we also need to define this kind of near plane so that's also what we need to do for an actual projection matrix but we have that view matrix is basically the inverse of the camera's transform we need to take that data we need to put it into our end row when we start a new scene right and then when something gets submitted which right now and Hazel as soon as it gets submitted it gets rendered we actually need to see what shader we're submitting that mesh or that vertex array with right we when we bind the shader for that we also need to upload in this case both the view projection and the actual model so that's kind of the architecture of this whole thing and n saying really does nothing right still kind of does nothing you could have it clear if you were copying data you could have a clear the data I don't know I wouldn't robably do that in any case you could just have like you could just keep track of whether it whether you're inside a scene or not so you could say like em you know scene or whatever equals false or naal or whatever and then that way if you try and render something that hasn't you haven't called begin scene or you call begin scene and you call begins in again without an scenic but like I said and make sure that you it's like a little protection thing that you do but anything will have stuff in the future obviously but not right now okay so that's kind of the idea of this whole camera system hopefully that makes sense to you hopefully this is enough information for you guys to try and figure this out on your own before I implement it in the next video but yeah this is like a whole kind of this is the whole basis for scenes and render isms although that's that's very it's all very exciting and you can see that it leads to a really really cool system in the future anyway hope you guys enjoy this video if you didn't hit that like button you can also help support the series by going patient on accomplice after Jerry you'll get access to source code earlier and videos a week earlier as I said in the future if you're watching this live on youtube right now publicly and you're not a patron you can just see the next episode immediately right now if you just go ahead and help support a series okay so as I said next time we're gonna actually dive into the C++ code and the share and everything like that and actually make this happen we're gonna design an orthographic camera not a perspective camera because currently we're kind of dealing with just 2d rendering and we could do a perspective camera I'm not sure but we will obviously eventually do that anywhere when we have a 3d scene and from there I'll probably want to maybe I don't know it will branch off into several things we might just talk about them when we actually get there and I'll try and kind of do something that you guys want to see but effectively we could continue on with 2d or 2d rendering and actually maybe make the camera controllable and also make it so that we could render multiple objects on the screen and then we could even make it to the game or something like that or we can just kind of do the base level work for that and then just move on straight to 3d depending on what you guys want I mean I'm probably more keen to do 3d to be honest because I love that stuff but we will probably make hazel more usable for actual QT Games more quickly if we did this first so it's kind of up to you guys to decide anyway in the next episode we'll implement the stuff make sure you have a go on your own before you actually look at the next episode I'll see you guys later good bye [Music]

Channel: The Cherno

Views: 24,330

Keywords: thecherno, thechernoproject, cherno, c++, programming, gamedev, game development, learn c++, c++ tutorial, game engine, how to make a game engine, game engine series, camera, what is a camera, game engine camera, renderer camera, rendering camera, graphics camera

Id: LfbqtmqxX04

Length: 38min 54sec (2334 seconds)

Published: Sun Jun 30 2019