• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Kuroyume0161

Members
  • Content count

    60
  • Joined

  • Last visited

Community Reputation

100 Neutral

About Kuroyume0161

  • Rank
    Member
  1. See what I mean? Fix it or shut down.
  2. I wouldn't even try a non-convex quad with the transform being built. Actually, even a triangle with an extra point along one of the sides (to fake a quad) fails the math (which I'll show in code shortly). Therefore the quad must be 'truly' convex (have internal angles less than 180d). A test triangle was working but no longer after some observational corrections so I'm stuck at trying to do the homography from unit square to triangle which might not be possible (ack!). There will be two directions for the code: aspect-conserving and not. The latter is where the unit-square to quad applies the transformation to associated geometry - which will skew and shear it. The former will simply make sure that the geometry fits within the bounds of the quad without any homography transformation. This will be the case for circular geometries by default to avoid egg-shaped results that would occur in certain transformations. Triangles have befuddled me here though. One solution, albeit rather contrived, is to simply truncate the triangle (which yields a quad) but this leaves the remaining area empty of geometry. And the code: <code>// 2D Matrix for doing collineation between quad and unit-square class Matrix2D { public: Real m0; Real m1; Real m3; Real m4; Real m5; Real m7; Real m12; Real m13; Real m15; Matrix2D() { // Unit Matrix m0 = 1.0f; m1 = 0.0f; m3 = 0.0f; m4 = 0.0f; m5 = 1.0f; m7 = 0.0f; m12 = 0.0f; m13 = 0.0f; m15 = 1.0f; } // Copy this matrix to matrix M void CopyTo(Matrix2D& M) { M.m0 = m0; M.m1 = m1; M.m3 = m3; M.m4 = m4; M.m5 = m5; M.m7 = m7; M.m12 = m12; M.m13 = m13; M.m15 = m15; } // Transform point p by matrix M: q = p*M friend const Vector operator * (const Vector& p, const Matrix2D& M) { Real d = p.x*M.m3 + p.z*M.m7 + M.m15; if (d) d = 1.0f/d; else return Vector(0.0f); Vector q; q.x = (p.x*M.m0 + p.z*M.m4 + M.m12) * d; q.z = (p.x*M.m1 + p.z*M.m5 + M.m13) * d; q.y = p.y; return q; } }; // Calculate matrix for unit-square to quad mapping // - vertices - square->quad transform //*---------------------------------------------------------------------------* Bool GMPThread::SquareToQuad(Real quad[4][2], Matrix2D* SQ) //*---------------------------------------------------------------------------* { Real x0 = quad[0][0]; Real x1 = quad[1][0]; Real x2 = quad[2][0]; Real x3 = quad[3][0]; Real y0 = quad[0][1]; Real y1 = quad[1][1]; Real y2 = quad[2][1]; Real y3 = quad[3][1]; Real dx3 = x0 - x1 + x2 - x3; Real dy3 = y0 - y1 + y2 - y3; // afine transform if (!dx3 && !dy3) { SQ->m0 = x1-x0; SQ->m1 = y1-y0; SQ->m3 = 0.0f; SQ->m4 = x2-x1; SQ->m5 = y2-y1; SQ->m7 = 0.0f; SQ->m12 = x0; SQ->m13 = y0; SQ->m15 = 1.0f; } // projective transform else { Real dx1 = x1 - x2; Real dx2 = x3 - x2; Real dy1 = y1 - y2; Real dy2 = y3 - y2; // determinants Real gtop = dx3 * dy2 - dx2 * dy3; Real htop = dx1 * dy3 - dx3 * dy1; Real bottom = dx1 * dy2 - dx2 * dy1; if (!bottom) return FALSE; bottom = 1.0f / bottom; Real g = gtop*bottom; Real h = htop*bottom; Real a = x1 - x0 + g * x1; Real b = x3 - x0 + h * x3; Real d = y1 - y0 + g * y1; Real e = y3 - y0 + h * y3; SQ->m0 = a; SQ->m1 = d; SQ->m3 = g; SQ->m4 = b; SQ->m5 = e; SQ->m7 = h; SQ->m12 = x0; SQ->m13 = y0; SQ->m15 = 1.0f; } return TRUE; } // Calculate matrix for quad to unit-square mapping // - vertices - square->quad transform //*---------------------------------------------------------------------------* void GMPThread::QuadToSquare(Real quad[4][2], Matrix2D* SQ) //*---------------------------------------------------------------------------* { if (!SquareToQuad(quad, SQ)) return; // invert through adjoint Real a = SQ->m0, d = SQ->m1, g = SQ->m3; Real b = SQ->m4, e = SQ->m5, h = SQ->m7; Real c = SQ->m12, f = SQ->m13; Real A = e - f * h; Real B = c * h - b; Real C = b * f - c * e; Real D = f * g - d; Real E = a - c * g; Real F = c * d - a * f; Real G = d * h - e * g; Real H = b * g - a * h; Real I = a * e - b * d; // Probably unnecessary since 'I' is also scaled by the determinant, // and 'I' scales the homogeneous coordinate, which, in turn, // scales the X,Y coordinates. // Determinant = a * (e - f * h) + b * (f * g - d) + c * (d * h - e * g); Real idet = 1.0f / (a * A + b * D + c * G); SQ->m0 = A*idet; SQ->m1 = D*idet; SQ->m3 = G*idet; SQ->m4 = B*idet; SQ->m5 = E*idet; SQ->m7 = H*idet; SQ->m12 = C*idet; SQ->m13 = F*idet; SQ->m15 = I*idet; }</code> The 2D matrix is about as simple as you can get and, yes, I've been lazy and just retained the pseudo-indices of the matrix elements from those that were removed because they have no impact.
  3. Already found a solution. Homography transforms was the correct direction - then on to collineation matrices and warps. Yes, this is a 2D problem. And code exists everywhere - if you only know what the heck you're trying to find! It shows up a lot in scanner/projector/image correction and manipulation sources. This link code works absolutely perfectly (even on triangles!!! - if you treat it as a quad with two identical points - which is what I actually want to do). http://code.google.com/p/wiimotetuio/source/browse/trunk/WiimoteTUIO/Warper.cs The projective transform (or affine in limited cases) was only one part of the puzzle. To do this correctly every time, it needs to be a properly inverted matrix from unit-square to quad that then does quad to unit-square (through the inversion). And the matrix multiplication of the points was not a simple transform matrix operation (as this isn't a transform matrix and 'w' is not always (0,0,1)). Once I understood the process and stopped evaluating the crappy incorrect code out there, proper code was found.
  4. Quote:Original post by Dave Eberly The perspective mapping between two *convex* quadrilaterals is described in this 1-page document: Perspective Mapping. How would this relate to matrix transformation? As I stated, this must go both ways with an inversion of the quad-to-unitsquare after some processing. Thanks!
  5. Quote:Original post by Emergent Can't always be done. Not all quads can be transformed by an affine transformation to a unit square. In fact, only parallelograms can... Of course, here I'm assuming you want to map a 2d quad to a 2d square. Do you actually want to infer perspective or something? Then you have more degrees of freedom... You assume correctly. :) A 3D quadrangle polygon has been transformed to the world center and 'placed' on the X-Z plane so that its y-values are 0.0f (essentially a 2D quadrangle). Now I want to matrix transform it to a unit square (on the same plane) for operations on geometry being placed on its surface (the geometry would be inverse transformed to fit the original quadrangle after the operations). I expect the polygon to be planar and convex (from polygonization by the supporting application). Code from Qt (QTransform::quadToSquare) is the type of transformation I think that I'm seeking but I cannot make it work (for hours!). It is using a 2D transform whereas I am limited to 3D transform matrices with an assumed (0,0,0,1) homogeneous vector. Their projective transform looks to be setting the homogeneous vector to (g, h, 1). I'm in the process of testing a self-made 2D transform using this code but am still a bit wary of the results. Thanks!
  6. Fo some reason I cannot find any maths for this. It could be a projective transform or a UV mapping type transform but I know that what is required here is a transformation matrix since the mapping must go both ways (inverse as well). For any arbitrary planar quadrangle, how do you map it into a unit square with a transformation matrix? Thanks!
  7. Already 'seriously Googled'. Started with '3D lipsync algorithm' and went from there. I've also already gathered all of those papers. :) I find that interesting on a game development site. Lip-sync is widely used in gaming (Half-Life 2 etc.), some gaming boxes have custom lip-sync parts to their APIs, MS SAPI is mentioned quite frequently (but mine will need to be Windows and MacOS so that's out), and it is used extensively in 3D CG movies/animations (when not using facial motion capture specifically). You are correct; it is complicated technology. Thus the reason to seek as much information as possible. But before I go about 'purchasing' every paper out there that is remotely related to this subject, it'd be better to narrow it down just a bit (having been an IEEE/ACM member, I know the numbers of papers on any given topic - they could number in the hundreds or thousands!). Thanks,
  8. I am doing research for implementing a high-quality lip-sync plugin in a 3D CG application for animation with audio (thus, not posting in the Game forums). So far, the APIs/SDKs encountered have been monetarily prohibitive for a single developer like myself and in these times (see Annosoft for $9500/year as a prime example). If there is one that is less costly supporting Windows and Mac in C++ for much less, links would be appreciated (haven't found one yet). Foregoing that if I must, then it'll be time to implement one myself. My background isn't strictly as a CG programmer and have no formal schooling, so it wasn't something that came up in my past (which would have been long before it was normal course material). This will be a cold start in developing a 3D lip-sync system. I'm looking for beefy information on quality lip-sync algorithms - not 'Joe's quick and dirty method'. My IEEE and ACM memberships/subscriptions have lapsed (again, thanks to the ever optimistic financial situation of late) so those resources have been barred except individual purchase of papers where possible. One book that is being considered is "Graphics Programming Methods" by Jeff Lander (who has a tutorial on lip-sync here iirc). "Stop Staring" by Jason Osipa is also under consideration but I haven't been able to determine if this is a programmers book or a users book yet (leaning towards 'users'). Basically, as part of the research stage, I am trying to gather as much useful, quality information as possible in various forms (papers, books, code, websites, etc.). It is a very complex field and the term 'lip-sync' intersects with many other non-related fields (lip-sync on DVDs/TVs, in other media formats, cartooning, and so on). Please, could anyone with previous experience please provide golden nuggets of where to find the best information? Thanks
  9. Unfortunately, the Vector class and its operators aren't mine - they are part of an existing SDK. What I found is that swapping v1 and v2 in the cross product (i.e.: v2%v1) removed an anomaly with creating the normal (you can do the math quickly to see what happens if the orthonormal vector is first). Very odd that. Subsequently, they were swapped in the VectorAngle() call. The swaps fixed the problems. Maybe it is a difference in the method/operator coding that requires this (?). Yes, I had previously tried the length*axis approach for the atan2() angle calculation. It may work now that this anomaly has been circumvented. Thank you very much, Robert
  10. I'm having a ball trying to get this to work. Here are the givens: There is a bone object which points down the +Z AXIS and is at the origin. I have a vector which describes where the bone should be pointing (relative to the origin). The obvious way to rotate the bone is to get the angle between two vectors. The one vector would be (0,0,1) for the bone and the other vector as given. Then I need to get the axis through which to rotate by angle. This would be the normal to the plane in which the two vectors lie. The code, as best I can find, is: Vector v1 = Vector(0.0f,0.0f,1.0f); Vector v2 = !epBB; // '!' normalizes vector operator Vector axis = v1%v2; // '%' is cross product operator Real angle = VectorAngle(v1, v2); // Angle between two vectors // Signed 3D angle between two vectors: atan2(dot(normal,cross(v1,v2)), dot(v1,v2)) Matrix bm; if (Abs(angle) < 0.00001f) bm = MatrixScale(Vector(epBBlen)); else bm = RotAxisToMatrix(!axis, angle) * MatrixScale(Vector(epBBlen)); This is failing in both angle AND axis. First, the cross product with an orthonormal vector is the same vector as the other with the one axis (1.0f) zeroed. So, v1 x v2 = (v2.x, v2.y, 0). That is useless - it isn't perpendicular to the plane containing them. What the f...? Maybe someone could illuminate how to go about doing this correctly? Thanks, Robert
  11. No. A matrix encodes a series of transformation operations, mainly scaling, rotation, and translation - sometimes reflection, shear, and other transformations are included. Think of it this way. You have a camera 'object'. If it isn't parented to anything, before you apply any transformations, it should be assumed that the camera origin is the same as the world system's origin (0,0,0), that lack of rotation (0d,0d,0d), say, has the lens face down the +Z axis (or whichever you decide), and that is has no scaling (1,1,1). The matrix that retains this untransformed camera is an identity matrix: 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 Okay. Now you want to have it moved and rotated (but not necessarily in that order). First, the basic order of a singular set of transformations (left to right) is Scales*Rotations*Translations (S*R*T). This isn't strict but is a good guide. Note that scaling and rotation occur while the camera is still at the world system's origin - where the camera origin is (0,0,0). In other words, at some point the camera must have a coordinate system and before any transformations it is usually coincident with the world system. If parented to another object, then the parent's coordinate system would be the initial one as reference. Either way, one normally wants to scale and rotate an object about its own center. This is exactly why scaling and rotation happen BEFORE translation. Translation moves the object with respect to ITS referential coordinate system. If you move the object and then rotate it, it is still being rotated from the origin - of the coordinate system, not the object's center. As already mentioned several times, the translation vector in a matrix is not the same as its position. You really shouldn't be applying a transformation matrix as a rotation-scale matrix and a position vector. Concatenate your transform operations in order and multiply the camera object's points or vectors by the resulting matrix.
  12. Solved! :) First, the rotation order is indeed YXZ (yes!). Second, the input matrix is in right-handed, row-major format (see "3D Computer Graphics" by Alan Watts (pp. 4 & 5)). Most other sources use a column-major format so the rotation extraction routines (Eberly) needed to consider the transposition of matrix elements. Third, instead of negating the z rotation, obviously :sarcasm: you have to negate the x and y rotations. Finally, the matrix determinant is then needed to negate these in the opposite direction (a positive determinant, multiply by -1, a negative determinant, multiply by 1). I'm going to take a nap now! ;) See. Sometimes a similarity matrix or simple reflection matrix will NOT suffice to convert a matrix in one handed system to the other. The similarity matrix may suffice if the determinant is also applied (hmm) but the matrix decomposition with the fiddly bits allows confirmable value comparisons and more direct control of the conversion. You guys need to get your heads out of OpenGL and DirectX more often. There is a world of maddeningly subtle pain that awaits you.
  13. I multiplied the input matrix with the identity matrix (with the one value negated as shown) trying both pre- and post-multiplication. Not doing it. This is pretty much the last-try idea that I had - apply a matrix with a negative z-scale to flip the axes. I might try a negative x-scale to see the results - but am not holding breath. All of these methods work here and there - but don't work on every case. So there is definitely something missing in the equation. Transposing the input matrix and applying a similarity matrix covered more cases - but still not all. And I think that this is because it flips all of the rotations. This won't work here. The only rotation needing flipping is the z-axis rotation. Unfortunately, there is no possibility of rectifying these matrices before input into the target application. Thanks for you input so far, yosh64! As can be seen by the stampede of assistance otherwise, nope, no brave mathematicians around (yes, I'm prodding). If I said "OpenGL to DirectX" there'd be fifty links and definite methods. Sorry, this isn't what I'm working with. The source application has its ways (which cannot be changed) and the target application has its ways - and its SDK doesn't consider things like right-to-left handed matrix conversion. Definitely not as deep and wide of breadth as these more generic graphics interfaces.