• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

334 Neutral

About PrestoChung

  • Rank
  1. So I have implemented a sequential impulses collision/contact solver including the contact manifold generation (up to 4 points for a pair of objects) in the 3-dimensional case. Now, do I *need* a contact graph to solve for "stacking" groups of objects? Or can I just add more points to the solver without regard to where they are relative to some "root" object, i.e. just use a "flat" list of contacts. For example if there were 3 objects and two contacts between them, that would be up to 8 contact points to solve for in the iterative solver. To help converge faster, I am aware of "warm-starting" which is basically caching the impulses over frames for persistent contacts (of course there are issues with "identifying" contact points when the manifolds are changing). Is this all I need to worry about? No contact graph necessary?
  2. That is the presentation I have mainly been working from. Part of the confusion might come from trying to apply the conditions to colliding contacts. The 3rd condition:   vrel_i = 0   or  \lambda = 0   seems different for collisions:   if you have a colliding contact point with a negative relative velocity of magnitude -1.0 in the normal direction, you want to drive the velocity to a positive value scaled by some restitution factor, say, 0.5: -1.0 -> 0.5   so you want to apply an impulse that changes the velocity in the normal direction +1.5. so the impulse \lambda is positive (non-zero), and the target velocity is positive (non-zero).   for the second point, say it is initially separating with velocity +0.7, by the signiori conditions because the velocity is positive, \lambda has to be zero (no impulse at separating contacts), at least for the 1st iteration.   but applying the impulse to the first point results in the second point having a negative velocity, say -0.3. if this was a resting contact, i would assume that we need to apply a positive impulse \lambda now that changes that -0.3 velocity to 0.0 velocity, fine. but this is a colliding contact, should the target velocity for the second point be a positive velocity determined by the restitution factor? 0.3  * 0.5 = +0.15, should it be 0.0 since the point was already "in contact" there's no distance to accelerate to -0.3 so this velocity is more or less virtual? or should the target be the original separating velocity +0.7? either way a positive \lambda is chosen, i *think* the answer is the target should be 0.0 for this second point since it was already in contact when the first point caused a collision in the first place.
  3. Right, but my question is what should the target velocity be for the second point after the accumulated impulse is applied? It was separating before the impulse for the first point was applied, now it is negative (closing). I want to find an impulse for the second point that either: makes the relative velocity 0.0? or returns it to the positive separating velocity it had at the time of impact?   After the impulse for the second point is found the the solver will loop back around to the first point and repeat the process.
  4. I'm using sequential impulses to drive the velocities of contact points to their targets:   - for collisions that means the target is the restitution velocity (separating) - for resting contacts it's 0.0 (the objects were already in contact so there was no distance to accelerate over so the target should remain zero)   How are targets chosen for other points that are *initially separating* but whose velocities become *closing* velocities as a result of handling the other contact points in the contact manifold?   If the same reasoning for resting contacts are applied, then there is no distance over which to accelerate so the restitution should not be some positive rebound velocity, so that leaves only two real choices of targets that I can see: either 0.0 or the *original* separating velocity. I'm guessing 0.0 but I don't have a real reason for it other than that's the way contacts work, but is the answer the same for both collisions and contacts?
  5. i use "asynchronous" in two senses:   1. the input thread is waiting on events (SDL_WaitEvent) instead of pumping at a fixed frequency 2. the input thread sends commands to the renderer via an asynchronous channel (since I"m using OpenGL i guess this is kind of like simulating multi-threaded rendering via command buffers)   #2. ensure that when the renderer is waiting on VSync, input processing still happens. #1. maybe isn't necessary if events received from SDL are already properly timestamped
  6. I'm currently using SDL contrary to specification and collecting events "asynchronously" on the main thread and rendering with OpenGL (vsync) in another thread. It seems to work fine. It may be internally that SDL is still blocking input collection on vsync, but it allows me to decouple input from rendering at least code-wise. Assuming input really is asynchronous, are SDL timestamps good enough to be used in a case such as this?:   http://www.gamedev.net/page/resources/_/technical/general-programming/asynchronous-keyboard-input-for-fixed-time-step-games-r3959   or should I be doing my own time-stamping?
  7. if you have line triangle you can get line prism by testing the line against each of the 8 triangles making up the prism (1 for each end, 2 for each side)
  8. Thanks for the pointers, I was going to modify my post to mention that I do use GJK already for distance and penetration calculation, but it does things pretty minimally so it usually returns a point/face as nearest features in a resting scenario.
  9. So it turned out I was looking at the Catto "Iterative Dynamics" paper, which is a bit more advanced than this scenario, and actually what I had been using before was Catto's GDC2006 powerpoint, which I had previously compared to Bender and Schmitt and found to be essentially the same, although Catto goes into picking points on boxes and some other tricks such as a 'bias' velocity.   Then I would say it's time to add more contact points, but I have general meshes, not only boxes. Does anyone have any pointers for finding contact points on a general surface? I'm guessing the brute force approach is just searching along the surface normal and comparing dot products.
  10.   That is the tangent used for collision response, the tangent for contacts is described on page 6.
  11. I have an impulse-based position constraint for contacts along the lines of this paper by Bender & Schmitt.   I'm reaching a case where the loop doesn't converge for the tangent (after being stable for about 20 seconds or 700 frames). The normal reaches target after about 4 iterations, but the tangent will only get so close before getting pushed further away. Continuing to run the loop, the normal will begin to oscillate over a negative and positive range, centered on zero, and the tangent will oscillate in some positive range but never reach the target.   In the paper, the tangent unit vector `t` is calculated by dropping the distance vector `d` between the contact points at the end of the timestep, onto the plane of the contact normal unit vector `n` at the end of the timestep: `t = normalize (d - n*dot(d,n))`. I noticed in Catto that he uses 2 tangent unit vectors, though that paper he is calculating a velocity constraint, not a position constraint. But with the tangent calculated above, the 2nd tangent given by `cross (n,t)` is going to have a distance of 0.0 so no impulse will be applied in that direction.   Possibilities:   1) calculate tangents based on relative velocities instead of distances 2) switch to a velocity constraints 3) add more points to the contact and solve pairs iteratively (currently it's only one pair of contact points)
  12. Oops, actually the target range was 0.0001 (edited the original post to fix this) which is 1/10 of the collision tolerance (0.001). Seems I can get away with 0.0004 (7 iterations) but after that it starts going up rather quickly (0.0003 -> 28 iterations, 0.0002 -> 70+ iterations). Hopefully that will be stable enough for stacking.
  13. I implemented an iterative constraint solver using impulses as described in Bender & Schmitt 2006:   http://www.researchgate.net/publication/228934234_Constraint-based_collision_and_contact_handling_using_impulses   Solving for the normal (penetration) constraint or the tangent constraint in isolation converges as expected, about 4-5 iterations before the penetration or tangent position is within the 'target' range (<0.0001). But running both constraints simultaneously causes 150+ iterations before they are both within target which sounds like too much for a single constraint, but maybe it is expected for a tight constraint?
  14. I have been heading the way of systems of linear equations for multiple simultaneous collisions/contacts, usually though in the sources I've looked at they don't mention doing so for a single collision point (or I'm not reading closely enough). Thanks for the pointer.
  15. So I have separate equations that reliably give the normal collision impulse and the tangent friction impulse.   But one affects the other. Say I apply the normal impulse first, the separating velocity is now correct. Now I apply a tangential friction impulse. Now the separating velocity is more or less than the 'target' separating velocity. Maybe that's not a problem, but what if it becomes negative again? Do you loop around and re-calculate a new normal and tangent impulse, or leave it as is?