Reputation: 592 Enlightened
- Active Posts:
- 1,323 (1.36 per day)
- 24-April 12
- Profile Views:
- Last Active:
- Yesterday, 09:56 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 23 Dec 2014My goal over the next two weeks is to start a YouTube channel and produce videos that for the most part covers exactly this! The 3 videos I have currently planned are vectors (about 80% complete), matrices (haven't started on it yet), and gimbal lock (which is getting a lot closer to what you are trying to do here). None of that completely covers what you are attempting. However, between the 3 it should give you a lot of the info you need. It sounds like you are not comfortable with vectors and matrices and that that is at the core of this problem. I have an actual XNA program that demonstrates gimbal lock and shows how to properly code rotations avoiding the use of pitch, yaw, and roll. Pitch, yaw, and roll basically don't work. They are the cause of gimbal lock and uncontrollable rotations. You should never use them to store rotational information, although it is okay to initially feed the starting point using them.
The XNA code, which I will be using in the future video, is complete and published on my website under the heading "Gimbal Lock". It is the entire VS project complete with the 3D arrow model I used and everything. You can look over that code and get some ideas.
I would also suggest looking over my Matrices in Motion tutorial. I think that one is getting very close to what you are trying to do. That one is basically an automobile simulator where you drive around a little "car". It has been a year or so since I have even looked at that code, but I think it uses velocity and acceleration in the way you are trying to use it although it is constricted to a 2D ground plane. In fact, it may not be what you're looking for because it is more "car like" motion than "space ship like" motion. But its a pretty good example of using matrices for not only motion but camera control as well.
For something a bit more like an airplane or in this case a spaceship, you may want to look at my "the Skybox" tutorial.
Again, these are all complete projects for downloads. Due to time constraints and having so much ground to cover, I stopped doing detailed tutorials after doing the Holodeck tutorial and started just writing example programs and commenting just about every single line of code so that someone studying the code could easily understand it.
My knowledge has been growing over the years as I put together these tutorials and my approach has probably changed slightly from the time I wrote the Holodeck tutorial and the later tutorials like the Gimbal Lock example. But all those would be good to look at. I might do things a little differently if I redid the Holodeck tutorial, maybe. But the others have held up pretty well to my increasing knowledge of the subject over the years.
But to answer your question more directly, as a physics question:
Velocity in space is the speed at which you change position over a given period of time. It is usually measured in Meters per Second, which is the number of meters your position changes in one second. It should probably be represented by a vector/arrow which points in the direction of movement and has a length of the number of meters the position changes in one second. Or actually, you want this to be per frame rather than per second; so you'll want to either start out in meters per frame or convert from meters per second to meters per frame.
It should be noted that when you have velocity in space, it is eternal. You will continue to move in that direction and at that speed for all of eternity until something changes (such as you hit a planet or something that stops you). So, the velocity vector needs to be added to the position every frame.
You want to store all of this in matrices as much as possible. What you most certainly do not want to do is store the rotation as pitch, yaw, and roll. You could store this with a vector, but the problem is that with a vector, there is no way to know how it is rotated around the vector itself. This is not so much a problem with a car moving in 2D in a 3D world, but with planes and spaceships this is going to be a problem.
So, a better solution is to use a matrix and let the matrix store the position and rotation/orientation. Then you can translate(change position) of that matrix each frame with the velocity vector.
At this point, we have no way to actually control the ship. That's where the engines come in. The engines provide acceleration in a given direction. Acceleration is measured in change of velocity. A velocity is meters per frame and that change happens over time and in this case is a single frame. So, the acceleration is measured in meters per frame each frame. That could be restated as meters per frame squared.
The engine, or acceleration, has a direction it pushes in. So, it can also be represented as a vector/arrow. It's direction is the direction of the engine push and its length/amount is the increase in velocity during that frame.
So, you are really adding the velocity vector to the position vector. But you are controlling the velocity vector with the acceleration vector.
Note that if the velocity vector and acceleration vector are pointed in the same direction, you will increase velocity. If they are pointed in exact opposite directions, you will slow down. And any other direction will change the direction you are moving. I did a very detailed 2D example of this which is also on the website where I used multiple engines which even caused the ship to rotate rather than simply move forward. It's the same thing in 3D just with the complication of another dimension. It's rough enough to understand in 2D the first go around.
You want to keep this information stored in the ship's world matrix as much as possible. You will be required to have this information when you draw the model by sending it to the graphics card. It will be the first thing the shader that is drawing the ship wants to know from you. For that reason, and to avoid gimbal lock, I would do my best to keep this information in the ship's world matrix at all times. My code should give examples of that although I admit I've been getting better at this over time and I haven't looked at some of that code in over a year.
So, position and orientation should be stored in a world matrix. The velocity vector could be stored in a velocity matrix which would also store rotational velocity, or spin. (I'm not sure if my examples do that.) Then the acceleration that changes the velocity could be a new vector for direction and yaw, pitch, and roll for describing the change in spin if you want; you are probably going to immediately convert that to a matrix.
So, at that point, you would first apply the acceleration to the velocity which would be:
Matrix Velocity; Matrix Acceleration = Matrix.Translation(AccelerationVector) * Matrix.CreateFromYawPitchRoll(NumberOfRadiansOfYawToSpeedUp, 0f, 0f); Velocity = Velocity * Acceleration; //This combines the two matrices and works more like addition than multiplication.
The next "level" would be to allow the engine(acceleration source) to be turned off and on. Then, you could take it even to the next level and control the length of the acceleration vector with a throttle percentage of full power and possibly the ability to change the angle the engine faces.
Then, whether the Acceleration has changed or not, you need to apply the Velocity matrix to the position, in the world matrix.
Matrix ShipsWorldMatrix; ShipsWorldMatrix = ShipsWorldMatrix * Velocity; //Again, this combines and acts more like addition than multiplication.
I'm writing this off the top of my head, so it may be a bit buggy. Potential problems I see immediately is that the order you multiply matrices in matters. You can mess around with what happens when you switch what's on each side of the multiplication sign and experiment with *= as well. Also, all rotations must happen at the origin. You have to move objects to the origin, rotate them, then move them back. Otherwise, they will orbit the origin instead of rotate on their local axis. I don't think I took that into account in my example code here.
But you should be able to look at my tutorials to see it done right.
Adding rotational velocity by using a velocity matrix is an idea I had while writing this post. So, that's probably not covered in my examples and may be a little buggy in the example here. I would have to write some code to make sure I had everything taken into account there. But my space ship tutorial in "the Skybox" has the type of movement you are talking about even if it does not store velocity as a matrix.
The longer I do 3D game programming, the more strongly I feel about always using matrices.
Hope that helps. Let me know if you have further questions.
Posted 22 Dec 2014If the art work is "not all that", you may want to consider partnering with an artist. There are several ways to go about that. You could check for local art schools (most colleges have an art department full of hopeful artists) and post for an artist to work on a game project. I even knew one guy that needed art work for a non-game project he was working on and he called up his favorite comic book artist as a complete stranger and said, "Would you draw this for me?" I think he paid the guy like $1,000 for basically one piece of art and he actually did it. Artists need to eat too. If you're willing to pay for it, even a big name artist might work for you. If the game is truly a lot of fun and just needs some good art work, you may find an artist willing to go 50/50 with you on the profits and work for free. But you would have to sell them on the idea that the game is actually a lot of fun. The most difficult part of that is finishing the game and having a product that you CAN sell. Then there's the nebulous "fun factor", but if you can build a case that the game can make some substantial money and the artist believes that the game is a lot of fun and likely to do well, they might be willing to join you for a share of the profits.
The hardest part is producing actual finished games (and it sounds like you have that at least) that you can demo to people and prove how fun it is. Everybody wants to be part of a success story, including artists.
Posted 21 Dec 2014You said that the error is "assembly code" of line 5. That line doesn't do anything except branch based on the condition of equality between a string ("mask") and an attribute of the hit object. The hit object is defined in the code I mentioned. If it is defined improperly, it is reasonable to assume it would cause a problem later when an attempt to use it occurs. Although, you would think it would give a more graceful error message.
Outside of that, it sounds like a bug in Unity and you need to completely uninstall Unity and reinstall it. I would thoroughly examine line 3 for its effect on line 5 first though.
Posted 20 Dec 2014On line 03, how does this make sense?
Shouldn't the second parameter be a direction? How does a zero "vector" make sense?
I'm looking at the Unity docs and the example has:
RaycastHit2D hit = Physics2D.Raycast(transform.position, -Vector2.up);
Although that's a bit weird in itself because why would you ever use a negative up vector? Wouldn't Vector2.down suffice and be more clear?
I have not used this before; so I don't really know how this works, but just looking at the doc it doesn't seem to match up with what you've got going on there. Plus, there's not really any such thing as a zero vector although mathematicians and programmers may argue with me on that one. Zero vectors are basically undefined.
I was just going over this yesterday. When a vector is zero'ed, it ceases to exist. A zero vector is basically the absence of a vector. You have to be careful when working with zero vectors because the results are likely undefined. For example, what is the length/magnitude of a zero'ed vector? Because it doesn't exist, the question is like "What is the sound of one hand clapping?" The problem is in the question. If you do the math, the length of a zero vector involves a divide by zero, which is also undefined and will give an error.
You almost never want a zero vector for anything. Zero vectors are generally bad. I'm not even completely sure why they were included in the language. I'm sure there's an occasion where they serve a purpose, but I would avoid them as much as possible.
But here, the parameter is a direction. A zero vector is never a direction. It's not anything. It's the absence of something, or the absence of a vector.
Anyway, that looks wrong to me.
But then the next thing is that ScreenToWorldPoint returns a Vector3 according to the doc. I don't see anything about returning a Vector2. There seems to be serious confusion here as to whether we're working in 2D or 3D. Can you not just use the mouse position? I could be wrong on that, since I've never done this, but that looks wrong to me.
Posted 17 Dec 2014You always want to send as little across the network as rarely as you possibly can. If you can send it less often, or better yet not at all, that's the goal. Once you reach that point, you have no choice but sending the data when required.
I'm not sure there's a magic formula. It's probably dependent on your exact program and the way you're doing things. And you may be able to find a better way than anyone has ever done it before.
- 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: