|
mikeschuld
|
 |
« on: 2006/10/22 20:35:11 » |
|
You know the drill 
|
|
|
|
« Last Edit: 2006/11/30 05:54:58 by mikeschuld »
|
Logged
|
|
|
|
|
Silver
|
 |
« Reply #1 on: 2006/10/26 01:52:26 » |
|
Hey.. First i wanna say, that i just love your tutorials, they are very nicely written and very easy to follow.  I've only tried your XNA tutorial for now, because that's what i'm mostly interested in, and i'm looking very much forward to the next tutorial.  I've been playing a bit with the HMInput class and the HMTexturedQuad, and i have a question.. Is it possible to make a cube out of those HMTexturedQuad objects, and just add them to the same node ? I've tried, using rotations, and position guessing mostly, but the problem i have is, that when i move around in the world, the sides are only visible from one side.. For example, the front of my cube, can only be seen from the front, and the right side only from the right.. Even when i'm inbetween the front and the right side, where it should both surfaces it only shows one.  I'm just curious if you have a suggestion, or maybe a quick sniplet on how to make a cube out of the HMTexturedQuad's.  Silver
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
 |
« Reply #2 on: 2006/10/26 02:10:42 » |
|
Well, I am putting up the skybox tutorial tonight (which is basically a list of 6 of the TexturedQuads) so you should get a good idea of how to get that all working from there. The same concept can be used to make a simple cube that doesn't follow the camera around
|
|
|
|
« Last Edit: 2006/10/26 02:57:23 by mikeschuld »
|
Logged
|
|
|
|
|
Silver
|
 |
« Reply #3 on: 2006/10/26 14:40:13 » |
|
I just completed the skybox tutorials, and i must say, that helped me a bit, as all the code for creating such a cube are in that class.  Wonderful job, and it is just as easy as the rest of the others.  Though i still don't get the math behind building the cube, i guess i have some more reading to do, can you suggest anything ? Also for building a cube, that doesn't follow the camera around, i guess that you don't need to calculate the offsets and such.  Again wonderful tutorial, and i almost cannot wait for the next one, what topic will you be covering there ? Silver
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
 |
« Reply #4 on: 2006/10/27 00:48:37 » |
|
The math behind the cube is fairly simple. Each texturedquad is by default a 1x1 square, which is why all of the offsets are of .5f. I started by just building the cube at its normal size and then added the scale in later. Offsetting the .5 * the scale alone with move all the 1x1 squares out to make the cube that size, and then each side is scaled the same way to get the edges to once again meet where they should. Play with the numbers a bit and you'll see what I mean. For the next tutorial, I am not entirely sure on what to put together. I have sprite billboarding working in my workspace project, but I want to save that for a bit later as it is only a shader and one more variable matrix added to the SetObjectSpecificParameters function. I will probably leave that part for the particle system tutorial set since they are closely related (as our particles will mostly be rendered as billboarded sprites). The major problem right now is that a lot of the lighting and other simple shader stuff we could add in right now depends on having a mesh or two, and the process of loading those and creating them is a HUGE pain in the ass without the Content Pipeline. I have a version of mesh loading working in my workspace as well, but I would rather not try to get into it in a tutorial format as I am going to soon delete that code anyway to make way for the CP. Lists of possibilities are: - More Shaders for things like bump mapping and parallax occlusion
- Simple particle engine based on billboarded textured quads
- Terrain mapping techniques (I wrote a HUGE paper on this two years ago for technical writing class, so it would be very long or a set of tutorials)
- Starting a theory section of tutorials
The theory tutorials would be in their own group and would discuss general game design/development theory and some more detailed concepts behind the 3d mathematics used in engines and shaders. What I really need to do is get the site moved over to the new layout, but that is always priortized behind getting the actual content out there so it still might be a bit. I think I'll stick up a vote and just let everyone decide what they would like to see next.
|
|
|
|
|
Logged
|
|
|
|
Darkside
Newbie
Offline
Posts: 1
The Beginnings of Game Development
|
 |
« Reply #5 on: 2006/11/08 05:11:12 » |
|
i would defintley like to see something more on terrain generation, especially if it's procedural and not madel based. Been tinkering arround with this for some time and would like to see some structured approach ideas.
Although Yes I agree it is a big subject, ta
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
 |
« Reply #6 on: 2006/11/08 16:41:14 » |
|
Terrain generation is one of my specialties  I had to do a project for my technical writing class about that. I ended up with about 5 different methods for generating terrains on the fly. A tutorial on this will have to wait until we throw together a general terrain component that will most likely just load heightmaps to start. Once the structures are in place though, extending them to be generated is not too much work.
|
|
|
|
|
Logged
|
|
|
|
|
Wasted
|
 |
« Reply #7 on: 2006/11/17 10:39:18 » |
|
First of all thank you for the great tutorials !! they are really handy.. I have a question about the 'mouse' input in XNA.
How can I reset the mouse pointer ? because now I can't look around when my mouse goes outside of the window boundries.. I just need sort of 'relative' movement I guess..
Atm I'am using the method as described in the tutorial for movement of the camera.
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
 |
« Reply #8 on: 2006/11/17 23:46:41 » |
|
The simplest way right now is to just pick a coordinate on the screen that is withing your game window (this is easiest for fullscreen since the whole screen is in the game) and do a Mouse.SetPosition to that spot every frame so the mouse never actually leaves the window. It will still catch the initial movement and update the camera correctly, but also set the mouse somewhere it can move from each frame
|
|
|
|
|
Logged
|
|
|
|
|
scjohnno
|
 |
« Reply #9 on: 2006/11/18 08:18:36 » |
|
I seem to be getting rotations around the Z axis of my camera, even when I've only mapped the mouse to rotate it around the X and Y axes. I used the following code inside HMDemo: HMCameraManager.ActiveCamera.Rotate( new Vector3(0, 1, 0), mouseMove.X * 0.01f); HMCameraManager.ActiveCamera.Rotate( new Vector3(1, 0, 0), mouseMove.Y * 0.01f); ...which handles the X and Y axes just fine. But I noticed that if I move the mouse diagonally so that I get a rotation around both the X and Y axes every frame, the camera rotates around the Z axis as well. The result is that the camera's view slowly turns upside down, which is problematic. The effect is very obvious when you move the mouse around in a circle. The HMCamera.Rotate() function is the same as in the tutorial, and this happens whether I reset the mouse's position every frame or not. Am I missing something simple here, or is it a limitation of the method used?
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
 |
« Reply #10 on: 2006/11/18 09:59:56 » |
|
Well, the X and Y rotations are applied around the camera axis itself, and are not actually done in terms of any global axis
e.x.
If the camera is rotated to 1/2 radian around the x axis, the next y rotation that would occur is not going to be around the same original world based axis that the camera was when the x rotation was done. This is because to the camera, the y axis is now 1/2 radian away from where it used to be.
This is how the rotations in the system work, and allow for a complete free range of motion at any angle (as opposed to the gimbal lock that axis based systems give). This might be what is causing the misconception.
|
|
|
|
|
Logged
|
|
|
|
|
matb
|
 |
« Reply #11 on: 2006/12/02 05:43:50 » |
|
Well, the X and Y rotations are applied around the camera axis itself, and are not actually done in terms of any global axis
e.x.
If the camera is rotated to 1/2 radian around the x axis, the next y rotation that would occur is not going to be around the same original world based axis that the camera was when the x rotation was done. This is because to the camera, the y axis is now 1/2 radian away from where it used to be.
This is how the rotations in the system work, and allow for a complete free range of motion at any angle (as opposed to the gimbal lock that axis based systems give). This might be what is causing the misconception.
But this is usually a behaviour not wanted in a game. How would you program an simple FPS Camera (which never rolls) with Quaternations?
|
|
|
|
|
Logged
|
|
|
|
|
MicahN
|
 |
« Reply #12 on: 2006/12/02 09:15:21 » |
|
On the same vain as matb's post.
In Tutorial 4, the line...
"We will need to be able to rotate, revolve, and translate the position of the camera. With these three we can use rotate+translate for first person cameras and revolve+translate for third person. Here are the three functions in their full glory"
confuses me.
So, I am wanting to do to 3rd person perspective, and so am I to use the revolve and tanslate functions or revolve Plus translate functions.
Anyway, maybe a quick example of how to correctly set up HMCamera in a Third Person scenario.
I am getting close, for example going forwards and back looks good, but when I go left or right the camera spins around my model. So, I guess my problem is keeping the model position and the camera position the same or something.
bottom-line, I am learning and do better at learning by example.
thanx
Micah
|
|
|
|
|
Logged
|
|
|
|
|
Chr0n1x
|
 |
« Reply #13 on: 2006/12/02 14:34:29 » |
|
When you are working on a 3rd person game, when the mouse is moved, you would be revolving the camera, but you would also be rotating the model to face the same way. So when the mouse moves, besides revolving the camera, you also rotate the avatar on the Y axis at the same rate, so that way the camera matches the facing of the avatar.
|
|
|
|
|
Logged
|
|
|
|
|
mikeschuld
|
 |
« Reply #14 on: 2006/12/03 04:59:42 » |
|
Also, the camera would be updated to always be centered around the player mesh (the same way we centered the skybox around the camera, only backwards)
|
|
|
|
|
Logged
|
|
|
|
|