coderchris

Members
  • Content count

    300
  • Joined

  • Last visited

Community Reputation

304 Neutral

About coderchris

  • Rank
    Member

Personal Information

  1. When contact resolution fails

    As an absolute last resort, you could look into using "rigid impact zones". It was originally devised for cloth simulation, but in my experience it works surprisingly well for complex rigid body collision scenarios. It will not resolve overlap that existed at the beginning of the time step, but it can guarantee that no new overlap will exist by the end of the step. The basic idea is to take a group of colliding bodies for which normal collision resolution failed to find a solution for, and treat that group as a single rigid body. This is done by computing, for that group, an average linear and angular velocity, then applying that to all objects in the group. This should all be done as the very last step in your solver. The method is detailed here (section 7.5): http://physbam.stanford.edu/~fedkiw/papers/stanford2002-01.pdf
  2. Ah interesting, hadn't seen those slides. In the slides they reference this paper (https://www.cs.ubc.ca/~rbridson/docs/english-siggraph08-cloth.pdf) which talks about performing an explicit velocity correction to counteract the effect. I'm guessing this correction would have to go after the velocity is computed. I will experiment with it some.
  3. Hello, In reference to position based dynamics survey section 4.2.5: http://matthias-mueller-fischer.ch/talks/2017-EG-CourseNotes.pdf The second order integration method they derive works very well for conserving energy. The original PBD integration loses a lot of energy, and it is especially apparent during rotation of groups of constrained particles. With the second order method, it looks almost perfect. However, I'm seeing bouncing and generally inconsistent reactions when this method is paired with any inequality constraints, but most importantly, collisions. They mention that no changes are required to the inner solve loop, but it seems as though inequality constraints will have to be treated specially for this type of integration to work. I don't understand the math enough to know how or why it isn't working. Does anyone know how to treat inequality constraints (collisions) properly with second order integration in position based dynamics? My current attempt to fix it is to change collisions to equality constraints, and essentially pull the colliding object back towards the collision point (like a distance constraint). This works and no longer bounces. However, now the problem is how to determine when to destroy the constraint... Thanks! -Chris
  4. Nah I dont think normalized constraints are any better from what I've seen.    I was playing with the normalized distance constraint because in his other paper (strain based dynamics), all the constraints are normalized.   That said, I ran into an issue getting the damping to work with strain based constraints - the damping was basically having little to no effect. This was due to those constraints being normalized. Turns out that the damping mechanism as described only works when the constraints are not normalized, so I'm having to unnormalize / scale the strain based constraints for damping to work on them.   I haven't figured out the exactly correct scaling though. Still trying to wrap my head around the math  :blink:
  5. I think you are correct, that seems to work nicely! Thanks for the input.   Everything seems to behave as described in the paper, definitely an improvement over regular PBD.   The stiffness parameter is a bit tricky though, for two reasons.   By their definition (if I'm interpreting correctly), alpha = 1 / stiffness. I found this to not completely solve a constraint in one step when stiffness = 1. So, I use a slightly modified version: alpha = (1 / stiffness) - 1. This will give alpha = 0 when stiffness is 1, which will fully solve a constraint in one step.   The second thing about the stiffness is that, although the valid range is [0, 1], how stiff it makes the constraint is highly dependent on the constraint's scaling. For example, with the usual distance constraint C(a,b) = |a - b| - restLength, with a stiffness of 0.5 and a timestep of 1, the constraint will be reasonably stiff using XPBD. However, using the normalized version C(a,b) = (|a - b| / restLength) - 1, will apply almost zero correction, so you need a much higher stiffness value to achieve the same effect.   Intuitively, this is due to the alpha in the denominator of the delta lambda "overpowering" the constraint. This is not a huge issue, since you can simply scale the stiffness value based on your choice of constraint function.
  6. The paper in question is XPBD (http://mmacklin.com/xpbd.pdf)   Equation (26) in the paper relates to adding damping to the constraint.   It contains a term that I do not understand how to evaluate - the grad C(xi - x^n) in the numerator.   For example, with a distance constraint we have grad C(a, b) = (a - b) / |a - b| This takes two positions, and is itself a vector function, but the equation in question (26) evaluates to a scalar.   What might they mean by this term as it relates to a distance constraint? 
  7. Cubic interpolation over a triangular surface

    This guy gives a good explanation for solving the system in 1D:   http://www.paulinternet.nl/?page=bicubic   Which all makes sense to me. I would like to apply this to my case, but I'm not sure what my system of equations actually is...
  8. stable constraint solver with no warmstarting

      In PBD (position based dynamics), we essentially move the predicted positions of each particle / object / fluid / whatever directly in order to solve any constraint (including friction).   [attachment=27691:PBD.png]   Pardon the crude drawing and probably poor explanation -    Consider this example of a static edge and a moving particle that collides with that edge. The black square is the initial position and the red square is its unconstrained predicted position. Predicted position = current position + current velocity * dt   To solve this collision constraint without friction, we project the predicted (red) position onto the edge which results in the (purple) point. We simply set our predicted position to this purple point - thats the constraint solve.   To add friction, we can compute the (blue) intersection point between the edge and the particles trajectory. We then compute a modified (green) position that is some amount between the (blue) intersection point and the (purple) projected point, based on how much friction we want. For example, for 100% friction we would set the predicted position to be at the blue point directly.   I guess it's not the most accurate way to model friction, but I did it this way because it let me have a normalized friction parameter [0, 1]   I have not implemented motors, but in the PBD framework you do have a velocity to play with, so I'm fairly sure it could be done without too much hassle.
  9. stable constraint solver with no warmstarting

    Maybe have a look into position based dynamics. It is most famously used for the cloth simulation in PhysX, but I have had success using the same framework for rigid body simulation. It requires no warmstarting and is very stable even with few iterations. You dont technically need to cache contacts at all. In my implementation I do cache contacts, but only to make handling static friction easier.   Here's the excellent paper describing the cloth simulation: http://matthias-mueller-fischer.ch/publications/posBasedDyn.pdf   And here's one describing it for rigid bodies (I have not read this one yet): http://www.interactive-graphics.de/index.php/research/55-position-based-rigid-body-dynamics-all
  10. I'm struggling to understand cubic interpolation over a triangle.   I am aware of and mostly understand bezier triangles:     Using this I can get an estimate of the function over the triangle given 10 control points and some barycentric coordinates (s, t, u).   However, this function does not go through all of the control points - it appears to only go through the 3 corner control points of the triangle.   I'm looking for an interpolation scheme that uses the same control point layout as a bezier triangle, but that goes through ALL of the control points.   What should I be searching for? Does this type of thing even exist?  
  11. Ah thanks, that saves having to add the extra attribute at least
  12. I thought of one possible solution, though I'm not sure if it is actually possible for a general mesh. Flat interpolation uses the attribute from the so called provoking vertex. If you could reorder your indices the right way, you could at least keep using indexed triangles. It would still use an extra vertex attribute. I think this would definitely work for meshes where each vertex had at most 3 triangles using it but I'm not sure about cases with more.
  13. So OpenGL 4 has gl_PrimitiveID available as an input to fragment shaders.   GL ES 3 does not (presumably due to not having geometry shaders).   One way I could emulate it is to convert my indexed triangle list into a non-indexed list, add a vertex attribute that is the triangle ID, and use flat interpolation on that attribute. The problem is that this will make drawing things much slower due to all the extra memory and bandwidth being used.   Does anyone have a better idea of how I might emulate gl_PrimiveID in the fragment shader under GL ES 3?
  14. Cool thanks, I'll keep looking in to it. Maybe I can create "ghost" vertices to make it look like a bezier triangle...    I found this: http://en.wikipedia.org/wiki/Polyharmonic_spline Which appears to be able to interpolate arbitrary point clouds. However, it is unclear to me if it is continuous in the sense that for a given point, if I choose say the 10 nearest vertices on my mesh, will that interpolate smoothly with a different point that has chosen a different set of 10 nearest vertices...    I suppose if I solved for ALL the vertices at once, then it would definitely be continuous across my entire mesh. My mesh will be changing alot though, so doing a large linear solve every time it changes probably wouldn't fit my computational budget.
  15. I have a triangle mesh. At each vertex of the mesh I have a color. For a given triangle in the mesh with vertex colors (a, b, c), and a point in that triangle with some barycentric coordinates (u, v, w), I can compute a linearly interpolated color as   color = a * u + b * v + c * w   This is fine, but I want a smoother interpolation. Given that I have all the adjacency information for the triangle mesh, is it possible to do some type of cubic interpolation? For a regular grid, the solution is documented: http://en.wikipedia.org/wiki/Bicubic_interpolation   However, I can't seem to find any information on doing it on a mesh. Is cubic interpolation even applicable here? If not, is there another type of interpolation which would give smoother results than linear interpolation?   Just to give a little more context, here is an example of the type of mesh I'm working with:   [attachment=26547:mesh.png]