Reputation: 602 Enlightened
- Active Posts:
- 1,340 (1.33 per day)
- 24-April 12
- Profile Views:
- Last Active:
- Yesterday, 06:53 PM
- OS Preference:
- Favorite Browser:
- Internet Explorer
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
- Expert In:
- Game Programming, XNA
Posts I've Made
Posted 28 Jan 2015When I clicked on the link I got the following error:
ERROR — This project has been removed by the author. It may return later.
Posted 27 Jan 2015Oh. Also, with Unity the concept of the GameObject and its transform is key to understanding the whole thing. You'll never understand Unity until you get that concept. Everything is designed to be a GameObject in Unity. It's transform positions it and rotates it in your scene. It does not necessarily have to draw anything to exist.
And game objects in Unity are expected to have children. In fact, your Unity scene will likely be a big tree of GameObject branches with children and grand children and great grand children and so forth. This not only organizes all your stuff, but builds relationships between them.
All children are attached to their parents. So, when you move a parent in the scene, all of it's children will likewise move. Children move independently of parents and do not cause their parents to move. So, if you have a player model, you can attach a sword to that player model's hand by making the sword a child of the player model GameObject and positioning it relative to the player model's hand. Then when you move the player model, the sword will stay attached. But you can still disconnect the sword or move it to the other hand or something.
GameObjects and these parent/child relationships is key to understanding how Unity works. Unity will create a lot of pre-made GameObjects for you which will help you get started, but you need to start creating your own and not using the premade ones in order to understand Unity.
Posted 27 Jan 2015That's really cool that you're getting into game design.
Like everyone said, there is just no substitute for practice.
If you want to use Unity, I might recommend YouTube videos. There's a lot of good tutorials teaching you how to do stuff in Unity on YouTube. I was not overly impressed with any of the Unity books and I have most of them. They are better than nothing, but let's just say I'm not impressed.
There's a whole lot to learn when we're talking about 3D game programming and a lot of it is going to be completely alien to you as you begin. So, it is extremely difficult to learn it without a good instructor. There's just a lot to it and you could spend a decade or more learning it. With the right instruction you should be able to cut that time down dramatically.
Without that, you pretty much just have to dive in somewhere, really anywhere, and just get started learning it piece by piece knowing that it's not going to all come together and make sense until you have the majority of the puzzle put together. It's like doing a jigsaw puzzle with no picture to guide you on what it is you are putting together. The only way to do it is to just take one piece and study it until you know how it works and can start finding other pieces to attach to it. At some point you may want to take another random piece and see what you can make join up with that. Eventually, you'll have a bunch of completely separate sections. As these sections become more and more complete they will start joining up with one another. Then eventually you'll start seeing the big picture and things will really start coming together at that point. But it all only happens by joining one small piece together with another.
There are really a few different skills involved. A lot of it boils down to art creation and code creation. Unity does most of the code for you as part of its engine. Still, it is so open ended that you end up needing to script a lot of stuff that is still relatively foundational. The bad part of that is that it may be more difficult, or impossible, to understand how it works because so much of what is happening is done by Unity for you and therefore is hidden from your view. If no one explains what's going on under the hood, you may misunderstand it or have no way to understand it. That's the biggest down side to using an engine. YouTube may help significantly with that. At some point you may want to delve super deep into it and do it in OpenGL or DirectX and then you'll start really understanding it at the deepest level, but this is even more difficult to learn and harder to find good instruction in.
So, Unity would be inclined to get you into the art end of things. However, with it's content store, you can buy almost enough models and art work to put together a game. You can also buy code as well. This is kind of good and kind of bad at the same time. The good is that if you need something now in order to learn something totally unrelated, you can buy it. For example, if you are trying to understand model animation, you don't have to first learn how to use a modeling program, learn digital sculpting, and learn animation in your modeling tool; you can theoretically just buy a model and go directly into using it to learn animation in Unity in Mechanim.
The reality is not all that. Most of the models in the store are not rigged and setup for animation properly, which means you still have to do a lot yourself and then that means you are doing a lot of what you were trying to avoid in order to get straight to learning something else unrelated. And you paid good money for this model.
The bad is that all of this can become a crutch where you're never really learning much because you're buying all the pieces of your game and merely assembling them like in a level editor. So, you aren't learning much.
Anyway, the important thing is to always every week be working on learning something you did not know the week before. Eventually, those weeks will add up and you'll know a whole lot.
And ask questions on this and other forums! There are people willing to help who have probably already solved your particular problem.
Posted 27 Jan 2015Since you left the question pretty open ended, maybe I should explain the View Matrix as well.
So, as yothsoggoth alluded to, your object will have the exact coordinates it had in your modeling program. You need a world matrix to position it in the scene differently than how it was positioned when you created it in the modeling program because the data in the import file is exactly what it was when you created it in the modeling program. Only a world, or transformation, matrix will change that.
The Projection matrix alone will be enough to draw the model on the screen as long it is withing the pyramid or bounding box of the projection. Basically, every single vertex position will be modified by the projection matrix to output a screen pixel position so that it can be drawn on the screen.
Everything, in your 3D game world is drawn with triangles (except of course line or point primitives). So, everything is actually three 3D points and the rasterizer fills in the pixels between those three points to draw a triangle. Your 3D object is just a whole lot of triangles arranged to look like something. But it all boils down to drawing triangles in 3D.
Each corner, or vertex, of the triangle will be defined and the insides will be shaded in to draw the triangle (unless its in wireframe mode and then you just draw lines between the 3 points).
So, the shader is fed all 3 points of the triangle one at a time. This is submitted as a 1 by 4 or 4 by 1 matrix (generally thought of as a 4D vector, but that's not what it really is). That is multiplied by the 4 by 4 projection matrix and the result is the exact 2D coordinate of that point on the backbuffer. (The backbuffer is the area of memory that represents your computer screen and what goes into the backbuffer is what is drawn on the screen when it becomes the frontbuffer and is then drawn on the actual physical screen).
The three points of the triangle will be mapped from 3D into 2D points on the computer screen. Then the rasterizer actually draws the triangle between the in 2D, not 3D. If it's wire frame the rasterizer can just simply draw 2D lines between the 2D points. The perspective projection matrix will have done all the necessary math to simulate 3D perspective in the 2D drawing by moving the points of the triangle according to their Z depth as described in the previous post.
So, as long as your model in the modeling program was created within the view box/pyramid of the projection matrix it will be drawn on the screen and everything is wonderful.
If it wasn't, then you need a world matrix to positions the object in a new position and orientation that puts it in front of the camera. We can't move this camera. So, you're stuck with that fact.
That's where the view matrix comes in. We can't move the camera. You just can't mathematically do it. For it to work it has to be looking straight down the Z axis (or one fixed axis) and at the origin. But we want to have the camera move around the scene and look in different directions.
The view matrix works the same as a world matrix but backwards. Like the world matrix, it holds the position and orientation (rotation) of the object it represents, which in this case is the camera. But the way it works is that it moves the entire 3D world around the camera. You think it's moving the camera, but it's not. It can't. But what it can do is reposition everything in the 3D world to make it appear as if the camera moved. This requires everything to be moved the exact same way in the opposite direction. If you want the camera to look left, you have to move everything in the scene right. If you want the camera to rotate upward you need rotate everything in the scene by the exact same amount downward. The end result is that the player will be tricked into believing the camera has moved. It didn't. The entire 3D world did.
This requires the view matrix to be an inverse matrix from a world matrix. You can load it up just like a world matrix and then invert it to get a working view matrix. But there is a LookAt function/method in pretty much every environment that will load it up for you with a camera position, look towards position, and up direction. The up direction is confusing at first, but it's the direction "above the camera". If the camera is rotated so that the area "above" it is to the right then the up vector needs to point right. Unless, you are rolling over, you can cheat and just always feed it a straight up vector and this will work until you try and roll the camera over, which often is not needed.
Anyway, your original coordinates of your model are exactly as created in the modeling program. Combining that with the object's world matrix by multiplying will position the object in the scene. Multiplying it by the view matrix will simulate camera movement by moving the entire scene in the opposite position or rotation. Multiplying it by the projection matrix will change it into 2D screen coordinates.
The first thing your shader is going to want is for the object's world matrix, the view matrix, and the projection matrix to all be multiplied together. This gives you a WVP matrix all in one matrix that contains all those calculations combined into a single matrix. Then that single matrix can be applied to every single vertex of the model to position every single vertex on the 2D screen for drawing. As that happens the rasterizer shades in the triangles between the 3 corner points and you have a 2D drawing that appears to be 3D on your screen.
(Actually, some lighting calculations are necessary to make it look 3D, which we didn't cover here. The actual results of this would be a silhouette of the object if the object is of uniform color. A textured object probably would not have this problem but a solid blue object would appear to be a blue 2D silhouette of the 3D object without some lighting in the shader. But that's the basic concept anyway.)
Posted 27 Jan 2015If you are using DirectX or OpenGL, DX definately has this built in and I'm sure OpenGL does as well.
How deep do you want to go down this rabbit hole? ;-)
In short, you are probably talking about 3D Perspective projection as opposed to Orthographic projection. Orthographic projection is actually pretty easy. Basically, you put a box in your 3D world that represents the viewable area.
The near plane of the box is basically the exact same dimensions as your computer screen and you are projecting everything inside the box within your 3D imaginary world on to the near plane. What is projected on to the near plane will be written directly to the back buffer which will be written to the computer screen and actually seen.
The far plane is the far side of the box. This is an axis aligned box and you have to be looking straight down the Z axis (or some other fixed axis) for this to work. Basically, at that point you throw away the Z value of all objects and everything is then compressed onto the near plane which is at Z=0. (Actually, it could be at Z=1 or any value since we threw away the Z value and everything is at the same X and Y regardless of Z.) Z values can actually be retained to determine which object draws on top of the others. But otherwise you just stop using the Z value and everything is projected into 2D space. The box is there largely because you can't draw wider or taller than your computer screen and expect it to be on the computer screen. The near and far planes limit what can be drawn because the Z depth is theoretically infinite and it helps to stop somewhere. In older games on older computers it helped to limit this substantially because it meant less work for the graphics card if you can tell it not to worry about object further away than the far plane. They often used fog as an effect to mask the fact that things beyond the far plane were not drawn.
Things behind the near plane are also outside of the box and not drawn. There are times when pushing the near plane out further helps. I generally set it close to near zero. I've never actually tried setting it to zero to see what happens. I think everything converges to an infinite point at zero and it would probably blow up. I'll have to try it some time. Until then, I'd use a value like 0.2 for the near plane.
Perspective projection simulates perspective making objects further away appear to be smaller and moving them inwards towards the center line. But it's basically the same concept but slightly more complex.
Here we use a four sided pyramid with the tip cut off to represent our near plane at the Z=0 place. (Actually, I think Z=0 converges everything into one infinite point and thus your near plane needs to be some infinitesimal point in front of that in order to be a rectangle and not a single point.) Our pyramid is basically still the box we had before except the far plane is so much bigger than the near plane that it turns into a pyramid. You also can't just do away with the Z value to get perspective. Things have to be made smaller and moved towards the center as the are closer to the far plane.
I haven't worked through all the math on this exactly. Many years ago I went through a lot of the math without using matrices. Matrices do basically the same thing.
I want to say that you divide the X and Y values by the Z value, throw away the Z value, or use it to determine overlapping and homogeneous coordinates.
So, something at point 4,6,2 gets divided by 2 and becomes 2,3,1 where 1 is now the homogeneous coordinate which will always be 1 but if you push it back out into space by multiplying the coordinates it will eventually give you same original point. It basically represents a line between the point where the homogeneous coordinates are 1 and where they are 2. The line is infinite in both directions and basically just passes through those two points. Notice that this line has perspective!
Notice that this pulls things towards the center the further they are away. 4,6,2 gets divided by 2 and becomes 2,3,1 but 4,6,1 is divided by 1 to give you 4,6,1. That has the same width and height, but the one closer doesn't change while the one further away becomes less wide and tall and moves positionally towards the center.
Your homogeneous coordinate of 2,3,1 throws away the 1 value and is X=2, Y=3 which are 2D screen coordinates where that object can be drawn.
When you have multiple 3D coordinates they will all be translated at different rates according to their distance from the near plane. And so things will appear to have perspective even if they are two points on the same object.
A lot of the explanations seem to very much over-complicate this.
The next step is to get this into a matrix.
But honestly, I've been doing 3D game programming stuff for years in XNA, and in DirectX for the past year, and I never have needed to know this. Pretty much all APIs and frameworks have a function that will create a Perspective Projection Matrix for you. You just feed it the field of view, screen aspect ratio, the near plane distance, and far plane distance. This gives an example of how DirectX does it.
Remember that this camera can't do anything other than look straight down the Z axis because of what it is and how it works. Basically, the function creates the view pyramid and loads it into a matrix. It wants the distance of the near plane along the Z axis to know where to make the near plane side of the box/pyramid. It needs the Z value of the far plane to know where to put the bottom of the pyramid as the far plane. Nothing will be drawn that is outside of the pyramid.
The field of view and aspect ratio are used to calculate a near plane that has a height and width that will map to your computer screen with the correct field of view and screen height to width ratio. The aspect ratio is necessary to create a near plane that has the same height and width ratio to map directly to your computer screen. The FOV is typically about 45 to 55 degrees for realism. It will distort things outside of roughly that range and look un-natural but may be appropriate for some applications. It basically controls the angular width of the pyramid and the aspect ratio can then give you the height.
Actually, as I think about it, I realize that the near plane will have the same aspect ratio as the screen, but is not necessarily positioned at Z=1 or Z=0. So, it's size will not match the screen or back buffer. I think you need to multiply it's height and width as well as everything projected on it by a conversion factor. The conversation factor should resize the results to perfectly match the backbuffer/screen height and width one for one. I imagine a projection matrix has that built into it as well since a projection matrix contains all the math necessary to project everything in the view pyramid on to the backbuffer/screen in one matrix.
But basically, all you need to do is use the function or method to create a perspective projection matrix for you. As long as you know what the input parameters mean, that's all you ever need to know.
A view matrix is necessary to simulate camera movement and get it away from just only looking straight down the z axis and standing on the origin.
Oh. Also, I briefly cover this in my matrix video I am just about to record for my YouTube channel. That will cover matrices and briefly describe what's in a projection matrix and kind of go over some of what I've just explained. The YouTube channel is VirtuallyProgramming.com and I hope to have this video posted soon. I've been putting off recording it for a couple of weeks now. Maybe this will give me some incentive to get it done this week.
- Member Title:
- Here to help.
- Age Unknown
- Birthday Unknown
- Dallas, Texas, US of A, Planet Earth, Sol System, Milky Way Galaxy
- Rock music composition and performance, Grunge Music, Bebop (think Thelonios Monk), Swing (think Cab Calloway), Gaming, Astronomy, RPGs, Scuba, Sail Boats, Furniture Building, Cooking, Rocky Patel Cigars, Character Driven Dramas(like HBO's Deadwood), Story Telling (plot writing), Linguistics, Economics, Target Shooting, Electronics (don't know as much as I'd like to), all aspects of 3D game programing including music, physics, modeling, texturing, annimation, probability, AI, lighting, etc., Texas Holdem' Poker, Learning, Dogs, the love of my life (my pit bull), guns (especially 19th century black powder), putting make-up on ogres, etc.
- Programming Languages:
- C, C++, C#, Visual Basic, Java, Pascal, T-SQL, HTML, FoxPro, ASP.Net(very little), Assembler, Machine Code(conceptually anyway)
- Website URL: