• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

206 Neutral

About missionctrl

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

900 profile views
  1. Nope, you're right. Neither will work really. I was thinking you were just following circles. What makes it complicated is the inverted loops in all three axes. I think you may have to reverse your thinking. It sounds like the player input affects the position and then you try to simulate the banking/rotation. I worked on an airplane game and we did the opposite. The player input controlled the banking/rotation and the position was calculated from there. Is that possible in your game?
  2. It looks like UE is using an Euler controller for rotation, which is always going to have flipping issues. 3D rotations can't properly be described by only 3 values, but Euler angles make sense to our brains, especially for animating. I can think of two solutions: 1: Add a parent node located at the center of the circle, and just rotate that instead of trying to move AND rotate the orbiting node. 2: Make your "up vector" point to the center of rotation (ie, the center of the circle) instead of the world up.
  3. DX11 trying with ssao

    I don't see this very important bit of math to transform/scale your normals: vec3 normal = normalVS.xyz * 2.0 - 1.0; normal = normalize(normal); I pulled this from the tutorial you referenced (although, if you arent using Normal Maps, you might not need this)
  4. Really well-said Gian-Reto. Great breakdown. I feel that Macs' value comes from their convenience - a kind of easy-to-use black box computer (an appliance, as I believe Steve Jobs once called it). Conversely, PCs are generally more versatile and powerful. Based on that reasoning, I actually dislike Mac desktop computers and strongly prefer PC desktops. But for a laptop, where convenience is the main driving factor, I really prefer Mac. But you bring up a couple other really good points. Do you want to play games on this machine as well? If so, then obviously a PC will be better suited. Also, what platforms are you developing for? Mac and/or iOS? Then you will need a Mac. Windows? Then you will need a PC. Android/web/etc? Then either would work.
  5. Unless you're planning on making beefy AAA-quality 3D assets (which I assume you aren't), I think a strong 3D card is over-rated. If you are planning on using Unity or Unreal or something similar with a big, complicated 3D editor application, then you probably want to stay away from real low-end hardware. Otherwise, most modern GPUs (even low-end ones) are powerful enough for your needs. I use a Late-2013 MacBookPro for all of my work (I do web and mobile 3D development) and I love it. It is surprisingly powerful and lightweight. For whatever reason, Apple computers are generally looked-down upon in game-developer communities, but I would strongly recommend a MacBook as a laptop. You can probably get a refurb MacBookPro for around $1000. Or a new MacBookAir for the same price. I have a MacBookAir at home that I use for freelance/personal work and it works great for most stuff (although, I've never tried running the Unity editor or any heavy-duty 3D games). It's super-lightweight and portable. The only downside with the Air is cooling. It does well most of the time, but a long 8-hour work day involving significant GPU load is going to be a problem.
  6. Rotation matrix multiplication causes Gimbal lock

    Thanks for the link! Some interesting stuff. I think I see what's going on... it looks like changing the order performs the rotation around a locally-centered origin, but not in a local orientation. Maybe that's my fault for mis-using terminology a bit. When I say "local rotation" I mean "rotation around a local axis." Also, notice that he is using an "AngleAxis" function which should be exactly the same math as I just posted. In theory, I think if you are doing rotations in local space like this, order shouldn't matter. You don't NEED to do the Y rotation around the world's up vector, but it helps a lot if you want to maintain an up/down direction as a point of reference for the player (the best example of this is gravity which is in almost every game.) It makes it a lot easier for the player to maintain a sense of orientation.
  7. Rotation matrix multiplication causes Gimbal lock

    I've never heard of this. I guess it could work that way. I'm going to look into this because it sounds intriguing and would save a lot of computation in my code for local rotations. But rotation about an arbitrary axis is pretty complex. Maybe it simplifies way down if the axis isn't arbitrary? But anyway here's my C code for axis rotation: matrix rotationAboutAxis(float angle, vector axis) { float x2 = axis.x*axis.x; float y2 = axis.y*axis.y; float z2 = axis.z*axis.z; float a = (degToRad(angle))/2.0; float s = sinf(a); float c = cosf(a); float s2 = s*s; float sc = s*c; matrix rot = matrixIdentity(); rot[0][0] = 1-2*(y2+z2)*s2; rot[0][1] = 2*(axis.x*axis.y*s2+axis.z*sc); rot[0][2] = 2*(axis.x*axis.z*s2-axis.y*sc); rot[1][0] = 2*(axis.y*axis.x*s2-axis.z*sc); rot[1][1] = 1-2*(z2+x2)*s2; rot[1][2] = 2*(axis.y*axis.z*s2+axis.x*sc); rot[2][0] = 2*(axis.z*axis.x*s2+axis.y*sc); rot[2][1] = 2*(axis.z*axis.y*s2-axis.x*sc); rot[2][2] = 1-2*(x2+y2)*s2; return rot; }
  8. Rotation matrix multiplication causes Gimbal lock

    This is simply how a transform or rotation matrix works. The first row is the x (right) vector, the second row is the y (up) vector, and the third row is the z (forward) vector. At anytime, you can fetch these axes to perform local rotations. This is what I was referring to in my post. If I understand what the OP is trying to do, the issue here has nothing to do with Quaternions or Eulers or Gimbal or whatever. The issue is the axis around which rotations are performed. Perform y rotations as a regular world-space rotation. This will allow you to maintain a constant up direction. Perform the rest of the rotations in local space. Do these with a "rotationAboutAxis"-type function, where your axis parameter is the right or forward vector from your matrix. Something like this: //Y Rotation is a regular rotation yRotation = rotation(0, yAngle, 0); myMatrix = myMatrix * yRotation; //X and Z Rotations are done using the newly-transformed x and z axis from the matrix xRotation = axisAngleRotation(myMatrix[0], xAngle); myMatrix = myMatrix * xRotation; zRotation = axisAngleRotation(myMatrix[2], zAngle); myMatrix = myMatrix * zRotation;
  9. Rotation matrix multiplication causes Gimbal lock

    If you want to keep a constant up/down direction (ie gravity) then here's a simple trick I use: First, be sure to reset your rotation every frame. Then perform pitch (x) rotation first. Then do your roll (z) rotation in local space. And then perform the yaw (y-rotation) in world space.
  10. Computer Setup

    If I were building a new rig, I would focus on lots of RAM and a big HDD first and foremost. You want a decent GPU, but it doesn't need to be top of the line. I don't think the CPU should be much of a concern. My experience is skewed toward content creation as opposed to programming, hence my differing hardware concerns. Which brings up a good point - are you focusing on programming, game design, or game art? I think it would change your priorities.
  11. one man vs many men on a single tile

    I tend to agree with you. Lots of things on a single tile will likely become cumbersome and might require its own new interface to manage. I'd rather keep it simple and use adjacent tile combat.
  12. Turn-Based, SP, Combat-System Idea

    In general, I think it's a great start. The counter-switch mechanic sounds fun and the melee weapon range is a cool variation. I don't like the blood system because it's just another name for hit points and you said you don't want hit points. This does sound like it could be a very involved, tactical, and somewhat slow system, which means it should really be the central focus of the game rather than a secondary feature. It could almost be a purely turn based arena fighting game without any other game play.
  13. 3D Billboarding between two points

    OpenGL has built in functionality to draw points and lines as "billboards". Use glDrawElements with the GL_POINTS and GL_LINES mode
  14. Your thoughts on a Game Dev Podcast

    I would listen to this. I think it's a good idea. Have you done anything like this before?
  15. Help with Quaternion Based Mouse Movement (FPS Camera)

    No, Gimbal lock isn't an issue here. Gimbal lock is really only an issue when you are interpolating between keyframes. But you are explicitly setting a rotation every frame, so Gimbal lock never happens.
  • Advertisement