• 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

1110 Excellent

About raigan

  • Rank
  1. Thanks raigan, I tried something like below: FindCollisionParticles();  // if found one, then mark this particle isActive = false; which makes it also not movable by its physical update or constraints.  for (num_iterations) {     SolveDistanceConstraints(); } // at the end of the update RecoverDeactivatedParticles();    // Reactive particles that are marked deactive in FindCollisionParticles();   Somehow this doesn't work for me.     Sorry, maybe I didn't explain very well: you need to handle collision *just like a constraint*, i.e you need to solve both collisions and other constraints together in the loop, otherwise the solver won't converge nicely. Something like: for (num_iterations) {     SolveDistanceConstraints();     SolveCollisionConstraints(); } This way the constraint forces can "talk" to each other and find a mutually acceptable equilibrium state. Of course: what does SolveCollisionConstraints() look like? There are many ways of implementing this; the un-optimized version is to run a full broad+narrow phase collision in here, but that gets slow. Instead you can cache the pairs returned by the broadphase before solving, and re-run narrow phase (i.e calculate the vert-face or edge-edge penetration depth and project out of collision if the two features are penetrating). JoeJ's approach also works, AFAICT it's Jacobi iterations instead of Gauss-Seidel -- see the paper "Mass Splitting for Jitter-Free Parallel Rigid Body Simulation" for more info: IIRC you shouldn't be scaling by some arbitrary number but instead averaging all particle displacements based on relative mass. The paper has more details. The downside to Jacobi is that it converges more slowly.
  2. This isn't as complicated a problem as you think -- you just need to remember that collision constraints are a type of constraint, and solve them *together* with the distance constraints in your solving loop. eg something like: for(num_solver_iterations) { SolveDistanceConstraints(); SolveCollisionConstraints(); } Of course, this moves collision detection to inside your solver loop, which is bad for performance. Typically people cache the broadphase and update the narrow phase, i.e your collision data knows the face+vertex that are colliding, and when solving the collision constraint you first check if collision is happening (which you have to do anyway to calculate the error term) and if not you skip solving it this iteration. I hope this makes sense! 
  3.   AFAICT this still requires some idea of a "rest pose"/starting configuration (the a_i unit vectors in the stackexchange reply). (Thanks so much btw, I hadn't realized there were approaches to this besides Muller's! Very interesting.) The OP wanted to know if there are any approaches that *don't* require some sort of initial state/rest pose.
  4.   I'm not an expert but I don't think that your conclusion necessarily follows. It just doesn't make sense to me: particles only have a defined position, not an orientation. You can aggregate their positions to get a COM, which helps you define all the other properties you listed (eg angular momentum doesn't make sense for a particle in isolation, but does relative to the COM), but AFAICT the COM doesn't help define an orientation. I'm struggling to see how you could define orientation without some sort of frame of reference similar to that provided by a rest pose.
  5.   I am using this method to analyze and control deformable soft bodies in a physics engine. When creating an object of a particular, well defined shape, like for instance a truss or girder with the orientation vector pointing along the length of the body, I can see on screen how the orientation (visualized by a point and a line) drifts away from the physical shape. This happens slowly by simply adding angular velocity and letting it rotate unconstrained by external forces. When influencing it through collision or by constraining it to other bodies, the orientation quickly drifts away from the correct value.   This seems like the exact use-case for shape matching -- i.e you start with a particular arrangement of particles. Why exactly do you want to avoid having to define a "rest pose"?
  6. This seems related to "shape matching"; this recent paper should have lots of useful references (and itself presents a method to extract rotation from a point cloud): http://matthias-mueller-fischer.ch/publications/stablePolarDecomp.pdf Note that AFAICT you'll need some sort of "rest pose" defined for the points or the concept of orientation doesn't make a lot of sense.
  7. Awesome! I'm glad that works :)   Thanks for letting me know about those details -- I wonder if it's an error in the paper or what.   Do normalized constraints offer any benefits? I've never come across them before.
  8. I'm a bit rusty but IIRC in PBD gradC is a vector, which means gradC(xi - x^n) might be a dot product, projecting the approximate velocity (xi - x^n) onto the constraint gradient gradC.   This is just a guess! Please let me know if you work it out, because I'd like to try implementing this too. :)
  9. hey -- no worries, it's a hard problem!   One thing that might have slipped under your radar is the physics-based locomotion R&D that Cryptic Sea are doing (in conjunction with their games Sub Rosa and A New Zero): https://twitter.com/crypticsea/status/796871092438605824
  10. awesome!    One thing I thought of, have you read any of Michiel van de Panne's papers? He does a lot of research into control of physics-driven characters:  https://www.cs.ubc.ca/~van/papers/Simbicon.htm https://www.cs.ubc.ca/~van/papers/2010-TOG-gbwc/index.html https://www.cs.ubc.ca/~van/papers/2013-TOG-MuscleBasedBipeds/index.html http://www.cs.mcgill.ca/~kry/pubs/abc/index.html https://www.cs.ubc.ca/~van/papers/2015-CGF-multiskilled/index.html
  11. Bullet forums maybe? (they're mostly dead lately though): http://bulletphysics.org/Bullet/phpBB3/viewforum.php?f=4   I really like this project/idea :)
  12. This is definitely something that has been presented in siggraph papers and some GDC lectures IIRC.   Here's a presentation that might be of interest: https://www.cs.princeton.edu/~prc/ChucKU/PerryCookPhysicalModelingGameSoundCon2014.pdf
  13. Here are my notes for two types of embedding: a V (single point) and C (two points).   In both cases you have two positions p0 and p1, and want to find the local coordinates r = (d,e) of the embedded point (which is a function of p0 and p1).   Note that d,e are local coordinates, based on p0p1 (i.e the d axis is local x, parallel to p0p1; the e axis is local y, perpendicular to p0p1; p0 is the origin). So the final worldspace position of the embedded point p = p0 + d*u + e*v where u = (p1 - p0)/||p1-p0|| and v = (-u.y,u.x)     2LinkV is the classic 2-link analytical IK formula (see http://mrl.nyu.edu/~perlin/gdc/ik/ ) a is the length of first link b is the length of second link a/\b p0 p1 c = |p1-p0| we want to find objspace knee position d,e the 2-link leg forms two right-triangles, which gives us: (1) a^2 = d^2 + e^2 (2) b^2 = (c-d)^2 + e^2 //c = d + (c-d) = c, i.e d is some point along the x axis (0 < d < c) then: (3) e^2 = a^2 - d^2 //rearrange (1) (4) b^2 = c^2 - 2cd + d^2 + e^2 //expand (2) (5) b^2 = c^2 - 2cd + d^2 + a^2 - d^2 = c^2 - 2cd + a^2 //substitute (3) into (4) so: (6) d = (c^2 + a^2 - b^2)/2c //rearrange (5) (7) e = sqrt(a^2 - d^2) //rearrange (1) 3LinkC is the first knee point in a 3-link "C" shape -we only need to figure out the formula for one of the knees; if the first knee is embedded in p0p1, the second knee is just the same but embedded in p1p0 C-shape: both knees on same side a is the length of first/last link b is the length of middle link _b_ a/ \a p0 p1 c = |p1-p0| we want to find objspace knee position d,e we know: (1) a^2 = d^2 + e^2 //the first link forms a right-triangle (2) c = 2*d + b //the middle link is parallel to the leg axis; the size of all links projected onto the leg axis = leg vector length = c so: (3) d = (c-b)/2 //rearrange (2) (4) e = sqrt(a^2 - d^2) //rearrange (1) Hopefully this helps give you some ideas! The main thing is to describe the embedded points as a function of the two endpoints (+ some additional constant data, eg link lengths)
  14. I have done something like this (in 2d only): https://www.youtube.com/watch?v=YHVyg2rDBy4 (only the endpoints are simulated, the other points are dependent on endpoint positions)   All you need to do is to be able to express the grey points as functions of the endpoints. This is what we based it on: http://mrl.nyu.edu/~perlin/gdc/ik/   Sorry.. work is very busy or I would help more!
  15. @Blackperl: I don't know if there's a single simple approach as with point-vs-infinite-line, but I've implemented "moving point vs moving capsule" by performing 4 sweep tests:   2x circle-vs-circle (for the query point vs the moving capsule's endpoints) 2x circle-vs-infinite-line* (for the query point vs the two sides/faces of the segment)   (*: you need a slight modification for these queries: when you find t (just like cadjunkie showed), check if the collision point at that time is on the segment at that time; if not, it doesn't count as a collision.)   Each of these 4 tests reports their earliest t, and the min() of those 4 t values is the time of intersection for point-vs-capsule.   If there's a simple "analytical"/direct way to solve this, I'd love to know   I have a feeling I don't need to do 2x point-vs-line, and instead I could solve for the times when the distance is r (instead of solving for when it's 0).. but I haven't thought enough about it yet.